Subject: RE: Problems booting Linux 2.6.18.1 on MIPS34K core

From: Trevor Hamm <[email-masked]>
Date: Tue, 14 Nov 2006 13:47:41 -0800

> -----Original Message-----
> From: Atsushi Nemoto [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 9:16 PM
> To: Trevor Hamm
> Cc: [email-masked]
> Subject: Re: Problems booting Linux 2.6.18.1 on MIPS34K core
> 
> 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.

> 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.

Thanks,
Trevor

---

From: Atsushi Nemoto <[email-masked]>
Date: Wed, 15 Nov 2006 23:06:33 +0900 (JST)

> completely to a login prompt.

Thank you for testing.  So we can omit "missing fludh_dcache_page()" case.

> 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