linux-mips
[Top] [All Lists]

Re: Problems booting Linux 2.6.18.1 on MIPS34K core

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Problems booting Linux 2.6.18.1 on MIPS34K core
From: David McCullough <david_mccullough@au.securecomputing.com>
Date: Thu, 23 Nov 2006 08:43:01 +1000
Cc: Trevor Hamm <Trevor_Hamm@pmc-sierra.com>, 'Atsushi Nemoto' <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
In-reply-to: <20061122215803.GA8819@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E8C8A5231DDE104C816ADF532E0639120194F4EB@bby1exm07.pmc_nt.nt.pmc-sierra.bc.ca> <20061122215803.GA8819@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.11
Jivin Ralf Baechle lays it down ...
> On Wed, Nov 22, 2006 at 12:31:10PM -0800, Trevor Hamm wrote:
> 
> > 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.
> 
> There are a few other potencial and real bugs me and Atsushi have found
> in squashfs.  Guess there is a reason why it's not yet in the kernel ...
> I'm still waiting for feedback from the squashfs author.

Not sure if it helps much,  but we run squashfs (with 7zip patch) on
ARM9, ARM10, SuperH and x86 without problems.  I haven't had any issues
with it so far on the au1500 either,

Cheers,
Davidm

-- 
David McCullough,  david_mccullough@securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

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