[BUG] 2.6.11- sym53c8xx Broken on pp64

[BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

Seems with 2.6.11 the sym53c8xx kernel module incorrectly identifies the
cache being misconfigured on a p630 (ppc64, POWER4+). 2.6.9 correctly
brings up this adaptor as does AIX with absolutely no indication of a
misconfigured cache.

Doing a simple diff I see ALOT of changes between 2.6.9 and 2.6.11
pertaining to this module. Any ideas?

O

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Benjamin Herrenschmidt]

On Wed, 2005-03-09 at 19:51 -0600, Omkhar Arasaratnam wrote:
> Seems with 2.6.11 the sym53c8xx kernel module incorrectly identifies the
> cache being misconfigured on a p630 (ppc64, POWER4+). 2.6.9 correctly
> brings up this adaptor as does AIX with absolutely no indication of a
> misconfigured cache.
> 
> Doing a simple diff I see ALOT of changes between 2.6.9 and 2.6.11
> pertaining to this module. Any ideas?

Are you sure it's plain 2.6.11 and not some bk clone of after 2.6.11 was
released ?

I just found a bug in the ppc64 ioremap code that got triggered by
the set_pte_at() patch that went into bk after 2.6.11 and that triggers
exactly that error, but I couldn't see anything wrong in 2.6.11 proper.

BTW, Linus: Any chance you ever change something to version or
extraversion in bk just after a release ? I know I already ask and it
degenerated into a flamefest, and I don't know if that is specifically
the case now, but I keep getting report of people saying "I have a bug
in 2.6.xx" while in fact, they have some kind of bk clone of sometime
after 2.6.xx...

Ben.

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Linus Torvalds]

On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
> 
> BTW, Linus: Any chance you ever change something to version or
> extraversion in bk just after a release ? I know I already ask and it
> degenerated into a flamefest, and I don't know if that is specifically
> the case now, but I keep getting report of people saying "I have a bug
> in 2.6.xx" while in fact, they have some kind of bk clone of sometime
> after 2.6.xx...

The answer is the same: I'd still like to have somebody (preferably Sam)  
who is comfortable with all the build scripts get a revision-control-
specific version at build-time, so that BK users would get the top-of-tree 
key value, and other people could get some CVS revision or something.

I don't want to tag things just randomly, especially as it would be very
error-prone (read: I'd forget). A script that looks at the top revision,
and if it's not a tag, takes the key value and appends it to the build
version seems to be The Right Thing (tm). 

I have this dim memory that Sam might even have had some early trials, but 
maybe thats just wishful thinking.. Sam?

		Linus

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

Benjamin Herrenschmidt wrote:

>Are you sure it's plain 2.6.11 and not some bk clone of after 2.6.11 was
>released ?
>
>  
>
Ben - I am in the process of downloading a clean tarball from kernel.org 
to be 100% certain.

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

Omkhar Arasaratnam wrote:

> Benjamin Herrenschmidt wrote:
>
>> Are you sure it's plain 2.6.11 and not some bk clone of after 2.6.11 was
>> released ?
>>
>>  
>>
> Ben - I am in the process of downloading a clean tarball from 
> kernel.org to be 100% certain.

I confirmed that this occurs with the 2.6.11 code straight from 
kernel.org Here is an error from the bringup:

sym0: No NVRAM, ID 7, Fast-80 LVD, parity checking
CACHE TEST FAILED: DMA error (dstat=0xa0) .sym0: CACHE INCORRECTLY 
CONFIGURED
sym0: giving up ...

ideas?

Omkhar

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Linus Torvalds]

On Wed, 9 Mar 2005, Omkhar Arasaratnam wrote:
> 
> I confirmed that this occurs with the 2.6.11 code straight from 
> kernel.org Here is an error from the bringup:

So if 2.6.9 works, and 2.6.11 does not, can you check 2.6.10? And perhaps 
hunt it down even more, to a -rc release?

> sym0: No NVRAM, ID 7, Fast-80 LVD, parity checking
> CACHE TEST FAILED: DMA error (dstat=0xa0) .sym0: CACHE INCORRECTLY CONFIGURED
> sym0: giving up ...

There are certainly sym changes in there too since 2.6.9, let's see if 
James or Willy have any suggestions. It might not be ppc64-specific.

		Linus

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

Linus Torvalds wrote:

