Subject: RE: Problems booting Linux 2.6.18.1 on MIPS34K core

From: Trevor Hamm <[email-masked]>
Date: Thu, 9 Nov 2006 09:20:12 -0800

> -----Original Message-----
> From: Atsushi Nemoto [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 7:58 PM
> To: Trevor Hamm
> Cc: [email-masked]
> Subject: Re: Problems booting Linux 2.6.18.1 on MIPS34K core
> 
> Hmm, could you try init=/bin/sh?  If the shell invoked successfully it
> might be COW issue.  

Yes, /bin/sh works.  I've also run different /sbin/init programs successfully (sysvinit, busybox; I think I mentioned sysvinit worked in my original post).  It's just with simpleinit from util-linux 2.12r that we've seen this issue.

> In this case, could you try deleting
> __HAVE_ARCH_COPY_USER_HIGHPAGE in include/asm-mips/page.h?
> 

Okay, I did this, but /sbin/init still hangs in the same place.  I also had to delete the copy_user_highpage function in arch/mips/mm/init.c to get the kernel to build.  It's now using the copy_user_highpage from include/linux/highmem.h.  I assume this was your intention?

Thanks,
Trevor

---

From: Atsushi Nemoto <[email-masked]>
Date: Fri, 10 Nov 2006 12:16:23 +0900 (JST)

On Thu, 9 Nov 2006 09:20:12 -0800 , Trevor Hamm <[email-masked]> wrote:
>  Yes, /bin/sh works.  I've also run different /sbin/init programs
> successfully (sysvinit, busybox; I think I mentioned sysvinit worked
> in my original post).  It's just with simpleinit from util-linux
> 2.12r that we've seen this issue.

Oh, I had missed that point.  And I realize you said the fault was
happend in /sbin/init itself.  So it should not be COW issue.

> Okay, I did this, but /sbin/init still hangs in the same place.  I
> also had to delete the copy_user_highpage function in
> arch/mips/mm/init.c to get the kernel to build.  It's now using the
> copy_user_highpage from include/linux/highmem.h.  I assume this was
> your intention?

Yes, then copy_user_highpage would not be guilty.  Your trial
confirmed this.  Thanks anyway.

So now I doubt flush_dcache_page/update_mmu_cache change caused your
problem, which was happen during 2.6.17.8 and 2.6.17.9.  This is a bit
inconsistent from your analysis (2.6.17.10 was OK), but in general
cache troubles are very sensitive anyway...

Could you confirm that removing whole "if (mapping ..." block from
__flush_dcache_page can hide your problem?

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?

---
Atsushi Nemoto