0b95:1790 [Asus N55SF] Bad performance of Asix Ethernet-to-USB device on USB3 port

[Stéphane Gourichon]

Plugging USB-to-ethernet device ID 0b95:1790 ASIX Electronics Corp. in USB3 port yields slow performance, dmesg flooded with errors. Plugging on USB2 port, exact same situation otherwise, works well. This is reproducible 3 out of 4 attempts. Machine has 2 USB3 ports on the left, 2 USB2 ports on the right.

### When working (USB2 port)
* ethernet auto-negociation is fast
* mii-tool is fast (typical 0.05s)
* few lines in dmesg
* good performance

### When failing :
* ethernet auto-negociation fails, then sometimes eventually works
* mii-tool is slow (10s of seconds instead of 0.05s)

time sudo mii-tool
eth0: no link
eth1: 10 Mbit, half duplex, no link
real 0m40.014s
user 0m0.013s
sys 0m0.006s

time sudo mii-tool
eth0: no link
eth1: 10 Mbit, half duplex, no link
real 0m50.015s
user 0m0.011s
sys 0m0.011s

time sudo mii-tool
eth0: no link
eth1: negotiated 100baseTx-FD, link ok
real 0m10.051s
user 0m0.000s
sys 0m0.012s

But on some attempts mii-tool is fast...
time sudo mii-tool
eth0: no link
eth1: negotiated 100baseTx-FD, link ok
real 0m0.057s
user 0m0.011s
sys 0m0.012s

* DHCP eventually completes (after about 30 seconds) then ethernet works.
* whole system behaviour feels a little sluggish (not very clear, though)
* mii-tool still slow (10s of seconds instead of 0.05s)

## dmesg when failing

Full dmesg attached.

Specific lines with occurrence count at random point (obtained with "dmesg | sed 's/^................//' | sort | uniq -c | sort -n" ).

     50 ei_me 0000:00:16.0: reset: wrong host start response
     51 ei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
     60 ax88179_178a 4-1:1.0 eth1: kevent 4 may have been dropped
    100 ei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
    141 xhci_hcd 0000:04:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
    214 ax88179_178a 4-1:1.0 eth1: ax88179 - Link status is: 1

Another attempt

     11 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0000: -110
     14 ax88179_178a 4-1:1.0 eth1: Failed to write reg index 0x0002: -110
     61 xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
     61 xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    209 ax88179_178a 4-1:1.0 eth1: kevent 4 may have been dropped
    809 ax88179_178a 4-1:1.0 eth1: ax88179 - Link status is: 1
    925 xhci_hcd 0000:04:00.0: ERROR Transfer event TRB DMA ptr not part of current TD

      5 IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
      6 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0001: -110
      6 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0009: -110
      6 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x000a: -110
      6 net_ratelimit: 31 callbacks suppressed
      9 IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
     10 net_ratelimit: 30 callbacks suppressed
     14 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0000: -110
     14 ax88179_178a 4-1:1.0 eth1: Failed to write reg index 0x0002: -110
    209 ax88179_178a 4-1:1.0 eth1: kevent 4 may have been dropped
    232 xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    232 xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    610 xhci_hcd 0000:04:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
    809 ax88179_178a 4-1:1.0 eth1: ax88179 - Link status is: 1

    Jan 16 18:39:35 n55sf-l kernel: [203181.206451] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:36 n55sf-l kernel: [203181.578841] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:36 n55sf-l kernel: [203181.578854] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:36 n55sf-l kernel: [203182.075350] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:36 n55sf-l kernel: [203182.075364] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:36 n55sf-l kernel: [203182.199491] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:36 n55sf-l kernel: [203182.199504] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:37 n55sf-l kernel: [203182.944174] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:37 n55sf-l kernel: [203182.944178] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:37 n55sf-l kernel: [203183.068300] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:37 n55sf-l kernel: [203183.068305] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:37 n55sf-l kernel: [203183.192433] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr

## On USB2 port everything fine.
    Jan 16 18:26:44 n55sf-l kernel: [202408.897761] usb 2-1.4: new high-speed USB device number 18 using ehci-pci
    Jan 16 18:26:44 n55sf-l kernel: [202408.996745] usb 2-1.4: New USB device found, idVendor=0b95, idProduct=1790
    Jan 16 18:26:44 n55sf-l kernel: [202408.996757] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    Jan 16 18:26:44 n55sf-l kernel: [202408.996763] usb 2-1.4: Product: AX88179
    Jan 16 18:26:44 n55sf-l kernel: [202408.996769] usb 2-1.4: Manufacturer: ASIX Elec. Corp.
    Jan 16 18:26:44 n55sf-l kernel: [202408.996774] usb 2-1.4: SerialNumber: 00000000000116
    Jan 16 18:26:44 n55sf-l kernel: [202409.325222] ax88179_178a 2-1.4:1.0 eth1: register 'ax88179_178a' at usb-0000:00:1d.0-1.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:05:1b:a3:37:f6
    Jan 16 18:26:45 n55sf-l kernel: [202409.681691] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
    Jan 16 18:26:45 n55sf-l kernel: [202409.685338] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
    Jan 16 18:26:47 n55sf-l kernel: [202411.782132] ax88179_178a 2-1.4:1.0 eth1: ax88179 - Link status is: 1
    Jan 16 18:26:47 n55sf-l kernel: [202411.785044] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

## Once things went fine on a USB3 port
    Jan 16 18:27:45 n55sf-l kernel: [202470.636671] usb 3-2: new high-speed USB device number 12 using xhci_hcd
    Jan 16 18:27:46 n55sf-l kernel: [202470.689067] usb 3-2: New USB device found, idVendor=0b95, idProduct=1790
    Jan 16 18:27:46 n55sf-l kernel: [202470.689079] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    Jan 16 18:27:46 n55sf-l kernel: [202470.689085] usb 3-2: Product: AX88179
    Jan 16 18:27:46 n55sf-l kernel: [202470.689090] usb 3-2: Manufacturer: ASIX Elec. Corp.
    Jan 16 18:27:46 n55sf-l kernel: [202470.689095] usb 3-2: SerialNumber: 00000000000116
    Jan 16 18:27:46 n55sf-l kernel: [202471.012136] ax88179_178a 3-2:1.0 eth1: register 'ax88179_178a' at usb-0000:04:00.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:05:1b:a3:37:f6
    Jan 16 18:27:46 n55sf-l kernel: [202471.367771] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
    Jan 16 18:27:46 n55sf-l kernel: [202471.371383] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
    Jan 16 18:27:48 n55sf-l kernel: [202473.414584] ax88179_178a 3-2:1.0 eth1: ax88179 - Link status is: 1
    Jan 16 18:27:48 n55sf-l kernel: [202473.416586] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

