xhci: suspend/resume issues
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20101111210420.GA9020@xanatos
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20101119185907.GA30923@xanatos
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20101119233046.GA13059@xanatos
A message that is not in the archive (sent off-list or not yet received): [email protected]
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.
Quoted 8 lines · Don Zickus
Quoted 7 lines · Sarah Sharp
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 5 lines
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
Quoted 5 lines · Sarah Sharp
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:
Quoted 8 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 5 lines
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
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver I could always suspend a few hundred accounts and watch what happens. -- Tanya User Friendly, 7/31/1998
Quoted 28 lines · Sarah Sharp
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.Quoted 8 lines · Don Zickus
Quoted 7 lines · Sarah Sharp
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 10 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 5 lines
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