Bug 35602
Summary: | Oops on resume enabling CPU1, setup_disablecpuid | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | Jukka Ollila (jiiksteri) |
Component: | x86-64 | Assignee: | platform_x86_64 (platform_x86_64) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | fenghua.yu, florian, maciej.rutecki, parag.lkml, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.39 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 7216, 32012 |
Description
Jukka Ollila
2011-05-22 13:23:54 UTC
Well, this is not reproducible on my Acer Ferrari One, so please bisect if you can. Duh, turns out the broken tree is not exactly 2.6.39 but some random upstream tree after that :( Bisect result is below, but since this is nothing that's exactly released, should this report just be closed and reopened if it appears in something that actually resembles a release, like .40-rc1? Bisect result: de5397ad5b9ad22e2401c4dacdf1bb3b19c05679 is the first bad commit commit de5397ad5b9ad22e2401c4dacdf1bb3b19c05679 Author: Fenghua Yu <fenghua.yu@intel.com> Date: Wed May 11 16:51:05 2011 -0700 x86, cpu: Enable/disable Supervisor Mode Execution Protection Enable/disable newly documented SMEP (Supervisor Mode Execution Protection) CPU feature in kernel. CR4.SMEP (bit 20) is 0 at power-on. If the feature is supported by CPU (X86_FEATURE_SMEP), enable SMEP by setting CR4.SMEP. New kernel option nosmep disables the feature even if the feature is supported by CPU. [ hpa: moved the call to setup_smep() until after the vendor-specific initialization; that ensures that CPUID features are unmasked. We will still run it before we have userspace (never mind uncontrolled userspace). ] Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> LKML-Reference: <1305157865-31727-1-git-send-email-fenghua.yu@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> :040000 040000 d8ad18a82278c0f4cea62fd4f98617aeb6da4799 b53858c394d5de9f8d2fdc799bb3061b34d0d7d7 M Documentation :040000 040000 fac275c02a6f2b7ce3e80b6eca2e51271cb730d2 58a10ce4381cfbe69b035bda4abae3ebb22d322b M arch No need to close, the issue is there, right? :-) Thanks for the bisection, we'll close the bug when the problem is fixed. Yes it's still there, tried 71a8638480eb8fb6cfabe2ee9ca3fbc6e3453a14 And reverting the bisected commit off that fixes the problem. Thanks Please check if the current Linus' tree fixes the problem for you. See if commit 1d487624fcc17a40aa67acaa9e8f3815fb7cd0f0 in Linus' tree fixes the issue. Should be fixed by Linus' commit 82da65dab5f438ac7df28eeb43e2f5b742aa00ef. I can confirm 1d487624fcc17a40aa67acaa9e8f3815fb7cd0f0 (identical to 82da65dab5f438ac7df28eeb43e2f5b742aa00ef) fixes this issue for me. Thank you. |