Hi Mathias, I've done additional debugging and found a few things that might be noteworthy. When I originally reported the issue, I noted that it was some sort of recovery problem related to failed control messages. So while you've been focused on why stopping the endpoint failed when it came time to kill the URB, I started looking at why the control message failed in the first place. This prompted me to hook up the USB analyzer in order to see the exact USB control message it failed on. The interesting thing is that control message which never succeeded never actually made it onto the bus. While I was expecting to see the setup message followed by either a missing in or out packet, or some other error such as a stall condition, I don't actually ever see the the setup message appear on the bus. The reason I'm bringing this up is because perhaps the reason the IRQ for the stop endpoint completion handler is failing to fire is because the TRB never actually got queued in the first place (hence we're trying to unlink TRBs that don't exist). It also suggests this isn't a case where the USB device isn't properly responding to the control message, since it never gets received in the first place. I do see the URB gets all the way to xhci_queue_ctrl_tx(), however I don't fully understand yet the internals of that function so cannot speculate on how much further it gets. One other thing worth mentioning: just as a hack I jammed a udelay(1000) right before xhci_queue_ctrl_tx() (outside the spin_lock_irqsave), thinking that this might be some sort of issue with bursts of control messages being queued too fast. However the problem still occurs even in that case. I'm not sure if any of the above offers any clue as to what's going on. Devin On Thu, Jan 22, 2015 at 6:32 AM, Alistair Grant <akgrant0710@xxxxxxxxx> wrote: > Hi Matthias, > > On Thu, Jan 22, 2015 at 12:22 PM, Mathias Nyman > <mathias.nyman@xxxxxxxxxxxxxxx> wrote: >> On 21.01.2015 21:16, Alistair Grant wrote: >>> Hi Matthias, >>> >>> On Tue, Jan 20, 2015 at 10:22 AM, Mathias Nyman >>> <mathias.nyman@xxxxxxxxxxxxxxx> wrote: >>>> On 19.01.2015 22:02, Devin Heitmueller wrote: >>>>> Hi Mathias, >>>>> >>>>> Thanks for getting back to me. >>>>> >>>>>> There are a couple of xhci bugs triggered by dvb devices: >>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=75521 >>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=65021 >>>>>> >>>>>> The first one (75521) I believe is mostly fixed by patches in 3.18 and early >>>>>> 3.19-rc, so work on a 3.19-rc kernel to eliminate those issues. >>>>> ... >>>>>> The second bug (65021) looks more like your case, it queues two stop_endpoints >>>>>> commands almost simultaneously, which end up never completing, ->timeout and tear down xhci. >>>>>> That bug has a debug patch for command ring status, you could try it out to check if >>>>>> the command queue is running among other details. >>>>> >>>>> The second bug definitely looks like what I'm seeing. I'll try your >>>>> tree and report back my findings. >>>> >>>> Ah, let me rebase that tree on top of a more current kernel first. >>> >>> I've been following this as it somewhat resembles the problems I'm >>> experiencing, which I've just formally reported in "Hauppauge >>> USB-Live2 recording fails on USB3 port". >>> >>> It looks like you did the rebase yesterday, so I tried running your >>> updated kernel. It didn't solve the problems, but was an incremental >>> improvement since the mainline 3.19rc5 kernel hangs during shutdown, >>> while your modified kernel shutdown cleanly. >>> >>> I've got a syslog with verbose xhci logging (echo -n 'module xhci_hcd >>> =p' > /sys/kernel/debug/dynamic_debug/control as you suggested above) >>> if you would like to take a look. It's 2.4M so please let me know how >>> you would like me to pass it on. >> >> I'm Interested yes, anyway is fine. Add it somewhere (bugreport, webpage) and send me the link, >> or just sending it as an email attachent to me works fine as well. > > You should be able to download it from: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1412121/+attachment/4303563/+files/syslog-14.10-3.19rc5mathias0.2-2.log > > Please let me know if you have any trouble accessing it, or would like > more testing, information, etc. > > Thanks, > Alistair > -- > 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 -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
