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? Harald 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.'
Attachment:
scanimage-usb2.dmesg.bz2
Description: application/bzip
Attachment:
scanimage-usb3.dmesg.bz2
Description: application/bzip
Attachment:
xhci-debug-enabled.dmesg.bz2
Description: application/bzip
