broken dpt_i2o (was: ext2_check_page: bad entry in directory)

DISCUSSION Anders Henke 3 participants 10 messages Nov 28, 2007 – Dec 6, 2007 SCSI

Share & tools

Anders Henke

author

2007-11-28 17:42 UTC #0 lore raw

Hi,

I've been bitten by the problem noted in the lkml message of rougly the same subject, dated back on Oct/24/2007.
My boxes were running 2.6.19 and have been upgraded to 2.6.23.1, but their bootup failed when trying to mount the root (ext2) filesystem:

---cut
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Loading Adaptec I2O RAID: Version 2.4 Build 5go
Detecting Adaptec I2O RAID controllers...
ACPI: PCI Interrupt 0000:04:08.0[A] -> GSI 48 (level, low) -> IRQ 16 Adaptec I2O RAID controller 0 irq=16

     BAR0 f8880000 - size= 100000
     BAR1 f8a00000 - size= 1000000

dpti: If you have a lot of devices this could take a few minutes.
dpti0: Reading the hardware resource table.
TID 008 Vendor: ADAPTEC Device: AIC-7902 Rev: 00000001
TID 009 Vendor: ADAPTEC Device: AIC-7902 Rev: 00000001
TID 515 Vendor: ESG-SHV S Device: SCA HSBP M21 Rev: 0.080
TID 518 Vendor: ADAPTEC R Device: RAID-1 Rev: 3B0AD
scsi0 : Vendor: Adaptec Model: 2010S FW:3B0A
scsi 0:1:0:0: Direct-Access ADAPTEC RAID-1 3B0A PQ: 0
ANSI: 2
scsi 0:1:6:0: Processor ESG-SHV SCA HSBP M21 0.08 PQ: 0
ANSI: 2
Adaptec aacraid driver 1.1-5[2449]-ms
GDT-HA: Storage RAID Controller Driver. Version: 3.05
GDT-HA: Found 0 PCI Storage RAID Controllers
3ware Storage Controller device driver for Linux v1.26.02.002. 3ware 9000 Storage Controller device driver for Linux v2.26.02.010. sd 0:1:0:0: [sda] 143374336 512-byte hardware sectors (73408 MB) sd 0:1:0:0: [sda] Write Protect is off
sd 0:1:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
sd 0:1:0:0: [sda] 143374336 512-byte hardware sectors (73408 MB) sd 0:1:0:0: [sda] Write Protect is off
sd 0:1:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 0:1:0:0: [sda] Attached SCSI disk
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: raid1 personality registered for level 1
EDAC MC: Ver: 2.1.0 Oct 23 2007
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI Shortcut mode
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 264k freed
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.
Rebooting in 30 seconds..
---cut

Rebooting the box into 2.6.19 works without any problems.

I've checked the changelogs for 2.6.24-rc*, but haven't come across a solution for this issue; but maybe I've also overseen the point.

http://lkml.org/lkml/2007/10/24/224, this bug has been reported earlier.

I've contacted Jan Kara off-list; as booting into 2.6.19 works and e2fsck on an e2image file doesn't show any errors, we assumed that the Ext2 itself is fine.

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.

For some strange reason, this doesn't affect all boxes running the dpt_i2o driver.

Affected (verified on 6 out of 6 tested boxes so far):

Intel SE7501WV2S using an Adaptec 2010S with the following "lspci -vn"-section:

0000:04:08.0 0104: 1044:a511 (rev 01)

        Subsystem: 1044:c035
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
        BIST result: 00
        Memory at fe900000 (32-bit, non-prefetchable) [size=1M]
        Memory at fb000000 (32-bit, prefetchable) [size=16M]
        Memory at f8000000 (32-bit, prefetchable) [size=32M]
        Expansion ROM at f6200000 [disabled] [size=32K]
        Capabilities: [44] Power Management version 2

Not affected are e.g. a box with a Supermicro X5DPR using an Adaptec 2015S and the following "lspci -vn"-section:

