* Re: [usb-storage] xhci: suspend/resume issues
2010-11-22 23:15 ` xhci: suspend/resume issues Sarah Sharp
@ 2010-11-23 4:51 ` Matthew Dharm
2010-11-23 19:09 ` Don Zickus
1 sibling, 0 replies; 3+ messages in thread
From: Matthew Dharm @ 2010-11-23 4:51 UTC (permalink / raw)
To: Sarah Sharp; +Cc: Don Zickus, usb-storage, linux-usb, Xu, Andiry, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]
On Mon, Nov 22, 2010 at 03:15:24PM -0800, Sarah Sharp wrote:
> 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:
> > 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.
That's mostly right. The USB and SCSI layers know the device has gone
away, but there is no way to signal to the filesystem layers that the
underlying device is gone. So, all the I/O requests are simply 'failed'
until the device is unmounted, at which point the refcount drops to zero
and the structures are actually deleted.
> > 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.
I'm coming late to the discussion, but Sara is right. If the device
disconnects, there is no way to know that it is the same device when it
reconnects.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
I could always suspend a few hundred accounts and watch what happens.
-- Tanya
User Friendly, 7/31/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: xhci: suspend/resume issues
2010-11-22 23:15 ` xhci: suspend/resume issues Sarah Sharp
2010-11-23 4:51 ` [usb-storage] " Matthew Dharm
@ 2010-11-23 19:09 ` Don Zickus
1 sibling, 0 replies; 3+ messages in thread
From: Don Zickus @ 2010-11-23 19:09 UTC (permalink / raw)
To: Sarah Sharp; +Cc: Xu, Andiry, linux-usb, usb-storage, linux-scsi
On Mon, Nov 22, 2010 at 03:15:24PM -0800, Sarah Sharp wrote:
> 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.
Yes please do.
>
> > 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.
Alright, thanks for the info.
Cheers,
Don
^ permalink raw reply [flat|nested] 3+ messages in thread