On 23.04.2015 17:38, Rodrigo Severo wrote: > On Mon, Apr 13, 2015 at 10:15 AM, Mathias Nyman > <mathias.nyman@xxxxxxxxxxxxxxx> wrote: >> Hi >> >> On 08.04.2015 20:45, Rodrigo Severo wrote: >>> >>> At that time I even tested enabling XHCI_TRUST_TX_LENGTH quirk for the >>> ASM1042A USB 3.0 Host Controller which eliminated the warnings on my >>> logs but didn't solve the hang issues. >> >> Can you add xhci debugging and post the output before the hang. >> >> Enable xhci debugging with: >> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > > I"m not sure my first message with the log uncompressed. Now I'm > sending it with the log compressed. > > I hope this is better. Hi Last patchseries I sent includes fixes for similar issues. The "ERROR Transfer event TRB DMA ptr not part of current TD" where we try to find a one old TRB should be fixed by: http://marc.info/?l=linux-usb&m=143040326306659&w=2 In your example case it was the TRB at 0x..9250 which we start searching for from 0x..9260 to, well, the same 0x..9260 Another issue is that the event ring likely also full as the transfer ring size is increassed from x2 -> x8, but event ring stays the same. This would explain the "Missed service interval errors". For isoc transfers we don't interrupt and handle event from the event ring until the last TD of the URB is ready on AS Media hosts, so we could have up to 32 TDs on the event ring before we get the first interrupt. The default event ring size is incresed in patch: http://marc.info/?l=linux-usb&m=143040325106650&w=2 If that still doesn't do it, you could try to add the BEI quirk for ASMedia hosts as well, currectly it is set for Intel hosts, but might be that others need. It will cause the host to interrupt on every finished TD instead of just the last one. xhci->quirks |= XHCI_AVOID_BEI The patches are not yet in Greg's tree, so you either have to wait a while or apply them yourself. -Mathias -- 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