0000:03:03.0 0104: 1044:a511 (rev 01)

        Subsystem: 1044:c034
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
        BIST result: 00
        Memory at f8300000 (32-bit, non-prefetchable) [size=1M]
        Memory at fb000000 (32-bit, prefetchable) [size=16M]
        Memory at fc000000 (32-bit, prefetchable) [size=32M]
        Capabilities: [44] Power Management version 2

... and of course boxes not using an dpt_i2o-driven Controller.

The Adaptec 2010S-boxes are currently running the Adaptec firmware 3B05, while the Adaptec 2015S box is running firmware 3B0A. As those controllers are capable of running the same firmware image, maybe a firmware update might resolve this issue as well (well, unlikely according to the changelog); the above bootup log is from an updated box, so the firmware update didn't help. What really helps is the older driver.

Anders

Signature · 8 lines

1&1 Internet AG              System Design
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

Anders Henke

author

2007-11-29 12:32 UTC #1 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 10 lines · Anders Henke

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:

anders@ista:/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

drivers/scsi/dpt_i2o.c +13 ~~-20~~

diff -Nur linux-2.6.22/drivers/scsi/dpt_i2o.c linux-2.6.23-rc1/drivers/scsi/dpt_i2o.c
@@ -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 = 0x00000000;	
 	
 	scsidir = 0x00000000;			// 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|0x10000000|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|0xD0000000|sg_dma_len(sg);
 		}
-		/* Make this an end of list */
-		mptr[-2] = direction|0xD0000000|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++ = 0xD0000000|direction|cmd->request_bufflen;
-			*mptr++ = pci_map_single(pHba->pDev,
-				cmd->request_buffer,
-				cmd->request_bufflen,
-				cmd->sc_data_direction);
-		}
+		*lenptr = len = 0;
+		reqlen = 12;
 	}
 	
 	/* Stick the headers on */

@@ -2232,7 +2225,7 @@
 	hba_status = detailed_status >> 8;
 
 	// calculate resid for sg 
-	cmd->resid = cmd->request_bufflen - readl(reply+5);
+	scsi_set_resid(cmd, scsi_bufflen(cmd) - readl(reply+5));
 
 	pHba = (adpt_hba*) cmd->device->host->hostdata[0];

---cut

Personally I guess that it's the large drop from lines 2164 on that's broken, who replaces a mapping routine by some static assignment.

Regards,

Anders

Signature · 8 lines

1&1 Internet AG              System Design
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

Andrew Morton

2007-12-05 00:58 UTC #2 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 32 lines · On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke <[email protected]> wrote:

Quoted 10 lines · Anders Henke
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:
anders@ista:/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:
(quoted diff) +0 -3
-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:

Quoted 8 lines

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.

Quoted 9 lines

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.

drivers/scsi/dpt_i2o.c renamed from drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-use-the-data-buffer-accessors +20 ~~-13~~

diff -puN drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-use-the-data-buffer-accessors 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 = 0x00000000;	
 	
 	scsidir = 0x00000000;			// 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|0x10000000|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|0xD0000000|sg_dma_len(sg);
+			sg++;
 		}
+		/* Make this an end of list */
+		mptr[-2] = direction|0xD0000000|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++ = 0xD0000000|direction|cmd->request_bufflen;
+			*mptr++ = pci_map_single(pHba->pDev,
+				cmd->request_buffer,
+				cmd->request_bufflen,
+				cmd->sc_data_direction);
+		}
 	}
 	
 	/* Stick the headers on */

