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
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.
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
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.
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
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
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
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 <[email protected]>
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 <[email protected]> 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
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
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 <[email protected]>
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.
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
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
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
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.
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.
(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 <[email protected]>
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
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
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.
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.
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