Red Hat Bugzilla – Bug 200549
[olpc] i586 kernel panics on boot on AMD Geode
Last modified: 2013-03-05 22:46:07 EST
Description of problem:
panic right after boot - I think even before the initramfs is started. Will
Version-Release number of selected component (if applicable):
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.
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
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!