Hi,
A few weeks ago I sent you debugging information for the problem
described below. Now I tried again using linux-3.5.1, and the problem
still exists. However, I got a new mainboard now that has Intel USB3
ports and ASM1042 USB3 ports. With both chipsets and the xhci_hcd driver
I get the same problems as with the one used on the older mainboard,
Etrontech EJ168A.
Any news?
Am 16.05.2012 23:59, schrieb Sarah Sharp:
On Tue, May 15, 2012 at 09:34:07AM +0200, Harald Judt wrote:
Hi Sarah,
The problem is still present in linux-3.4.0-rc7. You did not respond
to my last mail, so I simply decided to resend it, including the
attachments.
Maybe you can spend some time to look into this?
Hi Harald,
I'm sorry about not responding quickly about this. Thanks for reminding
me about this. I'll look into it.
Sarah Sharp
Am 18.04.2012 20:17, schrieb Harald Judt:
Hi Sarah,
Thanks for your response.
Am 11.04.2012 22:43, schrieb Sarah Sharp:
Hi Harald,
Can you point me to the original dmesg from both the successful run
under EHCI and the unsuccessful run under xHCI? I can't seem to find
it.
Attached you will find both original dmesg that I've sent to the mailing
list. IIRC there was not much revelatory information to find there
though.
I also need dmesg with CONFIG_USB_DEBUG and
CONFIG_USB_XHCI_HCD_DEBUGGING enabled for the run under xHCI.
A dmesg with these debugging options enabled is also attached
(xhci-debug-enabled).
I (very carefully) removed private data and some unnecessary
information, but there shouldn't be anything important missing. All
attachments are bzip2 compressed, as some are rather big. I hope they
prove helpful.
Harald
On Tue, Apr 10, 2012 at 12:43:58PM +0200, Harald Judt wrote:
*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.'
--
`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
