AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071012152216.46af4aa3@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<ralf@linux-mips.org>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	20071010163032.GA10243@linux-mips.org
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 12 Oct 2007 15:23:21 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: paging problem with ide-cs driver
Message-ID: <20071012152321.580b6841@ripper.onstor.net>
In-Reply-To: <20071010163032.GA10243@linux-mips.org>
References: <20071009132657.64ec9158@ripper.onstor.net>
	<20071009220530.0416792b@the-village.bc.nu>
	<20071010112550.GA1780@linux-mips.org>
	<20071010075041.60350e8a@ripper.onstor.net>
	<20071010163032.GA10243@linux-mips.org>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 10 Oct 2007 17:30:32 +0100 Ralf Baechle <ralf@linux-mips.org>
wrote:

> On Wed, Oct 10, 2007 at 07:50:41AM -0700, Andrew Sharp wrote:
> 
> > > (As collateral damage 06e523e89ec0322c4abcf41533d5380dfcd81f73
> > > breaks support for pass 1 BCM1250 parts.  But it seems I'm the
> > > last one with one of those ...)
> > 
> > I have 2 of those ~:^)  Thankfully they are only in the swarm
> > systems, because they only run for about an hour or so before
> > crashing.
> 
> Well, that's all fixable if you want to use the pass 1 parts.  The
> rest of the pass 1 workarounds still exists, just the code to avoid
> the use of Hit cacheops and exclusivly rely on Index cacheops would
> need to be reimplemented for c-r4k.c.

I really only use the swarm boards for testing and for showing the
hardware and prom developers that certain things will work if
the hardware and prom code are doing the right things ~:^)  Which
reminds me, I'm having a devil of a time getting a 64-bit kernel
(2.6.20.3) to boot on these machines -- is that a known limitation?

The hardware was not well cared for before I started here, and seems
flaky, and tends to crash within a few hours with a d-cache exception.
Which is a shame because I was hoping to use them as compute servers for
the developers around here to use to tune their code to work
efficiently wrt to the caches on the sibyte.

> For unrelated reasons I've recently written code to stop using indexed
> cacheops.  But the existing framework in c-r4k.c is flexible enough to
> add that case too.

Well, I'm pretty much a gitiot so this is taking me several hours
(cleanly commiting all my working tree changes and syncing my
repository w/o screwing everything up). If the important changes are
confined to c-r4k.c that would make back-porting it to my 2.6.22 based
branch much easier for me.  Or if you know off hand that the important
changes are confined to just a couple of files...

Cheers,

a
