*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
