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

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

[bugzilla-daemon]

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
           Product: SCSI Drivers
           Version: 2.5
    Kernel Version: 2.6.27
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
        AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org
        ReportedBy: markh@compro.net
        Regression: Yes


Created an attachment (id=26560)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=26560)
The boot process captured from a serial console

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 <James.Bottomley@HansenPartnership.com>
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 <stern@rowland.harvard.edu>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

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

Thanks and regards
Mark

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #1 from Alan Stern <stern@rowland.harvard.edu>  2010-05-27 20:31:16 ---
On Thu, 27 May 2010, Andrew Morton wrote:

> 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 <James.Bottomley@HansenPartnership.com>
> 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 <stern@rowland.harvard.edu>
>     Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> 
> :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.

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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #2 from Alan Stern <stern@rowland.harvard.edu>  2010-05-27 21:18:37 ---
On Thu, 27 May 2010, Mark Hounschell wrote:

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

I'd do 2.6.27 first, since that's where the problem started.  Then move 
on to 2.6.34.  There may be two different problems.

Alan Stern

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #3 from Mark Hounschell <markh@compro.net>  2010-05-27 22:05:35 ---
On 05/27/2010 04:30 PM, Alan Stern wrote:
> On Thu, 27 May 2010, Andrew Morton wrote:
> 
>> 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 <James.Bottomley@HansenPartnership.com>
>> 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 <stern@rowland.harvard.edu>
>>     Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>>
>> :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.
> 
> 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
> 
> 

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?

Mark

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #4 from Alan Stern <stern@rowland.harvard.edu>  2010-05-28 14:58:55 ---
On Fri, 28 May 2010, Mark Hounschell wrote:

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

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.

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

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.

In the meantime, you can track this down a little farther by adding
printk's to the appropriate places in drivers/scsi/sd.c.  Look at
sd_prep_fn() to see why there's 2048 bytes instead of 4096.

Alan Stern

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #5 from Mark Hounschell <dmarkh@cfl.rr.com>  2010-05-28 15:42:40 ---
On 05/27/2010 04:30 PM, Alan Stern wrote:
> On Thu, 27 May 2010, Andrew Morton wrote:
>
>   
>> 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 <James.Bottomley@HansenPartnership.com>
>> 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 <stern@rowland.harvard.edu>
>>     Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>>
>> :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.
>>     
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   
Alan,

I've added some printks in scsi.c and aic7xxx_core.c.

A TUR:

ahc_calc_residual: Entered
ahc_calc_residual: return Case 2 sgptr = 0x00000001

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

scsi_finish_command: Entered for cmd(6):0x00 0x00 0x00 0x00 0x00 0x00
cmd->result = 0x08000002
good_bytes = 0x0
scsi_finish_command: Complete


Another TUR:

scsi_finish_command: Entered for cmd(6):0x00 0x00 0x00 0x00 0x00 0x00
cmd->result = 0x00000000
good_bytes = 0x0
scsi_finish_command: Complete


A Read Capicity:

scsi_finish_command: Entered for cmd(10):0x25 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
cmd->result = 0x00000000
good_bytes = 0x8
scsi_finish_command: Complete

sd 8:0:0:0: [sde] 7260582 256-byte hardware sectors (1859 MB)


A Mode Sense:

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x3f 0x00 0x04 0x00
cmd->result = 0x00000000
good_bytes = 0x4
scsi_finish_command: Complete

sd 8:0:0:0: [sde] Write Protect is off


Another Mode Sense:

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x08 0x00 0x04 0x00
cmd->result = 0x00000000
good_bytes = 0x4
scsi_finish_command: Complete


Another Mode Sense:

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

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x08 0x00 0x20 0x00
cmd->result = 0x00000000
good_bytes = 0x20
scsi_finish_command: Complete

sd 8:0:0:0: [sde] Write cache: disabled, read cache: enabled, supports
DPO and FUA


Another TUR:

scsi_finish_command: Entered for cmd(6):0x00 0x00 0x00 0x00 0x00 0x00
cmd->result = 0x00000000
good_bytes = 0x0
scsi_finish_command: Complete


Another Read Capacity:

scsi_finish_command: Entered for cmd(10):0x25 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
cmd->result = 0x00000000
good_bytes = 0x8
scsi_finish_command: Complete

sd 8:0:0:0: [sde] 7260582 256-byte hardware sectors (1859 MB)


