Hi,
Thanks for your response.
Am 25.02.2012 20:39, schrieb Alan Stern:
On Sat, 25 Feb 2012, Harald Judt wrote:
Hi,
Am 23.02.2012 19:23, schrieb Alan Stern:
On Thu, 23 Feb 2012, Harald Judt wrote:
Hi,
I've been asked to contact this mailing list regarding
https://bugzilla.kernel.org/show_bug.cgi?id=42784:
Using the same configuration (kernel-3.3-rc4 and older versions), Canon
CanoScan LiDE 20 USB scanner works on the USB-2.0 port, but not on USB-3.0.
usb 5-1: usbfs: interface 0 claimed by usbfs while 'scanimage' sets
config #1
This message is not printed when using USB-2.0.
You can get more information in the dmesg log if you do:
echo true>/sys/module/usbcore/parameters/usbfs_snoop
before plugging in the scanner. Compare the results for the two
different ports.
Thanks for your response. I performed the following steps:
1) Deactivate the udev rules which start scanbuttond, so it won't get in
the way, because it spawns its own scanimage process at initialization.
2) echo 1> /sys/module/usbcore/parameters/usbfs_snoop
3) Connect scanner to usb2 port and execute scanimage -L, disconnect
scanner.
4) Connect scanner to usb3 port and execute scanimage -L, break out of
the ever-looping scanimage using<C>-<c>, disconnect scanner.
I've attached the kernel logs for step 3 and step 4. As they're not so
small, I bzipped them, I hope that's ok for you.
When I wrote "dmesg log" above, I didn't mean the dmesg file in
/var/log; I meant the output from the "dmesg" command. Sorry, I
should have made that more clear.
No, your suggestion was clear enough. I would have sent you the output
from the dmesg command had there been useful information in it. But it
was completely flooded with those usb 5-1: usbdev_do_ioctl:
REAPURBNDELAY lines. The log and the dmesg should be identical, except
the missing timestamps in dmesg.
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.
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?
Harald
--
`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
