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

[James Bottomley <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