hardkernel / linux

Linux kernel source tree
Other
427 stars 407 forks source link

ASIX AX88179 gigabit ethernet stops working after a while/under load #75

Closed TimJay closed 8 years ago

TimJay commented 9 years ago

I'm using a Plugable USB3-HUB3ME Gigabit Ethernet Adapter with 3 Port USB 3.0 Hub which is build around the ASIX AX88179 and VIA VL812 chipsets. While the harddrive works well on the USB 3.0 hub, the gigabit ethernet regularly stops working after a short while or under bigger load. There are no related messages in /var/log/syslog but when I un-plug and re-plug the ethernet cable after the network stopped working, I get the following messages:

Jan 16 22:49:36 * kernel: [ 1755.845627] [c0] ax88179_178a 4-1.1:1.0 eth2: ax88179 - Link status is: 0 Jan 16 22:49:39 * kernel: [ 1758.405614] [c0] ax88179_178a 4-1.1:1.0 eth2: ax88179 - Link status is: 1

Some basic functionality seems to be still available. But it does not reconnect.

I ran the odroid utility to update kernel, firmware, etc. but no change. At the same time the built-in ethernet works fine.

mdrjr commented 9 years ago

And that would be what board? what branch? Sorry but my crystal ball is out of batteries today

TimJay commented 9 years ago

Here fetch: throws two AA batteries The grey mist in the crystal ball slowly dissolves and magically a XU3 REV0.2 20140529 appears.

thebigb commented 9 years ago

Same here.

I can reliably make the USB ethernet controller disappear by running a simple iperf with a gigabit port on the remote side. The interesting thing is that it doesn't produce any debugging or error messages. The device simply appears to stop responding and even when reinserted fails to start. One interesting thing is that the data LED on the ethernet port keeps flashing rapidly when this occurs.

I tested the same controller on a desktop system (with USB 3.0 support) where I did not have issues (I didn't take note of the kernel version; it was running on 64-bit though).

This is with the odroidxu3-3.10.y branch of a little more than a week ago.

lsusb -t:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 5000M
        |__ Port 4: Dev 3, If 0, Class=vend., Driver=ax88179_178a, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
        |__ Port 4: Dev 4, If 0, Class=HID, Driver=usbhid, 12M
        |__ Port 4: Dev 4, If 1, Class=HID, Driver=usbhid, 12M
        |__ Port 4: Dev 4, If 2, Class=HID, Driver=usbhid, 12M

lsusb -v: http://pastebin.com/vpeQd7qL

I will check for the kernel version and ax88179_178a module version on the desktop system, and I'll report back.

I was also going to try and get a newer kernel version running, but I'm not sure how much work that will be. Wish me luck, guys XD

thebigb commented 9 years ago

Okay, quick update, the kernel version of the desktop system is:

Linux partedmagic 3.8.13-pmagic64 #1 SMP PREEMPT Mon May 20 10:47:21 CDT 2013

And I can find no trace of the ax88179_178a driver on that system, so either it was built with the kernel or it is hiding somewhere.

thebigb commented 9 years ago

I've managed to install abjiheet's kernel (kernel version 3.17.0-rc3+), and the does not occur there.

I get ~500Mbit/500Mbit throughput, which isn't the full gigabit, but at least it doesn't freeze up.

scotte commented 9 years ago

I've had this same problem with this ASIX adapter on other systems (not an odroid) running Debian Jessie with the stock 3.16 kernel. I was able to reproduce it using the driver from the running kernel, as well as the 1.14.1 driver directly from ASIX.

ASIX recently released a 1.14.2 driver and I could not make the problem happen with it, although that wasn't exactly the same circumstances where I was able to reproduce it previously. I also could no longer find the 1.14.1 driver anywhere to compare what was different, unfortunately. It seems possible that the in-kernel driver somewhere around 3.17+ incorporates a fix.

This seems to be a pretty common problem with the ASIX ax88179 adapter.

tobetter commented 9 years ago

I've looked 1.14.2 driver and couldn't find effective point to improve its function. The current driver version is "1.13.0" and updated couple of mounts. Since this issue is very old, half year :), and no report any more, seem the issue would be resolved with "1.13.0"

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e59d175..c4b12bc 100755
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -48,11 +48,11 @@

 #include "ax88179_178a.h"

-#define DRV_VERSION    "1.13.0"
+#define DRV_VERSION    "1.14.2"

 static char version[] =
 KERN_INFO "ASIX USB Ethernet Adapter:v" DRV_VERSION
-       " " __TIME__ " " __DATE__ "\n"
+//     " " __TIME__ " " __DATE__ "\n"
 "              http://www.asix.com.tw\n";

 static int msg_enable;
@@ -1280,7 +1280,11 @@ static int access_eeprom_mac(struct usbnet *dev, u8 *buf, u8 offset, bool wflag)

        if (!wflag) {
                if (ret < 0) {
-                       netdev_dbg(dev->net, "Failed to read MAC address from EEPROM: %d\n", ret);
+                       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 34)
+                               netdev_dbg(dev->net, "Failed to read MAC address from EEPROM: %d\n", ret);
+                       #else
+                               devdbg(dev, "Failed to read MAC address from EEPROM: %d\n", ret);
+                       #endif
                        return ret;
                }
                memcpy(dev->net->dev_addr, buf, ETH_ALEN);
@@ -1299,10 +1303,12 @@ static int ax88179_check_ether_addr(struct usbnet *dev)
 {
        unsigned char *tmp = (unsigned char*)dev->net->dev_addr;
        u8 default_mac[6] = {0, 0x0e, 0xc6, 0x81, 0x79, 0x01};
+       u8 default_mac_178a[6] = {0, 0x0e, 0xc6, 0x81, 0x78, 0x01};

        if (((*((u8*)tmp) == 0) && (*((u8*)tmp + 1) == 0) && (*((u8*)tmp + 2) == 0)) ||
            !is_valid_ether_addr((u8*)tmp) ||
-           !memcmp(dev->net->dev_addr, default_mac, ETH_ALEN)) {
+           !memcmp(dev->net->dev_addr, default_mac, ETH_ALEN) ||
+           !memcmp(dev->net->dev_addr, default_mac_178a, ETH_ALEN)) {
                int i;

                printk("Found invalid EEPROM MAC address value ");
@@ -1316,7 +1322,9 @@ static int ax88179_check_ether_addr(struct usbnet *dev)
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 4, 0)
                eth_hw_addr_random(dev->net);
 #else
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 36)
                dev->net->addr_assign_type |= NET_ADDR_RANDOM;
+#endif
                random_ether_addr(dev->net->dev_addr); 
 #endif
                *tmp = 0;