From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Date: Fri, 02 Apr 2010 14:41:07 +0000 Subject: Re: System hangs when using USB 3.0 HD with on Ubuntu Message-Id: <1270219267.2899.73.camel@mulgrave.site> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Alan Stern Cc: Jonas Schwertfeger , Kay Sievers , Douglas Gilbert , David Zeuthen , linux-hotplug-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sarah Sharp , linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, USB Storage List , Matthew Dharm , linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lennart Poettering On Fri, 2010-04-02 at 10:12 -0400, Alan Stern wrote: > On Fri, 2 Apr 2010, Jonas Schwertfeger wrote: >=20 > > Actually, you hit the nail on the head Kay. I moved the hdparm rule > > out of the way and voil=C3=A0, the drive mounts. I then manually ran hd= parm > > on the device: > >=20 > > sudo hdparm --verbose /dev/sdb > >=20 > > /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=3D0x0, host_status=3D0x7, driver_status=3D0x0 > > 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=3D0x0, host_status=3D0x7, driver_status=3D0x0 > > SG_IO: bad response (not CHECK_CONDITION) > > HDIO_DRIVE_CMD(identify) failed: Invalid exchange > > readonly =3D 0 (off) > > readahead =3D 256 (on) > > geometry =3D 36365/64/32, sectors =3D 0, start =3D 0 > >=20 > > 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. >=20 > That's nice to know. Other people have been reporting similar=20 > 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? >=20 > No idea. Except that it's probably not the drive's fault, but rather=20 > 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? >=20 > 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=20 > yet implemented reset. Hence no recovery is possible. >=20 > Alan Stern >=20 > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html