2.6.11- sym53c8xx Broken on pp64
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
Quoted 7 lines · 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?
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.
Quoted 7 lines · Benjamin Herrenschmidt
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
Quoted 9 lines · Linus Torvalds
Quoted 7 lines · Benjamin Herrenschmidt
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...
Quoted 4 lines
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:
Quoted 2 lines
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.)
Makefile +18 -0
@@ -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
init/Kconfig +12 -0
@@ -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
scripts/setlocalversion new file +62 -0
62 lines not on this page · raw message
scripts/setlocalversion.sh new file +26 -0
@@ -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
Signature · 2 lines
Ryan Anderson sometimes Pug Majere
Quoted 11 lines · Linus Torvalds
Quoted 7 lines · Benjamin Herrenschmidt
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...
Quoted 4 lines
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
PATCH 1/1 Auto-append localversion for BK users needs to use CONFIG_SHELL
(trimming cc: down a bit)
Quoted 9 lines · Sam Ravnborg
Quoted 8 lines · Linus Torvalds
Quoted 6 lines · Benjamin Herrenschmidt
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...
Quoted 7 lines
Quoted 4 lines
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.
Makefile +1 -1
@@ -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
Signature · 2 lines
Ryan Anderson sometimes Pug Majere
Re: [PATCH] Auto-append localversion for BK users needs to use CONFIG_SHELL
Quoted 4 lines · Ryan Anderson
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
Quoted 5 lines · Benjamin Herrenschmidt
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.
Quoted 8 lines · Omkhar Arasaratnam
Quoted 5 lines · Benjamin Herrenschmidt
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
Quoted 3 lines · Omkhar Arasaratnam
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?
Quoted 3 lines
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
Quoted 7 lines · Linus Torvalds
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
Quoted 9 lines · Linus Torvalds
Quoted 3 lines · Omkhar Arasaratnam
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?
Quoted 6 lines
Quoted 3 lines
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.
arch/ppc64/mm/init.c +6 -4
@@ -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.
Quoted 7 lines · Benjamin Herrenschmidt
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 theset_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.
Signature · 6 lines
"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
Quoted 4 lines · Matthew Wilcox
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
Quoted 10 lines · James Bottomley
Quoted 6 lines · Matthew Wilcox
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.
Quoted 9 lines
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
Quoted 3 lines · Omkhar Arasaratnam
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.
Quoted 4 lines · Benjamin Herrenschmidt
On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:
Quoted 12 lines
Quoted 3 lines
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.
Quoted 4 lines · Benjamin Herrenschmidt
On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:
Quoted 12 lines
Quoted 3 lines
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
Quoted 4 lines · Benjamin Herrenschmidt
On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:
Quoted 12 lines
Quoted 3 lines
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.
Quoted 5 lines · Omkhar Arasaratnam
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.