On Fri, 27 May 2011 markk@xxxxxxxxxxx wrote: > Hi, > > Alan Stern wrote: > >> Since most PL-3507 enclosures are probably user-upgradable and the most > >> recent > >> firmware doesn't have the off-by-one bug, it might be better to not > >> include > >> that UNUSUAL_DEV entry. Otherwise, e.g. using dd to create an image file > >> of the > >> disk omits the last sector. > > > > How is the kernel supposed to tell whether or not an enclosure is > > running the latest firmware? We don't want drives that haven't been > > updated yet to suddenly stop working right. > > That's a good question. There may not be anything in the lsusb output (see > below) to indicate the firmware version. There is a field which _should_ indicate the firmware version: bcdDevice. But the value is 0.01, which isn't helpful since the last-sector bug was originally reported for devices with that same value. In fact, the problem had already been fixed at the time it was originally reported (in 2005!). But not everybody can upgrade their firmware. See http://marc.info/?l=linux-usb-devel&m=111753034313487&w=2 > It is definitely possible to > determine the version though; the Prolific flashing program does that. I > haven't looked at its code to see exactly how it talks to the enclosure. Maybe we could copy the algorithm. I don't know if it would be worthwhile, though. > There is a changelog In the firmware archive on the Prolific web site but > none of the entries explicitly states when the off-by-one error was fixed. > > What is the typical failure mode if a device with off-by-one capacity bug > is connected? I'm assuming the kernel tries to read (what it thinks is) > the last sector, which fails. Right. > Does the kernel then refuse to access the > device at all? Or is the issue that the device itself crashes/hangs on > receiving a READ command for a too-large LBA? The kernel doesn't refuse anything; it just retries the failed command a bunch of times and then gives up and moves on to the next command. Various devices behave differently. Some simply return an error. Some wait for a while and then return an error (which makes the sequence of retries extremely slow). Some hang. Even under the best circumstances, we don't want the kernel to think the "last" sector really exists. It might try to write something important there. It is possible for you to override the last-sector flag by providing a module parameter for usb-storage: modprobe usb-storage quirks=0x067b:0x3507: should do it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
