https://bugzilla.kernel.org/show_bug.cgi?id=16058 --- Comment #12 from Mark Hounschell <dmarkh@xxxxxxxxxx> 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@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 > > > > -- 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
