Re: usb: host: xhci: stalled endpoint ring not cleared on empty td_list
On 04/11/2017 04:13 PM, Rolf Evers-Fischer wrote: Hi, Christian Gromm <christian.gr...@microchip.com> writes: we observe an issue with a td_list running empty and an endpoint being stalled at the same time on Linux ihu-low 4.1.27-abl #1 SMP PREEMPT Mon Mar 20 13:51:51 CET 2017 x86_64 x86_64 x86_64 GNU/Linux. we've recently observed the same problem with "Linux ihu-low 4.1.27-abl" kernel. In our case it was discovered from the logs that URBs, that are being killed by “usb_kill_anchored_urbs()”, are still being used by “handle_tx_event()”. Sooner or later the same URB was used and killed at the same time, which caused the “WARN Event TRB for slot 2 ep 28 with no TDs queued?” error message, and the whole communication stopped. Well, this sounds like a workaround to me as you are changing the timing by waiting for the URBs to finish. This might prevent the race from happening. I thought an USB device driver is allowed to kill anchored URBs at any time, isn't it? thanks, Chris The developer, who introduced the USB anchors, has added some demo code in the file drivers/usb/usb-skeleton.c. In this file he is invoking “usb_wait_anchor_empty_timeout()” before he calls “usb_kill_anchored_urbs()”. If I understand it correctly, the purpose of this function is to wait until all URBs have been processed. Therefore I suggested to do the same in the most driver. Fortunately it seems that this resolved our problem: We've never seen this problem anymore. BR Rolf -- 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
Re: usb: host: xhci: stalled endpoint ring not cleared on empty td_list
On 03/27/2017 11:31 AM, Felipe Balbi wrote: Hi, Christian Gromm <christian.gr...@microchip.com> writes: we observe an issue with a td_list running empty and an endpoint being stalled at the same time on Linux ihu-low 4.1.27-abl #1 SMP PREEMPT Mon Mar 20 13:51:51 CET 2017 x86_64 x86_64 x86_64 GNU/Linux. this is one old kernel. Please upgrade to v4.11-rc4 or v4.10 and try again. Unfortunately, the system is Yocto based and cannot be updated to 4.10+. We applied the following patches to have the xhci code at 4.1.39 $ git log --oneline v4.1.27..v4.1.39 -- drivers/usb/host/xhci-* c068da4 xhci: fix deadlock at host remove by running watchdog correctly 8e77b80 usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Apollo Lake 18ee106 usb: xhci: hold lock over xhci_abort_cmd_ring() af7f5bf xhci: Handle command completion and timeout race adae871 usb: host: xhci: Fix possible wild pointer when handling abort command 073dd4e usb: xhci: fix possible wild pointer 4b6ac34 xhci: free xhci virtual devices with leaf nodes first 605a696 xhci: workaround for hosts missing CAS bit c23a6dc xhci: add restart quirk for Intel Wildcatpoint PCH 3b244a6 xhci: fix usb2 resume timing and races. 631f063 xhci: fix null pointer dereference in stop command timeout function e1052fb usb: xhci: Fix panic if disconnect 23c50b2 xhci: always handle "Command Ring Stopped" events 95cb83b USB: xhci: Add broken streams quirk for Frescologic device id 1009 0c3f25d usb: xhci-plat: properly handle probe deferral for devm_clk_get() e78c8a5 xhci: Fix handling timeouted commands on hosts in weird states. The issue is still there. Any other recommendation? Thanks, Chris -- 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
usb: host: xhci: stalled endpoint ring not cleared on empty td_list
Hi, we observe an issue with a td_list running empty and an endpoint being stalled at the same time on Linux ihu-low 4.1.27-abl #1 SMP PREEMPT Mon Mar 20 13:51:51 CET 2017 x86_64 x86_64 x86_64 GNU/Linux. According to the logs, the halt condition of the endpoint is detected on host side, but not cleared. Instead the "WARN Event TRB..." message is displayed. After that, newly submitted URBs are queued, but the host controller does not issue any IN transactions on USB anymore. [ 103.353450] ihu-low kernel: xhci_hcd :00:15.0: Stalled endpoint [ 103.353453] ihu-low kernel: xhci_hcd :00:15.0: WARN Event TRB for slot 2 ep 28 with no TDs queued? [ 103.353456] ihu-low kernel: xhci_hcd :00:15.0: Event TRB with TRB type ID 32 [ 103.353459] ihu-low kernel: xhci_hcd :00:15.0: Offset 0x0 = 0x74930f30 [ 103.353462] ihu-low kernel: xhci_hcd :00:15.0: Offset 0x4 = 0x0 [ 103.353464] ihu-low kernel: xhci_hcd :00:15.0: Offset 0x8 = 0x60005f2 [ 103.353467] ihu-low kernel: xhci_hcd :00:15.0: Offset 0xc = 0x21d8001 [ 103.353666] ihu-low kernel: xhci_hcd :00:15.0: WARN halted endpoint, queueing URB anyway. The code shows that the function handle_tx_event() of xhci-ring.c detects the empty transfer descriptor list, throws the warning and skips the call to process_bulk_intr_td(), which would do the clean-up work. In case the td_list is not running empty, the stalled endpoint ring is perfectly cleaned up and communication on USB resumed. [ 20.310469] ihu-low kernel: xhci_hcd :00:15.0: Stalled endpoint [ 20.310473] ihu-low kernel: xhci_hcd :00:15.0: Cleaning up stalled endpoint ring [ 20.310476] ihu-low kernel: xhci_hcd :00:15.0: Finding endpoint context [ 20.310478] ihu-low kernel: xhci_hcd :00:15.0: Cycle state = 0x0 [ 20.310481] ihu-low kernel: xhci_hcd :00:15.0: New dequeue segment = 8800777ae000 (virtual) [ 20.310484] ihu-low kernel: xhci_hcd :00:15.0: New dequeue pointer = 0x765176e0 (DMA) [ 20.310486] ihu-low kernel: xhci_hcd :00:15.0: Queueing new dequeue state [ 20.310490] ihu-low kernel: xhci_hcd :00:15.0: Set TR Deq Ptr cmd, new deq seg = 8800777ae000 (0x76517000 dma), new deq ptr = 8800765176e0 (0x765176e0 dma), new cycle = 0 [ 20.310492] ihu-low kernel: xhci_hcd :00:15.0: // Ding dong! [ 20.310498] ihu-low kernel: xhci_hcd :00:15.0: Giveback URB 88005c312f00, len = 0, expected = 1522, status = -32 [ 20.310502] ihu-low kernel: xhci_hcd :00:15.0: Ignoring reset ep completion code of 1 [ 20.310505] ihu-low kernel: xhci_hcd :00:15.0: Successful Set TR Deq Ptr cmd, deq = @765176e0 [ 21.918842] ihu-low kernel: xhci_hcd :00:15.0: ep 0x8e - asked for 1522 bytes, 1472 bytes untransferred [ 22.918972] ihu-low kernel: xhci_hcd :00:15.0: ep 0x8e - asked for 1522 bytes, 1456 bytes untransferred thanks, Chris -- 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
