On Tue, 14 Nov 2006 13:47:41 -0800, Trevor Hamm <Trevor_Hamm@pmc-sierra.com>
> > Could you confirm that removing whole "if (mapping ..." block from
> > __flush_dcache_page can hide your problem?
> Yes, removing this block seems to hide the problem. I can boot
> completely to a login prompt.
Thank you for testing. So we can omit "missing fludh_dcache_page()" case.
> > Or if you changed a line in __update_cache():
> > int exec = (vma->vm_flags & VM_EXEC) && !cpu_has_ic_fills_f_dc;
> > to
> > int exec = 1;
> > then your problem still happen?
> Yes, with this change, the boot-up problem persists.
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...
Just for confirm:
1. This can happen on latest lmo git tree or 2.6.19-rc5.
2. UP kernel.
3. No L2 cache.
4. icache and dcache are both virtually indexed and physically tagged.