Description of problem: panic right after boot - I think even before the initramfs is started. Will attach screenshot. Version-Release number of selected component (if applicable): 2.6.17-1.2449.fc6 How reproducible: Always on AMD Geode. It's really bad as we need to move off the i686 kernel (see bug 200330 and bug 200409) as the AMD geode is not fully i686 compatible and the recent binutils started producing code where this is exposed. So right now we're kind of screwed. Please advise. Thanks!
Created attachment 133245 [details] photograph of panic
*** Bug 200037 has been marked as a duplicate of this bug. ***
Ok, this looks like binutils breakage to me. hj 'optimised' the NOP handling for 686, but seems to have busted 586 in the process. http://sources.redhat.com/ml/binutils/2006-06/msg00193.html 66 0f 1f is not valid on i586 (and possibly some 686s afair).
ftp://download.intel.com/design/Pentium4/manuals/25366720.pdf states ... The multi-byte form of NOP is available on processors with model encoding: ⢠CPUID.01H.EAX[Bytes 11:8] = 0110B or 1111B So, only family 6 and 15. Little wonder 586 is hurting.
note btw, that this statement does nothing to guarantee that the right thing happens with that code sequence on for eg, athlons, VIA-C3, or any other non-intel 686. It seems Intel only recently started documenting the multi-byte variants of NOP, so any vendors that based their own 686 implementation on reading (older) intel docs may be in for a surprise.
So what's the plan to fix things here? Unscrew binutils? In our example it would be great if we can compile somewhere else (for i686) and it still runs on the geode. Is upstream binutils actually broken in this case?
Can you try this patch http://sourceware.org/ml/binutils/2006-07/msg00360.html
Sounds like we have a working kernel after a rebuild with binutils and this patch. David, are we good to close?
Yup, the i686 kernel works on the Geode. Closing bug. Thanks to everyone involved!