Re: 2.6.20 instability

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

On Tue, Feb 13, 2007 at 10:46:42AM +0100, Manuel Lauss wrote:
> On Fri, Feb 09, 2007 at 08:46:53PM +0900, Paul Mundt wrote:
> > On Fri, Feb 09, 2007 at 12:38:41PM +0100, Manuel Lauss wrote:
> > > On Fri, Feb 09, 2007 at 07:23:16PM +0900, Paul Mundt wrote:
> > > > Once you've pre-faulted the page, please try to dump the whole page
> > > > and see if it manages to blow up at that same location. You can setup the
> > > > translation with:
> > > > 
> > > > 	pte_t entry = pfn_pte(0x18000000 >> PAGE_SHIFT, pgprot);
> > > > 	update_mmu_cache(NULL, 0xc0600000, entry);
> > > 
> > > Inserted this after the p3_ioremap() call; still oopsing at the same
> > > address.
> > > 
> > > The oops is triggered at drivers/net/pcmcia/pcnet_cs::get_hwinfo(),
> > > by the first readb().
> > >  
> > That makes me suspect that we're doing something evil to PTEA. Can you
> > try reverting the fast-path TLB miss handler (may need a bit of
> > munging..)?
> 
> Sorry for the late reply;
> Vanilla 2.6.20 with the TLB miss handler fast path reverted
> looks ok. Kernel survives 100+ insert/ejects of the pcnet_cs
> card just fine, also with the (default) 4MB memory windows.
> 
> Thanks!
> 
That's what I was afraid of. I've hit a few other problems with it as
well, so I think the right thing to do for now is to simply revert it. We
can toss it back in once it's recieved some more testing, since the
fast-path bits are quite small on their own.

It might also be worth checking the __do_page_fault() ->
update_mmu_cache() path for PG_dcache_dirty tests that might be causing
PTEA problems, but this is obviously something that needs to be looked
at more closely, especially for the legacy parts.

Thanks for the exhaustive testing!