Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#53375 - [linux] USB ethernet driver deadlocks network configuration (ip, iw, ifconfig, modprobe etc.)

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Sunday, 19 March 2017, 19:51 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 20 March 2017, 18:21 GMT
Task Type Bug Report
Category Kernel
Status Assigned
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No



I have been using the following ethernet adapter for ages without issues:
asix 1-6:1.0 eth1: register 'asix' at usb-0000:00:1a.7-6, ASIX AX88772 USB 2.0 Ethernet, 00:80:c8:3c:a2:04
After a recent upgrade from 4.4 to 4.10 kernels, it deadlocks my entire networking stack. Symptoms are the following:

* There is a frozen 'ip link set eth1 up' process (in a 'D' (defunct) state) started by netcfg. It stays around forever.
* All subsequent systemd units that deal with network freeze forever (i.e., the system won't even boot).
* modprobe or modprobe -r on network modules freezes forever and stays in a 'D' state; that includes virtual devices (tap, sit).
* ip freezes, iw freezes, ifconfig freezes (with or without parameters) -- all end up in a 'D' state forever.
* Even virtual network devices can't be set up (e.g. tap, sit etc.), tools freeze on those that already exist.

When I disable the asix-based network adapter, so that no attempts are made to bring it up, and/or leave it unplugged, everything works flawlessly.

The problem occurs with *both* the stock distro kernel and with my custom kernel. Exactly the same symptoms.

Additional info:
* package version(s)

linux 4.10.3-1
custom Linux 4.10.4 <-- Also tested with this; got exactly the same failure.
netcfg 3.2-1 <-- Likely irrelevant; running ip, iw, ifconfig manually causes the same issue.

* config and/or log files etc.

I'm attaching the relevant part of dmesg on a 4.10.3 stock Arch kernel. It shows quite a number of blocked processes. The backtrace that contains the 'asix' keyword might be the most interesting one.

Steps to reproduce:

Try to use an asix-driven USB ethernet adapter.


Don't use the USB network adapter. Without it, all my ethernet, hostapd-based WiFi, sit and tap interfaces work perfectly and nothing ever blocks.
This task depends upon

Comment by mattia (nTia89) - Wednesday, 04 October 2017, 16:36 GMT
could be an hardware problem of that USB adapter?
Comment by Angus Gratton (projectgus) - Friday, 16 March 2018, 06:10 GMT
I ran into the exactly the same symptoms today. I have two asix-based adapters (different models, one is probably an Asix ASIC clone the other is genuine). Both exhibit this behaviour.

I can reproduce every time by trying to run "ip link set eth0 up", which hangs (and breaks other parts of the system) in the same way that you describe.

Happens for me:
* On stock Arch kernel & also linux-zen kernels 4.15.9 and 4.14.14 (didn't try anything earlier).
* Even with all network management services stopped (I was using connman but disabled this and rebooted, same experience.)
* With all other USB devices disconnected.
* Without logging into a desktop environment (booted to lightdm login prompt, switched to a virtual terminal, logged in, reproduced.)
* With predictable interface names enabled (I noticed you also had these disabled, but after reenabling the same problem.)

The only way I could make it work is booting with "init=/bin/bash" on the kernel command line, then running "modprobe asix; ip link set eth0 up"...

Extremely weird thing, both these adapters have worked reliably on this system previously (although never used for extended periods). But they even worked earlier today with the exact same software installation.

I saw this discussion about inconsistent lock warnings on LKML. . I don't see the lock warnings in dmesg, but maybe we are triggering this deadlock?