Hi Harald, Can you point me to the original dmesg from both the successful run under EHCI and the unsuccessful run under xHCI? I can't seem to find it. I also need dmesg with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING enabled for the run under xHCI. Sarah Sharp On Tue, Apr 10, 2012 at 12:43:58PM +0200, Harald Judt wrote: > *BUMP*? > > Am 16.03.2012 10:12, schrieb Harald Judt: > >Hi Sarah, > > > >Am 05.03.2012 18:50, schrieb Sarah Sharp: > >>Hi Harald, > >> > >>Sorry about the lack of response. I'm preparing for a conference this > >>week, so I won't be able to look into this issue until next week. > >> > >>Sarah Sharp > > > >I hope you enjoyed the conference. Do you think you can spare some time > >now to help me with my problem? > > > >Harald Judt > > > > > For reference: > > > On Mon, Mar 05, 2012 at 05:59:17PM +0100, Harald Judt wrote: > >> > >> *BUMP*? > >> > >> Am 27.02.2012 21:41, schrieb Alan Stern: > >>> On Mon, 27 Feb 2012, Harald Judt wrote: > >>> > >>>>>> In step 4 scanimage hung until I interrupted it, producing > lots of the > >>>>>> following repeated lines in dmesg: > >>>>>> usb 5-1: usbdev_do_ioctl: REAPURBNDELAY > >>>>>> To save you from excessive scrolling, I've deleted most of these > >>>>>> repeated lines, as you will recognize when looking at the > timestamps. > >>>>> > >>>>> I don't see any of those "usbfs: interface 0 claimed by usbfs while > >>>>> 'scanimage' sets config #1" messages in either log. Also, both logs > >>>>> show that the scanimage program closed the device file and > then opened > >>>>> it again (although in the USB-2 case a lot of stuff happened first > >>>>> whereas in the USB-3 log relatively little happened). Any idea about > >>>>> that? > >>>> > >>>> Yes, I didn't see these either, neither in dmesg nor in > >>>> /var/log/messages. But that's because scanbuttond was not > running, which > >>>> would normally start "scanimage -L" for initialisation purposes. If I > >>>> enable scanbuttond and do another scanimage -L manually while the one > >>>> started by scanbuttond is still running/hanging, I get the > expected message > >>>> "usb 5-1: usbfs: interface 0 claimed by usbfs while 'scanimage' sets > >>>> config #1" > >>>> But I guess this is ok in this case and just a symptom, and something > >>>> else has to be wrong. > >>> > >>> Yes; those messages probably occur because both programs are trying to > >>> communicate with the scanner at the same time, which is not a good > >>> idea. At the very least, scanimage should have an option to skip its > >>> Set-Configuration step. > >>> > >>>> To summarize: The problem is not with usbfs, but with something else. > >>>> > >>>>> Both logs show minor errors of various sorts, but nothing really > >>>>> serious. At the end of the USB-3 log, it looks like the scanner just > >>>>> stopped replying. It's not clear whether this is because of a > problem > >>>>> in the scanner or the computer. > >>>>> > >>>>> Alan Stern > >>>> > >>>> I successfully tested the scanner in Windows 7 x64, using a trial > >>>> version of VueScan, which installs its own scanner driver, as > Canon does > >>>> not provide its own for this OS version. > >>>> > >>>> Looking at the observations I presented above, I conclude that the > >>>> problem can neither be the scanner nor the computer, but has to be > >>>> driver-related. In this case, rather a problem with USB3 because the > >>>> scanner works perfectly with USB2. BTW: Reproducible with 3.3-rc5+. > >>>> > >>>> I guess the "claimed by usbfs" messages occur with scanbuttond because > >>>> it checks regularly for button presses (on the scanner), and that may > >>>> hang too, producing the dmesg messages when scanimage calls for > action. > >>>> > >>>> What is your opinion on this? Any suggestions on how to proceed > from here? > >>> > >>> At this point it's up to the maintainer of the xhci-hcd driver (i.e., > >>> the USB-3 driver). Sarah will probably have some ideas for further > >>> debugging. > >>> > >>> Incidentally, now that we have a good idea of the reason for those > >>> "claimed by usbfs" messages, there's no reason to continue with > >>> usbfs_snoop turned on. If desired, almost all of the same information > >>> can also be obtained in a much more compact form from usbmon (see the > >>> instructions in Documentation/usb/usbmon.txt). > >>> > >>> But maybe Sarah won't want the usbmon info either. To summarize the > >>> problem: The scanner in question runs at full-speed. It works okay > >>> when attached to a USB-2 port but not when attached to a USB-3 port; at > >>> some point a bulk transfer fails to complete. > >>> > >>> Alan Stern > > -- > `Experience is the best teacher.' -- 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
