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 -- 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
