SGI IP28 support

SGI IP28 support

[Thomas Bogendoerfer]

I finally cleaned up Peter Fuerst's IP28 patches and solved some of
the IP28 issues in an IMHO more eye-friendly way (no ip26ucmem).
My IP28 boots with these patches from an Debian sarge NFS root and
is able to dd data from the harddrive. I'm going to send this patches
to this list and the subsystem maintainers.

There is one change missing to get a working SCSI driver, because
a proper fix will be done in 2.6.25. The quick&dirty workaround is
below. The workaround makes sure that the sense_buffer lives in
its own cache line by aligning and extendin it.

The patch "Use real cache invalidate" still contains one problem.
It will not flush the cache correctly, if the given size is bigger
than the second level cache. The problem is, that there is no index
invalidate cache operation available. I have two ideas to solve that.
One is to always do a range invalidate (maybe just by using this only
for R10k machines, which usually have quite big caches) or scan through
the cache and use the tag informations to do hit invalidate. If anybody
has a better idea please speak up :-)

Have fun with the patches,
Thomas.


diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index 3f47e52..3f3d7aa 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -87,11 +87,13 @@ struct scsi_cmnd {
 	struct request *request;	/* The command we are
 				   	   working on */
 
+	unsigned char xxx1[0x48];
 #define SCSI_SENSE_BUFFERSIZE 	96
 	unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE];
 				/* obtained by REQUEST SENSE when
 				 * CHECK CONDITION is received on original
 				 * command (auto-sense) */
+	unsigned char xxx2[32];
 
 	/* Low-level done function - can be used by low-level driver to point
 	 *        to completion function.  Not used by mid/upper level code. */




-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: SGI IP28 support

[Thomas Bogendoerfer]

On Mon, Nov 26, 2007 at 11:38:14PM +0100, Thomas Bogendoerfer wrote:
> [..]

There is one thing I forgot: You need a special gcc, which will generate
cache barriers to avoid speculative stores done by the R10k. Peter
had some patches submitted to the gcc maintainers, which I used to
build my own gcc 4.2.1 cross compiler. Does anybody know, if Peter's
paches are already intergrated in newer gcc versions ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: SGI IP28 support

[post]

Hi!

On Tue, 27 Nov 2007, Thomas Bogendoerfer wrote:

> Date: Tue, 27 Nov 2007 00:01:27 +0100
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> To: linux-mips@linux-mips.org
> Subject: Re: SGI IP28 support
> 
> On Mon, Nov 26, 2007 at 11:38:14PM +0100, Thomas Bogendoerfer wrote:
> > [..]
> 
> There is one thing I forgot: You need a special gcc, which will generate
> cache barriers to avoid speculative stores done by the R10k. Peter
> had some patches submitted to the gcc maintainers, which I used to
> build my own gcc 4.2.1 cross compiler. Does anybody know, if Peter's
> paches are already intergrated in newer gcc versions ?

They hardly are. At least i didn't undertake a second attempt yet. Nor
did i hear of the Gentoo-folks or someone else taking this unpleasant
job.

> 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessary a
> good idea.                                                [ RFC1925, 2.3 ]
> 
> 
> 

kind regards

peter

Re: SGI IP28 support

[Ralf Baechle]

On Mon, Nov 26, 2007 at 11:38:14PM +0100, Thomas Bogendoerfer wrote:

> I finally cleaned up Peter Fuerst's IP28 patches and solved some of
> the IP28 issues in an IMHO more eye-friendly way (no ip26ucmem).
> My IP28 boots with these patches from an Debian sarge NFS root and
> is able to dd data from the harddrive. I'm going to send this patches
> to this list and the subsystem maintainers.
> 
> There is one change missing to get a working SCSI driver, because
> a proper fix will be done in 2.6.25. The quick&dirty workaround is
> below. The workaround makes sure that the sense_buffer lives in
> its own cache line by aligning and extendin it.
> 
> The patch "Use real cache invalidate" still contains one problem.
> It will not flush the cache correctly, if the given size is bigger
> than the second level cache. The problem is, that there is no index
> invalidate cache operation available. I have two ideas to solve that.
> One is to always do a range invalidate (maybe just by using this only
> for R10k machines, which usually have quite big caches) or scan through
> the cache and use the tag informations to do hit invalidate. If anybody
> has a better idea please speak up :-)

A while ago I instrumented the cacheflushing functions to get a histogram
of cacheflush sizes.  I was surprised to find no flushes larger than 64K
even though I did that experiment on an Origin with a large RAID array
copying huge amounts of data with reads and writes of several MB.  So as
long as that finding holds your code will work.

  Ralf