Re: Aw: Re: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects
On Tue, 6 Oct 2015, Eugen Rogoza wrote: > > The only way to turn off Link Power Management currently is to disable > > CONFIG_PM entirely. > > I recompiled the 4.2.0 having disabled CONFIG_PM: > > # CONFIG_PM is not set > > This time there were no observable disconnects after just plugging in > the device and not doing anything else (like mounting). However, a > disconnect happened much later while browsing the directory structure > on a mounted FS of the HDD. Surprisingly, the disconnects do not > strictly correlate with the load: some heavy copying and seeking back > and forth in a HD movie worked just fine. Therefore I think the > disconnect would have happened on an idle connection as well. Okay, so Link Power Management isn't the answer. > Below is a fresh trace. The reason for the disconnect is > URB_INTERRUPT again (triggered in packet #2473): You've got it backward. The disconnect isn't _caused_ by the interrupt URB; rather, the interrupt URB _reports_ the disconnect to the kernel. In other words, the disconnect occurs first and then the interrupt URB completes. Alan Stern -- 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
Aw: Re: Re: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects
> You've got it backward. The disconnect isn't _caused_ by the interrupt > URB; rather, the interrupt URB _reports_ the disconnect to the kernel. > In other words, the disconnect occurs first and then the interrupt URB > completes. Then I guess the traces aren't the right way to investigate the issue, because they report on the effects and not on the cause. What can constitute a disconnect if there is no signalling from the device? Device/hub power-cycles the link? What other troubleshooting options do I have? Is there more debugging output that I can enable? Will it help to raise a formal bug? Or did I do it already? :) Thanks Eugen -- 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: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects
On Mon, 5 Oct 2015, Eugen Rogoza wrote: > Hello, > > in xHCI mode I'm experiencing random disconnects and reconnects of my ASMedia > ASM1051-based external HDD enclosure. > > The only combination where the disconnects are happening is Intel USB Host > Controller + Linux kernel + XHCI mode (see further observations below). > > I did some tracing with libpcap (can be opened in Wireshark). I did one trace > on the NEC chipset where I have no disconnects and one on the Intel chipset > where I do experience disconnects. The Intel output clearly shows that at > some point in time a URB_INTERRUPT is sent from "1.1" (I suppose it is the > hub) to the host (packet 1780) and the host requests a port reset (packet > 1800). The procedure repeats after a random time (packet 3648). The NEC trace > does not have such interrupts. > > Why is that interrupt sent? Where is it coming from? It comes from the xHCI host controller. It is an indication that the link to the device became inactive, possibly as a result of Link Power Management. > Additional info and observations below: > > Observations: > > - independent of activity/workload Are you sure about that? In your Intel pcap file, the problem occurred only after long periods of inactivity: 40 seconds the first time, 150 seconds the second time. > - works perfectly under Windows 7 in XHCI mode > - works everywhere (Linux and Windows) when using USB 2.0 mode (EHCI) > - tried with kernels 4.0.5, 4.2.0 and 3.18.16 - no difference > - enabling/disabling runtime PM and USB power management doesn't make any > difference The only way to turn off Link Power Management currently is to disable CONFIG_PM entirely. > - works on a different host hardware with a NEC USB3.0 host controller (see > details below). Tested with kernel 3.17.7. > > Traces can be downloaded here: > > http://wikisend.com/download/136936/usb3_intel.pcapng.gz > http://wikisend.com/download/612580/usb3_nec.pcapng.gz > > > Output of /var/log/messages demonstrating the issue: > http://pastebin.com/wbUr5mMe > > > lsusb and lspci outputs (Intel hardware): http://pastebin.com/XDEz2x2g > > > lsusb and lspci outputs (NEC hardware): http://pastebin.com/1M1ZVyJr > > > Thanks for help, Alan Stern -- 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
Aw: Re: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects
> > Observations: > > > > - independent of activity/workload > > Are you sure about that? In your Intel pcap file, the problem occurred > only after long periods of inactivity: 40 seconds the first time, 150 > seconds the second time. Yes, because it can disconnect any time. Last time it managed to disconnect during a file transfer. And also tonight I managed to capture a disconnect while just browsing a directory structure on the HDD (see below). > The only way to turn off Link Power Management currently is to disable > CONFIG_PM entirely. I recompiled the 4.2.0 having disabled CONFIG_PM: # CONFIG_PM is not set This time there were no observable disconnects after just plugging in the device and not doing anything else (like mounting). However, a disconnect happened much later while browsing the directory structure on a mounted FS of the HDD. Surprisingly, the disconnects do not strictly correlate with the load: some heavy copying and seeking back and forth in a HD movie worked just fine. Therefore I think the disconnect would have happened on an idle connection as well. Below is a fresh trace. The reason for the disconnect is URB_INTERRUPT again (triggered in packet #2473): http://wikisend.com/download/150664/usb3_intel2.pcapng.gz Cheers, Eugen -- 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
Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects
Hello, in xHCI mode I'm experiencing random disconnects and reconnects of my ASMedia ASM1051-based external HDD enclosure. The only combination where the disconnects are happening is Intel USB Host Controller + Linux kernel + XHCI mode (see further observations below). I did some tracing with libpcap (can be opened in Wireshark). I did one trace on the NEC chipset where I have no disconnects and one on the Intel chipset where I do experience disconnects. The Intel output clearly shows that at some point in time a URB_INTERRUPT is sent from "1.1" (I suppose it is the hub) to the host (packet 1780) and the host requests a port reset (packet 1800). The procedure repeats after a random time (packet 3648). The NEC trace does not have such interrupts. Why is that interrupt sent? Where is it coming from? Additional info and observations below: Observations: - independent of activity/workload - works perfectly under Windows 7 in XHCI mode - works everywhere (Linux and Windows) when using USB 2.0 mode (EHCI) - tried with kernels 4.0.5, 4.2.0 and 3.18.16 - no difference - enabling/disabling runtime PM and USB power management doesn't make any difference - works on a different host hardware with a NEC USB3.0 host controller (see details below). Tested with kernel 3.17.7. Traces can be downloaded here: http://wikisend.com/download/136936/usb3_intel.pcapng.gz http://wikisend.com/download/612580/usb3_nec.pcapng.gz Output of /var/log/messages demonstrating the issue: http://pastebin.com/wbUr5mMe lsusb and lspci outputs (Intel hardware): http://pastebin.com/XDEz2x2g lsusb and lspci outputs (NEC hardware): http://pastebin.com/1M1ZVyJr Thanks for help, Eugen -- 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
