Compile errors with kernel 5.16.10 // Getting your imrovements upstream into the Linux kernel

[frittentheke]

Thanks for looking into the apparent stability issues of the ASIX AX88179 chipset ...

• https://bugzilla.kernel.org/show_bug.cgi?id=212731
• https://bugzilla.kernel.org/show_bug.cgi?id=197971

When building your patch on Arch Linux running linux kernel 5.16 I run into these errors:

make
make -C /lib/modules/5.16.10-arch1-1/build M=/tmp/AX88179_178A_Linux_Driver/source modules
make[1]: Entering directory '/usr/lib/modules/5.16.10-arch1-1/build'
  CC [M]  /tmp/AX88179_178A_Linux_Driver/source/ax88179_178a.o
/tmp/AX88179_178A_Linux_Driver/source/ax88179_178a.c:1040:35: error: ‘usbnet_get_stats64’ undeclared here (not in a function); did you mean ‘usbnet_cdc_status’?
 1040 |         .ndo_get_stats64        = usbnet_get_stats64,
      |                                   ^~~~~~~~~~~~~~~~~~
      |                                   usbnet_cdc_status
/tmp/AX88179_178A_Linux_Driver/source/ax88179_178a.c: In function ‘ax88179_link_reset’:
/tmp/AX88179_178A_Linux_Driver/source/ax88179_178a.c:2085:55: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
 2085 |                 netdev_info(dev->net, "rx_urb_size = %u KB, hard_mtu = %u\n", dev->rx_urb_size >> 10, dev->hard_mtu);
      |                                                      ~^                       ~~~~~~~~~~~~~~~~~~~~~~
      |                                                       |                                        |
      |                                                       unsigned int                             size_t {aka long unsigned int}
      |                                                      %lu
make[2]: *** [scripts/Makefile.build:287: /tmp/AX88179_178A_Linux_Driver/source/ax88179_178a.o] Error 1
make[1]: *** [Makefile:1846: /tmp/AX88179_178A_Linux_Driver/source] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.16.10-arch1-1/build'
make: *** [Makefile:30: default] Error 2

There recently have been some changes for to this driver for 5.17 (https://github.com/torvalds/linux/commit/57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581).

Maybe you could add to those efforts to finally get this adapter working stable without any patches to the module.

[frittentheke]

@nothingstopsme may I nag you again about maybe getting your fixes upstream? As mentioned there is an issue being actively discussed in the Kernel bug tracker at https://bugzilla.kernel.org/show_bug.cgi?id=212731 to which your changes might be a fix?

Unfortunately your source does not build with more recent kernels anymore - I am now running 5.18 on Arch Linux.

[nothingstopsme]

@frittentheke Hi, thank you for being interested in this work and giving suggestions.

It looks like my fix could help the issue you mentioned; however I am not sure if my current fix has solved all the unstability problems of this driver; in my use case I have still observed some rare disconnection (LED on, interface present, but no packet transmission) under heavy outgoing loading. Further investigation is required to determine whether it is related to the driver.

As to the upstreaming, before being able to do that I think I'd better port the fix logic into the driver source contained in kernel rather than adapting this implementation, as the one from kernel seems to have been refactored a lot compared with the vendor one on which this project is based. That porting should be a matter of time, though I am struggling to spare some on it, so sorry for the slow progress.

[frittentheke]

Thanks @nothingstopsme for your positive response - with the current unstable state of things any improvement would be good!

[wagnerck]

For folks who want to compile this source on modern kernels, the fix is pretty simple. Edit ax88179_178a.c and replace this:

usbnet_get_stats64

with this:

dev_get_tstats64

After doing this, you can run make and it'll build and load (using insmod or whatever) on kernels 5.18 and 5.19. This also works on the unmodified source from ASIX (https://www.asix.com.tw/en/support/download). It will probably make the source stop compiling on older kernels, though, and changing the #if directives to do this correctly would require figuring out which kernel update made this change, and I don't really have the time to spend on that.

I don't know if this will actually resolve the problem for users experiencing the bugs mentioned previously in this thread, but it might be worth a shot.

[Schlaefer]

Just chiming in trying to get an ax adapter stable on a Raspi (Raspberry Pi OS ARM 32 bi armv6l, Linux 5.15). The change suggested by @wagnerck made the code compile :+1:, but the whole network stack stops working as long as the module is loaded. Dmesg:

[   32.027048] ax88179_178a: loading out-of-tree module taints kernel.
[   32.390749] ax88179_178a 1-1:2.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0000: -32
[   32.422486] ax88179_178a 1-1:2.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0002: -32
[   32.442384] ax88179_178a 1-1:2.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0002: -32
[   32.702568] ax88179_178a 1-1:2.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0001: -32
[   32.862504] ax88179_178a 1-1:2.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x0001: -32
[   32.862690] ax88179_178a: probe of 1-1:2.0 failed with error -32
[   32.951036] ax88179_178a 1-1:2.1 (unnamed net_device) (uninitialized): Failed to write reg index 0x0000: -32
[   32.961349] ax88179_178a 1-1:2.1 (unnamed net_device) (uninitialized): Failed to write reg index 0x0002: -32
[   33.012399] ax88179_178a 1-1:2.1 (unnamed net_device) (uninitialized): Failed to write reg index 0x0002: -32
[   33.262412] ax88179_178a 1-1:2.1 (unnamed net_device) (uninitialized): Failed to write reg index 0x0001: -32
[   33.422461] ax88179_178a 1-1:2.1 (unnamed net_device) (uninitialized): Failed to read reg index 0x0001: -32
[   33.422626] ax88179_178a: probe of 1-1:2.1 failed with error -32
[   33.423031] usbcore: registered new interface driver ax88179_178a
[   33.656583] usbcore: registered new interface driver cdc_ether
[   34.528009] ERROR::dwc_otg_hcd_urb_enqueue:501: Not connected
[   34.528092] ERROR::dwc_otg_hcd_urb_enqueue:501: Not connected
[   34.528261] ERROR::dwc_otg_hcd_urb_enqueue:501: Not connected
[   34.528443] cdc_ncm 1-1:2.0: bind() failure
[   34.528805] usbcore: registered new interface driver cdc_ncm
[   34.552790] usb 1-1: USB disconnect, device number 2
[   34.832027] usbcore: registered new interface driver cdc_wdm
[   35.252572] Indeed it is in host mode hprt0 = 00021501
[   35.321510] usbcore: registered new interface driver cdc_mbim
[   35.612363] usb 1-1: new high-speed USB device number 3 using dwc_otg
[   35.626548] Indeed it is in host mode hprt0 = 00001101
[   35.812600] cam-dummy-reg: disabling
[   36.141607] usb 1-1: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00
[   36.141711] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   36.141748] usb 1-1: Product: AX88179A
[   36.141776] usb 1-1: Manufacturer: ASIX
[   36.141826] usb 1-1: SerialNumber: 00000000000EE1
[   36.701114] Found invalid EEPROM MAC address value 
[   36.701164] FF
[   36.701217] -
[   36.701234] FF
[   36.701253] -
[   36.701267] FF
[   36.701283] -
[   36.701293] FF
[   36.701330] -
[   36.701346] FF
[   36.701364] -
[   36.701377] FF

