Re: xhci_hcd and Canon Lide 110 not playing well together

2014-01-08 Thread Xenia Ragiadakou

On 07/01/2014 11:46 μμ, Sarah Sharp wrote:

On Wed, Dec 25, 2013 at 09:51:28PM -0500, Alan Stern wrote:

Okay, now we know that usb_enable_interface takes a long time.  That
routine does nothing but call usb_enable_endpoint, which does nothing
but call usb_hcd_reset_endpoint, which calls the xhci_endpoint_reset
routine.

So we have traced the problem into xhci-hcd.  You could trace it
farther down if you want, but at this point it probably would be more
productive to see what Sarah has to say.  She may know about some new
changes that are not yet available in the development kernel.

I suspect the patch I asked Matthias and Holger to apply [1] has some
issues, and it's entirely possible that there's deadlocks.  One other
tester (Michal) confirms it fixes his issue with a Samsung scanner, but
the patch leads to list corruption in some xHCI structures:

https://bugzilla.kernel.org/show_bug.cgi?id=47421

In any case, all three testers (Matthias, Holger, and Michal) confirm
the patch fixes the underlying issue.  So we just need to get the
remaining race conditions and locking issues fixed up.

Xenia, would you mind if Dan or I finished your patch?  I know you don't
have much time for xHCI work since you started your new job.

Sarah Sharp

[1] http://marc.info/?l=linux-usb&m=138116117104619&w=2


Yes, sure you can finish the patch.

regards,
xenia
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2014-01-07 Thread Sarah Sharp
On Wed, Dec 25, 2013 at 09:51:28PM -0500, Alan Stern wrote:
> Okay, now we know that usb_enable_interface takes a long time.  That 
> routine does nothing but call usb_enable_endpoint, which does nothing 
> but call usb_hcd_reset_endpoint, which calls the xhci_endpoint_reset 
> routine.
> 
> So we have traced the problem into xhci-hcd.  You could trace it 
> farther down if you want, but at this point it probably would be more 
> productive to see what Sarah has to say.  She may know about some new 
> changes that are not yet available in the development kernel.

I suspect the patch I asked Matthias and Holger to apply [1] has some
issues, and it's entirely possible that there's deadlocks.  One other
tester (Michal) confirms it fixes his issue with a Samsung scanner, but
the patch leads to list corruption in some xHCI structures:

https://bugzilla.kernel.org/show_bug.cgi?id=47421

In any case, all three testers (Matthias, Holger, and Michal) confirm
the patch fixes the underlying issue.  So we just need to get the
remaining race conditions and locking issues fixed up.

Xenia, would you mind if Dan or I finished your patch?  I know you don't
have much time for xHCI work since you started your new job.

Sarah Sharp

[1] http://marc.info/?l=linux-usb&m=138116117104619&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-25 Thread Alan Stern
On Wed, 25 Dec 2013, Matthias [ISO-8859-1] Bl�sing wrote:

> The slow down can be tracked to:
> 
> usb_enable_interface(dev, intf, true);
> 
> I springled comments like this:
> 
> 
>   dev_info(&dev->dev, "T1\n");
>   /* re-init hc/hcd interface/endpoint state */
>   for (i = 0; i < config->desc.bNumInterfaces; i++) {
>   struct usb_interface *intf = config->interface[i];
>   struct usb_host_interface *alt;
>   dev_info(&dev->dev, "T2-1\n");
> 
>   alt = usb_altnum_to_altsetting(intf, 0);
>   dev_info(&dev->dev, "T2-2\n");
> 
>   /* No altsetting 0?  We'll assume the first altsetting.
>* We could use a GetInterface call, but if a device is
>* so non-compliant that it doesn't have altsetting 0
>* then I wouldn't trust its reply anyway.
>*/
>   if (!alt)
>   alt = &intf->altsetting[0];
> 
>   if (alt != intf->cur_altsetting) {
>   dev_info(&dev->dev, "T2-X1\n");
>   remove_intf_ep_devs(intf);
>   dev_info(&dev->dev, "T2-X2\n");
>   usb_remove_sysfs_intf_files(intf);
>   dev_info(&dev->dev, "T2-X3\n");
>   }
>   intf->cur_altsetting = alt;
>   dev_info(&dev->dev, "T2-3\n");
>   usb_enable_interface(dev, intf, true);
>   dev_info(&dev->dev, "T2-4\n");
>   if (device_is_registered(&intf->dev)) {
>   dev_info(&dev->dev, "T2-5\n");
>   usb_create_sysfs_intf_files(intf);
>   dev_info(&dev->dev, "T2-6\n");
>   create_intf_ep_devs(intf);
>   dev_info(&dev->dev, "T2-7\n");
>   }
>   }
>   dev_info(&dev->dev, "T3\n");
> 
> And got the attached log (minus my inline comments). As you can see it
> starts in the 5. call there it starts with a 5 second delay betewen T2-3
> and T2-4. In the next round 15s is reached and there it stays.
> 
> My tests of a second run support this and are finalized by xsane
> freezing and the final GPF.
> 
> Maybe this helps.

