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

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

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.

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 17 lines · Alan Stern

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

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

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 4 lines

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

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

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 17 lines · Alan Stern

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

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

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 4 lines

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

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

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

Quoted 57 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 17 lines · Alan Stern

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

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

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 4 lines

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

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

I'll take this one ... although we're a bit lacking in documentation for this driver.

Quoted 6 lines

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

Should maybe it be
doing the same for a 256 byte sector disk???

Quoted 57 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 17 lines · Alan Stern

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

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

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 4 lines

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

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

I'll take this one ... although we're a bit lacking in documentation for this driver.

Quoted 6 lines

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

Should maybe it be
doing the same for a 256 byte sector disk???

Quoted 69 lines · Mark Hounschell

Quoted 67 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 18 lines · Alan Stern

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

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

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 10 lines

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

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

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 7 lines

Quoted 4 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

Quoted 4 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 3 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Quoted 69 lines · Mark Hounschell

Quoted 67 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 18 lines · Alan Stern

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

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

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 10 lines

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

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

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 7 lines

Quoted 4 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

Quoted 4 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 3 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Quoted 89 lines · James Bottomley

Quoted 77 lines · Mark Hounschell

Quoted 74 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 24 lines · Alan Stern

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

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

Quoted 7 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 11 lines

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

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

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 9 lines

Quoted 5 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 11 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 9 lines

Quoted 5 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 9 lines

Quoted 4 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 89 lines · James Bottomley

Quoted 77 lines · Mark Hounschell

Quoted 74 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 24 lines · Alan Stern

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

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

Quoted 7 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 11 lines

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

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

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 9 lines

Quoted 5 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 11 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 9 lines

Quoted 5 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 9 lines

Quoted 4 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 133 lines · Mark Hounschell

Quoted 89 lines · James Bottomley

Quoted 77 lines · Mark Hounschell

Quoted 74 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 24 lines · Alan Stern

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

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

Quoted 7 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 11 lines

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

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

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 9 lines

Quoted 5 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 11 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 9 lines

Quoted 5 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 9 lines

Quoted 4 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

Quoted 4 lines

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

Quoted 133 lines · Mark Hounschell

Quoted 89 lines · James Bottomley

Quoted 77 lines · Mark Hounschell

Quoted 74 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 24 lines · Alan Stern

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

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

Quoted 7 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 11 lines

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

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

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 9 lines

Quoted 5 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 11 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 9 lines

Quoted 5 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 9 lines

Quoted 4 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

Quoted 4 lines

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

Quoted 158 lines · Mark Hounschell

Quoted 156 lines · Mark Hounschell

Quoted 100 lines · James Bottomley

Quoted 85 lines · Mark Hounschell

Quoted 81 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 26 lines · Alan Stern

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

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

Quoted 8 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 12 lines

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

Quoted 7 lines

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 11 lines

Quoted 6 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 12 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 11 lines

Quoted 6 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 11 lines

Quoted 5 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 4 lines

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Um, well, since you've got a lot of them that does rather argue against their being obsolete ...

Quoted 3 lines

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

fdisk is only the dos label ... there's a lot you can't do with a dos label. I think parted will allow you to write a label that will work.

I've got scsi_debug patched to work with 256 byte sectors. It actually looks like this has nothing to do with the residue. What I see is a hang because block is trying to do a zero sized read. I suspect something is trying to do a single sector read, which is impossible since the linux native sector size is 512 and it's getting rounded down.

This might, of course, argue that block cannot now support 256 sector devices and so they need to be deprecated ... I'll see.

James

Quoted 158 lines · Mark Hounschell

Quoted 156 lines · Mark Hounschell

Quoted 100 lines · James Bottomley

Quoted 85 lines · Mark Hounschell

Quoted 81 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 26 lines · Alan Stern

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

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

Quoted 8 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 12 lines

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

Quoted 7 lines

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.

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

Quoted 11 lines

Quoted 6 lines

James

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 12 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 11 lines

Quoted 6 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 11 lines

Quoted 5 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 4 lines

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Um, well, since you've got a lot of them that does rather argue against their being obsolete ...

Quoted 3 lines

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

fdisk is only the dos label ... there's a lot you can't do with a dos label. I think parted will allow you to write a label that will work.

