Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)

Justin P. Mattock
2010-02-02T07:03:44Z

On 02/01/10 22:55, Stefan Richter wrote:
> Justin P. Mattock wrote:
>> As for anything changed in the kernel
>> (2.6.31 - present), tough to say
>> from what I remember I had created a new fresh
>> lfs system using these CFLAGS:
>>
>> CFLAGS="-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer"
>> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>> (without -m option gcc defaults(I think)to -m32).
>>
>> which booted with ohci1394_dma=early just fine.
>>
>> then decided to build another lfs system with the same CFLAGS except
>> added -m64 (pure64) to the build process.
>> (then this showed up).
>>
>> What I can try is do a git revert to 2.6.29/27 to see if this thing
>> fires off(before going any further). if the system boots then do a bisect.
>
> Do I understand correctly that at this moment it is only known that the
> bug could be
> - *either* a 2.6.31 -> 2.6.32 regression
> - *or* an x86-64 specific bug that does not occur on x86-32,
> right?
>

at first I was under the impression this was an arch thing because of
building an x86_32, and then building x86_64(and hitting this). but now
after reverting to 2.6.27 I'm thinking other wise.(my bad, should of
done this at first but didn't even think too);

> I have an Core 2 Duo based PC with x86-32 kernel and userland and an AMD
> based x86-64 PC and could give ohci1394_dma=early a try on both (never
> tested it myself before). I could furthermore attempt to build and
> install an x86-64 kernel on the Core 2 Duo PC but I am afraid I am far
> too short of spare time for that.

no..
I need to do a bisect from 2.6.27 to present to see
(just need to crash for a few hrs, then can start);
then I'll go from there.

Justin P. Mattock