Matthew Dharm wrote: > On Mon, Aug 04, 2008 at 03:10:04AM +0200, Douglas Gilbert wrote: >> Alan Stern has already noted to another smartmontools developer >> that such a change is likely to break some USB storage devices. >> Perhaps the maximum sense buffer size could be optionally >> specified per usb storage device. Alternatively the usb mass >> storage logic could make some dynamic decisions itself. > > To clarify: A great many devices choke (fatally) if asked for sense data > other than 18 bytes. Since the first TEST_UNIT_READY will likely require > sense data, almost every device sees REQUEST_SENSE. > > Personally, I hate having to make dynamic decisions in usb-storage. The > more we try to do there, the more likely we are to get it wrong. > > If you've got an app that is sending a command, and you KNOW that command > should produce >18 bytes of sense data, then there should be a way to > specify to the SCSI core (and thus get passed to usb-storage) that sense > data of >18 bytes should be requested. > What?!! The number 18 comes totally from USB land at: drivers/usb/storage/transport.c:601 via call to scsi_eh_prep_cmnd Otherwise the entire kernel including scsi-ml and all user applications request 96 bytes of sense, always. So there is nothing the SCSI core or application can do about it. It is USB fix time I'm afraid. > Matt > The SAT layer will have to override transport.c/usb_stor_invoke_transport somehow and make do for bigger REQUEST_SENSE. Or a sense_size param per host, or per command. Boaz -- 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
