Re: xhci: suspend/resume issues

[Sarah Sharp <sarah.a.sharp@linux.intel.com>]

Ccing the scsi and USB mass storage devices lists on this issue.
Background: a USB 3.0 mass storage device shows up as a USB 2.0 device
after resume, and then migrates back to USB 3.0 speeds after a reset.

On Mon, Nov 22, 2010 at 05:49:47PM -0500, Don Zickus wrote:
> On Fri, Nov 19, 2010 at 03:30:46PM -0800, Sarah Sharp wrote:
> > The fifth patch had no effect on whether the device showed up as
> > SuperSpeed after a system resume, so I don't think it's needed.  Even
> > after the four I sent yesterday, the device still shows up as high speed
> > at first, which means USB persist won't work for it.  I'm going to look
> > into Alan Stern's suggestion to reorder the HS ports to be before the SS
> > ports.  I will probably need you to test again.
> > 
> > Thanks for working with me on this.
> 
> Thanks Sarah for you help.
> 
> Another issue popped up for me.  I noticed when I suspend having a usb3
> filesystem mounted (ie mount /dev/sdb2 /mnt), when the system comes back
> up, the filesystem is remounted onto /media (probably a distro thing) but
> more importantly it comes back as /dev/sdbc (note the 'c' and not 'b').

That's normal, as the USB core thinks the device disconnected, and a new
device was placed on that same port.  The USB core has to assume it was
a new device, so the block layer will create a new filesystem (sdc) for
it.  That's just a by-product of the broken device connecting as high
speed and then re-connecting as SuperSpeed once it's reset.

I was going to create a patch to reorder the ports, but Greg KH declined
to take the 2 patches that you've successfully tested for 2.6.37, as
they're too large.  Since I can't fix your broken device in 2.6.37, I'll
skip the workarounds I sent you and just send the split roothub patches
for 2.6.38.  Those should fix your issues, since they do an equivalent
thing to the disable ports patches I sent.  I'll have to send those
patches to test once they're finished.

> Looking into my previously mounted /mnt directory yields an i/o error
> (probably because it is now under /dev/sdc).

As long as it doesn't produce any kernel oops, that's normal.  The
kernel has noticed the device went away, but userspace hasn't.  At
least, that's my general impression.  You'll have to ask the USB mass
storage guys, or the SCSI folks for the details on how that's supposed
to work.

> Unmounting everything and remounting 'mount /dev/sdc2 /mnt' (using the new
> letter 'c' instead of 'b') works fine and no data loss seems to occur.
> 
> Just thought it might be annoying and was wondering if you had any ideas
> on that?

There's no way to work around it if the device disconnects, AFAIK.

Sarah