## Then bad again on next attempt on USB3 port with different infinite loop of error messages:
     11 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0000: -110
     14 ax88179_178a 4-1:1.0 eth1: Failed to write reg index 0x0002: -110
     61 xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
     61 xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    209 ax88179_178a 4-1:1.0 eth1: kevent 4 may have been dropped
    809 ax88179_178a 4-1:1.0 eth1: ax88179 - Link status is: 1
    925 xhci_hcd 0000:04:00.0: ERROR Transfer event TRB DMA ptr not part of current TD

      5 IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
      6 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0001: -110
      6 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0009: -110
      6 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x000a: -110
      6 net_ratelimit: 31 callbacks suppressed
      9 IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
     10 net_ratelimit: 30 callbacks suppressed
     14 ax88179_178a 4-1:1.0 eth1: Failed to read reg index 0x0000: -110
     14 ax88179_178a 4-1:1.0 eth1: Failed to write reg index 0x0002: -110
    209 ax88179_178a 4-1:1.0 eth1: kevent 4 may have been dropped
    232 xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    232 xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    610 xhci_hcd 0000:04:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
    809 ax88179_178a 4-1:1.0 eth1: ax88179 - Link status is: 1

    Jan 16 18:39:35 n55sf-l kernel: [203181.206451] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:36 n55sf-l kernel: [203181.578841] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:36 n55sf-l kernel: [203181.578854] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:36 n55sf-l kernel: [203182.075350] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:36 n55sf-l kernel: [203182.075364] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:36 n55sf-l kernel: [203182.199491] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:36 n55sf-l kernel: [203182.199504] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:37 n55sf-l kernel: [203182.944174] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:37 n55sf-l kernel: [203182.944178] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:37 n55sf-l kernel: [203183.068300] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
    Jan 16 18:39:37 n55sf-l kernel: [203183.068305] xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
    Jan 16 18:39:37 n55sf-l kernel: [203183.192433] xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr

## Additional attempts on USB2 port went fine.

https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.4.10
Re: ERROR transfer event TRB DMA ptr not part of current TD -- Linux USB http://www.spinics.net/lists/linux-usb/msg85388.html

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-15-generic 3.11.0-15.23
ProcVersionSignature: Ubuntu 3.11.0-15.23-generic 3.11.10
Uname: Linux 3.11.0-15-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: stephane 1815 F.... pulseaudio
Date: Thu Jan 16 18:34:32 2014
HibernationDevice: RESUME=UUID=d05e8def-662d-4d3a-b3b3-4d9d2997966d
MachineType: ASUSTeK Computer Inc. N55SF
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-15-generic root=UUID=12f862a8-f6b9-4c9e-8bf7-030b86b75241 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-15-generic N/A
 linux-backports-modules-3.11.0-15-generic N/A
 linux-firmware 1.116
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/29/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: N55SF.207
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: N55SF
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrN55SF.207:bd08/29/2011:svnASUSTeKComputerInc.:pnN55SF:pvr1.0:rvnASUSTeKComputerInc.:rnN55SF:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: N55SF
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Stéphane Gourichon (stephane-gourichon-lpad)]

dmesg of one attempt

[Joseph Salisbury (jsalisbury)]

Did this issue occur in a previous version of Ubuntu, or is this a new issue?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.13 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc8-trusty/

[Stéphane Gourichon (stephane-gourichon-lpad)]

Hello @jsalisbury,

Thank you for your reply.
For old releases I booted old versions of Ubuntu that I used before upgrading to 13.10 and are still lying
For new kernel, I followed your link and used URL http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc7-saucy/

Here's the summary of my tests :
* On Ubuntu 12.10 device is not recognized as an Ethernet device.
* On Ubuntu 13.04 device is not recognized as an Ethernet device.
* On upstream kernel 3.12.0-031200rc7-generic #201310271935

Linux n55sf-l 3.12.0-031200rc7-generic #201310271935 SMP Sun Oct 27 23:37:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

LC_ALL=C apt-cache policy linux-image-3.12.0-031200rc7-generic

linux-image-3.12.0-031200rc7-generic:
  Installed: 3.12.0-031200rc7.201310271935
  Candidate: 3.12.0-031200rc7.201310271935
  Version table:
 *** 3.12.0-031200rc7.201310271935 0
        100 /var/lib/dpkg/status

Do you want kernel logs for these 3 tests or any sort of extra details ?

[Stéphane Gourichon (stephane-gourichon-lpad)]

Oops, finger slip caused posting too early.

On upstream kernel 3.12.0-031200rc7-generic #201310271935 bug **still occurs** with same characteristics including probability of happening on any test (about 75% probability).

12.10 kernel was
Linux version 3.5.0-42-generic (buildd@lamiak) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #65-Ubuntu SMP Tue Oct 1 23:38:22 UTC 2013 (Ubuntu 3.5.0-42.65-generic 3.5.7.21)

13.04 kernel was
Linux version 3.8.0-27-generic (buildd@roseapple) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 (Ubuntu 3.8.0-27.40-generic 3.8.13.4)

Regards,

[Stéphane Gourichon (stephane-gourichon-lpad)]

According to https://launchpad.net/ax88179 the driver is in mainline kernel since 3.9 which explains why older Ubuntu releases did not recognize the device.

[penalvch (penalvch)]

gouri, just to clarify:
1) Could you please plug your ASIX device in, execute the following in a terminal and post it to this report:
usb-devices

2) Are you using a default install drivers (i.e. provided by supported Ubuntu repositories), the following PPA driver https://launchpad.net/~qji/+archive/ax88179 , something else?

[Stéphane Gourichon (stephane-gourichon-lpad)]

Hello Christopher,

> 1) Could you please plug your ASIX device in, execute the following in a terminal and post it to this report:
> usb-devices

Please see attached file
usb-devices_output_with_0b95_1790_ASIX_Electronics_Corp_USB2_port.txt

Currently, other than the device, only a mouse is physically plugged to an external USB port. Oher hardware listed (card reader, wifi, hubs, webcam) is permanently part of the laptop.

In case it matters, I haven't rebooted since last post, so still running
Linux n55sf-l 3.12.0-031200rc7-generic #201310271935 SMP Sun Oct 27 23:37:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

> 2) Are you using a default install drivers (i.e. provided by supported
> Ubuntu repositories), the following PPA driver
> https://launchpad.net/~qji/+archive/ax88179 , something else?

I haven't done anything about the device at any time : no PPA, no manual driver install, no user-space tool install, no nothing.
Just plug the device (and an Ethernet cable).

Only kernel-side maneuver was to install bumblebee (from regular package else machine draws a lot of power, heats and makes a loud fan noise, all cleanly fixed by bumblebee).

Regards,

[penalvch (penalvch)]

gouri, thank you for providing the requested information. Could you please test the latest mainline kernel (not 3.12-rc7) via http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-trusty/ and advise if this is reproducible?

[Stéphane Gourichon (stephane-gourichon-lpad)]

> gouri, thank you for providing the requested information. Could you please test the latest mainline kernel (not 3.12-rc7) via http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-trusty/ and advise if this is reproducible?

Hello again Christopher,

* Short answer

Reproduced with 3.13.0 from URL above.
Plugged 8 times in a USB3 port. First time yield a success log, others yielded a failure log.

Interesting fact : I noticed that when device works in a USB3 port it is recognized in kernel log as "high-speed" instead of "SuperSpeed". It already happened as you can see in bug description, look for "Jan 16 18:27:45".
So, it may be that the device actually never works when correctly recognized as SuperSpeed, but works in a USB3 port only when "by accident" it is only recognized as "high speed" (USB2) ?