>
>There are certainly sym changes in there too since 2.6.9, let's see if 
>James or Willy have any suggestions. It might not be ppc64-specific.
>
>		Linus
>
>  
>

I have tried with 2.6.10, this appears to fail as well. Unfortunately I 
don't have console access right now so I will have confirm the message 
in the am. I'll start bisecting patches once we confirm.

Omkhar

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Ryan Anderson]

On Wed, Mar 09, 2005 at 06:25:56PM -0800, Linus Torvalds wrote:
> On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
> > 
> > BTW, Linus: Any chance you ever change something to version or
> > extraversion in bk just after a release ? I know I already ask and it
> > degenerated into a flamefest, and I don't know if that is specifically
> > the case now, but I keep getting report of people saying "I have a bug
> > in 2.6.xx" while in fact, they have some kind of bk clone of sometime
> > after 2.6.xx...
> 
> The answer is the same: I'd still like to have somebody (preferably Sam)  
> who is comfortable with all the build scripts get a revision-control-
> specific version at build-time, so that BK users would get the top-of-tree 
> key value, and other people could get some CVS revision or something.

I've got something that fixes up the version by adding -BK and then 8
hex characters from the md5 hash of the top of tree changeset key.

I was starting to work on stuffing that same value into a /proc file so
that you can figure out what the tree looked like, but at the moment,
you at least get a semi-random string appended to the version.

I resent the patch yesterday, but I'll put it here, too:
 
> I have this dim memory that Sam might even have had some early trials, but 
> maybe thats just wishful thinking.. Sam?

I think that was my patch - Sam was going to look at it, but I suspect
it got lost in more interesting things. :)

(I sent a better described version to Andrew yesterday, if you want to
grab that description and use it instead.)
 
Signed-Off-By: Ryan Anderson <ryan@michonline.com>

diff -Nru a/Makefile b/Makefile
--- a/Makefile	2005-03-09 02:51:15 -05:00
+++ b/Makefile	2005-03-09 02:51:15 -05:00
@@ -550,6 +550,24 @@
 
 #export	INSTALL_PATH=/boot
 
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user to
+# build a release tree (i.e, 2.6.9) and also to continue developing against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9 tree 
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+	ifeq ($(shell ls -d $(srctree)/BitKeeper 2>/dev/null),$(srctree)/BitKeeper)
+		localversion-bk := $(shell $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+		LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+	endif
+endif
+
 #
 # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
 # relocations required by build roots.  This is not defined in the
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig	2005-03-09 02:51:15 -05:00
+++ b/init/Kconfig	2005-03-09 02:51:15 -05:00
@@ -69,6 +69,18 @@
 	  object and source tree, in that order.  Your total string can
 	  be a maximum of 64 characters.
 
+config LOCALVERSION_AUTO
+	bool "Automatically append version information to the version string"
+	default y
+	help
+	  This will try to automatically determine if the current tree is a
+	  release tree by looking for BitKeeper tags that belong to the
+	  current top of tree revision.
+	  A string of the format -BKxxxxxxxx will be added to the
+	  localversion.  The string generated by this will be appended 
+	  after any matching localversion* files, and after the 
+	  value set in CONFIG_LOCALVERSION
+
 config SWAP
 	bool "Support for paging of anonymous memory (swap)"
 	depends on MMU
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion	2005-03-09 02:51:15 -05:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <ryan@michonline.com>  GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+	print <<EOT;
+Usage: setlocalversion <srctree> <objtree>
+EOT
+	exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches)
+# We currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+
+#ryan@mythryan2 ~/dev/linux/local$ T=`bk changes -r+ -k`
+#ryan@mythryan2 ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+	chdir($srctree);
+	my $changeset = `bk changes -r+ -k`;
+	chomp $changeset;
+	my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+	printf("ChangeSet Key = '%s'\nTAG = '%s'\n", $changeset, $tag) if ($debug > 0);
+
+	if (length($tag) == 0) {
+		# We do not have a tag at the Top of Tree, so we need to generate a localversion file
+		# We'll use the given $changeset as input into this.
+		my $localversion = Digest::MD5::md5_hex($changeset);
+		$localversion = substr($localversion,0,8);
+
+		printf("localversion = '%s'\n",$localversion) if ($debug > 0);
+
+		push @LOCALVERSIONS, "BK" . $localversion;
+
+	}
+}
+
+
+if ( -d "BitKeeper" ) {
+	my $bk = `which bk`;
+	chomp $bk;
+	if (length($bk) != 0) {
+		do_bk_checks();
+	}
+}
+
+printf "-%s\n", join("-",@LOCALVERSIONS) if (scalar @LOCALVERSIONS > 0);
diff -Nru a/scripts/setlocalversion.sh b/scripts/setlocalversion.sh
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion.sh	2005-03-09 02:51:15 -05:00
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+BK=`which bk`
+MD5SUM=`which md5sum`
+
+srctree=$1
+objtree=$2
+
+if [ "$BK" == "" ];
+then
+	echo "scripts/setlocalversion.sh: Failed to find BK, not appending a -BK* version" >&2
+	exit 0
+fi
+
+if [ "$MD5SUM" == "" ];
+then
+	echo "scripts/setlocalversion.sh: Couldn't find md5sum, trying Perl version instead." >&2
+	exec perl scripts/setlocalversion $srctree $objtree
+fi
+
+cd $srctree
+changeset=`$BK changes -r+ -k`
+tag=`$BK prs -h -d':TAG:' -r'$changeset'`
+if [ "$tag" == "" ]; then
+	echo -n $changeset | md5sum | awk '{printf "-BK%s",substr($1,1,8)}'
+fi


