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" <justinmattock@gmail.com>]

On 02/03/10 01:18, Jan Beulich wrote:
>>>> "Justin P. Mattock"<justinmattock@gmail.com>  03.02.10 02:43>>>
>> The only thing I can think of at this point
>> is maybe the CFLAGS I used to build this system.
>> (as for the x86_32 working and x86_64 failing not sure);
>>
>> I'm curious to see if anybody else is hitting this?
>
> I think it is pretty clear how a page fault can happen here (but you're
> observing a double fault, which I cannot explain [nor can I explain
> why the fault apparently didn't get an error code pushed, which is
> why address and error code displayed are mixed up]): I would
> suspect that FIX_OHCI1394_BASE is now in a different (virtual) 2Mb
> range than what is covered by level{1,2}_fixmap_pgt, but this was
> a latent issue even before that patch (just waiting for sufficiently
> many fixmap entries getting inserted before
> __end_of_permanent_fixed_addresses).
>
> The thing is that head_64.S uses hard-coded numbers, but doesn't
> really make sure (at build time) that the fixmap page tables established
> indeed cover all the entries of importance (and honestly I even can't
> easily tell which of the candidates - FIX_DBGP_BASE,
> FIX_EARLYCON_MEM_BASE, and FIX_OHCI1394_BASE afaict - really
> matter). If either of the first does, the only reasonable solution imo
> is to move FIX_OHCI1394_BASE out of the boot time only range into
> the permanent range (unless the other two can be moved into the
> boot time only range). And obviously the hard coded numbers
> should be eliminated from head_64.S.
>
> Jan
>
>

Thanks for your info on this. I can try today moving things
around just to see. Looking more into this(keep in mind I
have no idea how these page,fix_to_virt calls etc.. work)
I was thinking with what stefan had mentioned ___alloc_bootmem_node
(still need to look into what that function does)maybe keeping fixmap.h 
as is and looking somewhere else might be where the fix might be(but 
could be wrong).

In any case I'll have another go at this today.

Justin P. Mattock