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