-- 

Ryan Anderson
  sometimes Pug Majere

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Sam Ravnborg]

On Wed, Mar 09, 2005 at 06:25:56PM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
> > 
> > BTW, Linus: Any chance you ever change something to version or
> > extraversion in bk just after a release ? I know I already ask and it
> > degenerated into a flamefest, and I don't know if that is specifically
> > the case now, but I keep getting report of people saying "I have a bug
> > in 2.6.xx" while in fact, they have some kind of bk clone of sometime
> > after 2.6.xx...
> 
> The answer is the same: I'd still like to have somebody (preferably Sam)  
> who is comfortable with all the build scripts get a revision-control-
> specific version at build-time, so that BK users would get the top-of-tree 
> key value, and other people could get some CVS revision or something.

I have a patch somewhere in my inbox, and got one from Ryan yesterday
also. I will see if I during the weekend find some time to look at it.

	Sam

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Benjamin Herrenschmidt]

On Wed, 2005-03-09 at 19:47 -0800, Linus Torvalds wrote:
> 
> On Wed, 9 Mar 2005, Omkhar Arasaratnam wrote:
> > 
> > I confirmed that this occurs with the 2.6.11 code straight from 
> > kernel.org Here is an error from the bringup:
> 
> So if 2.6.9 works, and 2.6.11 does not, can you check 2.6.10? And perhaps 
> hunt it down even more, to a -rc release?
> 
> > sym0: No NVRAM, ID 7, Fast-80 LVD, parity checking
> > CACHE TEST FAILED: DMA error (dstat=0xa0) .sym0: CACHE INCORRECTLY CONFIGURED
> > sym0: giving up ...
> 
> There are certainly sym changes in there too since 2.6.9, let's see if 
> James or Willy have any suggestions. It might not be ppc64-specific.

Ok, we have it working here on a similar machine with 2.6.11 and failing
in a similar way with bk which is why I asked ;)

The bk problem is found & fixed here tho. I'll send a patch later, it's
a bug with ppc64 iounmap() not properly flushing the hash table after
the set_pte_at() patch due to some crap in our custom implementation of
that guy.

Here's the patch, but I want to get rid of that stuff anyway (at least
make unmap_vm_area take the "mm", or rather make an unmap_vm_area_mm()
and make unmap_vm_area() just call it and then use that instead of our
own implementation, but I'm waiting for Hugh cleanup to get in before
touching any of this).

--

This patch fixes a bug in ppc64 local implementation of iounmap() that
would cause it to incorrectly flush the hash table since the changes to
set_pte have been applied.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Index: working-2.6/arch/ppc64/mm/init.c
===================================================================
--- working-2.6.orig/arch/ppc64/mm/init.c	2005-03-07 13:06:23.000000000 +1100
+++ working-2.6/arch/ppc64/mm/init.c	2005-03-10 12:59:50.000000000 +1100
@@ -288,7 +288,7 @@
 static void unmap_im_area_pte(pmd_t *pmd, unsigned long address,
 				  unsigned long size)
 {
-	unsigned long end;
+	unsigned long base, end;
 	pte_t *pte;
 
 	if (pmd_none(*pmd))
@@ -300,6 +300,7 @@
 	}
 
 	pte = pte_offset_kernel(pmd, address);
