linux-mips
[Top] [All Lists]

RE: Problems booting Linux 2.6.18.1 on MIPS34K core

To: "'Atsushi Nemoto'" <anemo@mba.ocn.ne.jp>
Subject: RE: Problems booting Linux 2.6.18.1 on MIPS34K core
From: Trevor Hamm <Trevor_Hamm@pmc-sierra.com>
Date: Wed, 22 Nov 2006 12:31:10 -0800
Cc: linux-mips@linux-mips.org
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
 

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Atsushi Nemoto
> Sent: Friday, November 17, 2006 4:13 AM
> To: Trevor Hamm
> Cc: linux-mips@linux-mips.org
> Subject: Re: Problems booting Linux 2.6.18.1 on MIPS34K core
> 
> Thanks.  I re-read your report and wonder why this happens only on
> power-up time.
> 
> If flush_data_cache_page or update_mmu_cache were broken, the problem
> can happen on every restart.
>

This page does eventually get flushed to main memory on the first boot, but 
unfortunately the call to __update_cache() happens after this page was copied 
through copy_user_highpage().

The source of the problem seems to be with squashfs.  When I compare booting a 
kernel using squashfs to one using cramfs (which always seems to boot 
successfully on power-up), both are reading the troublesome page from 
/lib/ld-uClibc.so, and both are calling flush_dcache_page() on this page.  But 
in the case of cramfs, flush_dcache_page() causes an immediate cache flush of 
that page (mapping_mapped(mapping) in __flush_dcache_page() is returning 
non-zero), while squashfs just marks the page as dirty and defers the cache 
flush (mapping_mapped(mapping) is returning zero).  I have no idea what causes 
this difference in behaviour, but right now it appears to be a bug in squashfs 
rather than the linux-mips kernel.

Trevor

<Prev in Thread] Current Thread [Next in Thread>