Hi Andrea, I'm no longer the xHCI driver maintainer. Please work with Mathias, and Cc the linux-usb mailing list. Sarah Sharp On Wed, Aug 20, 2014 at 04:12:49PM +0200, Andrea Arcangeli wrote: > Hi Sarah, > > just a short followup on this. I still had 1gbps hangs with the > 0b95:1790 ASIX Electronics Corp device using xhci. But it seems now > stable for the last 12 hours under heavy load after I removed all > powersaving features. > > Earlier I had these two command run at boot time: > > for i in /sys/bus/usb/devices/*/power/autosuspend_delay_ms; do echo 2000 > $i; done > for i in /sys/bus/*/devices/*/power/control; do echo auto > $i; done > > Removing these two and leaving all the power tweaks at their default > setting may have made a difference (even though I expect powertop > will now complain but I don't mind the battery life too much on the > laptop so this is ok for now if I can get it stable at least). > > Potentially it could be an hardware issue too related to suspending > some pci or usb2 device conflicting with xhci usb3. More likely > there's some software screwup in the powersave code that conflicts > with xhci runtime. > > The powersaving being the culprit didn't cross my mind earlier because > while there's a constant flood at 2gigabit through the usb3 network > card, I would never expect powersaving to potentially kick in. > > On Thu, Jul 03, 2014 at 02:30:17AM +0200, Andrea Arcangeli wrote: > > Hello Sarah, > > > > last year I bought this device: > > > > Bus 004 Device 002: ID 0b95:1790 ASIX Electronics Corp. > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 3.00 > > bDeviceClass 255 Vendor Specific Class > > bDeviceSubClass 255 Vendor Specific Subclass > > bDeviceProtocol 0 > > bMaxPacketSize0 9 > > idVendor 0x0b95 ASIX Electronics Corp. > > idProduct 0x1790 > > bcdDevice 1.00 > > iManufacturer 1 > > iProduct 2 > > iSerial 3 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 57 > > bNumInterfaces 1 > > bConfigurationValue 1 > > iConfiguration 0 > > bmAttributes 0xa0 > > (Bus Powered) > > Remote Wakeup > > MaxPower 124mA > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 3 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 255 Vendor Specific Subclass > > bInterfaceProtocol 0 > > iInterface 4 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x81 EP 1 IN > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0008 1x 8 bytes > > bInterval 11 > > bMaxBurst 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x82 EP 2 IN > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0400 1x 1024 bytes > > bInterval 0 > > bMaxBurst 3 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x03 EP 3 OUT > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0400 1x 1024 bytes > > bInterval 0 > > bMaxBurst 15 > > > > Unless the hardware is broken there's something wrong in xhci or the > > usbnet driver that makes it hang with my usual stress test I do to > > check if the networks is reliable. The device driver is ax88179_178a.c > > > > This is the USB host side on the laptop: > > > > 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) > > 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) > > 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) > > > > In normal usage it practically actually happens, it happened once but > > it's definitely not reproducible without the stress test. > > > > So I guess nobody has noticed this because it's kind of desktop > > hardware that is used without much QA. > > > > I never reported this because I never bothered to collect data but > > this time I did so I can report it now. > > > > For a while I just avoided to use the 1gigabit usb network card but > > then I got tired of the too slow wifi. It's not very nice to debug > > this because this happens on my devel laptop (I don't have xhci on the > > workstations). If you think it's the network card hardware broken I > > can try to buy a new network card... > > > > At 100mbit it tends to happen less but I think it happened once also > > at 100mbit. Still 100mbit defeats the point of not using wifi, and I > > can't stand anything less than 1gbit. > > > > At 21:02:59 the failure happens: > > > > Jul 2 18:30:10 ultra kernel: usb 1-1: finish resume > > Jul 2 18:30:10 ultra kernel: hub 1-1:1.0: hub_resume > > Jul 2 18:30:10 ultra kernel: usb 1-1-port5: status 0507 change 0000 > > Jul 2 18:30:10 ultra kernel: ehci-pci 0000:00:1a.0: reused qh ffff88009e8d6040 schedule > > Jul 2 18:30:10 ultra kernel: usb 1-1: link qh256-0001/ffff88009e8d6040 start 1 [1/0 us] > > Jul 2 18:30:10 ultra kernel: hub 1-1:1.0: state 7 ports 6 chg 0000 evt 0000 > > Jul 2 18:30:10 ultra kernel: usb 1-1.5: usb auto-resume > > Jul 2 18:30:10 ultra kernel: usb 1-1.5: finish resume > > Jul 2 18:30:10 ultra kernel: ehci-pci 0000:00:1a.0: reused qh ffff8802343a8340 schedule > > Jul 2 18:30:10 ultra kernel: usb 1-1.5: link qh16-0001/ffff8802343a8340 start 2 [2/0 us] > > Jul 2 18:30:10 ultra kernel: usb 1-1.5: unlink qh16-0001/ffff8802343a8340 start 2 [2/0 us] > > Jul 2 18:30:13 ultra kernel: usb 1-1.5: usb auto-suspend, wakeup 0 > > Jul 2 18:30:16 ultra kernel: hub 1-1:1.0: hub_suspend > > Jul 2 18:30:16 ultra kernel: usb 1-1: unlink qh256-0001/ffff88009e8d6040 start 1 [1/0 us] > > Jul 2 18:30:16 ultra kernel: usb 1-1: usb auto-suspend, wakeup 1 > > Jul 2 18:30:19 ultra kernel: hub 1-0:1.0: hub_suspend > > Jul 2 18:30:19 ultra kernel: usb usb1: bus auto-suspend, wakeup 1 > > Jul 2 18:30:19 ultra kernel: ehci-pci 0000:00:1a.0: suspend root hub > > Jul 2 18:30:19 ultra kernel: ehci-pci 0000:00:1a.0: hcd_pci_runtime_suspend: 0 > > Jul 2 20:54:41 ultra kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Transfer error on endpoint > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Finding endpoint context > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD. > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Cycle state = 0x0 > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: New dequeue segment = ffff880234dc4b60 (virtual) > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: New dequeue pointer = 0x234ef77c0 (DMA) > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Queueing new dequeue state > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880234dc4b60 (0x234ef7400 dma), new deq ptr = ffff880234ef77c0 (0x234ef77c0 dma), new cycle = 0 > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: // Ding dong! > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Giveback URB ffff88009da3f7c0, len = 8192, expected = 20480, status = -71 > > Jul 2 21:02:59 ultra kernel: ax88179_178a 4-2:1.0 enp0s20u2: rx throttle -71 > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1 > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @234ef77c0 > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Transfer error on endpoint > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Finding endpoint context > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD. > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: Cycle state = 0x0 > > Jul 2 21:02:59 ultra kernel: xhci_hcd 0000:00:14.0: New dequeue segment = ffff880234dc4b60 (virtual) > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: New dequeue pointer = 0x234ef77d0 (DMA) > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Queueing new dequeue state > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880234dc4b60 (0x234ef7400 dma), new deq ptr = ffff880234ef77d0 (0x234ef77d0 dma), new cycle = 0 > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: // Ding dong! > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Giveback URB ffff88009da3f700, len = 0, expected = 20480, status = -71 > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1 > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @234ef77d0 > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Transfer error on endpoint > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Cleaning up stalled endpoint ring > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Finding endpoint context > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Finding segment containing last TRB in TD. > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Cycle state = 0x0 > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: New dequeue segment = ffff880234dc4b60 (virtual) > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: New dequeue pointer = 0x234ef77e0 (DMA) > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Queueing new dequeue state > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: Set TR Deq Ptr cmd, new deq seg = ffff880234dc4b60 (0x234ef7400 dma), new deq ptr = ffff880234ef77e0 (0x234ef77e0 dma), new cycle = 0 > > Jul 2 21:03:00 ultra kernel: xhci_hcd 0000:00:14.0: // Ding dong! > *snip* -- 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