+	base = address & PMD_MASK;
 	address &= ~PMD_MASK;
 	end = address + size;
 	if (end > PMD_SIZE)
@@ -307,7 +308,7 @@
 
 	do {
 		pte_t page;
-		page = ptep_get_and_clear(&ioremap_mm, address, pte);
+		page = ptep_get_and_clear(&ioremap_mm, base + address, pte);
 		address += PAGE_SIZE;
 		pte++;
 		if (pte_none(page))
@@ -321,7 +322,7 @@
 static void unmap_im_area_pmd(pgd_t *dir, unsigned long address,
 				  unsigned long size)
 {
-	unsigned long end;
+	unsigned long base, end;
 	pmd_t *pmd;
 
 	if (pgd_none(*dir))
@@ -333,13 +334,14 @@
 	}
 
 	pmd = pmd_offset(dir, address);
+	base = address & PGDIR_MASK;
 	address &= ~PGDIR_MASK;
 	end = address + size;
 	if (end > PGDIR_SIZE)
 		end = PGDIR_SIZE;
 
 	do {
-		unmap_im_area_pte(pmd, address, end - address);
+		unmap_im_area_pte(pmd, base + address, end - address);
 		address = (address + PMD_SIZE) & PMD_MASK;
 		pmd++;
 	} while (address < end);


 

Ben.

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Matthew Wilcox]

On Thu, Mar 10, 2005 at 04:59:43PM +1100, Benjamin Herrenschmidt wrote:
> Ok, we have it working here on a similar machine with 2.6.11 and failing
> in a similar way with bk which is why I asked ;)
> 
> The bk problem is found & fixed here tho. I'll send a patch later, it's
> a bug with ppc64 iounmap() not properly flushing the hash table after
> the set_pte_at() patch due to some crap in our custom implementation of
> that guy.

Heh, the devel version of sym2 (that isn't submitted yet because
it depends on a few changes to the SPI transport that James hasn't
integrated yet) would probably fix this as it doesn't call iounmap()
until the driver exits.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[James Bottomley]

On Thu, 2005-03-10 at 12:17 +0000, Matthew Wilcox wrote:
> Heh, the devel version of sym2 (that isn't submitted yet because
> it depends on a few changes to the SPI transport that James hasn't
> integrated yet) would probably fix this as it doesn't call iounmap()
> until the driver exits.

They're integrated into the scsi-misc-2.6 tree, so if you send in the
sym2 patch to linux-scsi, everything should still work...

James

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

James Bottomley wrote:

>On Thu, 2005-03-10 at 12:17 +0000, Matthew Wilcox wrote:
>  
>
>>Heh, the devel version of sym2 (that isn't submitted yet because
>>it depends on a few changes to the SPI transport that James hasn't
>>integrated yet) would probably fix this as it doesn't call iounmap()
>>until the driver exits.
>>    
>>
>
>They're integrated into the scsi-misc-2.6 tree, so if you send in the
>sym2 patch to linux-scsi, everything should still work...
>
>James
>
>
>
>  
>
2.6.10 seems to have a different kernel panic which I'm investigating 
(could be a problem with my ramdisk as it happens in my linuxrc). So 
long story short the 2.6.10 sym driver looks ok.

Omkhar

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Benjamin Herrenschmidt]

On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:

> 2.6.10 seems to have a different kernel panic which I'm investigating 
> (could be a problem with my ramdisk as it happens in my linuxrc). So 
> long story short the 2.6.10 sym driver looks ok.

Can you try 2.6.11 with the 2.6.10 sym driver ?

Ben.

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

Benjamin Herrenschmidt wrote:

>On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:
>
>  
>
>>2.6.10 seems to have a different kernel panic which I'm investigating 
>>(could be a problem with my ramdisk as it happens in my linuxrc). So 
>>long story short the 2.6.10 sym driver looks ok.
>>    
>>
>
>Can you try 2.6.11 with the 2.6.10 sym driver ?
>
>Ben.
>
>
>
>  
>
I will try that and let you know how it works out.

Omkhar.

[PATCH] Auto-append localversion for BK users needs to use CONFIG_SHELL

