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. Does anyone know why the drive would not be able to cope with this command? And also, why does it not choke on it in USB 2.0 mode but only in USB 3.0? -Jonas -- 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