Regards,

* Long answer

I used a 3.12 because I aimed at the latest saucy kernel (and got it wrong, rc7 is not the latest, but anyway).

I did this :

wget -S http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-trusty/linux-headers-3.13.0-031300-generic_3.13.0-031300.201401192235_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-trusty/linux-image-3.13.0-031300-generic_3.13.0-031300.201401192235_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-trusty/linux-headers-3.13.0-031300_3.13.0-031300.201401192235_all.deb

sudo dpkg --install linux-headers-3.13.0-031300_3.13.0-031300.201401192235_all.deb linux-headers-3.13.0-031300-generic_3.13.0-031300.201401192235_amd64.deb linux-image-3.13.0-031300-generic_3.13.0-031300.201401192235_amd64.deb

reboot

login

Apport (or whoopsie ?) told me bbswitch failed, and indeed bumblebee was not active, with usual results (machine heats and makes a loud fan noise).

tail -f /var/log/kern.log

I plugged device, wait for a few seconds, see behavior, unplug the device.

Rest is in short answer.

[Stéphane Gourichon (stephane-gourichon-lpad)]

Kernel log. All 8 attempts were on one of the USB3 port on the left, not on any of the USB2 ports on the right, notice the first worked with mention:

> Jan 22 13:02:50 n55sf-l kernel: [ 152.219714] usb 3-2: new high-speed USB device number 2 using xhci_hcd

which indicates USB2 speed not USB3.

[penalvch (penalvch)]

gouri, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.

[Stéphane Gourichon (stephane-gourichon-lpad)]

> Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?
> Thank you for your understanding.

Thank you Christopher for your feedback.

I've read the instructions, they are clear and I'm convinced that following them exactly indeed makes things more efficient for everyone. Also thank your for having edited this bug title and first sentence they look more in the spirit of the instructions.

For added confidence, I'm considering first testing the device on another computer that also has USB3 and USB2 ports and/or another distribution using a live media, then updating here then doing the upstream report.

Regards.

[Stéphane Gourichon (stephane-gourichon-lpad)]

I tested on a "nettop" computer model SMT-FOX-NTA3500-BL (a machine that looks very similar to a foxconn-nt-a3500) running Ubuntu 13.10, but i386 not AMD64.
Kernel is 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:16:27 UTC 2013 i686 athlon i686 GNU/Linux
The machine has 3 USB3 ports and 4 USB2 ports.

Result: bug reproduced on that machine too, the same way.

I'll go on the upstream following instructions.

Regards.

[Stéphane Gourichon (stephane-gourichon-lpad)]

Hello Christopher,

Bug-report seems okay for upstream.

I first copy-paste its content below for two reasons:

* I've performed tests on the second machine where I have reproduced more tests. Results are not 100% similar. For example tons of "kevent 4 may have been dropped" but none of these :
 xhci_hcd 0000:04:00.0: A Set TR Deq Ptr command is pending.
 xhci_hcd 0000:04:00.0: WARN Cannot submit Set TR Deq Ptr
 xhci_hcd 0000:04:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
details below.

* second reason : to be sure the bug it is okay for kernel list. Anyway since its content is different from previous content, there's value in pasting it here. Following https://wiki.ubuntu.com/Bugs/Upstream/kernel the address to send to is <email address hidden> mailinglist.

Any feedback welcome.

Regards,

# upstream bug report

[1.] One line summary of the problem:

0b95:1790 [Asus N55SF] Bad performance of Ethernet-to-USB device on USB3 port, dmesg flooded with errors

[2.] Full description of the problem/report:

Plugging USB-to-ethernet device ID 0b95:1790 ASIX Electronics Corp. in USB3 port yields slow performance, dmesg flooded with errors. Plugging on USB2 port, exact same situation otherwise, always works well. Bug is reproducible roughly 3 out of 4 attempts. Every time the bug didn't occur on a USB3 port, the device was recognized as "high-speed" (USB2) instead of "SuperSpeed" (USB3) though it was plugged in a USB3 port.

Reproduced on two different machines including all there details above. Machines are:
* ASUS N55SF laptop, Intel CPU, kernel Linux 3.13.0 64-bit.
* SMT-FOX-NTA3500-BL (or foxconn-nt-a3500 ?), kernel Linux 3.13.0 32-bit.
Both machines have USB2 and USB3 ports.

### When working (USB2 port)
* ethernet auto-negociation is fast
* mii-tool is fast (typical 0.05s)
* few lines in dmesg
* good performance

### When failing (USB3 port, device recognized as SuperSpeed)
* ethernet auto-negociation fails, then eventually works (after a minute or so).
* mii-tool is often slow (10s of seconds instead of 0.05s) but sometimes fast
* DHCP eventually completes (after about 30 seconds) when applicable, then ethernet works.
* "ifconfig" and "ip addr list" slow like mii-tool.
* Unplugging-plugging the cable yields another slow auto-negociation round.

Except when noted, all details below are from the second machine.

Bug was tested on older kernels (3.5.0 and 3.8.0) but device is simply not recognized because driver was included only from 3.9.

Some parts of dmesg output and perfomance measurements given in section [7.7.] below.

[3.] Keywords (i.e., modules, networking, kernel):
[4.] Kernel version (from /proc/version):

Linux version 3.13.0-031300-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201401192235 SMP Mon Jan 20 03:46:44 UTC 2014

[5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt)

No oops.

[6.] A small shell script or example program which triggers the problem (if possible)

No program needed. Just plug the device and look at dmesg output.

[7.] Environment

lsb_release -rd

Description: Ubuntu 13.10
Release: 13.10