I've got scsi_debug patched to work with 256 byte sectors. It actually looks like this has nothing to do with the residue. What I see is a hang because block is trying to do a zero sized read. I suspect something is trying to do a single sector read, which is impossible since the linux native sector size is 512 and it's getting rounded down.

This might, of course, argue that block cannot now support 256 sector devices and so they need to be deprecated ... I'll see.

James

Quoted 181 lines · James Bottomley

Quoted 178 lines · Mark Hounschell

Quoted 175 lines · Mark Hounschell

Quoted 111 lines · James Bottomley

Quoted 100 lines · Mark Hounschell

Quoted 82 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 28 lines · Alan Stern

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

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

Quoted 9 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 13 lines

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

Quoted 8 lines

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.

Quoted 13 lines

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

Quoted 6 lines

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 13 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 13 lines

Quoted 7 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 13 lines

Quoted 6 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 10 lines

Quoted 5 lines

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Um, well, since you've got a lot of them that does rather argue against their being obsolete ...

Except I would _never_ attempt to use any of them for an actual Linux fs. If I did, and again I wouldn't, it would be after formatting them with a 512 byte sector. Way too slow and small. We only provide support for them in an emulation of an old RTOS called MPX-32 using the sg_io interface.

Quoted 18 lines

Quoted 4 lines

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

fdisk is only the dos label ... there's a lot you can't do with a dos label. I think parted will allow you to write a label that will work.

I've got scsi_debug patched to work with 256 byte sectors. It actually looks like this has nothing to do with the residue. What I see is a hang because block is trying to do a zero sized read. I suspect something is trying to do a single sector read, which is impossible since the linux native sector size is 512 and it's getting rounded down.

This might, of course, argue that block cannot now support 256 sector devices and so they need to be deprecated ... I'll see.

James

Quoted 181 lines · James Bottomley

Quoted 178 lines · Mark Hounschell

Quoted 175 lines · Mark Hounschell

Quoted 111 lines · James Bottomley

Quoted 100 lines · Mark Hounschell

Quoted 82 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 28 lines · Alan Stern

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

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

Quoted 9 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 13 lines

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

Quoted 8 lines

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.

Quoted 13 lines

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

Quoted 6 lines

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 13 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 13 lines

Quoted 7 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 13 lines

Quoted 6 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 10 lines

Quoted 5 lines

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Um, well, since you've got a lot of them that does rather argue against their being obsolete ...

Except I would _never_ attempt to use any of them for an actual Linux fs. If I did, and again I wouldn't, it would be after formatting them with a 512 byte sector. Way too slow and small. We only provide support for them in an emulation of an old RTOS called MPX-32 using the sg_io interface.

Quoted 18 lines

Quoted 4 lines

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

fdisk is only the dos label ... there's a lot you can't do with a dos label. I think parted will allow you to write a label that will work.

I've got scsi_debug patched to work with 256 byte sectors. It actually looks like this has nothing to do with the residue. What I see is a hang because block is trying to do a zero sized read. I suspect something is trying to do a single sector read, which is impossible since the linux native sector size is 512 and it's getting rounded down.

This might, of course, argue that block cannot now support 256 sector devices and so they need to be deprecated ... I'll see.

James

Quoted 213 lines · Mark Hounschell

Quoted 181 lines · James Bottomley

Quoted 178 lines · Mark Hounschell

Quoted 175 lines · Mark Hounschell

Quoted 111 lines · James Bottomley

Quoted 100 lines · Mark Hounschell

Quoted 82 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 28 lines · Alan Stern

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

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

Quoted 9 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 13 lines

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

Quoted 8 lines

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.

Quoted 13 lines

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

Quoted 6 lines

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 13 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 13 lines

Quoted 7 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 13 lines

Quoted 6 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 10 lines

Quoted 5 lines

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Um, well, since you've got a lot of them that does rather argue against their being obsolete ...

Except I would _never_ attempt to use any of them for an actual Linux fs. If I did, and again I wouldn't, it would be after formatting them with a 512 byte sector. Way too slow and small. We only provide support for them in an emulation of an old RTOS called MPX-32 using the sg_io interface.

Quoted 13 lines

Quoted 4 lines

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

fdisk is only the dos label ... there's a lot you can't do with a dos label. I think parted will allow you to write a label that will work.

