On Mon, 15 Sep 2014, Mathias Nyman wrote:
On 09/14/2014 01:52 AM, Mike Mammarella wrote:
On Sat, 26 Jul 2014, Mike Mammarella wrote:
On Fri, 4 Jul 2014, Mathias Nyman wrote:
On 07/01/2014 09:07 AM, Mike Mammarella wrote:
Hi
Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and run
`echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control`
as root,
and send me the output of dmesg.
Without debugging info it's hard to guess what's going on.
The microframe rounding look a bit suspicious:
[12864.453456] usb 3-4: ep 0x81 - rounding interval to 128 microframes, ep desc
says 255 microframes
xhci specs says it needs the interval rounded to nearest 2^(X) value, which
would be 256, not 128. I'll take a look at that.
An other possibility is that it's related to how xhci handles halted endpoints.
I got some untested code to fix this, It needs a lot of cleanup but can be
tested.
If you are able to test my ep_reset_halt_test branch (with xhci debugging) I'd
be interested to know if it helps.
Code is at:
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test
-Mathias
Thanks! I've built a kernel from fb58633e with CONFIG_DYNAMIC_DEBUG enabled.
(I also had to mount debugfs, it turns out.) The scanner does not work in
this configuration. I've posted the logs here:
http://spark.crystalorb.net/mikem/dmesg.log
http://spark.crystalorb.net/mikem/scanadf.log
dmesg seems to have much more information than what showed up on the
console (which showed only MATTU messages); it may be relevant when
sifting through that output that the root file system is also on USB.
Thanks,
Took a quick look, but can't find any obvious reason why it fails.
I'll be out of office next week, but I'll try to take a better look again when
I return
usbmon traces of this could give some hint on what is happening
-Mathias
Sorry for the delay getting back to you - I've captured traces with EHCI
(works) and XHCI (fails). In both cases the scanner is device 10 on bus 1. The
kernel is the Debian 3.14.12 kernel (so, in particular, not your
ep_reset_halt_test branch), in case that's important for these traces.
http://spark.crystalorb.net/mikem/usbmon-success.log
http://spark.crystalorb.net/mikem/usbmon-failure.log
I appreciate your help looking into this!
Mike
Hi, just curious if these traces were useful? Is there any other information I
could collect that would help?
Thanks!
Mike
I haven't had time to dig into the usbmon traces, but I just got another report
from Gunter K?ningsmann about similar scanner problem, and I just noticed
that in both cases we round the interval for high speed bulk _IN_ endpoint,
which should not have interval set at all.
The interval value should be ignored by host, but maybe setting it still could
cause some issues.
I don't have high hopes for this patch, but it's worth a shot.
Can you try this out and see if it makes any difference?
-Mathias
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8936211..7f21b77 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1291,7 +1291,8 @@ static unsigned int xhci_get_endpoint_interval(struct
usb_device *udev,
/* Max NAK rate */
if (usb_endpoint_xfer_control(&ep->desc) ||
usb_endpoint_xfer_bulk(&ep->desc)) {
- interval = xhci_parse_microframe_interval(udev, ep);
+ if (!usb_endpoint_dir_in(&ep->desc))
+ interval = xhci_parse_microframe_interval(udev,
ep);
break;
}
/* Fall through - SS and HS isoc/int have same decoding */
As Gunter noted, that doesn't seem to have any effect. For kicks I also
tried the change below (I suppose it's probably not correct to fall
though in this case, though), but it also didn't make any difference:
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90..a88a23a 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1291,8 +1291,10 @@ static unsigned int xhci_get_endpoint_interval(struct
usb_device *udev,
/* Max NAK rate */
if (usb_endpoint_xfer_control(&ep->desc) ||
usb_endpoint_xfer_bulk(&ep->desc)) {
- interval = xhci_parse_microframe_interval(udev, ep);
- break;
+ if (!usb_endpoint_dir_in(&ep->desc)) {
+ interval = xhci_parse_microframe_interval(udev,
ep);
+ break;
+ }
}
/* Fall through - SS and HS isoc/int have same decoding */
I was doing this on your ep_reset_halt_test branch, which has a lot of
MATTU messages scrolling by, but I'm pretty sure that the microframe
rounding message was not present when running with either of these
changes. So that may be a red herring after all...
Mike
--
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