Another Mode Sense:

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x3f 0x00 0x04 0x00
cmd->result = 0x00000000
good_bytes = 0x4
scsi_finish_command: Complete

sd 8:0:0:0: [sde] Write Protect is off


Another Mode Sense:

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x08 0x00 0x04 0x00
cmd->result = 0x00000000
good_bytes = 0x4
scsi_finish_command: Complete


Another Mode Sense:

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

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x08 0x00 0x20 0x00
cmd->result = 0x00000000
good_bytes = 0x20
scsi_finish_command: Complete

sd 8:0:0:0: [sde] Write cache: disabled, read cache: enabled, supports
DPO and FUA


Another TUR:

scsi_finish_command: Entered for cmd(6):0x00 0x00 0x00 0x00 0x00 0x00
cmd->result = 0x00000000
good_bytes = 0x0
scsi_finish_command: Complete


Another Read Capacity:

scsi_finish_command: Entered for cmd(10):0x25 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
cmd->result = 0x00000000
good_bytes = 0x8
scsi_finish_command: Complete

sd 8:0:0:0: [sde] 7260582 256-byte hardware sectors (1859 MB)


Another Mode Sense:

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x3f 0x00 0x04 0x00
cmd->result = 0x00000000
good_bytes = 0x4
scsi_finish_command: Complete

sd 8:0:0:0: [sde] Write Protect is off


Another Mode Sense:

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x08 0x00 0x04 0x00
cmd->result = 0x00000000
good_bytes = 0x4
scsi_finish_command: Complete


Another Mode Sense:

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

scsi_finish_command: Entered for cmd(6):0x1a 0x00 0x08 0x00 0x20 0x00
cmd->result = 0x00000000
good_bytes = 0x20
scsi_finish_command: Complete

sd 8:0:0:0: [sde] Write cache: disabled, read cache: enabled, supports
DPO and FUA


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?

BTW, I'll be in and out all day today so I may not be able to respond
quickly.

One thing all these machines I have doing this, have in common, is the
scsi controller (Aic7xxx).

Regards
Mark

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
Reply-To: James.Bottomley@suse.de

On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
> On Fri, 28 May 2010, Mark Hounschell wrote:
> 
> > 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.
> 
> 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.

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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[Mark Hounschell]

On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>
>
>
>
>
> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> Reply-To: James.Bottomley@suse.de
>
> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>   
>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>
>>     
>>> 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.
>>>       
>> 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.
>
>   
>>> 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?
>>>       
>> 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
>
>   
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???

Regards
Mark

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

[James Bottomley]

On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=16058
> >
> >
> >
> >
> >
> > --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> > Reply-To: James.Bottomley@suse.de
> >
> > On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
> >   
> >> On Fri, 28 May 2010, Mark Hounschell wrote:
> >>
> >>     
> >>> 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.
> >>>       
> >> 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.
> >
> >   
> >>> 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?
> >>>       
> >> 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
> >
> >   
> 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.

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

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

James

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

[Mark Hounschell]

On 05/28/2010 04:25 PM, James Bottomley wrote:
> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>   
>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>     
>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>
>>>
>>>
>>>
>>>
>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>> Reply-To: James.Bottomley@suse.de
>>>
>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>   
>>>       
>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>
>>>>     
>>>>         
>>>>> 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.
>>>>>       
>>>>>           
>>>> 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.
>>>
>>>   
>>>       
>>>>> 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?
>>>>>       
>>>>>           
>>>> 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
>>>
>>>   
>>>       
>> 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.
>
>   

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?

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

Regards
Mark

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

[Mark Hounschell]

