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
--
`Experience is the best teacher.'
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
--
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