The dongle shows up as ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet.

It also seems that there is a new, significantly rewritten ASIX driver from July designated 1.0.0 which compiles unmodified but also drops connection regularly.

[nothingstopsme]

Hi all, just to give you a quick update:

1. The latest commit to the "main" branch has included @wagnerck 's workaround (cheers, mate), as well as some new tweaks. It should be able to built successfully against both old and modern kernels.
2. A new branch named "porting" has been created, with the driver source from kernel upto this commit as its code base to which the fixes provided in "main" are ported. If you find the vendor's version (from "main" branch) does not work on your platform running a super new kernel, you might try this version.
3. Please be mindful that the differences between the source from kernel and the one from vendor are more than just due to refactoring, as I do spot a feature (tx dma) that is available in one but not in the other. The "porting" branch is only focused on the fixes from this project and will not touch on anything beyond.

Finally and as a side note, I have also found a patch to kernel that has already implemented a fix similar to the one offered here targeting rx, and it has been included in 5.19 and other later versions. If your linux distribution is built upon one of those kernels, I believe (hopefully) you will have already seen some stability gain (at least in terms of rx errors) using the built-in driver module.

[spxak1]

@nothingstopsme Thanks for your your work and input. I have added my comment in this kernel bug report.

I use 5.19.11 and 5.19.12 in Fedora, 5.19.0 on Pop, and the disconnections are still there. Compiling your driver and using that works fine (downloading at least, but I'll check uploading after your related comment).

So just to add, still no fix in 5.19.

Again, many thanks for this.

[lesandie]

Hey! just to thank you @nothingstopsme ... I can confirm this works on ubuntu with 5.19 kernel. Module compiles perfectly. And as @spxak1 commented, still this is not fixed in 5.19 mainline what a bummer.

[nothingstopsme]

You are very welcome, @spxak1 and @lesandie.

Just so you know, the upstream patches summarising the fixes made in this project had been sent out a while ago, and I also tried to ping the kernel team yesterday to check the progress. Unfortunately, I have not received any feedback/comments on the patches themselves yet; I don't even know whether the reviewing has started or not.

So I guess you might need to wait quite some time to see those patches get included in the kernel, if they can eventually survive the reviewing process.

[lesandie]

I'm happy with this. BTW the tx_dma_s works nicely too.