[-- Attachment #1: Type: text/plain, Size: 5100 bytes --]

On 05/30/2010 07:51 AM, Mark Hounschell wrote:
> On 05/28/2010 04:25 PM, James Bottomley wrote:
>   
>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>>   
>>     
>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>>     
>>>       
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>>> Reply-To: James.Bottomley@suse.de
>>>>
>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>>   
>>>>       
>>>>         
>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>>
>>>>>     
>>>>>         
>>>>>           
>>>>>> 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.
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> 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.
>>>>
>>>>   
>>>>       
>>>>         
>>>>>> 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?
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> 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
>>>>
>>>>   
>>>>       
>>>>         
>>> 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.
>>
>>   
>>     
> 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?
>
>   
>>>  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.
>>
>>   
>>     
>>>  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?
>
>   

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

Regards
Mark

[-- Attachment #2: make_scsi_disk_256_byte_sector_unsupported-2.6.34.patch --]
[-- Type: text/x-patch, Size: 1605 bytes --]

diff -urN linux-2.6.34.0-orig/drivers/scsi/sd.c linux-2.6.34.0/drivers/scsi/sd.c
--- linux-2.6.34.0-orig/drivers/scsi/sd.c	2010-05-31 07:04:26.000000000 -0400
+++ linux-2.6.34.0/drivers/scsi/sd.c	2010-05-31 07:07:07.000000000 -0400
@@ -1107,6 +1107,7 @@
 {
 	u64 start_lba = blk_rq_pos(scmd->request);
 	u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
+	u64 factor = scmd->device->sector_size / 512;
 	u64 bad_lba;
 	int info_valid;
 
@@ -1122,16 +1123,9 @@
 	if (scsi_bufflen(scmd) <= scmd->device->sector_size)
 		return 0;
 
-	if (scmd->device->sector_size < 512) {
-		/* only legitimate sector_size here is 256 */
-		start_lba <<= 1;
-		end_lba <<= 1;
-	} else {
-		/* be careful ... don't want any overflows */
-		u64 factor = scmd->device->sector_size / 512;
-		do_div(start_lba, factor);
-		do_div(end_lba, factor);
-	}
+	/* be careful ... don't want any overflows */
+	do_div(start_lba, factor);
+	do_div(end_lba, factor);
 
 	/* The bad lba was reported incorrectly, we have no idea where
 	 * the error is.
@@ -1651,8 +1645,7 @@
 	if (sector_size != 512 &&
 	    sector_size != 1024 &&
 	    sector_size != 2048 &&
-	    sector_size != 4096 &&
-	    sector_size != 256) {
+	    sector_size != 4096) { 
 		sd_printk(KERN_NOTICE, sdkp, "Unsupported sector size %d.\n",
 			  sector_size);
 		/*
@@ -1701,8 +1694,6 @@
 		sdkp->capacity <<= 2;
 	else if (sector_size == 1024)
 		sdkp->capacity <<= 1;
-	else if (sector_size == 256)
-		sdkp->capacity >>= 1;
 
 	blk_queue_physical_block_size(sdp->request_queue, sdkp->hw_sector_size);
 	sdkp->device->sector_size = sector_size;

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

[James Bottomley]

On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
> > On 05/28/2010 04:25 PM, James Bottomley wrote:
> >   
> >> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
> >>   
> >>     
> >>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> >>>     
> >>>       
> >>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> >>>> Reply-To: James.Bottomley@suse.de
> >>>>
> >>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
> >>>>   
> >>>>       
> >>>>         
> >>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
> >>>>>
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> 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.
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> 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.
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>>>>> 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?
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> 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
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>> 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.
> >>
> >>   
> >>     
> > 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?
> >
> >   
> >>>  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.
> >>
> >>   
> >>     
> >>>  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?
> >
> >   
> 
> 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 ...

>  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

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

[Mark Hounschell]

On 05/31/2010 10:02 AM, James Bottomley wrote:
> On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
>   
>> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
>>     
>>> On 05/28/2010 04:25 PM, James Bottomley wrote:
>>>   
>>>       
>>>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>>>>   
>>>>     
>>>>         
>>>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>>>>     
>>>>>       
>>>>>           
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>>>>> Reply-To: James.Bottomley@suse.de
>>>>>>
>>>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>>>>   
>>>>>>       
>>>>>>         
>>>>>>             
>>>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>>>>
>>>>>>>     
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>>>> 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.
>>>>>>>>       
>>>>>>>>           
>>>>>>>>             
>>>>>>>>                 
>>>>>>> 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.
>>>>>>
>>>>>>   
>>>>>>       
>>>>>>         
>>>>>>             
>>>>>>>> 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?
>>>>>>>>       
>>>>>>>>           
>>>>>>>>             
>>>>>>>>                 
>>>>>>> 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
>>>>>>
>>>>>>   
>>>>>>       
>>>>>>         
>>>>>>             
>>>>> 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.
>>>>
>>>>   
>>>>     
>>>>         
>>> 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?
>>>
>>>   
>>>       
>>>>>  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.
>>>>
>>>>   
>>>>     
>>>>         
>>>>>  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?
>>>
>>>   
>>>       
>> 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.

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

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

[Mark Hounschell]

On 05/31/2010 11:17 AM, Mark Hounschell wrote:
> On 05/31/2010 10:02 AM, James Bottomley wrote:
>   
>> On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
>>   
>>     
>>> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
>>>     
>>>       
>>>> On 05/28/2010 04:25 PM, James Bottomley wrote:
>>>>   
>>>>       
>>>>         
>>>>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>>>>>     
>>>>>>       
>>>>>>           
>>>>>>             
>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>>>>>> Reply-To: James.Bottomley@suse.de
>>>>>>>
>>>>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>>>>>
>>>>>>>>     
>>>>>>>>         
>>>>>>>>           
>>>>>>>>               
>>>>>>>>                 
>>>>>>>>> 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.
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>> 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.
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>>>>> 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?
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>> 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
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>> 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.
>>>>>
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>> 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?
>>>>
>>>>   
>>>>       
>>>>         
>>>>>>  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.
>>>>>
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>>>>  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?
>>>>
>>>>   
>>>>       
>>>>         
>>> 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.
>
>   
>>>  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
>>     

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

Thanks
Mark

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

[James Bottomley]

On Thu, 2010-06-17 at 07:04 -0400, Mark Hounschell wrote: 
> On 05/31/2010 11:17 AM, Mark Hounschell wrote:
> > On 05/31/2010 10:02 AM, James Bottomley wrote:
> >   
> >> On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
> >>   
> >>     
> >>> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
> >>>     
> >>>       
> >>>> On 05/28/2010 04:25 PM, James Bottomley wrote:
> >>>>   
> >>>>       
> >>>>         
> >>>>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> >>>>>>> Reply-To: James.Bottomley@suse.de
> >>>>>>>
> >>>>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>             
> >>>>>>>               
> >>>>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
> >>>>>>>>
> >>>>>>>>     
> >>>>>>>>         
> >>>>>>>>           
> >>>>>>>>               
> >>>>>>>>                 
> >>>>>>>>> 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.
> >>>>>>>>>       
> >>>>>>>>>           
> >>>>>>>>>             
> >>>>>>>>>                 
> >>>>>>>>>                   
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>             
> >>>>>>>               
> >>>>>>>>> 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?
> >>>>>>>>>       
> >>>>>>>>>           
> >>>>>>>>>             
> >>>>>>>>>                 
> >>>>>>>>>                   
> >>>>>>>> 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
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>             
> >>>>>>>               
> >>>>>> 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.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>> 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?
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>>>>>  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.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  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?
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>> 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.
> >
> >   
> >>>  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
> >>     
> 
> I know your a busy guy,  I was just wondering if this BUG is still being
> given consideration? 

Yes, but it got lost in the merge window.  I was investigating where the
break is ... since the whole of block has allowances for 256 byte sector
devices, it seems that something once used it.

James

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

[bugzilla-daemon]

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





--- Comment #7 from Mark Hounschell <dmarkh@cfl.rr.com>  2010-05-28 19:30:11 ---
On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>
>
>
>
>
> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> Reply-To: James.Bottomley@suse.de
>
> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>   
>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>
>>     
>>> 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.
>>>       
>> 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.
>
>   
>>> 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?
>>>       
>> 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
>
>   
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???

Regards
Mark

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #8 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 20:26:28 ---
Reply-To: James.Bottomley@suse.de

On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=16058
> >
> >
> >
> >
> >
> > --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> > Reply-To: James.Bottomley@suse.de
> >
> > On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
> >   
> >> On Fri, 28 May 2010, Mark Hounschell wrote:
> >>
> >>     
> >>> 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.
> >>>       
> >> 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.
> >
> >   
> >>> 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?
> >>>       
> >> 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
> >
> >   
> 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.

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

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

James

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #9 from Mark Hounschell <dmarkh@cfl.rr.com>  2010-05-30 11:51:53 ---
On 05/28/2010 04:25 PM, James Bottomley wrote:
> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>   
>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>     
>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>
>>>
>>>
>>>
>>>
>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>> Reply-To: James.Bottomley@suse.de
>>>
>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>   
>>>       
>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>
>>>>     
>>>>         
>>>>> 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.
>>>>>       
>>>>>           
>>>> 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.
>>>
>>>   
>>>       
>>>>> 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?
>>>>>       
>>>>>           
>>>> 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
>>>
>>>   
>>>       
>> 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.
>
>   

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?

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

Regards
Mark

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #10 from Mark Hounschell <dmarkh@cfl.rr.com>  2010-05-31 11:28:08 ---
On 05/30/2010 07:51 AM, Mark Hounschell wrote:
> On 05/28/2010 04:25 PM, James Bottomley wrote:
>   
>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>>   
>>     
>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>>     
>>>       
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>>> Reply-To: James.Bottomley@suse.de
>>>>
>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>>   
>>>>       
>>>>         
>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>>
>>>>>     
>>>>>         
>>>>>           
>>>>>> 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.
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> 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.
>>>>
>>>>   
>>>>       
>>>>         
>>>>>> 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?
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> 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
>>>>
>>>>   
>>>>       
>>>>         
>>> 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.
>>
>>   
>>     
> 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?
>
>   
>>>  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.
>>
>>   
>>     
>>>  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?
>
>   

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

Regards
Mark

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #11 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-31 14:03:42 ---
Reply-To: James.Bottomley@suse.de

On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
> > On 05/28/2010 04:25 PM, James Bottomley wrote:
> >   
> >> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
> >>   
> >>     
> >>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> >>>     
> >>>       
> >>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> >>>> Reply-To: James.Bottomley@suse.de
> >>>>
> >>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
> >>>>   
> >>>>       
> >>>>         
> >>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
> >>>>>
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> 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.
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> 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.
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>>>>> 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?
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> 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
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>> 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.
> >>
> >>   
> >>     
> > 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?
> >
> >   
> >>>  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.
> >>
> >>   
> >>     
> >>>  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?
> >
> >   
> 
> 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 ...

>  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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #12 from Mark Hounschell <dmarkh@cfl.rr.com>  2010-05-31 15:18:37 ---
On 05/31/2010 10:02 AM, James Bottomley wrote:
> On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
>   
>> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
>>     
>>> On 05/28/2010 04:25 PM, James Bottomley wrote:
>>>   
>>>       
>>>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>>>>   
>>>>     
>>>>         
>>>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>>>>     
>>>>>       
>>>>>           
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>>>>> Reply-To: James.Bottomley@suse.de
>>>>>>
>>>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>>>>   
>>>>>>       
>>>>>>         
>>>>>>             
>>>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>>>>
>>>>>>>     
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>>>> 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.
>>>>>>>>       
>>>>>>>>           
>>>>>>>>             
>>>>>>>>                 
>>>>>>> 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.
>>>>>>
>>>>>>   
>>>>>>       
>>>>>>         
>>>>>>             
>>>>>>>> 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?
>>>>>>>>       
>>>>>>>>           
>>>>>>>>             
>>>>>>>>                 
>>>>>>> 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
>>>>>>
>>>>>>   
>>>>>>       
>>>>>>         
>>>>>>             
>>>>> 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.
>>>>
>>>>   
>>>>     
>>>>         
>>> 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?
>>>
>>>   
>>>       
>>>>>  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.
>>>>
>>>>   
>>>>     
>>>>         
>>>>>  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?
>>>
>>>   
>>>       
>> 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.

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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #13 from Mark Hounschell <dmarkh@cfl.rr.com>  2010-06-17 11:06:21 ---
On 05/31/2010 11:17 AM, Mark Hounschell wrote:
> On 05/31/2010 10:02 AM, James Bottomley wrote:
>   
>> On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
>>   
>>     
>>> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
>>>     
>>>       
>>>> On 05/28/2010 04:25 PM, James Bottomley wrote:
>>>>   
>>>>       
>>>>         
>>>>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
>>>>>>     
>>>>>>       
>>>>>>           
>>>>>>             
>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
>>>>>>> Reply-To: James.Bottomley@suse.de
>>>>>>>
>>>>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
>>>>>>>>
>>>>>>>>     
>>>>>>>>         
>>>>>>>>           
>>>>>>>>               
>>>>>>>>                 
>>>>>>>>> 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.
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>> 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.
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>>>>> 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?
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>> 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
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>> 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.
>>>>>
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>> 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?
>>>>
>>>>   
>>>>       
>>>>         
>>>>>>  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.
>>>>>
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>>>>  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?
>>>>
>>>>   
>>>>       
>>>>         
>>> 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.
>
>   
>>>  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
>>     

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

Thanks
Mark

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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





--- Comment #14 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-06-17 13:36:44 ---
Reply-To: James.Bottomley@suse.de

On Thu, 2010-06-17 at 07:04 -0400, Mark Hounschell wrote: 
> On 05/31/2010 11:17 AM, Mark Hounschell wrote:
> > On 05/31/2010 10:02 AM, James Bottomley wrote:
> >   
> >> On Mon, 2010-05-31 at 07:25 -0400, Mark Hounschell wrote:
> >>   
> >>     
> >>> On 05/30/2010 07:51 AM, Mark Hounschell wrote:
> >>>     
> >>>       
> >>>> On 05/28/2010 04:25 PM, James Bottomley wrote:
> >>>>   
> >>>>       
> >>>>         
> >>>>> On Fri, 2010-05-28 at 15:29 -0400, Mark Hounschell wrote:
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> On 05/28/2010 12:34 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org>  2010-05-28 16:34:28 ---
> >>>>>>> Reply-To: James.Bottomley@suse.de
> >>>>>>>
> >>>>>>> On Fri, 2010-05-28 at 10:58 -0400, Alan Stern wrote:
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>             
> >>>>>>>               
> >>>>>>>> On Fri, 28 May 2010, Mark Hounschell wrote:
> >>>>>>>>
> >>>>>>>>     
> >>>>>>>>         
> >>>>>>>>           
> >>>>>>>>               
> >>>>>>>>                 
> >>>>>>>>> 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.
> >>>>>>>>>       
> >>>>>>>>>           
> >>>>>>>>>             
> >>>>>>>>>                 
> >>>>>>>>>                   
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>             
> >>>>>>>               
> >>>>>>>>> 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?
> >>>>>>>>>       
> >>>>>>>>>           
> >>>>>>>>>             
> >>>>>>>>>                 
> >>>>>>>>>                   
> >>>>>>>> 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
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>             
> >>>>>>>               
> >>>>>> 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.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>> 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?
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>>>>>  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.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  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?
> >>>>
> >>>>   
> >>>>       
> >>>>         
> >>> 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.
> >
> >   
> >>>  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
> >>     
> 
> I know your a busy guy,  I was just wondering if this BUG is still being
> given consideration? 

Yes, but it got lost in the merge window.  I was investigating where the
break is ... since the whole of block has allowances for 256 byte sector
devices, it seems that something once used it.

James

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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

xerofoify@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xerofoify@gmail.com

--- Comment #15 from xerofoify@gmail.com ---
This bug is against obsolete kernel. Please try with
newer kernel to see if it's fixed.
Cheers Nick

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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

Alan <alan@lxorguk.ukuu.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alan@lxorguk.ukuu.org.uk
         Resolution|---                         |OBSOLETE

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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

Mark Hounschell <dmarkh@cfl.rr.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmarkh@cfl.rr.com

--- Comment #16 from Mark Hounschell <dmarkh@cfl.rr.com> ---
This bug is still valid. A 256 byte sector disk will cause kernel-4.0.2 to
hang.
Every since this bug was reported I have rolled my own patch that causes 256
byte sector disk to be unsupported for a linux fs. I use these disks in raw
mode using sg3 API only. No one would ever use these disks for a linux fs. I
would be happy to submit this patch. 

Mark

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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

Alan <alan@lxorguk.ukuu.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
     Kernel Version|2.6.27                      |4.0.2
         Resolution|OBSOLETE                    |---

--- Comment #17 from Alan <alan@lxorguk.ukuu.org.uk> ---
It would be good to get this fixed so if you have a patch it would be good to
get it upstream. The only users I know of 256 byte/sector are a few ancient USB
devices and also retro-computing folk . For the retro stuff the file systems
are not native Linux anyway so requiring sg wouldn't be a problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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

--- Comment #18 from Mark Hounschell <dmarkh@cfl.rr.com> ---
Created attachment 176501
  --> https://bugzilla.kernel.org/attachment.cgi?id=176501&action=edit
make scsi disk 256 byte sector unsupported for linux filesystems

This patch makes 256 byte sector disks unsupported for linux fs. Since kernel
2.6.x or so I have been unable to boot with a 256 byte sector installed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

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

--- Comment #19 from Mark Hounschell <dmarkh@cfl.rr.com> ---
Feel free to add my signed off by:

Signed-off-by: Mark Hounschell <dmarkh@cfl.rr.com>

-- 
You are receiving this mail because:
You are watching the assignee of the bug.