From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sarah Sharp Date: Fri, 02 Apr 2010 17:36:25 +0000 Subject: Re: System hangs when using USB 3.0 HD with on Ubuntu Message-Id: <20100402173625.GB4864@xanatos> 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@vger.kernel.org, linux-usb@vger.kernel.org, USB Storage List , Matthew Dharm , linux-scsi@vger.kernel.org, Lennart Poettering On Fri, Apr 02, 2010 at 10:12:35AM -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=E0, the drive mounts. I then manually ran hdparm > > 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. >=20 > > 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. >=20 > > 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. 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