Okay, now we know that usb_enable_interface takes a long time.  That 
routine does nothing but call usb_enable_endpoint, which does nothing 
but call usb_hcd_reset_endpoint, which calls the xhci_endpoint_reset 
routine.

So we have traced the problem into xhci-hcd.  You could trace it 
farther down if you want, but at this point it probably would be more 
productive to see what Sarah has to say.  She may know about some new 
changes that are not yet available in the development kernel.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-25 Thread Matthias Bläsing
Hey Alan,

On Mo, 2013-12-23 at 15:38 -0500, Alan Stern wrote:
> On Mon, 23 Dec 2013, Matthias [ISO-8859-1] Blsing wrote:
> > Looking at the strace alone, I see, that the USBDEVFS_SETCONFIGURATION
> > ioctl calls take excessive time.
> > 
> 
> You're right; those calls took an excessively long time.  The usbmon 
> traces show that the communication with the device was very quick.  I 
> don't know where the rest of the time was spent.
> 
> The most likely possibility is locking the bandwidth mutex.  But that 
> wouldn't require much time either, unless something else was going on 
> at the same time.
> 
> You could try adding a few statements of the form
> 
>   dev_info(&dev->dev, "[Your message here]\n");
> 
> at various spots inside drivers/usb/core/message.c's 
> usb_reset_configuration() routine.  Maybe you'll be able to see where 
> everything slows down.  (Be sure to set CONFIG_PRINTK_TIME when you 
> build the kernel.)
> 

The slow down can be tracked to:

usb_enable_interface(dev, intf, true);

I springled comments like this:


dev_info(&dev->dev, "T1\n");
/* re-init hc/hcd interface/endpoint state */
for (i = 0; i < config->desc.bNumInterfaces; i++) {
struct usb_interface *intf = config->interface[i];
struct usb_host_interface *alt;
dev_info(&dev->dev, "T2-1\n");

alt = usb_altnum_to_altsetting(intf, 0);
dev_info(&dev->dev, "T2-2\n");

/* No altsetting 0?  We'll assume the first altsetting.
 * We could use a GetInterface call, but if a device is
 * so non-compliant that it doesn't have altsetting 0
 * then I wouldn't trust its reply anyway.
 */
if (!alt)
alt = &intf->altsetting[0];

if (alt != intf->cur_altsetting) {
dev_info(&dev->dev, "T2-X1\n");
remove_intf_ep_devs(intf);
dev_info(&dev->dev, "T2-X2\n");
usb_remove_sysfs_intf_files(intf);
dev_info(&dev->dev, "T2-X3\n");
}
intf->cur_altsetting = alt;
dev_info(&dev->dev, "T2-3\n");
usb_enable_interface(dev, intf, true);
dev_info(&dev->dev, "T2-4\n");
if (device_is_registered(&intf->dev)) {
dev_info(&dev->dev, "T2-5\n");
usb_create_sysfs_intf_files(intf);
dev_info(&dev->dev, "T2-6\n");
create_intf_ep_devs(intf);
dev_info(&dev->dev, "T2-7\n");
}
}
dev_info(&dev->dev, "T3\n");

And got the attached log (minus my inline comments). As you can see it
starts in the 5. call there it starts with a 5 second delay betewen T2-3
and T2-4. In the next round 15s is reached and there it stays.

