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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
