On Mon, 2 Apr 2012, Norman Diamond wrote: > 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.) You really should capture a usbmon trace while running the dd test. That will show exactly what is happening. See Documentation/usb/usbmon.txt. > >> 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. How do you know? That is, how do you know that the number printed by hdparm above is the value used by Windows and not a value obtained directly from the bridge by the hdparm program itself? Not that I have any reason to doubt this result -- I have no way of knowing whether or not Windows subtracts 1 from the value reported by any USB-(S)ATA bridge. By the way, just out of curiosity, why does it matter so much for your program to know the exact number of blocks a drive contains? > >>> 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.) Yes, there really are such bridges. You can find reports from people complaining about them in the email archives. Alan Stern -- 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