My tests of a second run support this and are finalized by xsane
freezing and the final GPF.

Maybe this helps.

Greetings

Matthias
=> Start
Dec 25 21:16:09 athena kernel: [  104.886377] usb 3-2: T1
Dec 25 21:16:09 athena kernel: [  104.886380] usb 3-2: T2-1
Dec 25 21:16:09 athena kernel: [  104.886381] usb 3-2: T2-2
Dec 25 21:16:09 athena kernel: [  104.886382] usb 3-2: T2-3
Dec 25 21:16:09 athena kernel: [  104.886647] usb 3-2: T2-4
Dec 25 21:16:09 athena kernel: [  104.886648] usb 3-2: T2-5
Dec 25 21:16:09 athena kernel: [  104.886649] usb 3-2: T2-6
Dec 25 21:16:09 athena kernel: [  104.886650] usb 3-2: T2-7
Dec 25 21:16:09 athena kernel: [  104.886651] usb 3-2: T3
Dec 25 21:16:15 athena kernel: [  111.329474] usb 3-2: T1
Dec 25 21:16:15 athena kernel: [  111.329478] usb 3-2: T2-1
Dec 25 21:16:15 athena kernel: [  111.329479] usb 3-2: T2-2
Dec 25 21:16:15 athena kernel: [  111.329481] usb 3-2: T2-3
Dec 25 21:16:15 athena kernel: [  111.329756] usb 3-2: T2-4
Dec 25 21:16:15 athena kernel: [  111.329758] usb 3-2: T2-5
Dec 25 21:16:15 athena kernel: [  111.329760] usb 3-2: T2-6
Dec 25 21:16:15 athena kernel: [  111.329762] usb 3-2: T2-7
Dec 25 21:16:15 athena kernel: [  111.329763] usb 3-2: T3
Dec 25 21:16:15 athena kernel: [  111.390151] usb 3-2: T1
Dec 25 21:16:15 athena kernel: [  111.390154] usb 3-2: T2-1
Dec 25 21:16:15 athena kernel: [  111.390155] usb 3-2: T2-2
Dec 25 21:16:15 athena kernel: [  111.390156] usb 3-2: T2-3
Dec 25 21:16:15 athena kernel: [  111.390428] usb 3-2: T2-4
Dec 25 21:16:15 athena kernel: [  111.390429] usb 3-2: T2-5
Dec 25 21:16:15 athena kernel: [  111.390430] usb 3-2: T2-6
Dec 25 21:16:15 athena kernel: [  111.390431] usb 3-2: T2-7
Dec 25 21:16:15 athena kernel: [  111.390432] usb 3-2: T3
Dec 25 21:16:15 athena kernel: [  111.470847] usb 3-2: T1
Dec 25 21:16:15 athena kernel: [  111.470850] usb 3-2: T2-1
Dec 25 21:16:15 athena kernel: [  111.470851] usb 3-2: T2-2
Dec 25 21:16:15 athena kernel: [  111.470852] usb 3-2: T2-3
Dec 25 21:16:15 athe

Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-23 Thread Alan Stern
On Mon, 23 Dec 2013, Matthias [ISO-8859-1] Bl�sing wrote:

> I went ahead and did some runs (once I was able to reproduce the general
> protection fault). The ehci port worked pretty fast (4 seconds from
> start to GUI display), the xhci port took 7s in the best case to more
> than one minute in the worst case.
> 
> The straces were taken with the "-T" Option.
> 
> Attached to this mail you find the gzipped log of one ehci run.
> 
> For the xhci case I attach the usbmon trace of 3 consecutive starts,
> where the strace is the result of the last start. This is the case that
> took more than one minute, which I stopped.
> 
> Looking at the strace alone, I see, that the USBDEVFS_SETCONFIGURATION
> ioctl calls take excessive time.
> 
> The version I used to test was 3.13-rc5 with both patches applied.
> 
> Maybe this can shed some light onto the problem.

You're right; those calls took an excessively long time.  The usbmon 
traces show that the communication with the device was very quick.  I 
don't know where the rest of the time was spent.

The most likely possibility is locking the bandwidth mutex.  But that 
wouldn't require much time either, unless something else was going on 
at the same time.