[7....

[penalvch (penalvch)]

gouri, please feel free to fire the e-mail away to all of the following parties:
linux-usb mailing list
<email address hidden>

[Stéphane Gourichon (stephane-gourichon-lpad)]

Posted to linux-usb list with cc to Freddy Xin (who introduced the driver to the list).

URL of upstream thread : http://thread.gmane.org/gmane.linux.usb.general/102382

Driver appears to have been introduced on January 2013 in that thread:
http://thread.gmane.org/gmane.linux.kernel/1420310

[william (william-linux-kernel-bugs)]

Created attachment 134931
3.14.2 - dmesg report

I've a Dell XPS 13 (ivy bridge, 2013 version) and I've bought an ASIX AX88179 USB 3.0 Gigabit Ethernet I'm using in one of the XPS's USB 3.0 port.

The kernel driver for the ASIX AX88179 appeared with the 3.9 kernel version.

I used the Ethernet adapter for the first time when the 3.10 kernel was released (I'm running ArchLinux which is in rolling release). At that time, transferring a huge number of files or pretty heavy files caused kernel panic: either I had a stacktrace displayed or the computer became completely unresponsive.

Tests performed on another machine, a Dell XPS 17 (L702X), gave the same results, while on Windows no problem so far. Testing with another adapter from another revision gave the same problem.

The disconnection with the Ethernet adapter is more likely to happen when transferring a huge number of files (e.g. several kernel sources with several 10k of files in it). After some disconnections-reconnections, the computer refuses to reconnect again, the adapter doesn't answer anymore, while the link led is still blinking like mad. I've do unplug the adapter and reconnect it again to recover my connection.

It appears the bug is known in upstream, but has not been solved so far: https://github.com/FreddyXin/ax88179_178a/issues/6

Please find as attachment what dmesg reports (on kernel 3.14.2) from the moment I connected the adapter until the adapter completely fails to responds at all.

[Stéphane Gourichon (stephane-gourichon-lpad)]

Summary: (1) bug also occurs on Trusty 14.04 (2) we need you (yes, you, affected by the bug) to help cure it

## Bug reproduced on Trusty

Just tested the same hardware again on kernel 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux.

Same behavior as already described.

Here's part of lsusb -t

/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M

situation above (device working in USB3 condition) reproduces the bug
situation below (device working in USB2 condition) works

/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 480M

## Contacting upstream

No reply to my e-mail to linux-usb and Freddy Xin dated january 2014:

Sujet: 0b95:1790 [Asus N55SF] Bad performance of Asix Ethernet-to-USB device on USB3 port
Date : Thu, 30 Jan 2014 06:20:01 +0100
De : Stéphane Gourichon <...@...>
Pour : linux-usb (address mangled on purpose) vger.kernel.org, Freddy Xin <...@...>

It would be a good thing to write again politely. I'm overwhelmed with work, so if someone affected by the bug may knock again at the list and developer to establish contact that would be great. For a good start read [Ask a kernel developer, part 2 [LWN.net]](http://lwn.net/Articles/356890/). It's short and simple.

Thank you for your attention.

[aklhfex (aklhfex-linux-kernel-bugs)]

Similarly on a Z68 motherboard with Asmedia ASM1042 USB 3.0. Works fine in the Z68 USB 2.0 port.

[alexminder (alexminder-linux-kernel-bugs)]

Similarly bug with Speed Dragon USB 3.0 10/100/1000Mbps Gigabit Ethernet Dongle
Kernel: 3.14.14-gentoo
OS: Gentoo Base System release 2.2

dmesg output:
[15564.878306] usb 2-3: USB disconnect, device number 2
[15564.878512] ax88179_178a 2-3:1.0 enp0s20u3: unregister 'ax88179_178a' usb-0000:00:14.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet
[15564.878524] ax88179_178a 2-3:1.0 enp0s20u3: Failed to read reg index 0x0002: -19
[15564.878528] ax88179_178a 2-3:1.0 enp0s20u3: Failed to write reg index 0x0002: -19
[15564.893360] ax88179_178a 2-3:1.0 (unregistered net_device): Failed to write reg index 0x0002: -19
[15564.893367] ax88179_178a 2-3:1.0 (unregistered net_device): Failed to write reg index 0x0001: -19
[15564.893371] ax88179_178a 2-3:1.0 (unregistered net_device): Failed to write reg index 0x0002: -19
[15565.100787] usb 2-3: new SuperSpeed USB device number 3 using xhci_hcd
[15565.115018] usb 2-3: New USB device found, idVendor=0b95, idProduct=1790
[15565.115023] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[15565.115026] usb 2-3: Product: AX88179
[15565.115028] usb 2-3: Manufacturer: ASIX Elec. Corp.
[15565.115031] usb 2-3: SerialNumber: 0000133B992E37
[15565.429907] ax88179_178a 2-3:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:13:3b:99:2e:37
[15565.458894] systemd-udevd[10806]: renamed network interface eth0 to enp0s20u3
[15565.782606] IPv6: ADDRCONF(NETDEV_UP): enp0s20u3: link is not ready
[15565.861783] ax88179_178a 2-3:1.0 enp0s20u3: ax88179 - Link status is: 1
[15567.527107] ax88179_178a 2-3:1.0 enp0s20u3: ax88179 - Link status is: 1
[15567.528657] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u3: link becomes ready
[29626.098636] usb 2-3: USB disconnect, device number 3
[29626.099058] ax88179_178a 2-3:1.0 enp0s20u3: unregister 'ax88179_178a' usb-0000:00:14.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet
[29626.099088] ax88179_178a 2-3:1.0 enp0s20u3: Failed to read reg index 0x0002: -19
[29626.099097] ax88179_178a 2-3:1.0 enp0s20u3: Failed to write reg index 0x0002: -19
[29626.112680] ax88179_178a 2-3:1.0 (unregistered net_device): Failed to write reg index 0x0002: -19
[29626.112686] ax88179_178a 2-3:1.0 (unregistered net_device): Failed to write reg index 0x0001: -19
[29626.112690] ax88179_178a 2-3:1.0 (unregistered net_device): Failed to write reg index 0x0002: -19
[29626.319548] usb 2-3: new SuperSpeed USB device number 4 using xhci_hcd
[29626.337384] usb 2-3: New USB device found, idVendor=0b95, idProduct=1790
[29626.337389] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[29626.337391] usb 2-3: Product: AX88179
[29626.337394] usb 2-3: Manufacturer: ASIX Elec. Corp.
[29626.337396] usb 2-3: SerialNumber: 0000133B992E37
[29626.651791] ax88179_178a 2-3:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:13:3b:99:2e:37
[29626.691929] systemd-udevd[14374]: renamed network interface eth0 to enp0s20u3
[29627.021759] IPv6: ADDRCONF(NETDEV_UP): enp0s20u3: link is not ready
[29627.138597] ax88179_178a 2-3:1.0 enp0s20u3: ax88179 - Link status is: 1
[29628.803882] ax88179_178a 2-3:1.0 enp0s20u3: ax88179 - Link status is:...

[krichter722 (krichter722-linux-kernel-bugs)]

(In reply to Chris Mayo from comment #1)
> Similarly on a Z68 motherboard with Asmedia ASM1042 USB 3.0. Works fine in
> the Z68 USB 2.0 port.

I experience disconnections on Lenovo IdeaPad-Z500 Touch (board name is `INVALID`, bios version `71CN45WW(V1.18)`). The disconnections occur on the USB 2.0 port, too.

I'm not sure whether the issues are related to and/or caused by btrfs errors or whether the btrfs errors are caused by the network failure (most likely because I've mounted some btrfs file images over cifs). `dmesg`

    [25266.546652] BTRFS info (device dm-0): disk space caching is enabled
    [25399.538504] CIFS VFS: Send error in Flush = -9
    [25400.281124] BTRFS: bdev /dev/mapper/image_lvm-image_lvm_01 errs: wr 0, rd 0, flush 1, corrupt 0, gen 0
    [25400.281133] BTRFS: error (device dm-0) in write_all_supers:3442: errno=-5 IO failure (errors while submitting device barriers.)
    [25400.281135] BTRFS info (device dm-0): forced readonly
    [25400.281138] BTRFS warning (device dm-0): Skipping commit of aborted transaction.
    [25400.281139] ------------[ cut here ]------------
    [25400.281168] WARNING: CPU: 3 PID: 13339 at /home/apw/COD/linux/fs/btrfs/super.c:259 __btrfs_abort_transaction+0x5f/0x130 [btrfs]()
    [25400.281181] BTRFS: Transaction aborted (error -5)
    [25400.281182] Modules linked in: ax88179_178a(OE) xfs libcrc32c usbnet md4 nls_utf8 cifs msr nls_iso8859_1 pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bbswitch(OE) btrfs xor bridge stp llc iptable_filter ip_tables x_tables raid6_pq snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec rfcomm intel_rapl arc4 snd_hwdep bnep x86_pkg_temp_thermal hid_generic nfsd intel_powerclamp uas uvcvideo hid_multitouch iwldvm snd_pcm videobuf2_vmalloc coretemp videobuf2_memops videobuf2_core kvm_intel auth_rpcgss mac80211 v4l2_common nfs_acl videodev usb_storage media snd_seq_midi kvm nfs snd_seq_midi_event snd_rawmidi snd_seq lockd usbhid binfmt_misc crct10dif_pclmul sunrpc crc32_pclmul fscache ghash_clmulni_intel snd_seq_device snd_timer hid aesni_intel iwlwifi btusb aes_x86_64 snd lrw gf128mul bluetooth glue_helper ablk_helper cfg80211 cryptd soundcore joydev 6lowpan_iphc serio_raw mei_me mei parport_pc lpc_ich ppdev ideapad_laptop lp sparse_keymap mac_hid parport zfs(POE) zunicode(POE) zavl(POE) zcommon(POE) znvpair(POE) spl(OE) i915 i2c_algo_bit drm_kms_helper psmouse ahci drm r8169 libahci mii video [last unloaded: ax88179_178a]
    [25400.281250] CPU: 3 PID: 13339 Comm: btrfs-transacti Tainted: P W OE 3.16.2-031602-generic #201409052035
    [25400.281251] Hardware name: LENOVO 20221/INVALID, BIOS 71CN45WW(V1.18) 05/10/2013
    [25400.281252] 0000000000000103 ffff8800127a3c28 ffffffff8178824b 0000000000000007
    [25400.281254] ffff8800127a3c78 ffff8800127a3c68 ffffffff8107207c ff003601127a3c98
    [25400.281268] ffff880024125800 ffff880088208460 00000000fffffffb 0000000000000623
    [25400.281270] Call Trace:
    [25400.281274] [<ffffffff8178824b>] dump_stack...

[krichter722 (krichter722-linux-kernel-bugs)]

`sudo rmmod ax88179_178a && sudo modprobe ax88179_178a` restores the original functionality of the adapter.

[krichter722 (krichter722-linux-kernel-bugs)]

I just installed generated deb files generated from 3.16.2 tarball from https://www.kernel.org/ and the issue seems to have disappeared. Usually the system crashed after minutes of network connection or after seconds under load and now it's running for half an hour with full load up or down stream.

I guess, it might be related to mainline kernel images. The size for `ax88179_178a.ko` is 36 KB in Ubuntu mailine kernels and 28 KB in build from kernel archives tarball. I simply did

    tar xf linux-3.16.2.tar.xz
    cd linux-3.16.2
    cp /boot/config-`uname -r` .config
    yes "" | make oldconfig
    make -j16
    make deb-pkg

from within a running Ubuntu mainline kernel image 3.16.2-utopic (http://kernel.ubuntu.com/~kernel-ppa/mainline/) on Ubuntu 14.04.1 (it will probably work with the latest correct mainline kernel image (with trusty-suffix) as well).

[krichter722 (krichter722-linux-kernel-bugs)]

Now it crashed again, the description mentioned above applies.

[aleksey.shipilev (aleksey.shipilev-linux-kernel-bugs)]

Same here with Asus UX32LN and Linux 3.17, the symptoms look very similar to already reported here. Under heavy file transfer, the network connection abruptly stops, and activity LED on my dongle continue blinking like mad.

Wireshark shows the adapter is sending ARP requests as it would normally do, but does not seem to receive any reply, even though the Wireshark on the other end sees the ARP replies. This seems to point to broken RX handler?

`sudo rmmod ax88179_178a && sudo modprobe ax88179_178a` helps. Nothing suspicious in dmesg at the time of failure:

[ 7508.542652] ax88179_178a 2-3:1.0 eth2: ax88179 - Link status is: 1
[ 7508.548610] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
// hang at 7600
// rmmod & modprobe around 7635
[ 7635.144630] usb 2-3: USB disconnect, device number 4
[ 7635.144851] ax88179_178a 2-3:1.0 eth2: unregister 'ax88179_178a' usb-0000:00:14.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet
[ 7635.144867] ax88179_178a 2-3:1.0 eth2: Failed to read reg index 0x0002: -19
[ 7635.144870] ax88179_178a 2-3:1.0 eth2: Failed to write reg index 0x0002: -19
[ 7635.168384] ax88179_178a 2-3:1.0 eth2 (unregistered): Failed to write reg index 0x0002: -19
[ 7635.168390] ax88179_178a 2-3:1.0 eth2 (unregistered): Failed to write reg index 0x0001: -19
[ 7635.168393] ax88179_178a 2-3:1.0 eth2 (unregistered): Failed to write reg index 0x0002: -19
[ 7636.522099] usb 2-3: new SuperSpeed USB device number 5 using xhci_hcd
[ 7636.544373] usb 2-3: New USB device found, idVendor=0b95, idProduct=1790
[ 7636.544378] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7636.544381] usb 2-3: Product: AX88179
[ 7636.544383] usb 2-3: Manufacturer: ASIX Elec. Corp.
[ 7636.544385] usb 2-3: SerialNumber: 0000000000095B
[ 7636.867736] ax88179_178a 2-3:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet, d8:eb:97:b3:50:18
[ 7637.413427] ax88179_178a 2-3:1.0 eth2: renamed from eth0
[ 7637.438314] systemd-udevd[13758]: renamed network interface eth0 to eth2
[ 7637.803412] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 7640.233013] ax88179_178a 2-3:1.0 eth2: ax88179 - Link status is: 1
[ 7640.239435] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready

[aleksey.shipilev (aleksey.shipilev-linux-kernel-bugs)]

Additional data point: the disconnect appears to occur much more frequently when the dongle is *receiving* a lot of stuff, rather than *sending*. Incoming iperf at ~850 Mbps gets the adapter stuck after 5-10s, reliably. Outgoing iperf at ~900 Mbps does not get stuck for 20 minutes now. This, again, points to bug in RX chain?

[erik.r.karlsson (erik.r.karlsson-linux-kernel-bugs)]

Created attachment 166171
3.18.6 - tcpdump trace

Recorded with: tcpdump -i eth1 -n | tee eth1.log

[erik.r.karlsson (erik.r.karlsson-linux-kernel-bugs)]

Created attachment 166181
3.18.6 - usbmon trace

recorded with:
sudo modprobe usbmon
sudo cat /sys/kernel/debug/usb/usbmon/2u | tee usb2.log

[erik.r.karlsson (erik.r.karlsson-linux-kernel-bugs)]

I have the same problems whth a Dell XPS 13 (L322X), a LevelOne USB-0401 ethernet adapter (HW ver: 4.0, chip: AX88179), Linux Mint 17.1, and kernel 3.18.6-031806-generic. I get sudden disconnects, especially under high load. I have reproduced the bug by flood pinging my router. The disconnect occured after 12 minutes of pinging.

I have attached tcmdump and usbmon traces. There it can be seen that at a certain point in time (15:49:35.595157 with tcpdump and 2303595162 with usbmon) incoming data stops arriving. That happens at the same time both at the USB level and at the network interface level.

This is the kernel log from the point of connection of the device to USB. No suspicous messages are apparent.

Feb 9 15:37:19 erik-XPS kernel: [ 1493.918410] usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd
Feb 9 15:37:19 erik-XPS kernel: [ 1493.941310] usb 2-1: New USB device found, idVendor=0b95, idProduct=1790
Feb 9 15:37:19 erik-XPS kernel: [ 1493.941314] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 9 15:37:19 erik-XPS kernel: [ 1493.941315] usb 2-1: Product: AX88179
Feb 9 15:37:19 erik-XPS kernel: [ 1493.941317] usb 2-1: Manufacturer: ASIX Elec. Corp.
Feb 9 15:37:19 erik-XPS kernel: [ 1493.941318] usb 2-1: SerialNumber: 0000116B6739BA
Feb 9 15:37:19 erik-XPS kernel: [ 1494.264241] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:11:6b:67:39:ba
Feb 9 15:37:19 erik-XPS kernel: [ 1494.286740] ax88179_178a 2-1:1.0 eth1: renamed from eth0
Feb 9 15:37:19 erik-XPS kernel: [ 1494.641674] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
Feb 9 15:37:21 erik-XPS kernel: [ 1496.477501] ax88179_178a 2-1:1.0 eth1: ax88179 - Link status is: 1
Feb 9 15:37:21 erik-XPS kernel: [ 1496.482897] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Feb 9 15:37:28 erik-XPS kernel: [ 1503.263088] device eth1 entered promiscuous mode
Feb 9 15:50:55 erik-XPS kernel: [ 2310.157519] device eth1 left promiscuous mode

[krichter722 (krichter722-linux-kernel-bugs)]

3.19 brings significant improvement which are concretely:

  * The interruptions are short and NetworkManager (0.9.8.8 on Ubuntu 14.10) manages to reconnect immediately which means effectively no interruptions except if there's a severe failure (often in conjunction of failure of all USB3.0 connected device).
  * The driver can run an extended period of time, now. I managed to transfer 2 TB from a cifs share which before seemed impossible. I didn't test with multiple connections which caused immediate failure before (as reported in https://bugzilla.kernel.org/show_bug.cgi?id=75381#c8).

Maybe [the script I wrote to force reconnecting by un- and reloading the driver][1] is of help for someone.

[1]:https://github.com/krichter722/ax88179_178a-pinger

[chris.bainbridge (chris.bainbridge-linux-kernel-bugs)]

I am still seeing this with 4.2.0-rc7+ when using bittorrent:

Aug 28 00:08:12 debian kernel: net_ratelimit: 2186 callbacks suppressed
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:12 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: net_ratelimit: 9326 callbacks suppressed
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:34 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:51 debian kernel: net_ratelimit: 16601 callbacks suppressed
Aug 28 00:08:51 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:51 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:51 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:51 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped
Aug 28 00:08:51 debian kernel: ax88179_178a 2-3.3.4.1:1.0 eth0: kevent 2 may have been dropped

[William Gathoye (wget)]

For your information, last year, I reported the bug upstream at
https://bugzilla.kernel.org/show_bug.cgi?id=75381
That bug report seems still active.
It has been also reported on the initial driver page on Github
https://github.com/FreddyXin/ax88179_178a/issues/6
Regards,

[Stéphane Gourichon (stephane-gourichon-lpad)]

Thanks William for your comment.

Reading activity following your links, there seems to be differences:

* launchpad (here): problem starts immediately, not on receiving heavy traffic. Adapter unusable in practice on USB3 (not even for moderate activity), always ok on USB2. Also, machine feels a little sluggish but no crash, kernel panic or hang observed.
* github: reports dmesg but not much detail about what's wrong
* bugzilla: "transferring a huge number of files or pretty heavy files caused kernel panic: either I had a stacktrace displayed or the computer became completely unresponsive.", USB3, sometimes USB2.

Might be a different bug?

[bugzilla.kernel.org (bugzilla.kernel.org-linux-kernel-bugs)]

Hello,

On 2014-01-16 I reported a detailed bug regarding this device (or at least a device with same USB vendor/product ID), see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269883 . Tested on different PC, USB2 (ok) and 3 (fail) ports, results are reproducible.

Then I posted to linux-usb list with cc to Freddy Xin (who introduced the driver to the list), see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269883/comments/19 .

It may or may not be the same bug, see comment there https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269883/comments/22 .

Hope this helps.

[penalvch (penalvch)]

gouri, Saucy reach EOL on July 17, 2014. For more on this please see https://wiki.ubuntu.com/Releases .

Is this reproducible in a supported release?

If so, could you please test the latest mainline kernel (4.2) and advise to the results?

[Christian Reis (kiko)]

Yes, I can confirm this bug with Precise, and with the Trusty kernel installed on Precise (so I assume it also happens with Precise). Note that previous comments indicate it also applies to Trusty.

[Stéphane Gourichon (stephane-gourichon-lpad)]

Summary: behavior is different in Wily, sometimes not working, sometimes working but fails on heavy traffic.

Done some test check booting a Asus n551 on Ubuntu 15.10 live (wily werewolf).

## First test : one-way link only?

First (sanity check / scientific control), tested integrated Ethernet port which works flawlessly.

With tested device (same Ethernet cable, cat 5e) at first try behavior seems to have improved compared with previous Ubuntu releases:
* ethernet auto-negociation is fast (like on previous kernels when it worked in USB2)
* mii-tool is fast (typical 0.05s) (like on previous kernels when it worked in USB2)
* few lines in dmesg (like on previous kernels when it worked in USB2)
* but DHCP does not complete

"tcpdump -n -i devicename" on both sides showed that packets sent by tested device are received on remote side but packets sent from remote side are not received by device (even ARP packets).

Tried reversing cable just in case, behavior is the same. Just plugging the same cable to integrated Ethernet of same machine instead of tested device, everything works.

Tested with another cable, same result.

## Subsequent tests: works then fails on heavy traffic

* Plugged the device in another USB port. Everything seemed to worked.
* Then tested again in the initial port. Worked again. Then after a moment (testing with dd anc nc), same problem (device received no packet).
* Unplugging then plugging the device -> no longer creates ethernet device enx(encodedmacaddress)
* Unplugging then plugging the device -> works again but load test using dd and nc quickly comes to the same problem.

Conclusion: behavior is different in Wiley, sometimes not working, sometimes working. Problem seems different from previous ones.

I attached part of dmesg. Promiscuous mode is when I used tcpdump.

[penalvch (penalvch)]

gouri, the latest mainline kernel is 4.3-rc6. Is this what you tested with?

[Stéphane Gourichon (stephane-gourichon-lpad)]

Hello Christopher.

Here's the reference of the kernel that booted yesterday using Xubuntu live image:

Linux version 4.2.0-16-generic (buildd@lcy01-07) (gcc version 5.2.1 20151003 (Ubuntu 5.2.1-21ubuntu2) ) #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 (Ubuntu 4.2.0-16.19-generic 4.2.3)

The aim of my previous message is to test whether Wily is affected and the answer is yes.

So, to summarize :
Ubuntu 13.10 is affected
Ubuntu 14.04 is affected
Ubuntu 15.10 is affected

[penalvch (penalvch)]

gouri, could you please test the latest upstream kernel available from the very top line at the top of the page from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D (the release names are irrelevant for testing, and please do not test the daily folder)? Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds . This will allow additional upstream developers to examine the issue.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, Y, and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the latest upstream kernel is complete, please mark this report's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Jeff Mixon (jeff-mixon)]

This issue still exists in kernel 4.5.3 FWIW.

dmesg snippet:
[35001.978557] usb 3-1: USB disconnect, device number 5
[35001.978714] ax88179_178a 3-1:1.0 eth0: unregister 'ax88179_178a' usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet
[35001.978725] ax88179_178a 3-1:1.0 eth0: Failed to read reg index 0x0002: -19
[35001.978727] ax88179_178a 3-1:1.0 eth0: Failed to write reg index 0x0002: -19
[35001.998616] ax88179_178a 3-1:1.0 eth0 (unregistered): Failed to write reg index 0x0002: -19
[35001.998620] ax88179_178a 3-1:1.0 eth0 (unregistered): Failed to write reg index 0x0001: -19
[35001.998623] ax88179_178a 3-1:1.0 eth0 (unregistered): Failed to write reg index 0x0002: -19

[William Gathoye (wget)]

Could we have news on this please? The problem is still present on 4.6.

Several disconnections. We don't have kernel panic any more, but the kernel refuses to reconnect to the device again, we need to unplug and replug manually.

Bug in upstream: https://bugzilla.kernel.org/show_bug.cgi?id=75381

[william (william-linux-kernel-bugs)]

Hi everyone.

Can we have updates on this topic? This is becoming quite blocking now as the vast majority of USB3 to Ethernet adapters are using the chipset ax88179_178a. We are now 2 years later now...

The problem is still present on 4.5 and even 4.6 but does not lead to kernel panics any more. We have still disconnections and the we need to unplug / replug the adapter manually in order to recover the connection. Also, when we are downloading at 1Gbps large files, it's likely the resulting file becomes corrupted at some point. I tried to transfer Linux distro isos, using FTP for maximum transfer rate, the iso were corrupted at the other end. Downgrading the connection bitrate or using SSH (ftp over ssh) sometimes helps, but this is not always the case.

[11597.425991] ax88179_178a 4-2:1.0 enp0s20u2: ax88179 - Link status is: 1
[11597.432683] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u2: link becomes ready
[16742.696384] usb 4-2: USB disconnect, device number 2
[16742.696488] ax88179_178a 4-2:1.0 enp0s20u2: unregister 'ax88179_178a' usb-0000:00:14.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet
[16742.696516] ax88179_178a 4-2:1.0 enp0s20u2: Failed to read reg index 0x0002: -19
[16742.696519] ax88179_178a 4-2:1.0 enp0s20u2: Failed to write reg index 0x0002: -19
[16742.713088] ax88179_178a 4-2:1.0 enp0s20u2 (unregistered): Failed to write reg index 0x0002: -19
[16742.713093] ax88179_178a 4-2:1.0 enp0s20u2 (unregistered): Failed to write reg index 0x0001: -19
[16742.713112] ax88179_178a 4-2:1.0 enp0s20u2 (unregistered): Failed to write reg index 0x0002: -19
[16744.796619] usb 4-2: new SuperSpeed USB device number 4 using xhci_hcd
[16745.144022] ax88179_178a 4-2:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:24:9b:07:36:81
[16745.189310] ax88179_178a 4-2:1.0 enp0s20u2: renamed from eth0
[16745.215327] IPv6: ADDRCONF(NETDEV_UP): enp0s20u2: link is not ready
[16745.536542] IPv6: ADDRCONF(NETDEV_UP): enp0s20u2: link is not ready
[16748.586260] ax88179_178a 4-2:1.0 enp0s20u2: ax88179 - Link status is: 1
[16748.591156] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u2: link becomes ready
[17046.546101] perf interrupt took too long (5006 > 4960), lowering kernel.perf_event_max_sample_rate to 25200

[pereze (pereze)]

Same problem running on Ubuntu Xenial Xerus 16.04.1 LTS on kernel 4.4.0-31
USB 3.0 ethernet Orico UTR3 (same chipset AX88179) and same bug/error.
Can reproduce it and upload any bug, log or trace report if needed.

The latest driver provided from ASIX for its USB 3.0 to Gigabit Ethernet controller chipset AX88179
http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112
is this:
www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.14.4_SOURCE.zip
Version: 1.14.0
srcversion: D095DEC763882D224F9E43A
Manually compiled/installed does not solve the problem.
Neither using latest kernel available 4.6.4

Ready to help, upload, fill-in report or debug if needed.
Thanks,

[pereze (pereze)]

What is needed to change the status from: incomplete to: confirmed?
Is the list of package affected correct?
It is assigned this bug? Does anyone read or follow this?

I'll be glad to collaborate and help as much as possible
Thanks,

[Stéphane Gourichon (stephane-gourichon-lpad)]

@pereze Thank you for reporting.

> What is needed to change the status from: incomplete to: confirmed?

AFAIK, what is needed is to answer question in comment 26 by @penalvch, which was:

> gouri, the latest mainline kernel is 4.3-rc6. Is this what you tested with?

According to http://kernel.ubuntu.com/~kernel-ppa/mainline/ latest mainline (stable) kernel is 4.6.4.

@pereze wrote:

> Manually compiled/installed does not solve the problem.
> Neither using latest kernel available 4.6.4

I believe that this is the mainline kernel, so I think the conditions are satisfied to add tag "kernel-bug-exists-upstream".

[penalvch (penalvch)]

gouri, it is best if you test it with your hardware personally. Otherwise, it's not a guarantee your problem will be addressed.

[Stéphane Gourichon (stephane-gourichon-lpad)]

@penalvch thank you for your comment. In theory it might indeed be a different problem.
I practice I cannot test is myself again at the moment, and the information given by @pereze seems convincing enough, as far as I understand.

@pereze, you wrote:

> Can reproduce it and upload any bug, log or trace report if needed.

Can you post relevant parts of dmesg?

Thanks.

[William Gathoye (wget)]

Hi guys. Great to hear some news about this blocking issue (for my use case).

Like explained in comment 21 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269883/comments/21)

