Re: Help testing for USB ethernet/xHCI regression
On Thu, Jan 30, 2014 at 09:32:49PM -0500, Mark Lord wrote: On 14-01-30 06:26 PM, Sarah Sharp wrote: On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote: On 14-01-30 04:41 PM, Sarah Sharp wrote: Mark and David, can you pull the 3.13-td-changes-reverted branch again, and see if the latest patch fixes your issue? It disables scatter gather for the ax88179_178a device, but only when it's operating at USB 3.0 speeds. As expected, this works just fine. Did it work when plugged into a USB 2.0 hub? Curiosity, NO. Dies almost immediately when run at USB 2.0 Hi-Speed. With a USB 2.0 hub, with a USB 2.0 port on a USB 3.0 hub, and with a USB 2.0 extension cable in place of a hub. Near instant hangs. Plugged directly to the USB 3.0 port, it works fine. Ok, that makes sense. The patch I wrote only limited scatter-gather at USB 3.0 speeds, to see if scatter-gather could work at USB 2.0 speeds. Reverting commit 3804fad45411b48233b48003e33a78f290d227c8 USBNET: ax88179_178a: enable tso if usb host supports sg dma is the right way to go instead. Sarah Sharp -- 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: Help testing for USB ethernet/xHCI regression
From: Sarah Sharp Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: With which kernel? I saw similar issues testing some patches yesterday. Both with the ax179_178a and smsx95xx cards (connected to xhci). My kernel claims to be 3.13.0-dsl+ but it is lying since it was updated from linus's tree earlier this week. I'd not seen any similar delays until the last week or so. The xhci controller I'm using is the Intel 'Panther Point' 8086:1e31 rev 4 (also says 8086:1e2d and 8086:1e26). David -- 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: Help testing for USB ethernet/xHCI regression
From: Sarah Sharp On Tue, Jan 28, 2014 at 11:30:51PM -0500, Mark Lord wrote: On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. It's funny, because there's certainly data transferred over endpoint 0x82, even though there were link TRBs in the middle of transfers. Did the untransferred messages stop when the device stopped working, or did they continue? What I saw was that the USB transfers continued, but the ethernet transmits stopped. This rather changes the packets generated by TCP at both ends. The effect can be seen in the timestamps (etc) in the USB trace. There are still tx and rx packets, after a while they'll only happen on ever-increasing timeouts. That was the point where I wrote the NOP patch just to see if it made a difference. I didn't really expect one! I think that the LINK trb splits a 1k usb message in two. This well and truly confuses the ethernet part of the ax88179_178a hardware to the point where it doesn't even reset itself on the next sub 1k message. It might be that other targets (eg the smsx95xx) is more resilient and only loses the single packet - which won't be immediately obvious. David -- 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: Help testing for USB ethernet/xHCI regression
When using the ax88179 connected via the via based card the whole system gets brought down after a while i got this my system log. I'm going to take a break and see if I can narrow anything more down tomorrow. This log is in reverse because of the wonderful way journalctl works. I suppose I could try using iommu=pt as a kernel boot parameter but that doesn't sound like a safe thing to do. Jan 30 21:04:38 athas kernel: [c11281a0] xhci_msi_irq [xhci_hcd] Jan 30 21:04:38 athas kernel: handlers: Jan 30 21:04:38 athas kernel: [a74f9ee6] system_call_fastpath+0x1a/0x1f Jan 30 21:04:38 athas kernel: [a715ef6a] ? SyS_epoll_ctl+0x4fa/0xb00 Jan 30 21:04:38 athas kernel: EOI [a715f181] ? SyS_epoll_ctl+0x711/0xb00 Jan 30 21:04:38 athas kernel: [a74f982a] common_interrupt+0x6a/0x6a Jan 30 21:04:38 athas kernel: [a700445a] do_IRQ+0x4a/0xf0 Jan 30 21:04:38 athas kernel: [a7004679] handle_irq+0x19/0x30 Jan 30 21:04:38 athas kernel: [a708200f] handle_edge_irq+0x6f/0x120 Jan 30 21:04:38 athas kernel: [a707f8b1] handle_irq_event+0x31/0x50 Jan 30 21:04:38 athas kernel: [a707f802] handle_irq_event_percpu+0xc2/0x140 Jan 30 21:04:38 athas kernel: [a7081b00] note_interrupt+0xe0/0x1e0 Jan 30 21:04:38 athas kernel: [a708176d] __report_bad_irq+0x2d/0xc0 Jan 30 21:04:38 athas kernel: IRQ [a74efd3f] dump_stack+0x45/0x56 Jan 30 21:04:38 athas kernel: Call Trace: Jan 30 21:04:38 athas kernel: 88043edc3ed8 a7081b00 Jan 30 21:04:38 athas kernel: 88043edc3e98 a708176d 880425031b00 004d Jan 30 21:04:38 athas kernel: 880425031b84 88043edc3e70 a74efd3f 880425031b00 Jan 30 21:04:38 athas kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A99FX PRO R2.0, BIOS 2201 11/22/2013 Jan 30 21:04:38 athas kernel: CPU: 7 PID: 1160 Comm: Chrome_IOThread Not tainted 3.13.0+ #13 Jan 30 21:04:38 athas kernel: irq event 77: bogus return value ff94 Jan 30 21:04:38 athas kernel: xhci_hcd :02:00.0: Host not halted after 16000 microseconds. Jan 30 21:04:38 athas kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0019 address=0x002b2000 flags=0x] Jan 30 21:04:38 athas kernel: xhci_hcd :02:00.0: WARNING: Host System Error Regards, Will Trives -- 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: Help testing for USB ethernet/xHCI regression
via vl800 pcie card kernel parameter iommu=pt ethtool -K xxx sg off ifconfig xxx mtu 4060 up stable so far, it's way past the point that it usually crashes. i'll do proper testing tomorrow iommu=pt bah ! Regards, Will Trives On Thursday 30 January 2014 21:46:27 renev...@internode.on.net wrote: When using the ax88179 connected via the via based card the whole system gets brought down after a while i got this my system log. I'm going to take a break and see if I can narrow anything more down tomorrow. This log is in reverse because of the wonderful way journalctl works. I suppose I could try using iommu=pt as a kernel boot parameter but that doesn't sound like a safe thing to do. Jan 30 21:04:38 athas kernel: [c11281a0] xhci_msi_irq [xhci_hcd] Jan 30 21:04:38 athas kernel: handlers: Jan 30 21:04:38 athas kernel: [a74f9ee6] system_call_fastpath+0x1a/0x1f Jan 30 21:04:38 athas kernel: [a715ef6a] ? SyS_epoll_ctl+0x4fa/0xb00 Jan 30 21:04:38 athas kernel: EOI [a715f181] ? SyS_epoll_ctl+0x711/0xb00 Jan 30 21:04:38 athas kernel: [a74f982a] common_interrupt+0x6a/0x6a Jan 30 21:04:38 athas kernel: [a700445a] do_IRQ+0x4a/0xf0 Jan 30 21:04:38 athas kernel: [a7004679] handle_irq+0x19/0x30 Jan 30 21:04:38 athas kernel: [a708200f] handle_edge_irq+0x6f/0x120 Jan 30 21:04:38 athas kernel: [a707f8b1] handle_irq_event+0x31/0x50 Jan 30 21:04:38 athas kernel: [a707f802] handle_irq_event_percpu+0xc2/0x140 Jan 30 21:04:38 athas kernel: [a7081b00] note_interrupt+0xe0/0x1e0 Jan 30 21:04:38 athas kernel: [a708176d] __report_bad_irq+0x2d/0xc0 Jan 30 21:04:38 athas kernel: IRQ [a74efd3f] dump_stack+0x45/0x56 Jan 30 21:04:38 athas kernel: Call Trace: Jan 30 21:04:38 athas kernel: 88043edc3ed8 a7081b00 Jan 30 21:04:38 athas kernel: 88043edc3e98 a708176d 880425031b00 004d Jan 30 21:04:38 athas kernel: 880425031b84 88043edc3e70 a74efd3f 880425031b00 Jan 30 21:04:38 athas kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A99FX PRO R2.0, BIOS 2201 11/22/2013 Jan 30 21:04:38 athas kernel: CPU: 7 PID: 1160 Comm: Chrome_IOThread Not tainted 3.13.0+ #13 Jan 30 21:04:38 athas kernel: irq event 77: bogus return value ff94 Jan 30 21:04:38 athas kernel: xhci_hcd :02:00.0: Host not halted after 16000 microseconds. Jan 30 21:04:38 athas kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0019 address=0x002b2000 flags=0x] Jan 30 21:04:38 athas kernel: xhci_hcd :02:00.0: WARNING: Host System Error Regards, Will Trives -- 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: Help testing for USB ethernet/xHCI regression
On Thu, Jan 30, 2014 at 09:44:53AM +, David Laight wrote: From: Sarah Sharp Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 With which kernel? I saw similar issues testing some patches yesterday. Both with the ax179_178a and smsx95xx cards (connected to xhci). My kernel claims to be 3.13.0-dsl+ but it is lying since it was updated from linus's tree earlier this week. I'd not seen any similar delays until the last week or so. I see a report that these types of errors have been seen since the 3.11 kernel: http://marc.info/?l=linux-usbm=139105963723745w=2 Since the USB ethernet scatter-gather support wasn't added until the 3.12 kernel, it's unlikely that the xHCI TD fragment issue is actually the root cause. The interesting piece of information in that report is that when the USB 3.0 device falls back to USB 2.0 speeds under xHCI, it works. The xhci controller I'm using is the Intel 'Panther Point' 8086:1e31 rev 4 (also says 8086:1e2d and 8086:1e26). That's the host I have as well. I've been able to find an ASIX device with the right chipset, so I'm going to poke around at what's happening at the USB 3.0 bus level. Sarah Sharp -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 01:44 PM, Sarah Sharp wrote: .. Since the USB ethernet scatter-gather support wasn't added until the 3.12 kernel, it's unlikely that the xHCI TD fragment issue is actually the root cause. The interesting piece of information in that report is that when the USB 3.0 device falls back to USB 2.0 speeds under xHCI, it works. Could be due to something related to the max URB length: USB 2.0 High-Speed: max URB length 512. USB 3.0 Super-Speed: max URB length 1024. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Sarah Sharp Sent: Thursday, January 30, 2014 10:44 AM To: David Laight Cc: renev...@internode.on.net; linux-usb@vger.kernel.org; Mark Lord; Greg Kroah-Hartman; net...@vger.kernel.org Subject: Re: Help testing for USB ethernet/xHCI regression On Thu, Jan 30, 2014 at 09:44:53AM +, David Laight wrote: From: Sarah Sharp Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 With which kernel? I saw similar issues testing some patches yesterday. Both with the ax179_178a and smsx95xx cards (connected to xhci). My kernel claims to be 3.13.0-dsl+ but it is lying since it was updated from linus's tree earlier this week. I'd not seen any similar delays until the last week or so. I see a report that these types of errors have been seen since the 3.11 kernel: http://marc.info/?l=linux-usbm=139105963723745w=2 Since the USB ethernet scatter-gather support wasn't added until the 3.12 kernel, it's unlikely that the xHCI TD fragment issue is actually the root cause. The interesting piece of information in that report is that when the USB 3.0 device falls back to USB 2.0 speeds under xHCI, it works. The xhci controller I'm using is the Intel 'Panther Point' 8086:1e31 rev 4 (also says 8086:1e2d and 8086:1e26). That's the host I have as well. I've been able to find an ASIX device with the right chipset, so I'm going to poke around at what's happening at the USB 3.0 bus level. Hi Sarah, Can you give a pointer to where we could buy one of these devices? I would like to test this with our (Synopsys) xHCI controller as well. -- Paul -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 02:54 PM, Paul Zimmerman wrote: Can you give a pointer to where we could buy one of these devices? I would like to test this with our (Synopsys) xHCI controller as well. newegg.com, item N82E16817659005 -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On Thu, Jan 30, 2014 at 03:00:47PM -0500, Mark Lord wrote: On 14-01-30 02:54 PM, Paul Zimmerman wrote: Can you give a pointer to where we could buy one of these devices? I would like to test this with our (Synopsys) xHCI controller as well. newegg.com, item N82E16817659005 Ah, so it's also the ASIX AX88179 that's causing you issues. Mark and David, can you pull the 3.13-td-changes-reverted branch again, and see if the latest patch fixes your issue? It disables scatter gather for the ax88179_178a device, but only when it's operating at USB 3.0 speeds. Please test with it plugged into a USB 3.0 port, and when it's plugged in behind a USB 2.0 hub. Sarah Sharp -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 04:41 PM, Sarah Sharp wrote: Mark and David, can you pull the 3.13-td-changes-reverted branch again, and see if the latest patch fixes your issue? It disables scatter gather for the ax88179_178a device, but only when it's operating at USB 3.0 speeds. As expected, this works just fine. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On 14-01-30 06:26 PM, Sarah Sharp wrote: On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote: On 14-01-30 04:41 PM, Sarah Sharp wrote: Mark and David, can you pull the 3.13-td-changes-reverted branch again, and see if the latest patch fixes your issue? It disables scatter gather for the ax88179_178a device, but only when it's operating at USB 3.0 speeds. As expected, this works just fine. Did it work when plugged into a USB 2.0 hub? Curiosity, NO. Dies almost immediately when run at USB 2.0 Hi-Speed. With a USB 2.0 hub, with a USB 2.0 port on a USB 3.0 hub, and with a USB 2.0 extension cable in place of a hub. Near instant hangs. Plugged directly to the USB 3.0 port, it works fine. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
On Tue, Jan 28, 2014 at 11:30:51PM -0500, Mark Lord wrote: On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. It's funny, because there's certainly data transferred over endpoint 0x82, even though there were link TRBs in the middle of transfers. Did the untransferred messages stop when the device stopped working, or did they continue? All I do is something akin to this: mount /server/ /x mount --bind / /t mirrordir -v --strict-mtimes /t /x/backups/empress mirrordir is similar to rsync, but less cryptic. The sequence above maintains a clone of the root filesystem of my ultrabook (empress) on an NFS server over GigE. Please send me the output of `sudo lsusb -t` and `sudo lsusb -v` with the USB device attached. I'd like to know whether you and David have the same device and driver. Perhaps the link TRB issue only impacts that device, and we can limit scatter-gather under xHCI for that device. If not, we'll have to look at bigger fixes. Sarah Sharp -- 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: Help testing for USB ethernet/xHCI regression
On Wed, Jan 29, 2014 at 04:21:00PM +1100, renev...@internode.on.net wrote: Hello, I am someone who has been struggling to get an ax88179 net adapter working reliably. I have an integrated Asmedia 1042 xhci controller that is reportedly version 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX chipset. The big issue I am currently facing is that I cannot get the device to work at all with 3.13 and current 3.14 mainline. This does not occur with 3.12. With the working kernel, were you using vanilla 3.12, or a later 3.12 stable release, like 3.12.5? Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: With which kernel? [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65 [ 63.389500] usbcore: registered new interface driver ax88179_178a [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1 [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [snip] [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index 0x0002: -110 Can you enable xHCI debugging as well, and send dmesg? You'll need to have CONFIG_USB_DEBUG turned on, and also run this command as root: echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control Any traffic sent to the nic isn't seen by Linux. I can confirm the following problems for me with 3.14: reverting the writeq patch made USB 3 work for me again. http://marc.info/?t=13909329462r=1w=2 So what was the issue that caused you to revert that patch? The traffic not going to the device, or the device not being enumerated at all? and http://marc.info/?l=linux-usbm=139092084714232w=2 got rid of transiever errors I cannot really test stability for the ax88179 until I can get it to work when plugging it in as above. I've tried the frag reversion and it's made no difference to this issue. What about also reverting the writeq patch, on top of the other patches I asked Mark to try? Sarah Sharp -- 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: Help testing for USB ethernet/xHCI regression
I just tried with 3.12.9 and got the errors. I'll keep going back. It doesn't look like the nic is faulty, i'm using it right now plugged into a usb 2.0 port. [ 303.418028] usb 5-5: new high-speed USB device number 2 using ehci-pci [ 303.548948] usb 5-5: New USB device found, idVendor=0b95, idProduct=1790 [ 303.548956] usb 5-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 303.548961] usb 5-5: Product: AX88179 [ 303.548964] usb 5-5: Manufacturer: ASIX Elec. Corp. [ 303.548968] usb 5-5: SerialNumber: 00803F5D080C65 [ 305.418719] ax88179_178a 5-5:1.0 eth0: register 'ax88179_178a' at usb-:00:12.2-5, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65 [ 305.418780] usbcore: registered new interface driver ax88179_178a [ 306.279300] systemd-udevd[1124]: renamed network interface eth0 to enp0s18f2u5 [ 414.395858] IPv6: ADDRCONF(NETDEV_UP): enp0s18f2u5: link is not ready [ 417.196352] ax88179_178a 5-5:1.0 enp0s18f2u5: ax88179 - Link status is: 1 [ 417.198690] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s18f2u5: link becomes ready I'll try those debugging options too and get back to you. Regards, Will Trives On Wednesday 29 January 2014 13:54:08 you wrote: On Wed, Jan 29, 2014 at 04:21:00PM +1100, renev...@internode.on.net wrote: Hello, I am someone who has been struggling to get an ax88179 net adapter working reliably. I have an integrated Asmedia 1042 xhci controller that is reportedly version 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX chipset. The big issue I am currently facing is that I cannot get the device to work at all with 3.13 and current 3.14 mainline. This does not occur with 3.12. With the working kernel, were you using vanilla 3.12, or a later 3.12 stable release, like 3.12.5? Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: With which kernel? [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65 [ 63.389500] usbcore: registered new interface driver ax88179_178a [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1 [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [snip] [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index 0x0002: -110 Can you enable xHCI debugging as well, and send dmesg? You'll need to have CONFIG_USB_DEBUG turned on, and also run this command as root: echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control Any traffic sent to the nic isn't seen by Linux. I can confirm the following problems for me with 3.14: reverting the writeq patch made USB 3 work for me again. http://marc.info/?t=13909329462r=1w=2 So what was the issue that caused you to revert that patch? The traffic not going to the device, or the device not being enumerated at all? and http://marc.info/?l=linux-usbm=139092084714232w=2 got rid of transiever errors I cannot really test stability for the ax88179 until I can get it to work when plugging it in as above. I've tried the frag reversion and it's made no difference to this issue. What about also reverting the writeq patch, on top of the other patches I asked Mark to try? Sarah Sharp -- 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: Help testing for USB ethernet/xHCI regression
On Thu, Jan 30, 2014 at 11:13:53AM +1100, renev...@internode.on.net wrote: I just tried with 3.12.9 and got the errors. I'll keep going back. But which version of 3.12 worked? Just 3.12? Sarah Sharp -- 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
Help testing for USB ethernet/xHCI regression
Hi Mark,
You reported that you had an issue with a USB ethernet device on 3.12,
and that updating to 3.13-rc4 (which included commit 587194873820 xhci:
convert TRB_CYCLE to le32 before using it to set Link TRB's cycle bit)
fixed the issue for you. Later you said applying that patch on top of
3.12 didn't fix your issue. It was unclear whether your issue was fixed
by another patch in 3.13-rc4.
That particular commit is causing regressions in the storage
layer (which we've fixed) and now also the usbfs layer (which has a
potential solution). It also causes issues with 0.96 ASMedia xHCI hosts
(which also has a potential solution).
I'm concerned that there will be further regressions as well. Before
applying additional regression fixes for David's patch, I'd like to slow
down and double check that the patch actually solved the issue it set
out to.
Can you please pull this branch, which contains a 3.13 kernel with
David's patch reverted, and test whether your USB ethernet device works
or fails?
git clone -b 3.13-td-changes-reverted
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
If it fails, please turn on xHCI debugging:
# echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control
trigger the failure, and send me the resulting dmesg, along with the
procedure/commands you used to make the device fail.
Also, please double check to see if vanilla 3.13 works or fails.
David, please do the same and send me dmesg.
I know the log will be large due to untransferred length message, but
I need those messages, so please compress the files or stick the dmesg
up on pastebin.
Thanks,
Sarah Sharp
On Fri, Dec 06, 2013 at 12:55:23AM -0500, Mark Lord wrote:
On 13-12-02 04:42 PM, Greg Kroah-Hartman wrote:
On Mon, Dec 02, 2013 at 12:49:08PM -0800, Sarah Sharp wrote:
The following changes since commit
c24cb6c8b501ebdf1aacec7960110a9741a45ced:
Merge tag 'fixes-for-v3.13-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
(2013-11-27 09:49:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
tags/for-usb-linus-2013-12-02
Pulled and pushed out, thanks.
Did this commit make it into linux-3.12.3 ?
I ask, because the NIC still locks up with that kernel,
and even with the patch I had been using from David Laight.
Reverting the change that originally broke it still works though.
Could we please get this reverted until such time as a reworked
patch can be prepared for it?
This is what I am reverting locally to make it all work
as it did prior to linux-3.12 was released. Unmangled copy also attached:
--- linux/drivers/net/usb/ax88179_178a.c.orig 2013-11-03 18:41:51.0
-0500
+++ linux/drivers/net/usb/ax88179_178a.c 2013-11-17 13:23:39.525734277
-0500
@@ -1177,18 +1177,31 @@
int frame_size = dev-maxpacket;
int mss = skb_shinfo(skb)-gso_size;
int headroom;
+ int tailroom;
tx_hdr1 = skb-len;
tx_hdr2 = mss;
if (((skb-len + 8) % frame_size) == 0)
tx_hdr2 |= 0x80008000; /* Enable padding */
- headroom = skb_headroom(skb) - 8;
+ headroom = skb_headroom(skb);
+ tailroom = skb_tailroom(skb);
- if ((skb_header_cloned(skb) || headroom 0)
- pskb_expand_head(skb, headroom 0 ? 8 : 0, 0, GFP_ATOMIC)) {
+ if (!skb_header_cloned(skb)
+ !skb_cloned(skb)
+ (headroom + tailroom) = 8) {
+ if (headroom 8) {
+ skb-data = memmove(skb-head + 8, skb-data, skb-len);
+ skb_set_tail_pointer(skb, skb-len);
+ }
+ } else {
+ struct sk_buff *skb2;
+
+ skb2 = skb_copy_expand(skb, 8, 0, flags);
dev_kfree_skb_any(skb);
- return NULL;
+ skb = skb2;
+ if (!skb)
+ return NULL;
}
skb_push(skb, 4);
--- linux/drivers/net/usb/ax88179_178a.c.orig 2013-11-03 18:41:51.0
-0500
+++ linux/drivers/net/usb/ax88179_178a.c 2013-11-17 13:23:39.525734277
-0500
@@ -1177,18 +1177,31 @@
int frame_size = dev-maxpacket;
int mss = skb_shinfo(skb)-gso_size;
int headroom;
+ int tailroom;
tx_hdr1 = skb-len;
tx_hdr2 = mss;
if (((skb-len + 8) % frame_size) == 0)
tx_hdr2 |= 0x80008000; /* Enable padding */
- headroom = skb_headroom(skb) - 8;
+ headroom = skb_headroom(skb);
+ tailroom = skb_tailroom(skb);
- if ((skb_header_cloned(skb) || headroom 0)
- pskb_expand_head(skb, headroom 0 ? 8 : 0, 0, GFP_ATOMIC)) {
+ if (!skb_header_cloned(skb)
+ !skb_cloned(skb)
+ (headroom + tailroom) = 8) {
+ if (headroom 8) {
+ skb-data = memmove(skb-head + 8, skb-data, skb-len);
+ skb_set_tail_pointer(skb,
Re: Help testing for USB ethernet/xHCI regression
On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. All I do is something akin to this: mount /server/ /x mount --bind / /t mirrordir -v --strict-mtimes /t /x/backups/empress mirrordir is similar to rsync, but less cryptic. The sequence above maintains a clone of the root filesystem of my ultrabook (empress) on an NFS server over GigE. Also, please double check to see if vanilla 3.13 works or fails. Okay, will try that before bed. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com log.gz Description: GNU Zip compressed data
Re: Help testing for USB ethernet/xHCI regression
On 14-01-28 11:30 PM, Mark Lord wrote: On 14-01-28 03:30 PM, Sarah Sharp wrote: .. Can you please pull this branch, which contains a 3.13 kernel with David's patch reverted, and test whether your USB ethernet device works or fails? Fails. dmesg log attached. All I do is something akin to this: mount /server/ /x mount --bind / /t mirrordir -v --strict-mtimes /t /x/backups/empress mirrordir is similar to rsync, but less cryptic. The sequence above maintains a clone of the root filesystem of my ultrabook (empress) on an NFS server over GigE. Also, please double check to see if vanilla 3.13 works or fails. Okay, will try that before bed. Vanilla 3.13 does not appear to have the USB3 ethernet lockup issue, and even USB3 hot-plug appears to be working again (was not working in 3.13-rc4). Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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: Help testing for USB ethernet/xHCI regression
Hello, I am someone who has been struggling to get an ax88179 net adapter working reliably. I have an integrated Asmedia 1042 xhci controller that is reportedly version 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX chipset. The big issue I am currently facing is that I cannot get the device to work at all with 3.13 and current 3.14 mainline. This does not occur with 3.12. Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65 [ 63.389500] usbcore: registered new interface driver ax88179_178a [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1 [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [snip] [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index 0x0002: -110 Any traffic sent to the nic isn't seen by Linux. I can confirm the following problems for me with 3.14: reverting the writeq patch made USB 3 work for me again. http://marc.info/?t=13909329462r=1w=2 and http://marc.info/?l=linux-usbm=139092084714232w=2 got rid of transiever errors I cannot really test stability for the ax88179 until I can get it to work when plugging it in as above. I've tried the frag reversion and it's made no difference to this issue. Regards, Will Trives -- 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: Help testing for USB ethernet/xHCI regression
just to add I have a vantec 2 bay usb 3.0 disk dock that has appeared to always work fine connected to the asmedia 1042 with version 3.13 and with 3.14 (with the writeq reversion and transciever fix) On Wednesday 29 January 2014 16:21:00 you wrote: Hello, I am someone who has been struggling to get an ax88179 net adapter working reliably. I have an integrated Asmedia 1042 xhci controller that is reportedly version 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX chipset. The big issue I am currently facing is that I cannot get the device to work at all with 3.13 and current 3.14 mainline. This does not occur with 3.12. Current issue is when plugging in the ax88179 there is lag when bringing the interface up and a bunch of kernel messages: [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65 [ 63.389500] usbcore: registered new interface driver ax88179_178a [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1 [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1 [snip] [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index 0x0002: -110 Any traffic sent to the nic isn't seen by Linux. I can confirm the following problems for me with 3.14: reverting the writeq patch made USB 3 work for me again. http://marc.info/?t=13909329462r=1w=2 and http://marc.info/?l=linux-usbm=139092084714232w=2 got rid of transiever errors I cannot really test stability for the ax88179 until I can get it to work when plugging it in as above. I've tried the frag reversion and it's made no difference to this issue. Regards, Will Trives -- 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
