On Tue, 14 Nov 2006 13:47:41 -0800, Trevor Hamm <Trevor_Hamm@xxxxxxxxxxxxxx> wrote: > > 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 problem. 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. All correct? --- Atsushi Nemoto
