Bug 14884
| Summary: | Kernel configured for "586/K5/6x86/6x86MX" does not run on a Cyrix/IBM 6x86 | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Roman Mamedov (rm+bko) |
| Component: | i386 | Assignee: | platform_i386 |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | akpm, hpa, mingo, rm+bko, rusty, yuhongbao_386 |
| Priority: | P1 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.32.1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Config of the kernel which doesn't boot
Config of the kernel which boots fine |
||
Created attachment 24316 [details]
Config of the kernel which boots fine
So it looks like X86_CMPXCHG64 now wrongly defaults to "y" for CONFIG_M586 in the newer kernel, upping the requirement for X86_MINIMUM_CPU_FAMILY be upped to 5 from 4. This is a regression caused by this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ae1b22f6e46c03cede7cea234d0bf2253b4261cf A workaround which I use for now: - depends on !M386 && !M486 + depends on !M386 && !M486 && !M586 s/be upped// Also adding to CC the author and the committer of the probematic git change. Found another commit which could be relevant: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=982d007a6eec4a0abb404d2355eeec2c041c61ea It was only affecting "the obvious Intel CPU", and said "if you enable it on other CPUs later, do it carefully", but the regression-causing commit mentioned above just sets X86_CMPXCHG64=y on ALL kinds of CPUs except for 386 and 486. Thanks, I'll reassign this regression to x86. The use of the CPU level in Ingo's patch is just plain wrong, since this is a CPUID-bit-equipped feature. However, it is Rusty's patch that breaks non-Intel chips: the logic is not equivalent. You're right. Intel's page said CMPXCHG8B was "not supported on Intel(R) processors earlier than the Pentium(R) processors." from which I intuited that it was in M586. But that is over-reading, and this is a Cyrix anyway. Ingo's comment on being careful with other CPUs was prophetic; I should have read it :( I do like the idea of changing from a positive to a negative list, but I can't find enough canonical information to be sure. So patch is best reverted (breaks lguest but I'll simply emulate the pushf and cli insns). Sending patch now... Rusty. Fixed in 2.6.33-rc3. Thanks! I was just going to mention the NT4 bug, but the problem here with Cyrix is that while the Cyrix 6x86L does support CX8, it simply do not enable the CPUID instruction by default, which is needed to detect CX8. To enable it, you will need to do the Cyrix 5/2 test, then if a Cyrix is detected, flip a bit in some register accessed by port 0x22/0x23 to enable the CPUID instruction. And on the 6x86, it implements only 486 features, period, thus should need a 486 compiled kernel. |
Created attachment 24315 [details] Config of the kernel which doesn't boot Right after starting to boot, the kernel stops and shows a message (roughly): "Expected a 586 CPU but only a 486 class CPU detected. Please use the kernel corresponding to your type of hardware". 2.6.30.9 compiled with similar options works fine. The CPU is: processor : 0 vendor_id : CyrixInstead cpu family : 4 model : 4 model name : 6x86L 2x Core/Bus Clock stepping : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : yes fpu : yes fpu_exception : no cpuid level : -1 wp : yes flags : cyrix_arr bogomips : 149.91 clflush size : 32 power management: Attaching kernel configs. Used menuconfig to select the processor type as "586/K5/6x86/6x86MX" in both cases. Result: 2.6.30.9 boots, 2.6.32.1 doesn't. Looks like CONFIG_X86_MINIMUM_CPU_FAMILY=5 could be the reason in the latter case, but (1) this didn't seem to be available in menuconfig as a separate option and (2) why wasn't this automatically set to "4" when I selected the processor type?