https://bugzilla.kernel.org/show_bug.cgi?id=16058 --- Comment #13 from Mark Hounschell <dmarkh@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16058 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --- Comment #6 from Anonymous Emailer <anonymous@xxxxxxxxxxxxxxxxxxxx> 2010-05-28 16:34:28 --- >>>>>>> Reply-To: James.Bottomley@xxxxxxx >>>>>>> >>>>>>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
