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