New: [BUG] Cannot boot any kernel from 2.6.27 on if a 256 byte sector SCSI disk is attached

https://bugzilla.kernel.org/show_bug.cgi?id=16058

Summary: [BUG] Cannot boot any kernel from 2.6.27 on if a 256
byte sector SCSI disk is attached

As of 2.6.27 if any SCSI disk is attached that has been formatted with a 256 byte sector size, the boot process hangs. 512, 768, and 1024 byte sector disks do not seem to trigger this. The disks in use do NOT have a partition table. They are being used by out applications via the sg_io interface only.

A 2.6.26.8 kernel works fine.

I have bisected this problem to the following commit:

# git bisect good
427e59f09fdba387547106de7bab980b7fff77be is first bad commit
commit 427e59f09fdba387547106de7bab980b7fff77be
Author: James Bottomley <[email protected]>
Date:   Sat Mar 8 18:24:17 2008 -0600

[SCSI] make use of the residue value

USB sometimes doesn't return an error but instead returns a residue value indicating part (or all) of the command wasn't completed. So if the driver _done() error processing indicates the command was fully processed, subtract off the residue so that this USB error gets propagated.

Cc Alan Stern <[email protected]>

Signed-off-by James Bottomley <[email protected]>

:040000 040000 d3bad84ebe1bc231e8e7d6267907ca62fd4d0dcd
c85f8cb8bd4910724f0101e41054555980727e16 M drivers

Now, what USB has to do with my SCSI disks is beyond me. I have a feeling that this commit is just uncovering another problem. I've attached a bootlog from a serial console that ends where the boot hangs.

The does the same thing on a 2.6.34 kernel. Anything I can do to help, I'm available.

Quoted 34 lines · Andrew Morton

https://bugzilla.kernel.org/show_bug.cgi?id=16058

Summary: [BUG] Cannot boot any kernel from 2.6.27 on if a 256
byte sector SCSI disk is attached

As of 2.6.27 if any SCSI disk is attached that has been formatted with a 256 byte sector size, the boot process hangs. 512, 768, and 1024 byte sector disks do not seem to trigger this. The disks in use do NOT have a partition table. They are being used by out applications via the sg_io interface only.

A 2.6.26.8 kernel works fine.

I have bisected this problem to the following commit:

# git bisect good
427e59f09fdba387547106de7bab980b7fff77be is first bad commit
commit 427e59f09fdba387547106de7bab980b7fff77be
Author: James Bottomley <[email protected]>
Date:   Sat Mar 8 18:24:17 2008 -0600

[SCSI] make use of the residue value

USB sometimes doesn't return an error but instead returns a residue value indicating part (or all) of the command wasn't completed. So if the driver _done() error processing indicates the command was fully processed, subtract off the residue so that this USB error gets propagated.

Cc Alan Stern <[email protected]>

Signed-off-by James Bottomley <[email protected]>

:040000 040000 d3bad84ebe1bc231e8e7d6267907ca62fd4d0dcd
c85f8cb8bd4910724f0101e41054555980727e16 M drivers

Quoted 6 lines

Now, what USB has to do with my SCSI disks is beyond me. I have a feeling that this commit is just uncovering another problem. I've attached a bootlog from a serial console that ends where the boot hangs.

The does the same thing on a 2.6.34 kernel. Anything I can do to help, I'm available.

I'd guess that this has nothing to do with the sector size. Instead the drive probably reports a non-zero residue when it shouldn't. Can you add some debugging printk's to the patch to find out in more detail what's going wrong?

Alan Stern

Quoted 5 lines

Quoted 5 lines

As of 2.6.27 if any SCSI disk is attached that has been formatted with a 256 byte sector size, the boot process hangs. 512, 768, and 1024 byte sector disks

The does the same thing on a 2.6.34 kernel. Anything I can do to help, I'm available.

Yes, I can. But first let me ask, since reverting this patch on at least 2.6.32 - 2.6.34 does not help, would it possibly be better if I did a little more work to find out where it stops working with the above patch reverted or not?

Quoted 35 lines · Andrew Morton

https://bugzilla.kernel.org/show_bug.cgi?id=16058