@@ -2178,7 +2185,7 @@ static s32 adpt_i2o_to_scsi(void __iomem
 	hba_status = detailed_status >> 8;
 
 	// calculate resid for sg 
-	scsi_set_resid(cmd, scsi_bufflen(cmd) - readl(reply+5));
+	cmd->resid = cmd->request_bufflen - readl(reply+5);
 
 	pHba = (adpt_hba*) cmd->device->host->hostdata[0];

FUJITA Tomonori

2007-12-05 01:05 UTC #3 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 51 lines · On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton <[email protected]>…

Quoted 32 lines · On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke <[email protected]> wrote:
Quoted 10 lines · Anders Henke
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:
anders@ista:/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:
(quoted diff) +0 -3
-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:
Quoted 8 lines
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.
Quoted 5 lines
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).

Quoted 7 lines

Quoted 4 lines
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-kernel&m=119641892129732&w=2

Andrew Morton

2007-12-05 01:12 UTC #4 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 59 lines · On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori…

Quoted 56 lines · On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton <[email protected]>…
Quoted 32 lines · On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke <[email protected]> wrote:
Quoted 10 lines · Anders Henke
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:
anders@ista:/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:
(quoted diff) +0 -3
-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:
Quoted 8 lines
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.
Quoted 9 lines
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:

Quoted 7 lines

Quoted 2 lines
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-kernel&m=119641892129732&w=2

Oh. Jan broke message threading :(

So it's been nearly a week and nothing has happened? Do we revert that change?

FUJITA Tomonori

2007-12-05 01:31 UTC #5 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 68 lines · On Tue, 4 Dec 2007 17:11:55 -0800 Andrew Morton <[email protected]>…

Quoted 65 lines · On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori…
Quoted 51 lines · On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton <[email protected]>…
Quoted 32 lines · On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke <[email protected]> wrote:
Quoted 10 lines · Anders Henke
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:
anders@ista:/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:
(quoted diff) +0 -3
-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:
Quoted 8 lines
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.
Quoted 5 lines
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).
Quoted 7 lines
Quoted 4 lines
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:

Quoted 6 lines

Quoted 1 line
http://marc.info/?l=linux-kernel&m=119641892129732&w=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?

Andrew Morton

2007-12-05 02:52 UTC #6 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 73 lines · On Wed, 05 Dec 2007 10:30:54 +0900 FUJITA Tomonori…

Quoted 70 lines · On Tue, 4 Dec 2007 17:11:55 -0800 Andrew Morton <[email protected]>…
Quoted 66 lines · On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori…
Quoted 51 lines · On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton <[email protected]>…
Quoted 32 lines · On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke <[email protected]> wrote:
Quoted 10 lines · Anders Henke
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:
anders@ista:/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:
(quoted diff) +0 -3
-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:
Quoted 8 lines
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.
Quoted 5 lines
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).
Quoted 7 lines
Quoted 4 lines
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-kernel&m=119641892129732&w=2

Quoted 8 lines

Quoted 4 lines
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(-)

drivers/scsi/dpt_i2o.c renamed from drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-scsi-hotplug-model +61 ~~-71~~

diff -puN drivers/scsi/dpt_i2o.c~revert-dpt_i2o-convert-to-scsi-hotplug-model 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; pHba = pHba->next) {
-		if (adpt_scsi_register(pHba) < 0) {
+		if( adpt_scsi_register(pHba,sht) < 0){
 			adpt_i2o_delete_hba(pHba);
 			continue;
 		}
 		pHba->initialized = TRUE;
 		pHba->state &= ~DPTI_STATE_RESET;
-		scsi_scan_host(pHba->host);
 	}
 
 	// Register our control device node
 	// nodes will need to be created in /dev to access this
 	// the nodes can not be created from within the driver
 	if (hba_count && register_chrdev(DPTI_I2O_MAJOR, DPT_DRIVER, &adpt_fops)) {
-		adpt_exit();
+		adpt_i2o_sys_shutdown();
 		return 0;
 	}
 	return hba_count;
 }
 
 
