linux-mips
[Top] [All Lists]

Re: SB1250 locking up in init on current 2.6.16 kernel

To: Larry Stefani <lstefani@yahoo.com>
Subject: Re: SB1250 locking up in init on current 2.6.16 kernel
From: Thiemo Seufer <ths@networkno.de>
Date: Fri, 28 Mar 2008 17:11:46 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <54971.71316.qm@web38813.mail.mud.yahoo.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20080328134317.GA21099@networkno.de> <54971.71316.qm@web38813.mail.mud.yahoo.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.17+20080114 (2008-01-14)
Larry Stefani wrote:
> Hi Thiemo,
> 
> I applied your patch (from
> http://www.linux-mips.org/archives/linux-mips/2008-03/msg00001.html)
> on 2.6.16.60, and also patched arch/mips/mm/c-sb1.c to
> remove:
> 
>           local_flush_data_cache_page = (void *)
> sb1_nop;
> 
> in order to compile after your changes to cache.c and
> cacheflush.h.  However, this did not work on my board,
> and I experienced the same lockup as before.

Stick with the original 2.6.16.60 code but try to remove the

   if (cpu_has_dc_aliases) {

conditional in ide.h _without_ using my patch. This is what made
it boot for me.

> >>Keep in mind that this is a crude workaround on top
> of other cache code hacks for the SB-1.
> 
> What other "cache code hacks for SB-1"?  Are there
> additional changes required to 2.6.16.60 to make SB1
> work properly?  Did you post those hacks somewhere?

No, what I meant to say is that the old sb-1 cache code isn't quite
the most trustibe code, it had some holes which were papered over
by doing more cache flushes than necessary.


Thiemo

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