linux-kernel - Looks like a broken hub? (was Re: 3.16.2: 2TiB Seagate Expansion Desk apparently still broken with both USB mass storage *and* UAS: some debugging output)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 07 Sep 2014 23:14:58 +0100
From:	Nix <nix@...eri.org.uk>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alexandre Oliva <oliva@....org>,
	Matthew Dharm <mdharm-usb@...-eyed-alien.net>,
	USB list <linux-usb@...r.kernel.org>,
	Linux SCSI List <linux-scsi@...r.kernel.org>
Subject: Looks like a broken hub? (was Re: 3.16.2: 2TiB Seagate Expansion Desk apparently still broken with both USB mass storage *and* UAS: some debugging output)

On 7 Sep 2014, Alan Stern spake thusly:

> On Sun, 7 Sep 2014, Nix wrote:
>
>> I have a brand new Seagate Expansion Desk drive attached to my x86-64
>> desktop. (I also have a 4TiB model of the same drive, but I haven't even
>> unboxed it: there seems little point as long as the 2TiB version doesn't
>> work.) I am seeing apparently the same problem as Alexandre Oliva
>> reported in <https://bugzilla.kernel.org/show_bug.cgi?id=79511>. The
>> drive is USB ID 0bc2:3321, so probably a slightly different model than
>> Alexandre's 0bc2:3320, but similar enough to be broken it seems.
>> 
>> I've tried it with both the usb-storage driver on xhci and with UAS,
>> with verbose USB mass storage debugging turned on. Both fail with
>> different log messages: see below. I haven't tried Alexandre's quirk
>> yet. (I have USB debugging for the UAS case only, alas, because the
>> system helpfully autoloaded and used that module when I was trying to
>> replicate the usb-storage-only failure, sigh. Autoloading is annoying
>> sometimes! :) )
>
> ...
>
>> I'm happy to do whatever further debugging people may deem necessary:
>> this system has up-to-date backups and is easy to reboot and try new
>> kernels on, and the drive is brand new and completely empty so it's
>> pretty much impossible to mess up!
>
> Please post a usbmon trace showing what happens when the drive binds to 
> usb-storage.  To prevent extraneous data from cluttering the trace, you 
> should unplug as many of the other USB devices on the same bus as 
> possible before starting the trace.

Done. I dropped the no-name hub out of the equation by taking over my
existing backup device's USB link (which also meant I could figure out
the bus number, since it doesn't change while the system is running :) ).

And... now it works, at least well enough to get a device file. So it's
not the disk that's at fault: it's the no-name hub! (Which is, I think,
USB ID 2109:0811 -- at least two instances of this disappear when I
unplug the hub.)

Attached, usbmon output from a successful negotiation, and a failed one
via the hub.

I am more than slightly annoyed. This machine only *has* two physical
USB3 ports, both on the same bus, and they're almost totally
inaccessible round the back, because of course you'd want your fastest
ports to be hardest to reach. The whole point of this hub was to fix
that stupid case-design decision.

So... anyone got any suggestions for a USB-3 hub I might buy that
doesn't mess things up for devices plugged into it? Do I just need one
new enough that it supports UAS? (And... how on earth can I tell before
buying?)

Sigh. Hardware sucks. (But maybe you can quirk around this...)

View attachment "6.mon.uas.out" of type "text/plain" (87995 bytes)

View attachment "6.mon.hub.out" of type "text/plain" (9678 bytes)