Summary: [BUG] Cannot boot any kernel from 2.6.27 on if a 256
byte sector SCSI disk is attached

As of 2.6.27 if any SCSI disk is attached that has been formatted with a 256 byte sector size, the boot process hangs. 512, 768, and 1024 byte sector disks do not seem to trigger this. The disks in use do NOT have a partition table. They are being used by out applications via the sg_io interface only.

A 2.6.26.8 kernel works fine.

I have bisected this problem to the following commit:

# git bisect good
427e59f09fdba387547106de7bab980b7fff77be is first bad commit
commit 427e59f09fdba387547106de7bab980b7fff77be
Author: James Bottomley <[email protected]>
Date:   Sat Mar 8 18:24:17 2008 -0600

[SCSI] make use of the residue value

USB sometimes doesn't return an error but instead returns a residue value indicating part (or all) of the command wasn't completed. So if the driver _done() error processing indicates the command was fully processed, subtract off the residue so that this USB error gets propagated.

Cc Alan Stern <[email protected]>

Signed-off-by James Bottomley <[email protected]>

:040000 040000 d3bad84ebe1bc231e8e7d6267907ca62fd4d0dcd
c85f8cb8bd4910724f0101e41054555980727e16 M drivers

Quoted 7 lines

Now, what USB has to do with my SCSI disks is beyond me. I have a feeling that this commit is just uncovering another problem. I've attached a bootlog from a serial console that ends where the boot hangs.

The does the same thing on a 2.6.34 kernel. Anything I can do to help, I'm available.

I'd guess that this has nothing to do with the sector size. Instead the drive probably reports a non-zero residue when it shouldn't. Can you add some debugging printk's to the patch to find out in more detail what's going wrong?

Alan Stern

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

From here it just keeps repeating this read of 8 blocks. (2048 bytes) so

First READ(10):

sde:
ahc_calc_residual: Entered
ahc_calc_residual: return Case 5-1 resid = 0x800
ahc_calc_residual: return Case 5-2 resid = 0x800

scsi_finish_command: Entered for cmd(10):0x28 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x08 0x00
cmd->result = 0x00000000
good_bytes == old_good_bytes = 0x800 scsi_get_resid(cmd) = 0x800 New good_bytes = 0x0
scsi_finish_command: Complete

From here it just keeps repeating this read of 8 blocks. (2048 bytes) so it looks like the machine is hung.

Now, I know for a fact that _if_ this read CDB is actually being sent to the drive, it's actual residual count will be zero. These are working disks and that read CDB is valid.

Why is ahc_calc_residual saying that the residual count is as though the read never took place? I noticed that the first read on all the SATA drives was for 4096 bytes, why is this one only 2048? Should it have been 4096 and ahc_calc_residual assume that?

Quoted 14 lines · Mark Hounschell

First READ(10):

sde:
ahc_calc_residual: Entered
ahc_calc_residual: return Case 5-1 resid = 0x800
ahc_calc_residual: return Case 5-2 resid = 0x800

scsi_finish_command: Entered for cmd(10):0x28 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x08 0x00
cmd->result = 0x00000000
good_bytes == old_good_bytes = 0x800 scsi_get_resid(cmd) = 0x800 New good_bytes = 0x0
scsi_finish_command: Complete

Quoted 2 lines

From here it just keeps repeating this read of 8 blocks. (2048 bytes) so it looks like the machine is hung.

Probably not hung, just doing a lot of retries. It should time out eventually, but it might take a long time (perhaps as long as 15 minutes). The combination of the block layer and the SCSI layer isn't very good at knowing when to give up.

Quoted 4 lines

Now, I know for a fact that _if_ this read CDB is actually being sent to the drive, it's actual residual count will be zero. These are working disks and that read CDB is valid.

Quoted 4 lines

Why is ahc_calc_residual saying that the residual count is as though the read never took place? I noticed that the first read on all the SATA drives was for 4096 bytes, why is this one only 2048? Should it have been 4096 and ahc_calc_residual assume that?

I don't know the answer to any of these questions. They could well be due to bugs in the driver, and I know nothing about how the aic7xxx driver works. You should talk to someone who does.