Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Fri, 2007-11-30 at 11:34 +0100, Anders Henke wrote: Am 30.11.2007 schrieb FUJITA Tomonori: According to the 2.6.23-rc1 short-form changelog, there is one major edit on the dpt_i2o driver: FUJITA Tomonori [SCSI] dpt_i2o: convert to use the data buffer accessors Stephen Rothwell dpt_i2o depends on virt_to_bus Fujita, would you please take a look at this? In between, I've ruled out that the static assignment isn't source of the problem. And due to some manually made make clean which didn't clean enough, I've also pointed out the wrong patch - sorry, Fujita, definitely the right one which breaks my boxes is the dpt_i2o patch from 2.6.23-rc2 to 2.6.23-rc3 (7 kb in Size) from Matthew Wilcox. commit 55d9fcf57ba5ec427544fca7abc335cf3da78160 Author: Matthew Wilcox [EMAIL PROTECTED] Date: Mon Jul 30 15:19:18 2007 -0600 [SCSI] dpt_i2o: convert to SCSI hotplug model I just noticed the same bug when I tried to update a 2.6.18 server to 2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init segfaults, or can't be found .. anyway, driver/fs errors. In the kernel config, under processor type and features, I disabled 64GB memory support (changed to 4GB) and I also disabled 64 bit Memory and IO resources and the problem went away. Do you by any chance happen to have those features enabled ? The dpt_i2o driver is not 64-bit clean, it happens to work with PAE/64-bit dma in earlier kernels but that might be by chance. Perhaps the different initialization ordering exposes the problem. I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that driver. I intended to submit it for 2.6.25 or so ... if I have some time later today or tomorrow I'll try that next to see if that makes a difference. Mike. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Tue, 2007-12-11 at 15:40 +0100, Miquel van Smoorenburg wrote: I just noticed the same bug when I tried to update a 2.6.18 server to 2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init segfaults, or can't be found .. anyway, driver/fs errors. In the kernel config, under processor type and features, I disabled 64GB memory support (changed to 4GB) and I also disabled 64 bit Memory and IO resources and the problem went away. Do you by any chance happen to have those features enabled ? The dpt_i2o driver is not 64-bit clean, it happens to work with PAE/64-bit dma in earlier kernels but that might be by chance. Perhaps the different initialization ordering exposes the problem. I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that driver. I intended to submit it for 2.6.25 or so ... if I have some time later today or tomorrow I'll try that next to see if that makes a difference. I just recompiled 2.6.23.9 with the 64 bit patch for dpt_i2o and now it boots just fine. The patch is here: http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch It's not the final version - it needs a few cleanups before it can be submitted, but perhaps you can test if it also works for you. Mike. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Tue, 4 Dec 2007 Andrew Morton wrote: On Wed, 05 Dec 2007 10:30:54 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 17:11:55 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke [EMAIL PROTECTED] wrote: On November 28 2007, Anders Henke wrote: As everything is reported as being zero is quite odd an Jan took a guess that it might be block-layer or driver-related, I've assumed that the driver is responsible for this; just out of the curiousity, I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me. I haven't yet fine-tested from which kernel release on the dpt_i2o driver behaves like this and spews out zeroed blocks when trying to mount the rootfs. Maybe this is just some timing issue. I've started the fine-tests and can say so far that dpt_i2o from 2.6.22 is still fine. Test is simple: [EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/ ... recompile the kernel, reboot: works. 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different patch sets: -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1 -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3 -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10. When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel, the zero blocks-symptom show up, so it's the lucky situation that the smallest patch actually seams to be the broken one. According to the 2.6.23-rc1 short-form changelog, there is one major edit on the dpt_i2o driver: FUJITA Tomonori [SCSI] dpt_i2o: convert to use the data buffer accessors Stephen Rothwell dpt_i2o depends on virt_to_bus Fujita, would you please take a look at this? He won't have seen this. cc's added. I think that something's broken in there, leading to the dpt_i2o sending out blocks of zeroes right after initialization, at least on some specific controllers (in this case, Adaptec 2010S on Intel SE7501WV2S-based boxes). I don't have insight kernel driver development knowledge, so I'm quite out of help right now. Nevertheless, I'll add the diff from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o: Can you please confirm that this revert (against 2.6.24-rc4) fixes the data corruption problems? Anders said that my patch is fine and seems that Matthew's hotplug conversion patch leads to the problem: http://marc.info/?l=linux-kernelm=119641892129732w=2 Oh. Jan broke message threading :( So it's been nearly a week and nothing has happened? Do we revert that change? SCSI people really want this conversion... Matthew, did you have a chance to look at it? It seems pretty improbably that a change of that nature could cause data corruption. Anders, are you able to determine whether the revert (against current Linus mainline or 2.6.24-rc4) fixes things? Because it would be very strange... This is a grave bug. It's really quite urgent... Thanks. drivers/scsi/dpt_i2o.c | 132 ++- drivers/scsi/dpti.h|9 ++ 2 files changed, 68 insertions(+), 73 deletions(-) I've done the following: -untared a clean 2.6.24-rc4 and compiled it with my 2.6.23.1-settings in order to verify that the driver is still broken: checked, the box still won't boot. -patched the just compiled kernel source with your patch, make dist-clean (by means of make-kpkg clean) and recompile: box boots fine. I've put the captured console logs to http://w.sysiphus.de/dpt_i2o/bootlog.2624-rc4-pristine http://w.sysiphus.de/dpt_i2o/bootlog.2624-rc4-patched ... and the kernelconfig (which shouldn't matter) to http://w.sysiphus.de/dpt_i2o/kernelconfig.2624-rc4 Regards, Anders -- 11 Internet AGEnter any 11-digit prime number to continue. Brauerstrasse 48 v://49.721.91374.50 D-76135 Karlsruhe f://49.721.91374.225 Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe from this list: send the line unsubscribe linux-scsi
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Wed, 5 Dec 2007 11:14:41 +0100 Anders Henke [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 Andrew Morton wrote: On Wed, 05 Dec 2007 10:30:54 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 17:11:55 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke [EMAIL PROTECTED] wrote: On November 28 2007, Anders Henke wrote: As everything is reported as being zero is quite odd an Jan took a guess that it might be block-layer or driver-related, I've assumed that the driver is responsible for this; just out of the curiousity, I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me. I haven't yet fine-tested from which kernel release on the dpt_i2o driver behaves like this and spews out zeroed blocks when trying to mount the rootfs. Maybe this is just some timing issue. I've started the fine-tests and can say so far that dpt_i2o from 2.6.22 is still fine. Test is simple: [EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/ ... recompile the kernel, reboot: works. 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different patch sets: -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1 -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3 -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10. When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel, the zero blocks-symptom show up, so it's the lucky situation that the smallest patch actually seams to be the broken one. According to the 2.6.23-rc1 short-form changelog, there is one major edit on the dpt_i2o driver: FUJITA Tomonori [SCSI] dpt_i2o: convert to use the data buffer accessors Stephen Rothwell dpt_i2o depends on virt_to_bus Fujita, would you please take a look at this? He won't have seen this. cc's added. I think that something's broken in there, leading to the dpt_i2o sending out blocks of zeroes right after initialization, at least on some specific controllers (in this case, Adaptec 2010S on Intel SE7501WV2S-based boxes). I don't have insight kernel driver development knowledge, so I'm quite out of help right now. Nevertheless, I'll add the diff from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o: Can you please confirm that this revert (against 2.6.24-rc4) fixes the data corruption problems? Anders said that my patch is fine and seems that Matthew's hotplug conversion patch leads to the problem: http://marc.info/?l=linux-kernelm=119641892129732w=2 Oh. Jan broke message threading :( So it's been nearly a week and nothing has happened? Do we revert that change? SCSI people really want this conversion... Matthew, did you have a chance to look at it? It seems pretty improbably that a change of that nature could cause data corruption. Anders, are you able to determine whether the revert (against current Linus mainline or 2.6.24-rc4) fixes things? Because it would be very strange... This is a grave bug. It's really quite urgent... Thanks. drivers/scsi/dpt_i2o.c | 132 ++- drivers/scsi/dpti.h|9 ++ 2 files changed, 68 insertions(+), 73 deletions(-) I've done the following: -untared a clean 2.6.24-rc4 and compiled it with my 2.6.23.1-settings in order to verify that the driver is still broken: checked, the box still won't boot. -patched the just compiled kernel source with your patch, make dist-clean (by means of make-kpkg clean) and recompile: box boots fine. I've put the captured console logs to http://w.sysiphus.de/dpt_i2o/bootlog.2624-rc4-pristine http://w.sysiphus.de/dpt_i2o/bootlog.2624-rc4-patched ... and the kernelconfig (which shouldn't matter) to http://w.sysiphus.de/dpt_i2o/kernelconfig.2624-rc4 Thanks for testing. So reverting Matthew's hotplug patch fixes the problem though I have no idea how the patch leads to this. Seems that nobody has any clue on that. We need to revert that patch for the moment. - To unsubscribe from this list: send the line unsubscribe
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Thu, 06 Dec 2007 14:49:37 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: drivers/scsi/dpt_i2o.c | 132 ++- drivers/scsi/dpti.h|9 ++ 2 files changed, 68 insertions(+), 73 deletions(-) I've done the following: -untared a clean 2.6.24-rc4 and compiled it with my 2.6.23.1-settings in order to verify that the driver is still broken: checked, the box still won't boot. -patched the just compiled kernel source with your patch, make dist-clean (by means of make-kpkg clean) and recompile: box boots fine. I've put the captured console logs to http://w.sysiphus.de/dpt_i2o/bootlog.2624-rc4-pristine http://w.sysiphus.de/dpt_i2o/bootlog.2624-rc4-patched ... and the kernelconfig (which shouldn't matter) to http://w.sysiphus.de/dpt_i2o/kernelconfig.2624-rc4 Thanks for testing. So reverting Matthew's hotplug patch fixes the problem though I have no idea how the patch leads to this. Seems that nobody has any clue on that. We need to revert that patch for the moment. OK, thanks. Let's leave it a couple of days for people to register objections, have bright ideas, etc. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Thu, 29 Nov 2007 13:31:50 +0100
Anders Henke [EMAIL PROTECTED] wrote:
On November 28 2007, Anders Henke wrote:
As everything is reported as being zero is quite odd an Jan took a
guess that it might be block-layer or driver-related, I've assumed
that the driver is responsible for this; just out of the curiousity,
I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
I haven't yet fine-tested from which kernel release on the dpt_i2o driver
behaves like this and spews out zeroed blocks when trying to mount
the rootfs. Maybe this is just some timing issue.
I've started the fine-tests and can say so far that dpt_i2o from
2.6.22 is still fine. Test is simple:
[EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/
dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
... recompile the kernel, reboot: works.
2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
patch sets:
-one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
-one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
-one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel,
the zero blocks-symptom show up, so it's the lucky situation
that the smallest patch actually seams to be the broken one.
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
He won't have seen this. cc's added.
I think that something's broken in there, leading to the dpt_i2o
sending out blocks of zeroes right after initialization, at least on
some specific controllers (in this case, Adaptec 2010S on Intel
SE7501WV2S-based boxes).
I don't have insight kernel driver development knowledge, so I'm
quite out of help right now. Nevertheless, I'll add the diff
from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o:
Can you please confirm that this revert (against 2.6.24-rc4) fixes the data
corruption problems?
Thanks.
diff -puN
drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-use-the-data-buffer-accessors
drivers/scsi/dpt_i2o.c
---
a/drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-use-the-data-buffer-accessors
+++ a/drivers/scsi/dpt_i2o.c
@@ -2062,13 +2062,12 @@ static s32 adpt_scsi_to_i2o(adpt_hba* pH
u32 *lenptr;
int direction;
int scsidir;
- int nseg;
u32 len;
u32 reqlen;
s32 rcode;
memset(msg, 0 , sizeof(msg));
- len = scsi_bufflen(cmd);
+ len = cmd-request_bufflen;
direction = 0x;
scsidir = 0x; // DATA NO XFER
@@ -2125,21 +2124,21 @@ static s32 adpt_scsi_to_i2o(adpt_hba* pH
lenptr=mptr++; /* Remember me - fill in when we know */
reqlen = 14;// SINGLE SGE
/* Now fill in the SGList and command */
+ if(cmd-use_sg) {
+ struct scatterlist *sg = (struct scatterlist
*)cmd-request_buffer;
+ int sg_count = pci_map_sg(pHba-pDev, sg, cmd-use_sg,
+ cmd-sc_data_direction);
- nseg = scsi_dma_map(cmd);
- BUG_ON(nseg 0);
- if (nseg) {
- struct scatterlist *sg;
len = 0;
- scsi_for_each_sg(cmd, sg, nseg, i) {
+ for(i = 0 ; i sg_count; i++) {
*mptr++ = direction|0x1000|sg_dma_len(sg);
len+=sg_dma_len(sg);
*mptr++ = sg_dma_address(sg);
- /* Make this an end of list */
- if (i == nseg - 1)
- mptr[-2] = direction|0xD000|sg_dma_len(sg);
+ sg++;
}
+ /* Make this an end of list */
+ mptr[-2] = direction|0xD000|sg_dma_len(sg-1);
reqlen = mptr - msg;
*lenptr = len;
@@ -2148,8 +2147,16 @@ static s32 adpt_scsi_to_i2o(adpt_hba* pH
len, cmd-underflow);
}
} else {
- *lenptr = len = 0;
- reqlen = 12;
+ *lenptr = len = cmd-request_bufflen;
+ if(len == 0) {
+ reqlen = 12;
+ } else {
+ *mptr++ = 0xD000|direction|cmd-request_bufflen;
+ *mptr++ = pci_map_single(pHba-pDev,
+ cmd-request_buffer,
+ cmd-request_bufflen,
+ cmd-sc_data_direction);
+ }
}
/*
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke [EMAIL PROTECTED] wrote: On November 28 2007, Anders Henke wrote: As everything is reported as being zero is quite odd an Jan took a guess that it might be block-layer or driver-related, I've assumed that the driver is responsible for this; just out of the curiousity, I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me. I haven't yet fine-tested from which kernel release on the dpt_i2o driver behaves like this and spews out zeroed blocks when trying to mount the rootfs. Maybe this is just some timing issue. I've started the fine-tests and can say so far that dpt_i2o from 2.6.22 is still fine. Test is simple: [EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/ ... recompile the kernel, reboot: works. 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different patch sets: -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1 -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3 -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10. When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel, the zero blocks-symptom show up, so it's the lucky situation that the smallest patch actually seams to be the broken one. According to the 2.6.23-rc1 short-form changelog, there is one major edit on the dpt_i2o driver: FUJITA Tomonori [SCSI] dpt_i2o: convert to use the data buffer accessors Stephen Rothwell dpt_i2o depends on virt_to_bus Fujita, would you please take a look at this? He won't have seen this. cc's added. I think that something's broken in there, leading to the dpt_i2o sending out blocks of zeroes right after initialization, at least on some specific controllers (in this case, Adaptec 2010S on Intel SE7501WV2S-based boxes). I don't have insight kernel driver development knowledge, so I'm quite out of help right now. Nevertheless, I'll add the diff from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o: Can you please confirm that this revert (against 2.6.24-rc4) fixes the data corruption problems? Anders said that my patch is fine and seems that Matthew's hotplug conversion patch leads to the problem: http://marc.info/?l=linux-kernelm=119641892129732w=2 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke [EMAIL PROTECTED] wrote: On November 28 2007, Anders Henke wrote: As everything is reported as being zero is quite odd an Jan took a guess that it might be block-layer or driver-related, I've assumed that the driver is responsible for this; just out of the curiousity, I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me. I haven't yet fine-tested from which kernel release on the dpt_i2o driver behaves like this and spews out zeroed blocks when trying to mount the rootfs. Maybe this is just some timing issue. I've started the fine-tests and can say so far that dpt_i2o from 2.6.22 is still fine. Test is simple: [EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/ ... recompile the kernel, reboot: works. 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different patch sets: -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1 -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3 -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10. When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel, the zero blocks-symptom show up, so it's the lucky situation that the smallest patch actually seams to be the broken one. According to the 2.6.23-rc1 short-form changelog, there is one major edit on the dpt_i2o driver: FUJITA Tomonori [SCSI] dpt_i2o: convert to use the data buffer accessors Stephen Rothwell dpt_i2o depends on virt_to_bus Fujita, would you please take a look at this? He won't have seen this. cc's added. I think that something's broken in there, leading to the dpt_i2o sending out blocks of zeroes right after initialization, at least on some specific controllers (in this case, Adaptec 2010S on Intel SE7501WV2S-based boxes). I don't have insight kernel driver development knowledge, so I'm quite out of help right now. Nevertheless, I'll add the diff from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o: Can you please confirm that this revert (against 2.6.24-rc4) fixes the data corruption problems? Anders said that my patch is fine and seems that Matthew's hotplug conversion patch leads to the problem: http://marc.info/?l=linux-kernelm=119641892129732w=2 Oh. Jan broke message threading :( So it's been nearly a week and nothing has happened? Do we revert that change? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Tue, 4 Dec 2007 17:11:55 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke [EMAIL PROTECTED] wrote: On November 28 2007, Anders Henke wrote: As everything is reported as being zero is quite odd an Jan took a guess that it might be block-layer or driver-related, I've assumed that the driver is responsible for this; just out of the curiousity, I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me. I haven't yet fine-tested from which kernel release on the dpt_i2o driver behaves like this and spews out zeroed blocks when trying to mount the rootfs. Maybe this is just some timing issue. I've started the fine-tests and can say so far that dpt_i2o from 2.6.22 is still fine. Test is simple: [EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/ ... recompile the kernel, reboot: works. 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different patch sets: -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1 -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3 -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10. When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel, the zero blocks-symptom show up, so it's the lucky situation that the smallest patch actually seams to be the broken one. According to the 2.6.23-rc1 short-form changelog, there is one major edit on the dpt_i2o driver: FUJITA Tomonori [SCSI] dpt_i2o: convert to use the data buffer accessors Stephen Rothwell dpt_i2o depends on virt_to_bus Fujita, would you please take a look at this? He won't have seen this. cc's added. I think that something's broken in there, leading to the dpt_i2o sending out blocks of zeroes right after initialization, at least on some specific controllers (in this case, Adaptec 2010S on Intel SE7501WV2S-based boxes). I don't have insight kernel driver development knowledge, so I'm quite out of help right now. Nevertheless, I'll add the diff from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o: Can you please confirm that this revert (against 2.6.24-rc4) fixes the data corruption problems? Anders said that my patch is fine and seems that Matthew's hotplug conversion patch leads to the problem: http://marc.info/?l=linux-kernelm=119641892129732w=2 Oh. Jan broke message threading :( So it's been nearly a week and nothing has happened? Do we revert that change? SCSI people really want this conversion... Matthew, did you have a chance to look at it? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
On Wed, 05 Dec 2007 10:30:54 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Tue, 4 Dec 2007 17:11:55 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 05 Dec 2007 10:04:03 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Tue, 4 Dec 2007 16:57:38 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 29 Nov 2007 13:31:50 +0100
Anders Henke [EMAIL PROTECTED] wrote:
On November 28 2007, Anders Henke wrote:
As everything is reported as being zero is quite odd an Jan took a
guess that it might be block-layer or driver-related, I've assumed
that the driver is responsible for this; just out of the
curiousity,
I've manually replaced the dpt_i2o driver by the 2.6.19 one by
copying
driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into
a
vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
I haven't yet fine-tested from which kernel release on the dpt_i2o
driver
behaves like this and spews out zeroed blocks when trying to mount
the rootfs. Maybe this is just some timing issue.
I've started the fine-tests and can say so far that dpt_i2o from
2.6.22 is still fine. Test is simple:
[EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/
dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
... recompile the kernel, reboot: works.
2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two
different
patch sets:
-one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
-one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
-one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel,
the zero blocks-symptom show up, so it's the lucky situation
that the smallest patch actually seams to be the broken one.
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
He won't have seen this. cc's added.
I think that something's broken in there, leading to the dpt_i2o
sending out blocks of zeroes right after initialization, at least on
some specific controllers (in this case, Adaptec 2010S on Intel
SE7501WV2S-based boxes).
I don't have insight kernel driver development knowledge, so I'm
quite out of help right now. Nevertheless, I'll add the diff
from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o:
Can you please confirm that this revert (against 2.6.24-rc4) fixes the
data
corruption problems?
Anders said that my patch is fine and seems that Matthew's hotplug
conversion patch leads to the problem:
http://marc.info/?l=linux-kernelm=119641892129732w=2
Oh. Jan broke message threading :(
So it's been nearly a week and nothing has happened? Do we revert that
change?
SCSI people really want this conversion...
Matthew, did you have a chance to look at it?
It seems pretty improbably that a change of that nature could cause data
corruption. Anders, are you able to determine whether the revert (against
current Linus mainline or 2.6.24-rc4) fixes things? Because it would be
very strange...
This is a grave bug. It's really quite urgent...
Thanks.
drivers/scsi/dpt_i2o.c | 132 ++-
drivers/scsi/dpti.h|9 ++
2 files changed, 68 insertions(+), 73 deletions(-)
diff -puN drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-scsi-hotplug-model
drivers/scsi/dpt_i2o.c
--- a/drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-scsi-hotplug-model
+++ a/drivers/scsi/dpt_i2o.c
@@ -173,20 +173,20 @@ static struct pci_device_id dptids[] = {
};
MODULE_DEVICE_TABLE(pci,dptids);
-static void adpt_exit(void);
-
-static int adpt_detect(void)
+static int adpt_detect(struct scsi_host_template* sht)
{
struct pci_dev *pDev = NULL;
adpt_hba* pHba;
+ adpt_init();
+
PINFO(Detecting Adaptec I2O RAID controllers...\n);
/* search for all Adatpec I2O RAID cards */
while ((pDev = pci_get_device( PCI_DPT_VENDOR_ID, PCI_ANY_ID, pDev))) {
if(pDev-device == PCI_DPT_DEVICE_ID ||
pDev-device == PCI_DPT_RAPTOR_DEVICE_ID){
- if(adpt_install_hba(pDev) ){
+ if(adpt_install_hba(sht, pDev) ){
PERROR(Could not Init an I2O RAID device\n);
PERROR(Will not try to detect others.\n);
return hba_count-1;
@@ -248,33 +248,34 @@ rebuild_sys_tab:
}
for (pHba = hba_chain; pHba;
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
Am 29.11.2007 schrieb Matthew Wilcox:
On Thu, Nov 29, 2007 at 05:45:57PM +0100, Anders Henke wrote:
On Nov 29 2007, FUJITA Tomonori wrote:
@@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
- .use_sg_chaining= ENABLE_SG_CHAINING,
+ .use_sg_chaining= DISABLE_SG_CHAINING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
The structure to patch does look different and doesn't include an
tag use_sg_chaining:
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
Just add the line
.use_sg_chaining= DISABLE_SG_CHAINING,
};
Just out of curiosity, I've tried 2.6.24-rc3 and patched the kernel
accordingly (DISABLE_SG_CHAINING): doesn't boot successfully,
same error as usual:
EXT2-fs error (device sda1): ext2_check_page: bad entry in directory #2:
rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
As sent in a parallel mail, I've found out that 2.6.23-rc2 works and
2.6.23-rc3 shows the same problems - so the problem has to be searched
in the dpt_i2o-changes made for 2.6.23-rc3.
Anders
--
11 Internet AG System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhef://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
Am 30.11.2007 schrieb FUJITA Tomonori:
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
Sorry about the bug. Can you try this?
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 8258506..1255b26 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
- .use_sg_chaining= ENABLE_SG_CHAINING,
+ .use_sg_chaining= DISABLE_SG_CHAINING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
The structure to patch does look different and doesn't include an
tag use_sg_chaining:
Sorry, I misread your bug report. If you use 2.6.23, the sg chaining
is unrelated.
What architecture do you use?
Mainstream 32-bit-x86, the affected boxes are running Intel Xeons (P4)
at 2.66 or 2.8 GHz.
In between, I've ruled out that the static assignment isn't
source of the problem. And due to some manually made make clean which
didn't clean enough, I've also pointed out the wrong patch - sorry,
Fujita, definitely the right one which breaks my boxes is the dpt_i2o patch
from 2.6.23-rc2 to 2.6.23-rc3 (7 kb in Size) from Matthew Wilcox.
commit 55d9fcf57ba5ec427544fca7abc335cf3da78160
Author: Matthew Wilcox [EMAIL PROTECTED]
Date: Mon Jul 30 15:19:18 2007 -0600
[SCSI] dpt_i2o: convert to SCSI hotplug model
- Delete refereces to HOSTS_C
- Switch to module_init/module_exit instead of detect/release
- Don't pass around the host template and rename it to
adpt_template
- Switch from scsi_register/scsi_unregister to scsi_host_alloc,
scsi_add_host, scsi_scan_host and scsi_host_put.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
Acked-by: Salyzyn, Mark [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
Definitely as in
-applied the diff-patch onto 2.6.23.1 with a dpt_i2o from 2.6.23-rc1
to verify that booting failes.
-Recompiled a clean unpacked 2.6.23-rc2 to verify that the driver
from -rc2 still works.
-Recompiled a clean unpacked 2.6.23-rc3 to verify that the driver
from -rc3 breaks booting on my boxes.
So sorry for mispointing the bug to you, it's an issue for Matthew.
Anders
--
11 Internet AG System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhef://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
Adding relevant people and lists to CC...
Honza
- Forwarded message from Anders Henke [EMAIL PROTECTED] -
Date: Thu, 29 Nov 2007 13:31:50 +0100
From: Anders Henke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in
directory)
User-Agent: Mutt/1.5.13 (2006-08-11)
On November 28 2007, Anders Henke wrote:
As everything is reported as being zero is quite odd an Jan took a
guess that it might be block-layer or driver-related, I've assumed
that the driver is responsible for this; just out of the curiousity,
I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
I haven't yet fine-tested from which kernel release on the dpt_i2o driver
behaves like this and spews out zeroed blocks when trying to mount
the rootfs. Maybe this is just some timing issue.
I've started the fine-tests and can say so far that dpt_i2o from
2.6.22 is still fine. Test is simple:
[EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c
dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
... recompile the kernel, reboot: works.
2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
patch sets:
-one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
-one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
-one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel,
the zero blocks-symptom show up, so it's the lucky situation
that the smallest patch actually seams to be the broken one.
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
I think that something's broken in there, leading to the dpt_i2o
sending out blocks of zeroes right after initialization, at least on
some specific controllers (in this case, Adaptec 2010S on Intel
SE7501WV2S-based boxes).
I don't have insight kernel driver development knowledge, so I'm
quite out of help right now. Nevertheless, I'll add the diff
from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o:
---cut
diff -Nur linux-2.6.22/drivers/scsi/dpt_i2o.c
linux-2.6.23-rc1/drivers/scsi/dpt_i2o.c
--- linux-2.6.22/drivers/scsi/dpt_i2o.c 2007-07-09 01:32:17.0 +0200
+++ linux-2.6.23-rc1/drivers/scsi/dpt_i2o.c 2007-07-22 22:41:00.0
+0200
@@ -2078,12 +2078,13 @@
u32 *lenptr;
int direction;
int scsidir;
+ int nseg;
u32 len;
u32 reqlen;
s32 rcode;
memset(msg, 0 , sizeof(msg));
- len = cmd-request_bufflen;
+ len = scsi_bufflen(cmd);
direction = 0x;
scsidir = 0x; // DATA NO XFER
@@ -2140,21 +2141,21 @@
lenptr=mptr++; /* Remember me - fill in when we know */
reqlen = 14;// SINGLE SGE
/* Now fill in the SGList and command */
- if(cmd-use_sg) {
- struct scatterlist *sg = (struct scatterlist
*)cmd-request_buffer;
- int sg_count = pci_map_sg(pHba-pDev, sg, cmd-use_sg,
- cmd-sc_data_direction);
+ nseg = scsi_dma_map(cmd);
+ BUG_ON(nseg 0);
+ if (nseg) {
+ struct scatterlist *sg;
len = 0;
- for(i = 0 ; i sg_count; i++) {
+ scsi_for_each_sg(cmd, sg, nseg, i) {
*mptr++ = direction|0x1000|sg_dma_len(sg);
len+=sg_dma_len(sg);
*mptr++ = sg_dma_address(sg);
- sg++;
+ /* Make this an end of list */
+ if (i == nseg - 1)
+ mptr[-2] = direction|0xD000|sg_dma_len(sg);
}
- /* Make this an end of list */
- mptr[-2] = direction|0xD000|sg_dma_len(sg-1);
reqlen = mptr - msg;
*lenptr = len;
@@ -2163,16 +2164,8 @@
len, cmd-underflow);
}
} else {
- *lenptr = len = cmd-request_bufflen;
- if(len == 0) {
- reqlen = 12;
- } else {
- *mptr++ = 0xD000|direction|cmd-request_bufflen;
- *mptr++ = pci_map_single(pHba-pDev,
- cmd-request_buffer,
- cmd-request_bufflen,
- cmd-sc_data_direction);
- }
+ *lenptr = len = 0;
+
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Thu, 29 Nov 2007 14:03:19 +0100
Jan Kara [EMAIL PROTECTED] wrote:
Adding relevant people and lists to CC...
Honza
- Forwarded message from Anders Henke [EMAIL PROTECTED] -
Date: Thu, 29 Nov 2007 13:31:50 +0100
From: Anders Henke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in
directory)
User-Agent: Mutt/1.5.13 (2006-08-11)
On November 28 2007, Anders Henke wrote:
As everything is reported as being zero is quite odd an Jan took a
guess that it might be block-layer or driver-related, I've assumed
that the driver is responsible for this; just out of the curiousity,
I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
I haven't yet fine-tested from which kernel release on the dpt_i2o driver
behaves like this and spews out zeroed blocks when trying to mount
the rootfs. Maybe this is just some timing issue.
I've started the fine-tests and can say so far that dpt_i2o from
2.6.22 is still fine. Test is simple:
[EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/
dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
... recompile the kernel, reboot: works.
2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
patch sets:
-one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
-one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
-one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel,
the zero blocks-symptom show up, so it's the lucky situation
that the smallest patch actually seams to be the broken one.
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
Sorry about the bug. Can you try this?
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 8258506..1255b26 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
- .use_sg_chaining= ENABLE_SG_CHAINING,
+ .use_sg_chaining= DISABLE_SG_CHAINING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Nov 29 2007, FUJITA Tomonori wrote:
On Thu, 29 Nov 2007 14:03:19 +0100
Jan Kara [EMAIL PROTECTED] wrote:
Adding relevant people and lists to CC...
Honza
- Forwarded message from Anders Henke [EMAIL PROTECTED] -
Date: Thu, 29 Nov 2007 13:31:50 +0100
From: Anders Henke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in
directory)
User-Agent: Mutt/1.5.13 (2006-08-11)
On November 28 2007, Anders Henke wrote:
As everything is reported as being zero is quite odd an Jan took a
guess that it might be block-layer or driver-related, I've assumed
that the driver is responsible for this; just out of the curiousity,
I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
I haven't yet fine-tested from which kernel release on the dpt_i2o driver
behaves like this and spews out zeroed blocks when trying to mount
the rootfs. Maybe this is just some timing issue.
I've started the fine-tests and can say so far that dpt_i2o from
2.6.22 is still fine. Test is simple:
[EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/
dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
... recompile the kernel, reboot: works.
2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
patch sets:
-one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
-one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
-one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel,
the zero blocks-symptom show up, so it's the lucky situation
that the smallest patch actually seams to be the broken one.
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
Sorry about the bug. Can you try this?
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 8258506..1255b26 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
- .use_sg_chaining= ENABLE_SG_CHAINING,
+ .use_sg_chaining= DISABLE_SG_CHAINING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
The structure to patch does look different and doesn't include an
tag use_sg_chaining:
---cut
static struct scsi_host_template adpt_template = {
.name = dpt_i2o,
.proc_name = dpt_i2o,
.proc_info = adpt_proc_info,
.info = adpt_info,
.queuecommand = adpt_queue,
.eh_abort_handler = adpt_abort,
.eh_device_reset_handler = adpt_device_reset,
.eh_bus_reset_handler = adpt_bus_reset,
.eh_host_reset_handler = adpt_reset,
.bios_param = adpt_bios_param,
.slave_configure= adpt_slave_configure,
.can_queue = MAX_TO_IOP_MESSAGES,
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
---cut
Anders
--
11 Internet AG System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhef://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Thu, Nov 29, 2007 at 05:45:57PM +0100, Anders Henke wrote:
On Nov 29 2007, FUJITA Tomonori wrote:
@@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
- .use_sg_chaining= ENABLE_SG_CHAINING,
+ .use_sg_chaining= DISABLE_SG_CHAINING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
The structure to patch does look different and doesn't include an
tag use_sg_chaining:
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
Just add the line
.use_sg_chaining= DISABLE_SG_CHAINING,
};
--
Intel are signing my paycheques ... these opinions are still mine
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Thu, 29 Nov 2007 17:45:57 +0100
Anders Henke [EMAIL PROTECTED] wrote:
On Nov 29 2007, FUJITA Tomonori wrote:
On Thu, 29 Nov 2007 14:03:19 +0100
Jan Kara [EMAIL PROTECTED] wrote:
Adding relevant people and lists to CC...
Honza
- Forwarded message from Anders Henke [EMAIL PROTECTED] -
Date: Thu, 29 Nov 2007 13:31:50 +0100
From: Anders Henke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in
directory)
User-Agent: Mutt/1.5.13 (2006-08-11)
On November 28 2007, Anders Henke wrote:
As everything is reported as being zero is quite odd an Jan took a
guess that it might be block-layer or driver-related, I've assumed
that the driver is responsible for this; just out of the curiousity,
I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
I haven't yet fine-tested from which kernel release on the dpt_i2o
driver
behaves like this and spews out zeroed blocks when trying to mount
the rootfs. Maybe this is just some timing issue.
I've started the fine-tests and can say so far that dpt_i2o from
2.6.22 is still fine. Test is simple:
[EMAIL PROTECTED]:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/
dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
... recompile the kernel, reboot: works.
2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
patch sets:
-one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
-one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
-one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
When applying the 2.6.23-rc1-based driver to my 2.6.31.1 kernel,
the zero blocks-symptom show up, so it's the lucky situation
that the smallest patch actually seams to be the broken one.
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
Sorry about the bug. Can you try this?
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 8258506..1255b26 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
- .use_sg_chaining= ENABLE_SG_CHAINING,
+ .use_sg_chaining= DISABLE_SG_CHAINING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
The structure to patch does look different and doesn't include an
tag use_sg_chaining:
Sorry, I misread your bug report. If you use 2.6.23, the sg chaining
is unrelated.
What architecture do you use?
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