You could try adding a few statements of the form

dev_info(&dev->dev, "[Your message here]\n");

at various spots inside drivers/usb/core/message.c's 
usb_reset_configuration() routine.  Maybe you'll be able to see where 
everything slows down.  (Be sure to set CONFIG_PRINTK_TIME when you 
build the kernel.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-22 Thread Alan Stern
On Sun, 22 Dec 2013, Matthias [ISO-8859-1] Bl�sing wrote:

> To give some reference: This is Kernel 3.13.0-rc4 with both patches
> applied.
> 
> I now see also a device, that at least works partly now (I can scan with
> scanimage and simple-scan, but xsane fails). I think xsane does some
> more complex interaction with the device (this is a hunch!) and in
> consequence fails. Before I hit the fatal problem, I see xsane reacting
> sluggish - the gui is blocked for interaction. I didn't see the same
> with the EHCI bus.

Perhaps it would help to compare usbmon traces for an xHCI port and an 
EHCI port.  In theory, they should be very similar.  Any differences 
could point to a problem.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-21 Thread Holger Hans Peter Freyther
On Fri, Dec 20, 2013 at 03:41:36PM -0800, Sarah Sharp wrote:

> The first one fixes an issue where userspace tries to reset a USB
> endpoint when it's not actually halted:
> 
> http://marc.info/?l=linux-usb&m=138116117104619&w=2



> Try applying them to the latest kernel and see if they fix your issue.
> I suspect the first one might.  If it doesn't, remove that patch and try

Yes it does. When (re-)starting the scan application the second time
the code hits xhci_endpoint_reset

  if (!virt_ep->stopped_td) {
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
"reset not halted endpoint 0x%x",
ep->desc.bEndpointAddress);
ret = xhci_reset_not_halted_ep(xhci, udev, ep);
...


[15877.581997] xhci_hcd :00:14.0: reset not halted endpoint 0x81


holger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-20 Thread Sarah Sharp
On Wed, Dec 18, 2013 at 09:59:33PM +0100, Matthias Bläsing wrote:
> Hey all,
> 
> On Fr, 2013-12-13 at 17:53 +0100, Holger Hans Peter Freyther wrote:
> > On Tue, May 28, 2013 at 07:40:57PM +0200, Holger Hans Peter Freyther wrote:
> 
> > > Is there a timeline when you think this could be fixed?
> > 
> > 
> > I tried with 3.10.x and 3.12.5 and the symptoms remain the same. The first
> > time it is working, the second time the scanning does not start. The scanner
> > is still working fine on other machines (with the identical cable).
> > 
> 
> as I'm facing a similar problem (Canon Lide, though 25 instead of 110),
> I would also like to know if there are news about this. See
> 
> 
> http://thread.gmane.org/gmane.linux.usb.general/99815
> 
> for details about the hardware. If something is missing I'll try to
> provide it. Its strange, that the same hardware (notebook and scanner)
> works on one port, but not on the other).
> 
> I tried again today and all physical ports I can access are either
> connected to Bus 03 (I suspect, that Bus 04 and Bus 03 are the same,
> only differing in their speed) or Bus 02.
> 
> Bus 02 (Driver=ehci-pci/2p, 480M) works, Bus 03 (Driver=xhci_hcd/4p,
> 480M) fails.
> 
> Any ideas?

I still don't know exactly what's wrong with those particular scanners.
usbmon bus traces haven't helped me figure out what's wrong.

There are two potential outstanding issues that may (or may not) be the
problem.  Patches to fix those issues have been sent out, but the
original submitters haven't followed up on either sending a second
revision, or responding with whether a modified patch helped.

The first one fixes an issue where userspace tries to reset a USB
endpoint when it's not actually halted:

http://marc.info/?l=linux-usb&m=138116117104619&w=2

The second one fixes an issue with the xHCI driver not reporting a
zero-length control transfer properly:

http://marc.info/?l=linux-usb&m=138247042431789&w=2

Try applying them to the latest kernel and see if they fix your issue.
I suspect the first one might.  If it doesn't, remove that patch and try
the second one.

If neither one work, I'm not sure what else to try.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-18 Thread Matthias Bläsing
Hey all,

