Subject: RE: Problems booting Linux 2.6.18.1 on MIPS34K core

From: Trevor Hamm <[email-masked]>
Date: Wed, 8 Nov 2006 11:51:08 -0800

> -----Original Message-----
> From: Ralf Baechle [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 1:24 PM
> To: Trevor Hamm
> Cc: 'Atsushi Nemoto'; [email-masked]
> Subject: Re: Problems booting Linux 2.6.18.1 on MIPS34K core
> 
> On Wed, Nov 08, 2006 at 11:09:37AM -0800, Trevor Hamm wrote:
> 
> > So just for fun, I built a linux image to use a 
> write-through caching policy, and it boots from power-up every time.
> > 
> > With this information, I would conclude the problem is due 
> to cache management, either in the way we're initializing the 
> cache, or something else in the squashfs code.  Or is there 
> another explanation that I'm overlooking?
> 
> Does your processor have cache aliases?
> 
>   Ralf
> 

Yes, we've got 64kB, 4-way caches using 4kB page size.

Trevor

---

From: Trevor Hamm <[email-masked]>
Date: Wed, 15 Nov 2006 15:09:34 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Atsushi Nemoto
> Sent: Wednesday, November 15, 2006 8:07 AM
> To: Trevor Hamm
> Cc: [email-masked]
> Then, I can imagine three (hardly possible) case:
> 
> A.  PG_dcache_dirty bit was cleared accidently.
> 
> B.  The page is accessed by user process without page_mapping()
> 
> C.  kernel forgot to call update_mmu_cache() at somewhere.
> 
> If case A, removing "&& Page_dcache_dirty(page)" condition from
> __update_cache() will hide your problem.  If case B, calling
> flush_dcache_page() unconditionally in __update_cache() will hide your
> problem.
> 
> Anyway for now I can not see why this can happen...
> 

Okay, so after writing up that long explanation, reading through some more kernel code, and re-reading what you wrote above, I realize that all I've done was to verify what you've already suspected all along -- that a flush_dcache_page on this page somehow doesn't flush the page.  This is my first time studying the cache/memory management code in Linux 2.6; thanks for being so patient with me :-)

I tried the remedies you suggested for Case A and B, but neither one produces a kernel which can boot from power-up.  So far, the only work-around that works is calling flush_data_cache_page unconditionally from __flush_dcache_page.  This would imply that Case C is the culprit.  I'll see what I can do to verify this.

Thanks,
Trevor