Re: 2.6.20 instability

[Paul M. <le...@li...>]

On Thu, Feb 08, 2007 at 08:43:39AM +0100, Manuel Lauss wrote:
> It seems the error condition is depeding on the size of the
> window getting p3_ioremap()ed in the socket driver.
> For example, a minimal kernel with SCIF/pcmcia/net/ide support
> will NOT oops when the window size is reduced to 2MB
> (the MAP_SIZE constant in exm7760_ss.c).
> 
> For a larger kernel with more built-in hardware I need to
> reduce the window size to 1MB.
> 
> Oopses occur when something tries to access beyond 0xc0400000.
> (just a guess though)
> 
This looks quite strange indeed. First, are you doing anything strange
with VMALLOC_START? If not, can you set it to P3 + 4MB and see if you hit
the same problem elsewhere outside of the p3_ioremap() context (or
optionally just remap an empty hole to bump it up)?

Assuming no luck and you hit the same problem again, but at a different
offset, and it's repeatable, can you walk the page tables and print out
the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
each remapped PTE?

Going by the oops, it looks like you have a bogus PGD. Can you print out
the value of get_TTB() (and also get_TTB() + pgd_index(addr)) in
do_page_fault() under the oops path before the die()?

If that still doesn't provide any hints, can you trap the faulting
address in the TLB miss handler and see whether you're coming out alive
or not? Any branches in to handle_exception() from tlb_miss() you might
be able to spot with a JTAG on that faulting range would be interesting.