Re: xhci_hcd and Canon Lide 110 not playing well together

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 21 Oct 2012, Holger Hans Peter Freyther wrote:

> On Mon, Oct 15, 2012 at 04:21:47PM -0400, Alan Stern wrote:
> > On Mon, 15 Oct 2012, Holger Freyther wrote:
> 
> Hi,
> 
> > 
> > Actually, it would help to compare two usbmon traces taken on the same
> > computer, one using xhci-hcd and the other using {eou}hci-hcd.  If
> > that's not possible then two such traces from different computers would
> > be almost as good.
> 
> this laptop only has usb3.0 ports to the outside. I had to record on
> a different system and the differences are sadly more than xhci-hcd and
> *hci-hcd.
> 
> Procedure:
> 1.) use a scan app to scan one page and exit.
> 2.) use a scan app to scan one page and exit.
> 
> USB3.0 (Linux 3.6.2):
> First page works, launching the scanning fails. Traces start
> with usb3*. This is on Debian Unstable with libusb(x) (libusb-1.0-0:i386
> 2:1.0.12-2) on a 32 bit userland.
> 
> USB2.0 (Linux 3.2.):
> First and second launch work. The traces start with usb2*. This is a
> Ubuntu system and sane still uses libusb-0.1 api/lib.
> 
> 
> 
> > Did you actually scan a page while collecting the wireshark capture?  
> > There's no indication of it in the data.
> 
> in all cases a white page (none) should be scanned.
> 
> > 
> > It would be very helpful to get a copy of that oops message as well, if 
> > you can get netconsole to work.
> 
> I will try to provoke it again (last time I managed to provoke it by making
> an ioctl with USBRESET).
> 
> 
> is there anything that jumps into your eye?

Sort of.  The working and non-working traces are essentially identical
up to the point where the failure occurs.  (The only difference is on
line 8 of the traces.  The usb3_working.out file has a 00 byte where
the other three have 50.  This probably doesn't mean anything
important.)

When the scanner stops working, nothing special shows up in the trace.  
It simple fails to respond to a request.  30 seconds later the request 
is cancelled, and that's it -- nothing works from that point onward.

Here's an extract for comparison.  The working USB-3 trace (the USB-2 
traces look the same):

ee6c5140 371532052 S Co:3:023:0 s 40 04 0083 0000 0002 2 = c800
ee6c5140 371532413 C Co:3:023:0 0 2 >
ee6c5140 371532449 S Co:3:023:0 s 40 04 0082 0001 0008 8 = 00020001 00020000
ee6c5140 371532836 C Co:3:023:0 0 8 >

And the corresponding part of the non-working trace:

f492d740 409213040 S Co:3:023:0 s 40 04 0083 0000 0002 2 = c800
f492d740 409213397 C Co:3:023:0 0 2 >
f492d740 409213413 S Co:3:023:0 s 40 04 0082 0001 0008 8 = 00020001 00020000
f492d740 439213525 C Co:3:023:0 -2 0

Unfortunately there's nothing here to indicate the cause of the 
problem.  Either the scanner just stopped working (for no apparent 
reason), or the xHCI controller stopped communicating with it (for no 
apparent reason).

Did you connect the scanner to the computer with a USB-2 cable or a 
USB-3 cable?  Not that it's supposed to matter...

Maybe Sarah can give you some pointers on where to look next.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux