On Thu, Nov 04, 2010 at 09:32:07AM -0700, VanCutsem, Geoffroy wrote: > Hi Sarah, > > > -----Original Message----- > > From: Sharp, Sarah A > > > > There may be both EHCI and xHCI host controllers in the same system. > > xHCI handles all speeds of USB devices plugged into it. The odd thing > > is your dmesg on the bug report you linked to shows that the xHCI > > driver > > is handling your storage device, but your lspci output doesn't show it! > > Wasn't it reflected by this entry: > 0f:00.0 USB Controller: NEC Corporation Device 0194 (rev 03) (prog-if 30) Oh, sorry, I guess I missed that. > I have done this today and the interesting thing is that with this vanilla 2.6.35.8 kernel (from kernel.org) and debugging turned on, the problem seems to have gone away. I have been able to 'dd' the exact same image onto a USB stick (tried twice, once from a USB3 port and once from the 'normal' port)... so perhaps this is a bug in Ubuntu/Canonical variant of 2.6.35?? I have attahched the relevant dmesg / lspci output to this email. Well, I'm not so sure you actually triggered the bug. The previous log showed the crash after the USB device disconnected in the middle of the dd transfer. This log doesn't show a disconnect during a transfer under the USB 3.0 port; it only shows a disconnect when you switched the device over to the USB 2.0 port. You can probably trigger the bug if you physically pull out the device while you're in the middle of the dd. Can you try that with the 2.6.35.8 kernel? Another possibility is the USB core and xHCI debugging is causing a delay that's hiding the bug. You can also try turning off debugging on the 2.6.35.8 kernel and dding a iso over, if yanking out the device doesn't cause the bug. Sarah Sharp -- 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