On Fr, 2013-12-13 at 17:53 +0100, Holger Hans Peter Freyther wrote:
> On Tue, May 28, 2013 at 07:40:57PM +0200, Holger Hans Peter Freyther wrote:

> > Is there a timeline when you think this could be fixed?
> 
> 
> I tried with 3.10.x and 3.12.5 and the symptoms remain the same. The first
> time it is working, the second time the scanning does not start. The scanner
> is still working fine on other machines (with the identical cable).
> 

as I'm facing a similar problem (Canon Lide, though 25 instead of 110),
I would also like to know if there are news about this. See


http://thread.gmane.org/gmane.linux.usb.general/99815

for details about the hardware. If something is missing I'll try to
provide it. Its strange, that the same hardware (notebook and scanner)
works on one port, but not on the other).

I tried again today and all physical ports I can access are either
connected to Bus 03 (I suspect, that Bus 04 and Bus 03 are the same,
only differing in their speed) or Bus 02.

Bus 02 (Driver=ehci-pci/2p, 480M) works, Bus 03 (Driver=xhci_hcd/4p,
480M) fails.

Any ideas?

Greetings

Matthias

PS: I removed my subscription of linux-usb as I got flooded with mails,
please keep me CCed.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-12-13 Thread Holger Hans Peter Freyther
On Tue, May 28, 2013 at 07:40:57PM +0200, Holger Hans Peter Freyther wrote:

Good Evening,


> Is there a timeline when you think this could be fixed?


I tried with 3.10.x and 3.12.5 and the symptoms remain the same. The first
time it is working, the second time the scanning does not start. The scanner
is still working fine on other machines (with the identical cable).

any ideas?

holger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2013-05-28 Thread Holger Hans Peter Freyther
On Mon, Oct 22, 2012 at 10:01:04AM -0700, Sarah Sharp wrote:

Good Evening,

> > Maybe Sarah can give you some pointers on where to look next.
> 
> I've asked for a physical bus trace from one of our QA folks with the
> same scanner.  I think that will shed some light on whether this is a
> host-side bug or a software bug.  I do know that a certain set of
> scanners don't work under Ivy Bridge/Panther Point xHCI hosts, I just
> haven't had time to look at the bus trace to figure out why.

