Yes, there is a bug on device side. Device side application logic is not expecting this request and locks up. It should respond with a STALL for such requests. That said, it was very unusual to see a MS specific descriptor request during Linux enumeration. We were not able to see similar request for a USB 3.0 Hard disk (maybe the HDD had already STALLed in a previous enumeration). Thanks, Aditya On Mar 29, 2012, at 2:58 AM, Peter Stuge <peter@xxxxxxxx> wrote: > Hi Sarah, > > Sarah Sharp wrote: >> Here is the other mail I was referring to in the thread with shashank. >> >> Alan, perhaps there's a change from 2.6.38 to 3.0 that makes the USB >> core request a string descriptor that the USB devices don't like? >> >> On Tue, Mar 27, 2012 at 08:23:03PM +0530, Aditya Mittal wrote: >>> We see a request for string descriptor 238 (0xEE) which is a microsoft >>> specific descriptor with kernel 3.0.0 whereas we do not see a request for >>> this string descriptor for version 2.6.38. > > Interesting. The 0xee string is indeed a Microsoft USB extension. It > can be used to tell Windows what driver it should use for the device. > Works really well out of the box on Windows 8 and later. > > I'm also surprised if Linux is sending that. I'm not saying that it's > wrong, just surprised. In any case, any device *must* be able to deal > with a request for a string descriptor which doesn't exist. > > This is clearly a problem in the device, regardless of where the 0xee > request is coming from. (Wild guess: virtual machine someone forgot > was still running?) Windows XPSP1 and later ask exactly once for the > string descriptor, for every device that hasn't been seen before. > > > //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
