On Thu, 23 Jan 2014, Steph Nguyen wrote: > Hi USB team USB team? That sounds like part of a sports league. > I'm trying to debug an issue related to sending an ATA command (IDENTIFY > DEVICE = 0xEC) to a SCSI disk connected to a USB port on my PC. After > turning USB/storage debugging on in the kernel, it turns out that the > issue is with a device babble. If the disk is SCSI, why would it respond to an ATA command? > A little more kernel instrumentation shows that it's the bulk CSW that > is babbled. The CBW is going through fine, the returned data-in is > correct but the CSW length returned by the device to the USB controller > is more than the expected 13 bytes. > > I'm now trying to go further in the debugging process and find out what > is being babbled... The QH overlay is written back properly (including > the token that confirms the babble) but the actual DMA buffer pointed to > by the qh->hw->hw_buf[0] is not. All I can see in this buffer is the > previous command issued in the corresponding CBW (the same DMA buffer is > used for both CBW and CSW). > > So, is there any way of figuring out the babbled content - or in other > words, is the babbled content stored anywhere or is it just discarded by > the USB controller as soon as it sees more bytes coming in than expected? Those are two different questions. It sounds like you have already proved that the content is discarded by the host controller. But that doesn't mean it's impossible to find out what the data was -- all you have to do is use a USB analyzer. Or you could tweak the driver to make it accept a 512-byte CSW. 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
