> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Atsushi Nemoto
> Sent: Wednesday, November 15, 2006 8:07 AM
> To: Trevor Hamm
> Cc: email@example.com
> Subject: Re: Problems booting Linux 18.104.22.168 on MIPS34K core
> 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
> 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