[Ryan Anderson]

(trimming cc: down a bit)

On Thu, Mar 10, 2005 at 06:40:11AM +0100, Sam Ravnborg wrote:
> On Wed, Mar 09, 2005 at 06:25:56PM -0800, Linus Torvalds wrote:
> > On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
> > > BTW, Linus: Any chance you ever change something to version or
> > > extraversion in bk just after a release ? I know I already ask and it
> > > degenerated into a flamefest, and I don't know if that is specifically
> > > the case now, but I keep getting report of people saying "I have a bug
> > > in 2.6.xx" while in fact, they have some kind of bk clone of sometime
> > > after 2.6.xx...
> > 
> > The answer is the same: I'd still like to have somebody (preferably Sam)  
> > who is comfortable with all the build scripts get a revision-control-
> > specific version at build-time, so that BK users would get the top-of-tree 
> > key value, and other people could get some CVS revision or something.
> 
> I have a patch somewhere in my inbox, and got one from Ryan yesterday
> also. I will see if I during the weekend find some time to look at it.

Sam, you'll probably want this on top of the patch I sent.  (I haven't
built in a clean tree in a while, found a minor problem when I was
transitioning to quilt today.)

When running scripts/setlocalversion.sh, use $(CONFIG_SHELL) so the
executable bit doesn't need to be set.

Signed-off-by: Ryan Anderson <ryan@michonline.com>

Index: local-quilt/Makefile
===================================================================
--- local-quilt.orig/Makefile	2005-03-12 20:36:24.000000000 -0500
+++ local-quilt/Makefile	2005-03-12 20:54:40.000000000 -0500
@@ -563,7 +563,7 @@
 
 ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
 	ifeq ($(shell ls -d $(srctree)/BitKeeper 2>/dev/null),$(srctree)/BitKeeper)
-		localversion-bk := $(shell $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+		localversion-bk := $(shell $(CONFIG_SHELL) $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
 		LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
 	endif
 endif


-- 

Ryan Anderson
  sometimes Pug Majere

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

Benjamin Herrenschmidt wrote:

>On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:
>
>  
>
>>2.6.10 seems to have a different kernel panic which I'm investigating 
>>(could be a problem with my ramdisk as it happens in my linuxrc). So 
>>long story short the 2.6.10 sym driver looks ok.
>>    
>>
>
>Can you try 2.6.11 with the 2.6.10 sym driver ?
>
>Ben.
>
>
>
>  
>
I copied over the code from drivers/scsi/sym53c8xx_2/ on 2.6.10 to the 
2.6.11 dir. The machine didn't come back up after the reboot - I will 
have to wait till Monday to see the error as I do not have remote 
console access to the machine - I will report my findings then.

Omkhar

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Omkhar Arasaratnam]

Benjamin Herrenschmidt wrote:

>On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:
>
>  
>
>>2.6.10 seems to have a different kernel panic which I'm investigating 
>>(could be a problem with my ramdisk as it happens in my linuxrc). So 
>>long story short the 2.6.10 sym driver looks ok.
>>    
>>
>
>Can you try 2.6.11 with the 2.6.10 sym driver ?
>
>Ben.
>
>
>
>  
>
The 2.6.11.3 kernel with the 2.6.10 driver seems to fail with the same 
sym2 driver error - so I suppose it goes deeper than the driver itself.


O.

Re: [BUG] 2.6.11- sym53c8xx Broken on pp64

[Benjamin Herrenschmidt]

On Tue, 2005-03-15 at 09:54 -0600, Omkhar Arasaratnam wrote:
> Benjamin Herrenschmidt wrote:

> The 2.6.11.3 kernel with the 2.6.10 driver seems to fail with the same 
> sym2 driver error - so I suppose it goes deeper than the driver itself.
> 

Let's move that to linuxppc64-dev and drop the CC-list. Last message on
this thread.

Ben.

Re: [PATCH] Auto-append localversion for BK users needs to use CONFIG_SHELL

[Sam Ravnborg]

On Sat, Mar 12, 2005 at 11:32:29PM -0500, Ryan Anderson wrote:
> 
> Sam, you'll probably want this on top of the patch I sent.  (I haven't
> built in a clean tree in a while, found a minor problem when I was
> transitioning to quilt today.)

Combined this to one patch and applied it.
Let's see what feedback lkml gives.

	Sam