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