I reported the bug upstream on the kernel bugzilla instance
https://bugzilla.kernel.org/show_bug.cgi?id=75381

I also reported the bug on the initial driver page on Github
https://github.com/FreddyXin/ax88179_178a/issues/6

I think federating around the bug on kernel.org would be best for everyone.

[William Gathoye (wget)]

This bug is by far really complete, if I take into acount info posted upstream.

[peci1 (peci1-linux-kernel-bugs)]

I also suffer from this error on kernel 4.4. But I've seen the asix driver version distributed with 4.7 stable kernel is still from year 2011. Why don't we update the driver to a newer version provided by the manufacturer?

http://www.asix.com.tw/FrootAttach/driver/AX88772C_772B_772A_760_772_178_LINUX_DRIVER_v4.18.1_Source.tar.gz

[william (william-linux-kernel-bugs)]

Thanks Martin. The driver version you mentioned is for AX88772C and onwards AFAIK, not AX88179. But I think the issues are the same. The in tree ASIX drivers might not have been updated for ages.

AX88179: http://www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.14.4_SOURCE.zip

Comparing the file ax88179_178a.c from the zip and the one from the kernel, there are huge differences in them.

The last update brought to that file in kernel tree dates back from 2014-10-20.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/usb/ax88179_178a.c

Btw, I realized there was a community package which brings an up to date version of the driver for my GNU Linux distribution (Arch Linux). Gonna test that one if things changes.
https://aur.archlinux.org/packages/asix-ax88179-dkms/

