Alan Stern wrote: > On Thu, 29 Mar 2012, Norman Diamond wrote: >> Alan Stern wrote: >>> On Wed, 28 Mar 2012, Norman Diamond wrote: >>>> I don't want to manhandle that old notebook's fragile vendor proprietary IDE cable again, but I'll try to find another way to test that drive again without going though USB. >>> >>> You don't have to worry about that. sg_dd works fine over USB. >>> >>>>> The USB-to-IDE bridge is vendor 067b, product 2507, Prolific Technology Inc., and usb-storage matches it for quirk 110. >>> >>> What is the bcdDevice value? >> >> Is that different from 2507? > > It is a separate value from the product ID. It appears in the output from "lsusb -v" or in /sys/kernel/debug/usb/devices (where it is labelled "Rev="). bcdDevice is 1.00 sg_dd did work fine with proper parameters. I apologize for wasting the time of other kind participants in this thread. Fortunately we have one genuine bug here waiting to be fixed. >>>>> Digression: Someone adjusts the number of blocks from the reported 39070080 (which I think is correct) to 39070079 (which I think is wrong). I'll have to install the drive in an old notebook to check if the reported number of blocks is really correct. >>>> >>>> Further on this digression: The number of blocks really is 39070080.� Today libata made no adjustment and the number of blocks was correct. So some USB component makes a misadjustment to screw up the number of blocks. >>> >>> usb-storage does this, because in the past Prolific's bridges have reported the wrong number of blocks. In fact, I'm surprised that it seems to work correctly with your drive. >> >> It is hard to imagine a USB bridge adding 1 to the number of blocks. Did that really happen? > > No. What happened was that the bridge reported the number of blocks, but SCSI's READ CAPACITY command requires the device to report the highest available block number (which is one smaller since blocks are numbered starting from 0). I guess you mean that some USB bridges screw up the result of the READ CAPACITY command, so you have to subtract 1 in those cases. This particular bridge isn't one of them, and the subtraction of 1 was wrong in this case. hdparm reports the bugged capacity after the incorrect subtraction of 1. HDIO_GETGEO_BIG also gets the bugged capacity. I don't see an option to sdparm to get the device capacity (real SCSI devices probably have it in a VPD page but this USB bridge doesn't provide any VPD pages). sg_dd with correct parameters successfully read the actual last block! That must be because sg_dd accessed /dev/sgsomething instead of /dev/sdmumble. My program doesn't know if a USB bridge is defective and/or if a driver defectively manipulated a block count. So I have to open a /dev/sgsomething, try to read 1 sector past the last sector that we think is valid. If it fails then I have to find out if the error was due to nonexistence or other reason. If it succeeds then I have to execute more painful hacks that I have to add. -- 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