-static int adpt_release(adpt_hba *pHba)
+/*
+ * scsi_unregister will be called AFTER we return.
+ */
+static int adpt_release(struct Scsi_Host *host)
 {
-	struct Scsi_Host *shost = pHba->host;
-	scsi_remove_host(shost);
+	adpt_hba* pHba = (adpt_hba*) host->hostdata[0];
 //	adpt_i2o_quiesce_hba(pHba);
 	adpt_i2o_delete_hba(pHba);
-	scsi_host_put(shost);
+	scsi_unregister(host);
 	return 0;
 }

@@ -881,7 +882,7 @@ static int adpt_reboot_event(struct noti
 #endif
 
 
-static int adpt_install_hba(struct pci_dev* pDev)
+static int adpt_install_hba(struct scsi_host_template* sht, struct pci_dev* pDev)
 {
 
 	adpt_hba* pHba = NULL;

@@ -1028,6 +1029,8 @@ static void adpt_i2o_delete_hba(adpt_hba
 
 
 	mutex_lock(&adpt_configuration_lock);
+	// scsi_unregister calls our adpt_release which
+	// does a quiese
 	if(pHba->host){
 		free_irq(pHba->host->irq, pHba);
 	}

@@ -1079,6 +1082,17 @@ static void adpt_i2o_delete_hba(adpt_hba
 }
 
 
+static int adpt_init(void)
+{
+	printk("Loading Adaptec I2O RAID: Version " DPT_I2O_VERSION "\n");
+#ifdef REBOOT_NOTIFIER
+	register_reboot_notifier(&adpt_reboot_notifier);
+#endif
+
+	return 0;
+}
+
+
 static struct adpt_device* adpt_find_device(adpt_hba* pHba, u32 chan, u32 id, u32 lun)
 {
 	struct adpt_device* d;

@@ -2164,6 +2178,37 @@ static s32 adpt_scsi_to_i2o(adpt_hba* pH
 }
 
 
+static s32 adpt_scsi_register(adpt_hba* pHba,struct scsi_host_template * sht)
+{
+	struct Scsi_Host *host = NULL;
+
+	host = scsi_register(sht, sizeof(adpt_hba*));
+	if (host == NULL) {
+		printk ("%s: scsi_register returned NULL\n",pHba->name);
+		return -1;
+	}
+	host->hostdata[0] = (unsigned long)pHba;
+	pHba->host = host;
+
+	host->irq = pHba->pDev->irq;
+	/* no IO ports, so don't have to set host->io_port and
+	 * host->n_io_port
+	 */
+	host->io_port = 0;
+	host->n_io_port = 0;
+				/* see comments in scsi_host.h */
+	host->max_id = 16;
+	host->max_lun = 256;
+	host->max_channel = pHba->top_scsi_channel + 1;
+	host->cmd_per_lun = 1;
+	host->unique_id = (uint) pHba;
+	host->sg_tablesize = pHba->sg_tablesize;
+	host->can_queue = pHba->post_fifo_size;
+
+	return 0;
+}
+
+
 static s32 adpt_i2o_to_scsi(void __iomem *reply, struct scsi_cmnd* cmd)
 {
 	adpt_hba* pHba;

@@ -3279,10 +3324,12 @@ static static void adpt_delay(int millis
 
 #endif
 
-static struct scsi_host_template adpt_template = {
+static struct scsi_host_template driver_template = {
 	.name			= "dpt_i2o",
 	.proc_name		= "dpt_i2o",
 	.proc_info		= adpt_proc_info,
+	.detect			= adpt_detect,
+	.release		= adpt_release,
 	.info			= adpt_info,
 	.queuecommand		= adpt_queue,
 	.eh_abort_handler	= adpt_abort,

@@ -3297,62 +3344,5 @@ static struct scsi_host_template adpt_te
 	.use_clustering		= ENABLE_CLUSTERING,
 	.use_sg_chaining	= ENABLE_SG_CHAINING,
 };
-
-static s32 adpt_scsi_register(adpt_hba* pHba)
-{
-	struct Scsi_Host *host;
-
-	host = scsi_host_alloc(&adpt_template, sizeof(adpt_hba*));
-	if (host == NULL) {
-		printk ("%s: scsi_host_alloc returned NULL\n",pHba->name);
-		return -1;
-	}
-	host->hostdata[0] = (unsigned long)pHba;
-	pHba->host = host;
-
-	host->irq = pHba->pDev->irq;
-	/* no IO ports, so don't have to set host->io_port and
-	 * host->n_io_port
-	 */
-	host->io_port = 0;
-	host->n_io_port = 0;
-				/* see comments in scsi_host.h */
-	host->max_id = 16;
-	host->max_lun = 256;
-	host->max_channel = pHba->top_scsi_channel + 1;
-	host->cmd_per_lun = 1;
-	host->unique_id = (uint) pHba;
-	host->sg_tablesize = pHba->sg_tablesize;
-	host->can_queue = pHba->post_fifo_size;
-
-	if (scsi_add_host(host, &pHba->pDev->dev)) {
-		scsi_host_put(host);
-		return -1;
-	}
-
-	return 0;
-}
-
-static int __init adpt_init(void)
-{
-	int count;
-
-	printk("Loading Adaptec I2O RAID: Version " DPT_I2O_VERSION "\n");
-#ifdef REBOOT_NOTIFIER
-	register_reboot_notifier(&adpt_reboot_notifier);
-#endif
-
-	count = adpt_detect();
-
-	return count > 0 ? 0 : -ENODEV;
-}
-
-static void adpt_exit(void)
-{
-	while (hba_chain)
-		adpt_release(hba_chain);
-}
-
-module_init(adpt_init);
-module_exit(adpt_exit);
+#include "scsi_module.c"
 MODULE_LICENSE("GPL");

drivers/scsi/dpti.h renamed from drivers/scsi/dpti.h~revert-dpt_i2o-convert-to-scsi-hotplug-model +7 -2

diff -puN drivers/scsi/dpti.h~revert-dpt_i2o-convert-to-scsi-hotplug-model drivers/scsi/dpti.h
@@ -28,9 +28,11 @@
  * SCSI interface function Prototypes
  */
 
+static int adpt_detect(struct scsi_host_template * sht);
 static int adpt_queue(struct scsi_cmnd * cmd, void (*cmdcomplete) (struct scsi_cmnd *));
 static int adpt_abort(struct scsi_cmnd * cmd);
 static int adpt_reset(struct scsi_cmnd* cmd);
+static int adpt_release(struct Scsi_Host *host);
 static int adpt_slave_configure(struct scsi_device *);
 
 static const char *adpt_info(struct Scsi_Host *pSHost);

@@ -47,6 +49,8 @@ static int adpt_device_reset(struct scsi
 
 #define DPT_DRIVER_NAME	"Adaptec I2O RAID"
 
+#ifndef HOSTS_C
+
 #include "dpt/sys_info.h"
 #include <linux/wait.h>
 #include "dpt/dpti_i2o.h"

@@ -285,7 +289,7 @@ static s32 adpt_i2o_init_outbound_q(adpt
 static s32 adpt_i2o_hrt_get(adpt_hba* pHba);
 static s32 adpt_scsi_to_i2o(adpt_hba* pHba, struct scsi_cmnd* cmd, struct adpt_device* dptdevice);
 static s32 adpt_i2o_to_scsi(void __iomem *reply, struct scsi_cmnd* cmd);
-static s32 adpt_scsi_register(adpt_hba* pHba);
+static s32 adpt_scsi_register(adpt_hba* pHba,struct scsi_host_template * sht);
 static s32 adpt_hba_reset(adpt_hba* pHba);
 static s32 adpt_i2o_reset_hba(adpt_hba* pHba);
 static s32 adpt_rescan(adpt_hba* pHba);

@@ -295,7 +299,7 @@ static void adpt_i2o_delete_hba(adpt_hba
 static void adpt_inquiry(adpt_hba* pHba);
 static void adpt_fail_posted_scbs(adpt_hba* pHba);
 static struct adpt_device* adpt_find_device(adpt_hba* pHba, u32 chan, u32 id, u32 lun);
-static int adpt_install_hba(struct pci_dev* pDev) ;
+static int adpt_install_hba(struct scsi_host_template* sht, struct pci_dev* pDev) ;
 static int adpt_i2o_online_hba(adpt_hba* pHba);
 static void adpt_i2o_post_wait_complete(u32, int);
 static int adpt_i2o_systab_send(adpt_hba* pHba);

@@ -339,4 +343,5 @@ static void adpt_i386_info(sysInfo_S* si
 #define FW_DEBUG_BLED_OFFSET       8
 
 #define FW_DEBUG_FLAGS_NO_HEADERS_B    0x01
+#endif				/* !HOSTS_C */
 #endif				/* _DPT_H */

Anders Henke

author

2007-12-05 10:14 UTC #7 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 89 lines · On Tue, 4 Dec 2007 Andrew Morton wrote:

Quoted 73 lines · On Wed, 05 Dec 2007 10:30:54 +0900 FUJITA Tomonori…
Quoted 70 lines · On Tue, 4 Dec 2007 17:11:55 -0800 Andrew Morton <[email protected]>…
Quoted 66 lines · On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori…
Quoted 51 lines · On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton <[email protected]>…
Quoted 32 lines · On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke <[email protected]> wrote:
Quoted 10 lines · Anders Henke
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:
anders@ista:/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:
(quoted diff) +0 -3
-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:
Quoted 8 lines
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.
Quoted 5 lines
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).
Quoted 7 lines
Quoted 4 lines
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-kernel&m=119641892129732&w=2
Quoted 8 lines
Quoted 4 lines
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...

Quoted 7 lines

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

Signature · 8 lines

1&1 Internet AG            Enter 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

FUJITA Tomonori

2007-12-06 05:50 UTC #8 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 107 lines · On Wed, 5 Dec 2007 11:14:41 +0100 Anders Henke <[email protected]> wrote:

Quoted 89 lines · On Tue, 4 Dec 2007 Andrew Morton wrote:
Quoted 73 lines · On Wed, 05 Dec 2007 10:30:54 +0900 FUJITA Tomonori…
Quoted 70 lines · On Tue, 4 Dec 2007 17:11:55 -0800 Andrew Morton <[email protected]>…
Quoted 66 lines · On Wed, 05 Dec 2007 10:04:03 +0900 FUJITA Tomonori…
Quoted 51 lines · On Tue, 4 Dec 2007 16:57:38 -0800 Andrew Morton <[email protected]>…
Quoted 32 lines · On Thu, 29 Nov 2007 13:31:50 +0100 Anders Henke <[email protected]> wrote:
Quoted 10 lines · Anders Henke
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:
anders@ista:/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:
(quoted diff) +0 -3
-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:
Quoted 8 lines
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.
Quoted 5 lines
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).
Quoted 7 lines
Quoted 4 lines
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-kernel&m=119641892129732&w=2
Quoted 8 lines
Quoted 4 lines
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...
Quoted 7 lines
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:
(quoted diff) +0 -2
-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.

Quoted 5 lines

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.

Andrew Morton

2007-12-06 07:09 UTC #9 lore raw

Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)

Quoted 13 lines · On Thu, 06 Dec 2007 14:49:37 +0900 FUJITA Tomonori…

Quoted 13 lines

Quoted 3 lines

 drivers/scsi/dpt_i2o.c |  132 ++++++++++++++++++---------------------
 drivers/scsi/dpti.h    |    9 ++
 2 files changed, 68 insertions(+), 73 deletions(-)

I've done the following:

(quoted diff) +0 -2

-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.

Quoted 10 lines

Quoted 5 lines
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.