[matthieupepin (matthieupepin-linux-kernel-bugs)]

I have the same issue with a plugable brand USB3 gigabit adapter with the AX88719 chipset. I can make it crash in a few seconds by receiving a 1080P H264 stream via UDP. My laptop is a Dell XPS 13 9350 (Skylake, 2016 version).

[qfulsher (qfulsher-linux-kernel-bugs)]

We are having the same issue with a cluster of Odroid UX3 boards which are part of a research project. The error appears when we put the network under load through an intensive MPI program. In this case we are using Ethernet as interconnects for the boards in the cluster. We've attempted compiling and loading the newest available driver for the ax88179 chip (v1.16.0) which we found here:

http://www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.16.0_SOURCE.tar.bz2

Rerunning the program shows that the bug is still present in the newest driver. We have some people on the team who have experience hacking the kernel and are seeing if they can find any clues about what is causing this error.

[bugzilla.kernel.org (bugzilla.kernel.org-linux-kernel-bugs)]

Hello Quentin.

From http://www.hardkernel.com/main/products/prdt_info.php?g_code=g140448267127 I see that Odroid UX3 has one USB3 and 4 USB2 ports. Which one do you use?
Can you try the other option and tell about any observed difference in behavior?

This information would help to clarify if we've got one or two different bugs. Some people report trouble only on high network load, while another case is trouble with USB3 at all times (details about what to look for in dmesg log are in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269883 ).

