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 */ -- 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
