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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