[qfulsher (qfulsher-linux-kernel-bugs)]

Hi Stéphane,

We have been using the ethernet adaptors with the USB 3.0 ports under light loads (SSH and/or SCP) and it seems to be working fine. We are only seeing issues when putting them under heavy load during the MPI program. We can try switching to USB 2.0 ports and see if that changes any behaviour.

[cinder (cinder-linux-kernel-bugs)]

Hello, I am experiencing this using an Azulle Byte Plus device which has this chipset onboard running kernel 4.17.17.

[ 10.641645] ax88179_178a 1-3.4:1.0 eth0: Failed to write reg index 0x000d: -71
[ 10.641724] ax88179_178a 1-3.4:1.0 eth0: Failed to write reg index 0x000e: -71
[ 10.641802] ax88179_178a 1-3.4:1.0 eth0: Failed to write reg index 0x000d: -71
[ 10.641883] ax88179_178a 1-3.4:1.0 eth0: Failed to write reg index 0x000e: -71
[ 10.641964] ax88179_178a 1-3.4:1.0 eth0: Failed to read reg index 0x0000: -71
[ 10.642015] ax88179_178a 1-3.4:1.0 eth0: Failed to write reg index 0x0000: -71
[ 10.642160] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

I am wondering if anybody is working on this or if there is any additional information not available here or one of the other linked bug reports. I would like to attempt to fix the issue, but if there is any additional information, it would save me time to have that. I also don't want to step on anybody's toes if they're already looking into it.

