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. Alan Stern -- 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
