First, more big news: My USB-to-IDE bridge DOES NOT CRASH when reading a bad block. When a Linux driver tries to reassign a new USB address and crashes the bridge, the fault is a Linux driver. (And when Windows forgets about the existence of the drive, the fault is Windows.) echo 0 >/sys/block/sdc/queue/read_ahead_kb might or might not be necessary; I haven't tried sg_dd without it. sg_dd if=/dev/sdc bs=512 count=1 bpt=1 blk_sgio=1 skip=39070080 | od gets the error that I expected because the block doesn't exist. dmesg does not show the error; sg_dd detected the error and displayed it on the terminal. Next I can do this: sg_dd if=/dev/sdc bs=512 count=1 bpt=1 blk_sgio=1 skip=39070079 | od and get the contents of the last block. sg_dd if=/dev/sdc bs=512 count=1 bpt=1 blk_sgio=1 skip=551562 | od gets the error that I expected because the block is bad. dmesg does not show the error; sg_dd detected the error and displayed it on the terminal. Next I can do this: sg_dd if=/dev/sdc bs=512 count=1 bpt=1 blk_sgio=1 skip=551563 | od and get the contents of the block after the bad block. The USB cable did not need to be unplugged and replugged. Therefore when an ordinary dd fails and a USB driver tries to assign a new address but fails, and the USB cable has to be unplugged and replugged, the fault is a driver. Alan Stern wrote: > On Sat, 31 Mar 2012, Norman Diamond wrote: > >>>> bcdDevice is 1.00 >>> >>> That's the same as a bridge that was reported non-working. Which means the OS has no way to tell them apart. >> >> There's still something wrong here. When the bridge is connected to Windows XP, Windows accesses the correct number of blocks. We need to find someone who has a non-working but indistinguishable bridge, ask them to connect it to Windows XP, and see if Windows XP gets a number of blocks that is too large by 1. > > How would you tell? http://hdparm-win32.dyndns.org/hdparm/ D:\hdparm for Windows\binary\hdparm-6.9-20070516.win32\bin>hdparm /dev/sdg /dev/sdg: geometry = 2432/255/63, sectors = 39070080, start = 0 Windows did not get a number of blocks that was too large by 1. The bridge provided the correct answer for READ CAPACITY, Windows accepted it, and Linux improperly subtracted 1. > And what's so special about XP? Why not Vista or Windows 7? OK, I have Windows 7 installed in two computers (64 bit and 32 bit) and should try the Windows port of the obsolete version of hdparm. >>> There is no good solution to this problem. >> >> Agreed. 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.) >> But in my case I think I need to disable that quirk entirely for all USB bridges, so that my uses of Linux will always believe what the USB bridge reports. At least then my program will work correctly when working bridges are attached. Then if a user complains, we can tell them to use a different bridge. > > Well, if you want to disable the quirk entirely, it's not hard to do. > In drivers/usb/storage/scsiglue.c, just get rid of the lines that set > sdev->fix_capacity and sdev->guess_capacity. > > If you want to find out who reported the problems with the bridge chip, look in the unusual_devs.h file for the entry with vendor ID 0x067b and product ID 0x2507. Uh, then feel free to credit me in that file for reporting that the same bridge works ^_^ -- 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