[william (william-linux-kernel-bugs)]

Hi Cinder,

Thanks for your interest. Monitoring this thread and the aforementioned links as well, I can confirm to you it seems indeed there is unfortunately nobody working on a fix at the moment.

On my side, since I couldn't invest more time in it, I switched to a RTL8153 which didn't suffer on these reliability problem but suffers a bitrate problem (we are more likely to the 125 Mbps rather than to the advertised 1 Gbps, but that's another story).

I'm maintaining the DKMS linux out-of-tree package for ax88179_178a on Arch Linux and I have realized I don't have issues any more printed on dmesg, but the dongle is still not stable, I'm unable to perform a scp or rsync properly without the application layer from lagging then unexpectedly crashing.

So my idea was maybe to rebase the kernel code to the latest one provided by ASIX and find out the issue.

If you need additional pieces of information since I own dongle devices, I would be glad to help! :)

NB: Please not I don't have a custom kernel any more, only default Arch Linux one 4.18.3 at the moment).

[cinder (cinder-linux-kernel-bugs)]

Thanks for confirming. I did try building the driver available from ASIX last night, it didn't seem to fare any better. I think comparing the two versions is a good idea though.

Unfortunately, since this is an onboard LAN, I don't have much of an option to swap it out. (I actually bought a dongle just to check if the hardware was bad, but as luck would have it the dongle uses the very same chipset as the mainboard with the same results.)

I will update as I work on this.

[bugzilla.kernel.org (bugzilla.kernel.org-linux-kernel-bugs)]

Quentin wrote:

> We can try switching to USB 2.0 ports and see if that changes any behaviour.

Hi Quentin.

It's been a while. Did you try switching to USB 2.0 ports? Please share any relevant information.

[qfulsher (qfulsher-linux-kernel-bugs)]

Its been a while, I looked into it for an electrical engineering friend. I cant remember exactly what the workaround was.

I believe he switched to using USB 2.0 ports. He also might have used a different USB 3.0 adapter.

[matthieupepin (matthieupepin-linux-kernel-bugs)]

Still an issue in 4.18.9... However, I have 2 different USB3 adapters with the same chipset. One is the Plugable USB3-E1000 (which has the problem within a second when running iperf). The other one is a cheap Amazon Basics USB3 Gigabit Ethernet Adapter which runs perfectly fine. Both use the same driver. I don't have any USB2 ports on my Dell laptop so I can't test if USB2 is OK.

[cinder (cinder-linux-kernel-bugs)]

Matthieu, can you e-mail me a link to the Amazon branded adapter that works? <email address hidden> I'd like to pick one up for testing.

[matthieupepin (matthieupepin-linux-kernel-bugs)]

Sure, I bought this one:

http://a.co/d/cZbYwot

[cinder (cinder-linux-kernel-bugs)]

Interesting. I do have this device. The last I tested (on 4.17.17), it reproduced the issue, albeit not immediately. I will have to give it another try when I get back to my test machine with a newer kernel.

[Marc H. (makedir)]

Just found by Google search to this post. I have the same issue on Windows 10 with a AX88179 adapter. The adapter randomly crashes / driver crashes under heavy load or the bandwidth suddenly drops down from 500mbit/s to around 3mbit/s. You can see the issue happening here:

https://i.imgur.com/TtWRpAE.gif

So it doesnt seem to be a Linux only issue at all. I am using the latest driver on Windows by Asix 1.20.7.0 which doesnt do anything for this issue.

[Marc H. (makedir)]

Maybe the issue is heat, and the chip slows down of it overheats, and some manufacturers did not include a heatsink on it, some did.