Alan Stern wrote: > On Tue, 3 Apr 2012, Norman Diamond wrote: >>>> Wrong. We CAN try to read the last block that the bridge says exists, to see if it really exists or not. (Well, only partly wrong. Maybe there really are some bridges that crash in that situation, but mine doesn't, and a broken driver still needs fixing.) >>> >>> Yes, there really are such bridges. You can find reports from people complaining about them in the email archives. >> >> Wait. Is there a bridge which overreports the last sector number by 1, and which ALSO crashes when the host PC tries to read that supposed last sector number? > > Yes. Like I said before, you can find complaints about these things in the mailing list archives. However it's not clear whether the crashing is the fault of the bridge itself or the drive it is attached to. Or the driver. I think it is not the fault of the drive. If a drive crashed when a driver tried to access a nonexistent sector, then the drive would crash when mounted internally on an ATA or SATA cable not only when connected to a USB cable. It might be the fault of the bridge, BUT, does a single bridge really suffer from BOTH faults as I asked? You seem to be saying yes, but then you cloud it up by saying it's unclear if it might be the drive instead of the bridge. I still wonder if it's the driver instead of the bridge, but surely not the drive. >> If so then we need a quirk for that doubly broken bridge. > > That's what the existing quirk entries are there for. Surely that's not what the quirk is for on my bridge. >> But otherwise, we can try to read the supposedly last sector number and figure out whether we have to subtract 1. > > True enough, but we don't have any way to know which bridges do crash and which don't other than trying it. And you'll probably agree that trial and error is not such a good idea in the cases where the bridge does crash. This still makes me wonder why Windows is able to handle the same bridges. Now, as far as I can tell, I have found a WTF of a standard. I only have drafts of old T10 documents but it sure looks like a WTF unless something was fixed later. In SCSI Block Commands, it seems to me that the READ CAPACITY (10) command (opcode 0x25) returns the number of blocks. In Reduced Block Commands, it says explicitly that the READ CAPACITY command (opcode 0x25) returns the LBA of the last logical block of the media contained in the device. So a USB-to-ATA bridge is required to subtract 1 from the number of blocks reported by ATA IDENTIFY, and a USB-to-SCSI bridge has to subtract 1 from the result of READ CAPACITY (10). (Our present discussion involves the fact that a defective bridge might not subtract that 1, whereupon the next step gets spindled and mutilated.) If a driver wants the last block number then it has to subtract 1 in the case of SCSI, and it wants the number of blocks then it has to add 1 in the case of USB. Did I really read this right? -- 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
