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
