On Tue, 12 May 2009, Phil Endecott wrote: > Hi Alan, > > I debugged this from the "bottom up" with a USB analyser and wrote down > the SCSI commands as I deciphered them. Basically I see a READ > CAPACITY early on that returns 0000FFF0; a bit later I see reads: > > Address Length > 0 1 > 1 1F > FF00 8 > FFE0 8 > FFF0 1 > > This last one fails. (Oddly the response to REQUEST SENSE looks like > an OK to me - though I don't really know anything about SCSI error > reporting. It has 0x70 in the response code field and everything else > is 0. Did I also see a quirk related to error reporting?) No. > It goes on to do lots of other reads but it re-visits this > beyond-the-end sector several times and each time the read fails. > > So I'm pretty certain that it is, currently, suffering from this > off-by-one bug. But I'm equally sure that it was working before, with > the same kernel. It seems unlikely that this is the sort of bug that > would come-and-go, so my guess is that it causes a problem now because > the flash is nearly full and whatever bit of filesystem metadata is > stored at the end of the device is now reaching into the last block, or > something like that. Or other changes in your userspace environment are now causing some program like udev or hal to try reading the last sector. > I can also see the "prevent/allow removal" commands failing in the USB > analyser trace. That quirk is not necessary to make the device work > but it certainly makes the logs a lot quieter. Okay, then I guess the patch is okay as it stands. Phil D., care to take charge of 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