Debian/Sid has a 3.8 kernel now and I wanted to check if the scanner
can be used for my daily scanning routines. In terms of symptoms it
is still the same (the first page can be scanned, on the next scan
it just doesn't work).

Is there a timeline when you think this could be fixed?

holger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-22 Thread Sarah Sharp
On Mon, Oct 22, 2012 at 09:15:09PM +0200, Holger Hans Peter Freyther wrote:
> On Mon, Oct 22, 2012 at 10:01:04AM -0700, Sarah Sharp wrote:
> 
> Dear Sarah,
> 
> > > Maybe Sarah can give you some pointers on where to look next.
> > 
> > I've asked for a physical bus trace from one of our QA folks with the
> > same scanner.  I think that will shed some light on whether this is a
> > host-side bug or a software bug.  I do know that a certain set of
> > scanners don't work under Ivy Bridge/Panther Point xHCI hosts, I just
> > haven't had time to look at the bus trace to figure out why.
> 
> is there anything I can help with at this point in time? How high/low
> is this issue in your queue and do you know scanners that definately
> work with xHCI hosts?

I believe the scanners work under NEC/Rensas xHCI hosts, but not Intel
hosts.  So it is is an Intel specific issue.  I'll let you know if
there's anything you can do to help me.

I currently have 19 bugs in our tracking system (2 priority 1, 2 P2, 4
P3, and 10 P4 bugs).  Plus 4 todo items that may or may not be related
to said bugs.  The biggest challenge right now is the LPM code, which
causes I/O errors on USB hard drives that don't support it, and some
issues with suspend and hibernate.  Those are priority 1 bugs.

Your scanner issue is filed as a low priority (priority 4) bug because
there is a work-around.  For our scanner, if you unplug the device
between scanning pages, it works.  Does that work for you as well?

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-22 Thread Holger Hans Peter Freyther
On Mon, Oct 22, 2012 at 10:01:04AM -0700, Sarah Sharp wrote:

Dear Sarah,

> > Maybe Sarah can give you some pointers on where to look next.
> 
> I've asked for a physical bus trace from one of our QA folks with the
> same scanner.  I think that will shed some light on whether this is a
> host-side bug or a software bug.  I do know that a certain set of
> scanners don't work under Ivy Bridge/Panther Point xHCI hosts, I just
> haven't had time to look at the bus trace to figure out why.

is there anything I can help with at this point in time? How high/low
is this issue in your queue and do you know scanners that definately
work with xHCI hosts?

thanks
holger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-22 Thread Holger Hans Peter Freyther
On Mon, Oct 22, 2012 at 11:52:16AM -0400, Alan Stern wrote:
> On Sun, 21 Oct 2012, Holger Hans Peter Freyther wrote:

Dear Alan,

thanks for having a look.

> 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...

I used the same cable for all four traces and it is a USB-2 cable.


holger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-22 Thread Sarah Sharp
On Mon, Oct 22, 2012 at 11:52:16AM -0400, Alan Stern wrote:
> On Sun, 21 Oct 2012, Holger Hans Peter Freyther wrote:
> > On Mon, Oct 15, 2012 at 04:21:47PM -0400, Alan Stern wrote:
> 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...

Yeah, that shouldn't matter.

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

I've asked for a physical bus trace from one of our QA folks with the
same scanner.  I think that will shed some light on whether this is a
host-side bug or a software bug.  I do know that a certain set of
scanners don't work under Ivy Bridge/Panther Point xHCI hosts, I just
haven't had time to look at the bus trace to figure out why.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-22 Thread Alan Stern
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  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 0002
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  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 0002
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-15 Thread Alan Stern
On Mon, 15 Oct 2012, Holger Freyther wrote:

> Holger Freyther  writes:
> 
> 
> > 
> > Debian unstable switched to libusbx but kept the package name at
> > libusb. I have tested this with version 1.0.12.Okay, I see that there
> > has been some usb 3.0 changes in 1.0.13 and 1.0.14 and I am going to
> > test again.
> 
> I have tested with 38e6eb86b2 (two commits after v1.0.14), verified
> that my version of libusb is picked (cat /proc/PID/maps | grep usb)
> and the symptoms are the same (first scan works, second one doesn't).
> 
> I re-tested the scanner and it does not appear to be defective (I
> can scan several pages using a different computer/os).
> 
> any ideas?

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.

I generally find usbmon output a lot easier to work with than wireshark
capture files.  It's much more condensed and doesn't require any
mousing around.  See Documentation/usb/usbmon.txt.

Did you actually scan a page while collecting the wireshark capture?  
There's no indication of it in the data.

> it works perfectly with my old notebook and in OSX. The most notable
> change is that I now have USB 3.0 and that xhci_hcd doesn't appear to
> be too stable and is easy to blame. Unplug/Wait/Plug allows me to scan
> another page. Sometimes this leads to an oops in xhcd-hci (but the oops
> scrolls out of the console too fast and the system hardlocks and I don't
> have netconsole running).

It would be very helpful to get a copy of that oops message as well, if 
you can get netconsole to work.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-15 Thread Holger Freyther
Holger Freyther  writes:


> 
> Debian unstable switched to libusbx but kept the package name at
> libusb. I have tested this with version 1.0.12.Okay, I see that there
> has been some usb 3.0 changes in 1.0.13 and 1.0.14 and I am going to
> test again.

I have tested with 38e6eb86b2 (two commits after v1.0.14), verified
that my version of libusb is picked (cat /proc/PID/maps | grep usb)
and the symptoms are the same (first scan works, second one doesn't).

I re-tested the scanner and it does not appear to be defective (I
can scan several pages using a different computer/os).

any ideas?



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-15 Thread Holger Freyther
Alan Stern  writes:


> 
> What is the bugzilla report number?

it is #48801.


> It's notable that the pcap file does not show any data being sent from 
> the scanner to the computer, only from the computer to the scanner.

Did I use usbmom/wireshark incorrectly?

 

> The necessary support isn't present in libusb-1.0.0.  I don't remember 
> in which version it was added, but you should try running the lastest 
> version.  (In fact, maybe the support wasn't added to libusb at all, 
> but only to libusbx.)

Debian unstable switched to libusbx but kept the package name at
libusb. I have tested this with version 1.0.12.Okay, I see that there
has been some usb 3.0 changes in 1.0.13 and 1.0.14 and I am going to
test again.


> What makes you think this is related to xhci-hcd in any way?  Maybe the 
> scanner just isn't working -- you said so yourself in the first 
> sentence.

it works perfectly with my old notebook and in OSX. The most notable
change is that I now have USB 3.0 and that xhci_hcd doesn't appear to
be too stable and is easy to blame. Unplug/Wait/Plug allows me to scan
another page. Sometimes this leads to an oops in xhcd-hci (but the oops
scrolls out of the console too fast and the system hardlocks and I don't
have netconsole running).



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: xhci_hcd and Canon Lide 110 not playing well together

2012-10-15 Thread Alan Stern
On Mon, 15 Oct 2012, Holger Freyther wrote:

> Hi,
> 
> I have some severe issues with USB on a new system. This is
> an Acer Aspire S5 (i7, Ivybridge) and the scanner can be mostly
> classified as non working.
> 
> Symptoms:
> 1.) Start a scan application (e.g. simple-scan)
> 2.) Scan a page
> 3.) Exit the app
> 4.) Start a scan application (e.g. simple-scan)
> 5.) Scan a page..
> 
> In step five the scanning will not start. There is no kernel
> output. I have tried putting a USB 2.0 hub between the physical
> port and the scanner but the symptoms remain the same. The issue
> occurs on 3.2, 3.5 and 3.6.x. I initially created a bug report on
> the kernel bugzilla and will link to the uploads I made there.

