On Fri, Apr 02, 2010 at 10:12:35AM -0400, Alan Stern wrote: > On Fri, 2 Apr 2010, Jonas Schwertfeger wrote: > > > Actually, you hit the nail on the head Kay. I moved the hdparm rule > > out of the way and voilà, the drive mounts. I then manually ran hdparm > > on the device: > > > > sudo hdparm --verbose /dev/sdb > > > > /dev/sdb: > > outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00 > > SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0 > > SG_IO: bad response (not CHECK_CONDITION) > > outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00 > > SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0 > > SG_IO: bad response (not CHECK_CONDITION) > > HDIO_DRIVE_CMD(identify) failed: Invalid exchange > > readonly = 0 (off) > > readahead = 256 (on) > > geometry = 36365/64/32, sectors = 0, start = 0 > > > > Does the command sent by hdparm look familiar? Exactly, it is the > > third ATA command (IDENTIFY DEVICE) we discovered earlier and caused > > the drive to stall. > > That's nice to know. Other people have been reporting similar > problems. Now we can tell where they come from. > > > Does anyone know why the drive would not be able to cope with this > > command? > > No idea. Except that it's probably not the drive's fault, but rather > the fault of the USB-(S)ATA chip that controls the drive. > > > And also, why does it not choke on it in USB 2.0 mode but > > only in USB 3.0? > > That's easy: It chokes in USB-2.0 mode also. But the ehci-hcd > driver is able to reset the drive and recover, whereas xhci-hcd has not > yet implemented reset. Hence no recovery is possible. The xhci-hcd driver in 2.6.32 doesn't support configured device reset, but it was added in 2.6.33. So an update to a later kernel should allow the device to work in USB 3.0 mode. Sarah Sharp -- 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
