Upgrading a machine to Core Update 162, I noticed after rebooting the Asix Electronics AX88772C USB-to-LAN adaptor (whitelabeld by "Edimax") was no longer usable: The device comes up and is being initialised, but does not handle any traffic anymore. Dec 23 11:09:16 firewall kernel: usb 2-5: new high-speed USB device number 4 using xhci_hcd Dec 23 11:09:16 firewall kernel: usb 2-5: New USB device found, idVendor=0b95, idProduct=772b, bcdDevice= 0.01 Dec 23 11:09:16 firewall kernel: usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 23 11:09:16 firewall kernel: usb 2-5: Product: AX88772B Dec 23 11:09:16 firewall kernel: usb 2-5: Manufacturer: ASIX Elec. Corp. Dec 23 11:09:16 firewall kernel: usb 2-5: SerialNumber: 26C4D7 Dec 23 11:09:16 firewall kernel: libphy: Asix MDIO Bus: probed Dec 23 11:09:16 firewall kernel: Asix Electronics AX88772C usb-002:004:10: attached PHY driver (mii_bus:phy_addr=usb-002:004:10, irq=POLL) Dec 23 11:09:16 firewall kernel: asix 2-5:1.0 eth0: register 'asix' at usb-0000:00:14.0-5, ASIX AX88772B USB 2.0 Ethernet, x Dec 23 11:09:16 firewall kernel: asix 2-5:1.0 blue0: renamed from eth0 Dec 23 11:09:16 firewall codel: Codel AQM has been enabled on 'blue0'. Dec 23 11:09:20 firewall vnstatd[1646]: Interface "blue0" enabled. Aside from that, no other anomalies show up in the logs. Unplugging the adapter, these messages are logged: Dec 23 11:26:02 firewall dhcpd: receive_packet failed on blue0: Network is down Dec 23 11:26:02 firewall charon: 06[KNL] interface blue0 deactivated Dec 23 11:26:02 firewall kernel: usb 2-1: USB disconnect, device number 2 Dec 23 11:26:02 firewall kernel: asix 2-1:1.0 blue0: unregister 'asix' usb-0000:00:14.0-1, ASIX AX88772B USB 2.0 Ethernet Dec 23 11:26:02 firewall kernel: asix 2-1:1.0 blue0: Failed to write reg index 0x0000: -19 Dec 23 11:26:02 firewall kernel: asix 2-1:1.0 blue0: Failed to enable software MII access Dec 23 11:26:02 firewall kernel: asix 2-1:1.0 blue0: Failed to write reg index 0x0000: -19 Dec 23 11:26:02 firewall kernel: asix 2-1:1.0 blue0: Failed to enable software MII access This is a regression probably introduced in Linux 5.15.x, or our configuration of it. Please let me know if there is anything I should provide as well (if necessary, I can mail you the adapter itself).
The same effect is reproducible with a Asix Electronics AX88772B USB-to-LAN adapter as well. A MosChip USB-to-LAN adapter continues to work fine.
Have you already found a patch somewhere? My Asix AX88772 (0b95:7720) works as usual on i686. I will search my stock for a AX88772B or C.
Hi Arne, while testing this further, I found both the ASIX adapters were working fine on my testing machine. Also, a MosChip-based adapter is not recognised on the affected machine either - while the very same device works fine on my testing machine, too. Therefore, I believe the problem is not related to the USB-to-LAN adapter, but to some changes in kernel 5.15.x that cause USB-to-LAN adapters not to work properly anymore on that board. It's Fireinfo profile is: https://fireinfo.ipfire.org/profile/7fcc7f0644fd90afc1e93ae39dd66f09a820fbc5 I will provide relevant messages of /var/log/bootlog tomorrow - is there anything specific you need as well? Thanks, and best regards, Peter Müller
While investigating I found these differences in /var/log/bootlog between kernel 5.10.x and 5.15.x: - usb 2-5: New USB device found, idVendor=0b95, idProduct=772b, bcdDevice= 0.01 - usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 - usb 2-5: Product: AX88772B - usb 2-5: Manufacturer: ASIX Elec. Corp. - usb 2-5: SerialNumber: 26C4D7 + usb 2-1: New USB device found, idVendor=0b95, idProduct=772b, bcdDevice= 0.01 + usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + usb 2-1: Product: AX88772B + usb 2-1: Manufacturer: ASIX Elec. Corp. + usb 2-1: SerialNumber: 0035B9 - asix 2-5:1.0 eth0: register 'asix' at usb-0000:00:14.0-5, ASIX AX88772B USB 2.0 Ethernet, 00:50:b6:26:c4:d7 + asix 2-1:1.0 eth0: register 'asix' at usb-0000:00:14.0-1, ASIX AX88772B USB 2.0 Ethernet, 00:00:00:00:35:b9 => The MAC address and S/N of the device changed. Does this make any sense to you?
https://lore.kernel.org/stable/20211126122340.1193239-2-mathias.nyman@linux.intel.com/ sounds somehow related to this issue, but here, the adapter just silently does nothing, without triggering any log messages.
What about this? https://lore.kernel.org/all/20211220143044.382652365@linuxfoundation.org/
I have tested some adapters on the IPFire Duo and they works normally. MosChip 100mBit, an Asix USB3 Gigabit and a Realtek. I still have not find a ASIX AX88772B in my collection yet.
As upcoming Core Update 164 ships a new kernel, I am bumping this to MODIFIED, as I am pretty sure the problem has been fixed upstream meanwhile...
https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing
I had similar scenario with USB->LAN adapter when upgrading 161 to 163. I appended my notes to the community site under heading of 'Update 158 –> to 161 problems with USB Ethernet Adpater'. Turns out the USB->LAN adapter was constantly sending (per WireShark descript) PROTOCOL='MAC CTRL', DEST='Spanning-tree-(for-bridges)_01', INFO='Pause: pause_time: 0 quanta', and INFO='Pause: pause_time: 65535 quanta'
Last time I had the opportunity to check, Core Update 164 did not make any difference; the USB-to-LAN adapter was still unusable. Since kernel 5.15.35 might fix contain a fix for that, I am not giving up my hopes yet, leaving this on ON_QA unless I am able to insect that IPFire machine again.
Resetting back to ASSIGNED, since the problem has not been resolved. https://community.ipfire.org/t/2nd-usb-ethernet-adapter-not-recognized-after-reboot-unless-replugged/8142 looks related.
https://patchwork.ipfire.org/project/ipfire/patch/4d8360ae-829c-5fcc-9ed7-8e3d5875ea0b@ipfire.org/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=e155e2f99938555576b25b1be4a31a3c0a492ae4 However, Arne mentioned to me on the phone the other day that this patch is unlikely to solve the observed problem.
https://blog.ipfire.org/post/ipfire-2-27-core-update-175-is-available-for-testing