What is the bugzilla report number?

> lsusb without the scanner attached [1]
> lsusb with the scanner attached[2]
> pcap file of usbmon when it does not work[3]

It's notable that the pcap file does not show any data being sent from 
the scanner to the computer, only from the computer to the scanner.

> I am using Debian unstable and by default sane-backends is built
> with libusb-0.1 support, I rebuilt it to use libusb-1.0.0. I have

The necessary support isn't present in libusb-1.0.0.  I don't remember 
in which version it was added, but you should try running the lastest 
version.  (In fact, maybe the support wasn't added to libusb at all, 
but only to libusbx.)

> seen an old mail from Sarah about xhci/libusb and I added the
> following to my cmdline (usbcore.usbfs_memory_mb=1000) but it didn't
> change anything. I am using 3.6.2 right now and have enabled the
> xhcd debug option and can provide more output.

What makes you think this is related to xhci-hcd in any way?  Maybe the 
scanner just isn't working -- you said so yourself in the first 
sentence.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


xhci_hcd and Canon Lide 110 not playing well together

2012-10-15 Thread Holger Freyther
Hi,

I have some severe issues with USB on a new system. This is
an Acer Aspire S5 (i7, Ivybridge) and the scanner can be mostly
classified as non working.

Symptoms:
1.) Start a scan application (e.g. simple-scan)
2.) Scan a page
3.) Exit the app
4.) Start a scan application (e.g. simple-scan)
5.) Scan a page..

In step five the scanning will not start. There is no kernel
output. I have tried putting a USB 2.0 hub between the physical
port and the scanner but the symptoms remain the same. The issue
occurs on 3.2, 3.5 and 3.6.x. I initially created a bug report on
the kernel bugzilla and will link to the uploads I made there.


lsusb without the scanner attached [1]
lsusb with the scanner attached[2]
pcap file of usbmon when it does not work[3]


I am using Debian unstable and by default sane-backends is built
with libusb-0.1 support, I rebuilt it to use libusb-1.0.0. I have
seen an old mail from Sarah about xhci/libusb and I added the
following to my cmdline (usbcore.usbfs_memory_mb=1000) but it didn't
change anything. I am using 3.6.2 right now and have enabled the
xhcd debug option and can provide more output.


I have a trace of a successful scan but it was too big to be
uploaded. I have recompiled 3.6.2 

kind regards
  holger


[1] https://bugzilla.kernel.org/attachment.cgi?id=83461
[2] https://bugzilla.kernel.org/attachment.cgi?id=83471
[3] https://bugzilla.kernel.org/attachment.cgi?id=83481




--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html