On Fri, 2010-04-02 at 10:12 -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. Yes ... I think we're starting to need to get a handle on all these userspace random pokes which can disrupt (the admittedly badly written and badly tested) devices which the kernel tries so hard not to upset. > > 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. Best guess (and it's a guess only) would be that the USB bridge SAT layer doesn't implement ATA_16 and so fails in interesting ways when it comes in. Does the ATA_12 version of IDENTIFY DEVICE succeed? James > > 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 -- 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