I've got scsi_debug patched to work with 256 byte sectors. It actually looks like this has nothing to do with the residue. What I see is a hang because block is trying to do a zero sized read. I suspect something is trying to do a single sector read, which is impossible since the linux native sector size is 512 and it's getting rounded down.

Quoted 5 lines

Quoted 5 lines

This might, of course, argue that block cannot now support 256 sector devices and so they need to be deprecated ... I'll see.

James

I know your a busy guy, I was just wondering if this BUG is still being given consideration?

Quoted 213 lines · Mark Hounschell

Quoted 181 lines · James Bottomley

Quoted 178 lines · Mark Hounschell

Quoted 175 lines · Mark Hounschell

Quoted 111 lines · James Bottomley

Quoted 100 lines · Mark Hounschell

Quoted 82 lines · On 05/28/2010 12:34 PM, [email protected] wrote:

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

--- Comment #6 from Anonymous Emailer <[email protected]> 2010-05-28 16:34:28 ---
Reply-To: [email protected]

Quoted 28 lines · Alan Stern

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

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

Quoted 9 lines

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.

Actually, I think this is a partition read. Each partition manager tends to read a page through the page cache. If we get an error, we seem to re-read to fill the cache.

Quoted 13 lines

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

Quoted 8 lines

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.

Quoted 13 lines

I'll take this one ... although we're a bit lacking in documentation for this driver.

I think the 2048 is because something is hardcoded to think 8 sectors is a page.

James

Quoted 6 lines

Your probably right. But is a 256 byte sector really a supported sector size for a linux fs on a SCSI disk?

Quoted 13 lines

In theory the block layer can support any power of two sector size (or really any sector size which is a divisor of the page size). We had a use for 256 byte sectors once, so they're in SCSI. In practice, since they're so rare, the code paths are never tested (as you found out) and there's a more annoying problem which is since the linux base sector size is 512, you have to multiply to get from 256 to 512 ... for all other sector sizes you have to divide, so any conversion routine that only right shifts would get this wrong.

from the fdisk man page:

-b sectorsize Specify the sector size of the disk. Valid
values are 512, 1024, 2048 or 4096. (Recent kernels know the sector size. Use this only on old kernels or to override the kernel's ideas.)

So how does one create a linux fs on a 256 byte sectored disk?

Quoted 13 lines

Quoted 7 lines

When it sees a 768 byte sector disk,
it says it's an unsupported size and goes on with the boot process without even doing a read for a partition table.

that's because 768 isn't a power of 2, so it's completely unsupportable.

Quoted 13 lines

Quoted 6 lines

Should maybe it be
doing the same for a 256 byte sector disk???

Possibly ... I don't know what the 256 byte sector support was for ... all I know is that whatever it was, I don't have one.

Back in the old days, almost any scsi disk could be formatted with a 256 byte sector. At one time it probably made since to support it. But try to find one that supports that sector size today.

In any case, if you can't even partition a 256 byte sector scsi disk in linux, why would the kernel still claim it supports that format?

Quoted 10 lines

Quoted 5 lines

In fact, the attached patch works for me. However, if you wish to pursue functional 256 byte sector support, I have plenty of these disks and will be happy to test what ever you come up with.

Um, well, since you've got a lot of them that does rather argue against their being obsolete ...

Except I would _never_ attempt to use any of them for an actual Linux fs. If I did, and again I wouldn't, it would be after formatting them with a 512 byte sector. Way too slow and small. We only provide support for them in an emulation of an old RTOS called MPX-32 using the sg_io interface.

Quoted 13 lines

Quoted 4 lines

Not a lot I can really
do without fdisk support though. Even so, I'm all ears???

fdisk is only the dos label ... there's a lot you can't do with a dos label. I think parted will allow you to write a label that will work.

I've got scsi_debug patched to work with 256 byte sectors. It actually looks like this has nothing to do with the residue. What I see is a hang because block is trying to do a zero sized read. I suspect something is trying to do a single sector read, which is impossible since the linux native sector size is 512 and it's getting rounded down.

Quoted 5 lines

Quoted 5 lines

This might, of course, argue that block cannot now support 256 sector devices and so they need to be deprecated ... I'll see.

James

I know your a busy guy, I was just wondering if this BUG is still being given consideration?