r8152 driver no longer releases USB NIC for VM passthrough

Bug #1988504 reported by Rolf Kutz
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

I run a KVM-VM with Ubuntu OS (tested with 20.04 and 22.04) on an Ubuntu Laptop. I add a usb-host-device network card to the VM with virt-manager. This used to work fine with Ubuntu 20.04 as host OS. The card would show up in the VM and was working fine. This stopped working after upgrading the host to 22.04. The card will show up in dmesg, but gives an error:

[ 1.446991] usb 1-5: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 1024
[ 1.447068] usb 1-5: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 1024
[ 1.450528] usb 1-5: config 2 interface 1 altsetting 1 bulk endpoint 0x81 has invalid maxpacket 1024
[ 1.450600] usb 1-5: config 2 interface 1 altsetting 1 bulk endpoint 0x2 has invalid maxpacket 1024
[ 1.453858] usb 1-5: New USB device found, idVendor=17ef, idProduct=720c, bcdDevice=30.00
[ 1.453920] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 1.453959] usb 1-5: Product: Lenovo USB-C to LAN
[ 1.453989] usb 1-5: Manufacturer: Lenovo
[ 1.454012] usb 1-5: SerialNumber: D832B9000000
[ 1.736899] usb 1-5: can't set config #2, error -32

Removing and re-adding the card gives the same result. If I plug in a network cable, the device is often recognized and given an IP by the host system instead of the VM.

Description: Ubuntu 22.04.1 LTS
Release: 22.04

If needed, I can provide further information or testing.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Rolf,
I do not have a USB network card around to try the same over here but I've asked a few friends if they could. While not able to recreate let me ask a few things to get this started ...

1. you mention that "given an IP by the host" which clearly indicates it isn't fully passed through (or failing at doing so and given back). You posted the guest dmesg afaics, it might be useful to look at what the host think is right/wrong while you try to do this.
Could you try to gather `sudo dmesg -w`, `sudo journalctl -f` and `sudo tail -f /var/log/libvirt/qemu/<guestname>.log` from when you try to attach it?

2. How do you issue and configure the attach command?
Do you use virt-manager or an XML + virsh or anything else?
If so how is your guest config as well as the one for the device to pass look like?

Changed in libvirt (Ubuntu):
status: New → Incomplete
Revision history for this message
Rolf Kutz (vzsze) wrote :
Download full text (26.5 KiB)

Hi Christian,

here's the requested info. The VM is Ubuntu 22.04 in this case.

> Could you try to gather `sudo dmesg -w`, `sudo journalctl -f` and `sudo tail -f /var/log/libvirt/qemu/<guestname>.log` from when you try to attach it?

I plugged in the USB network card, then attached it to the VM,then plugged in a network cable and removed it again. In this case, the dmesg output of the VM didn't show an error, but the outcome is the same. Other times it often gives the "can't set config #2, error -32" error from above.

On host:
sudo dmesg -w

[ 2828.582191] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2831.585497] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2834.585584] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2837.589359] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2840.589631] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2843.589702] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2843.827413] usb 2-3.4: new SuperSpeed USB device number 6 using xhci_hcd
[ 2843.852217] usb 2-3.4: New USB device found, idVendor=17ef, idProduct=7205, bcdDevice=30.00
[ 2843.852226] usb 2-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 2843.852229] usb 2-3.4: Product: Thinkpad USB LAN
[ 2843.852231] usb 2-3.4: Manufacturer: Lenovo
[ 2843.852233] usb 2-3.4: SerialNumber: 1C6955000000
[ 2843.939781] usb 2-3.4: reset SuperSpeed USB device number 6 using xhci_hcd
[ 2843.986357] r8152 2-3.4:1.0: load rtl8153a-3 v2 02/07/20 successfully
[ 2844.016984] r8152 2-3.4:1.0 eth0: v1.12.12
[ 2844.636625] r8152 2-3.4:1.0 enx3c18a01c6955: renamed from eth0
[ 2846.593901] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2849.594001] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2852.640938] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2855.617820] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2858.617880] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2861.029282] audit: type=1400 audit(1662629782.512:114): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-298acbf4-0ef2-45eb-84b9-01754fced637" pid=12934 comm="apparmor_parser"
[ 2861.106273] r8152 2-3.4:1.0 enx3c18a01c6955: Stop submitting intr, status -108
[ 2861.601784] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2861.691979] usb 2-3.4: reset SuperSpeed USB device number 6 using xhci_hcd
[ 2861.750606] r8152 2-3.4:1.0: load rtl8153a-3 v2 02/07/20 successfully
[ 2861.781394] r8152 2-3.4:1.0 eth0: v1.12.12
[ 2861.826719] r8152 2-3.4:1.0 enx3c18a01c6955: renamed from eth0
[ 2861.843859] usb 2-3.4: usbfs: interface 0 claimed by r8152 while 'qemu-system-x86' sets config #1
[ 2864.621915] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 2867.622172] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lock...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Just to help others reading this "rpc-libvirtd: debugfs access is restricted" is bug 1957924 and a non critical (noise, but not breaking) issue. You can ignore any of these (at least that was the assumption so far.

In dmesg we have no usual suspects (apparmor denials for example:
We only see the device "coming back to the host" without much info about an issue.
Maybe this one:
  usb 2-3.4: usbfs: interface 0 claimed by r8152 while 'qemu-system-x86' sets config #1

That is a conflict between the host r8152 driver and qemu.

In the libvirt log we see that libvirt fails because it can not set the config as being busy.
2022-09-08T09:36:23.331793Z qemu-system-x86_64: libusb_set_configuration: -6 [BUSY]

That could match to the above dmesg entry of a fight between host driver and qemu.

I do not know if the host changed behavior in how hard it hold onto this device.
But instead of hot-plugging it back and forth we could try releasing it from the host a bit more before attaching it to the guest.
Then you can try to move it to the guest and see if it works now.
(Of course if you need it in host and guest we will eventually need to sort out how to do this more smoothly).

So I wonder, if yo'd be ok (if you do not need the driver for something else) to try on the host to blacklist that driver.
0. blacklist on the host
 $ echo "blacklist r8152" > /etc/modprobe.d/lp-1988504-avoid-hostdrivers.conf
 $ echo "blacklist cdc_ether" >> /etc/modprobe.d/lp-1988504-avoid-hostdrivers.conf
 # not sure if this is loaded by initramfs (surely not if unplugged) but to be sure
 $ sudo update-initramfs -u
1. Unplug your USB network device
2. Reboot
3. Plug in your USB network
4. Check lsmod, it should not more have r8152 or cdc_ether loaded on the host
5. now start your guest
6. set up the log watches again
7. try to attach the USB dev

Let me know if that gets you any further

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

A friend of mine reported that he sees the same behavior.
So whatever it is - it seems to be a general issue for this setup and not so much "your config".

Interested to hear back from your try what happens if the host properly leaves this device alone.

Revision history for this message
Rolf Kutz (vzsze) wrote :
Download full text (3.9 KiB)

Thanks for the workaround. The VM is getting a an IP now, so the blacklisting works. See the logs below. It does only solve the problem partially for me, since I sometimes use the USB network card on the host, too (and sometimes more than one, mixed between host and VM).

This all used to work with Ubuntu 20.04 host, so it is a bug and regression.

Host:

journalctl -f
Sep 08 15:41:11 suki kernel: Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
Sep 08 15:41:11 suki kernel: usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
Sep 08 15:41:14 suki kernel: Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
Sep 08 15:41:16 suki firefox.desktop[5274]: Unsupported modifier, resource creation failed.
Sep 08 15:41:16 suki firefox.desktop[5274]: XXX: resource creation failed
Sep 08 15:41:17 suki kernel: Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
Sep 08 15:41:17 suki firefox.desktop[5274]: Unsupported modifier, resource creation failed.
Sep 08 15:41:17 suki firefox.desktop[5274]: XXX: resource creation failed
Sep 08 15:41:20 suki kernel: Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
Sep 08 15:41:23 suki kernel: Lockdown: rpc-libvirtd: debugfs access is restr

No log from sudo tail -f /var/log/libvirt/qemu/ubuntu22.log

dmesg -w:
[ 351.694209] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 354.698552] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 357.702326] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 360.702176] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 363.702654] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 366.702513] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 369.702080] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 372.706535] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 375.706651] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 377.947626] audit: type=1400 audit(1662644470.623:105): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-298acbf4-0ef2-45eb-84b9-01754fced637" pid=6651 comm="apparmor_parser"
[ 378.717833] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 378.848430] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[ 381.718332] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7
[ 384.718034] Lockdown: rpc-libvirtd: debugfs access is restricted; see man kernel_lockdown.7

On VM:
dmesg -w:
[ 302.038735] usb 1-4: new high-speed USB device number 4 using ehci-pci
[ 302.196684] usb 1-4: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 1024
[ 302.196689] usb 1-4: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 1024
[ 302.197303] usb 1-4: config 2 interface 1 altsetting 1 bulk endpoint 0x81 has invalid ma...

Read more...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thanks for trying, I agree it is a bug/regression - but I'm not yet sure where exactly to point it to. Of the many involved components the two most involved here are libvirt and the kernel.

Would you be able to try this with either:
1. an older libvirt (hard to get onto the new system)
2. a newer libvirt on the old system (if you have a second comparable one you can use https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports)
3. Trying an older kernel matching what 20.04 had - I assume you had the default being 5.4.0-26.30 (you might use https://kernel.ubuntu.com/~kernel-ppa/mainline/ to pick a 5.4 kernel)
4. On said olders system from #2 if you have it try a newer kernel through the HWE stack (https://wiki.ubuntu.com/Kernel/LTSEnablementStack)

Revision history for this message
Rolf Kutz (vzsze) wrote :

I used linux-oem-5.14 before upgrading. I tried that kernel on 22.04, but it didn't solve the problem. I also tried linux-5.15 default and linux-oem-5.17 kernel. The bug did show with all of those kernel versions, so I guess it is a libvirt problem. I can try again and create some logs if that would help. I don't have a 20.04 system to try, at the moment.

Revision history for this message
Rolf Kutz (vzsze) wrote :
Download full text (13.0 KiB)

I tested on an Ubuntu 20.04 maschine with a Debian VM. The logs show inserting the USB networking card, delegating, inserting the cable. The VM is getting an IP address after running a dhclient command.

Host:
Ubuntu 20.04.5 LTS
Linux airi 5.15.0-46-generic #49~20.04.1-Ubuntu SMP Thu Aug 4 19:15:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
libvirt0:amd64/focal-security 6.0.0-0ubuntu8.16 uptodate

VM:
Debian GNU/Linux 10
Linux management 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64 GNU/Linux

on Host:
dmesg -w
[ 774.246011] usb 2-4: new SuperSpeed USB device number 4 using xhci_hcd
[ 774.266707] usb 2-4: New USB device found, idVendor=17ef, idProduct=7205, bcdDevice=30.00
[ 774.266726] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 774.266732] usb 2-4: Product: Thinkpad USB LAN
[ 774.266738] usb 2-4: Manufacturer: Lenovo
[ 774.266742] usb 2-4: SerialNumber: 1C6955000000
[ 774.294021] usbcore: registered new interface driver r8152
[ 774.301860] usbcore: registered new interface driver cdc_ether
[ 774.422616] usb 2-4: reset SuperSpeed USB device number 4 using xhci_hcd
[ 774.469822] r8152 2-4:1.0: load rtl8153a-3 v2 02/07/20 successfully
[ 774.504631] r8152 2-4:1.0 eth0: v1.12.12
[ 774.538923] r8152 2-4:1.0 enx3c18a01c6955: renamed from eth0
[ 854.297055] audit: type=1400 audit(1663234104.465:129): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-21d2ab6e-d039-4e13-8956-4249b580d756" pid=29798 comm="apparmor_parser"
[ 854.977562] usb 2-4: reset SuperSpeed USB device number 4 using xhci_hcd
[ 855.036675] r8152 2-4:1.0: load rtl8153a-3 v2 02/07/20 successfully
[ 855.070558] r8152 2-4:1.0 eth0: v1.12.12
[ 855.409642] usb 2-4: reset SuperSpeed USB device number 4 using xhci_hcd

journalctl -f
ep 15 11:27:01 airi CRON[27337]: pam_unix(cron:session): session opened for user rk by (uid=0)
Sep 15 11:27:01 airi CRON[27338]: pam_unix(cron:session): session opened for user rk by (uid=0)
Sep 15 11:27:01 airi CRON[27339]: (rk) CMD (/usr/bin/wget -4 --no-check-certificate --output-document=/dev/null --timeout=600 -q "https://naoko.zsze.de")
Sep 15 11:27:01 airi CRON[27340]: (rk) CMD (/usr/bin/wget -6 --no-check-certificate --output-document=/dev/null --timeout=600 -q "https://naoko.zsze.de")
Sep 15 11:27:01 airi CRON[27338]: pam_unix(cron:session): session closed for user rk
Sep 15 11:27:01 airi CRON[27337]: pam_unix(cron:session): session closed for user rk
Sep 15 11:27:04 airi kernel: usb 2-4: new SuperSpeed USB device number 4 using xhci_hcd
Sep 15 11:27:04 airi kernel: usb 2-4: New USB device found, idVendor=17ef, idProduct=7205, bcdDevice=30.00
Sep 15 11:27:04 airi kernel: usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
Sep 15 11:27:04 airi kernel: usb 2-4: Product: Thinkpad USB LAN
Sep 15 11:27:04 airi kernel: usb 2-4: Manufacturer: Lenovo
Sep 15 11:27:04 airi kernel: usb 2-4: SerialNumber: 1C6955000000
Sep 15 11:27:04 airi kernel: usbcore: registered new interface driver r8152
Sep 15 11:27:04 airi kernel: usbcore: registered new interface driver cdc_ether
Sep 15 11:27:04 airi kernel: usb 2-4: reset SuperSpeed USB device number 4 using xhci_hcd
Se...

Revision history for this message
Rolf Kutz (vzsze) wrote :
Download full text (8.8 KiB)

I updated the hosts libvirt to the version of the backport ppa you mentioned, inserted, delegated the USB-NIC and inserted the cable. It shows the same error as Ubuntu 22.04 before. This strongly suggests, that it is indeed a libvirt bug.

Host:
libvirt0:amd64/focal 8.0.0-1ubuntu7.1~backport20.04.202205310636~ubuntu20.04.1 uptodate

On Host:
dmesg:
[ 446.125558] usb 2-4: new SuperSpeed USB device number 3 using xhci_hcd
[ 446.145912] usb 2-4: New USB device found, idVendor=17ef, idProduct=7205, bcdDevice=30.00
[ 446.145924] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 446.145927] usb 2-4: Product: Thinkpad USB LAN
[ 446.145929] usb 2-4: Manufacturer: Lenovo
[ 446.145931] usb 2-4: SerialNumber: 1C6955000000
[ 446.173154] usbcore: registered new interface driver r8152
[ 446.183791] usbcore: registered new interface driver cdc_ether
[ 446.302087] usb 2-4: reset SuperSpeed USB device number 3 using xhci_hcd
[ 446.349809] r8152 2-4:1.0: load rtl8153a-3 v2 02/07/20 successfully
[ 446.383514] r8152 2-4:1.0 eth0: v1.12.12
[ 446.424504] r8152 2-4:1.0 enx3c18a01c6955: renamed from eth0
[ 470.390919] audit: type=1400 audit(1663236916.760:125): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-21d2ab6e-d039-4e13-8956-4249b580d756" pid=18610 comm="apparmor_parser"
[ 471.097459] usb 2-4: reset SuperSpeed USB device number 3 using xhci_hcd
[ 471.151505] r8152 2-4:1.0: load rtl8153a-3 v2 02/07/20 successfully
[ 471.179161] r8152 2-4:1.0 eth0: v1.12.12

journalctl:
Sep 15 12:14:52 airi kernel: usb 2-4: new SuperSpeed USB device number 3 using xhci_hcd
Sep 15 12:14:52 airi kernel: usb 2-4: New USB device found, idVendor=17ef, idProduct=7205, bcdDevice=30.00
Sep 15 12:14:52 airi kernel: usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
Sep 15 12:14:52 airi kernel: usb 2-4: Product: Thinkpad USB LAN
Sep 15 12:14:52 airi kernel: usb 2-4: Manufacturer: Lenovo
Sep 15 12:14:52 airi kernel: usb 2-4: SerialNumber: 1C6955000000
Sep 15 12:14:52 airi kernel: usbcore: registered new interface driver r8152
Sep 15 12:14:52 airi kernel: usbcore: registered new interface driver cdc_ether
Sep 15 12:14:52 airi kernel: usb 2-4: reset SuperSpeed USB device number 3 using xhci_hcd
Sep 15 12:14:52 airi kernel: r8152 2-4:1.0: load rtl8153a-3 v2 02/07/20 successfully
Sep 15 12:14:52 airi kernel: r8152 2-4:1.0 eth0: v1.12.12
Sep 15 12:14:52 airi networkd-dispatcher[867]: WARNING:Unknown index 20 seen, reloading interface list
Sep 15 12:14:52 airi systemd-udevd[18057]: Using default interface naming scheme 'v245'.
Sep 15 12:14:52 airi systemd-udevd[18057]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Sep 15 12:14:52 airi kernel: r8152 2-4:1.0 enx3c18a01c6955: renamed from eth0
Sep 15 12:14:52 airi systemd-networkd[513]: eth0: Interface name change detected, eth0 has been renamed to enx3c18a01c6955.
Sep 15 12:14:52 airi networkd-dispatcher[867]: WARNING:Unknown index 20 seen, reloading interface list
Sep 15 12:14:52 airi systemd-udevd[18059]: Using default interface naming scheme 'v245'.
Sep 15 12:14:52 airi systemd-udevd[18059]: ethtool: autonegotiation is unse...

Read more...

Revision history for this message
Rolf Kutz (vzsze) wrote :

Is there anything missing or anything I can do to help fix this bug?

Revision history for this message
Rolf Kutz (vzsze) wrote :

Interestingly usb-passthrough does work with an ax88179 NIC. But that might be, because of initialization errors on the Host or because of diffent kind of initialization. Despite the errors it does work on the host.

Host (Ubuntu 22.04, Kernel Linux 5.15.0-52-generic)
[45964.858866] ax88179_178a 3-8:2.1 eth1: Failed to read reg index 0x000e: -32
[message repeated multiple times]
[45964.901841] ax88179_178a 3-8:2.1 eth1: Failed to write reg index 0x000e: -32
[45964.912302] ax88179_178a 3-8:2.1 eth1: Failed to read reg index 0x0000: -32
[45965.988669] ax88179_178a 3-8:2.0 eth0: unregister 'ax88179_178a' usb-0000:00:14.0-8, ASIX AX88179 USB 3.0 Gigabit Ethernet
[45965.988726] ax88179_178a 3-8:2.0 eth0: Failed to read reg index 0x0002: -19
[45965.988732] ax88179_178a 3-8:2.0 eth0: Failed to write reg index 0x0002: -19
[45966.031579] ax88179_178a 3-8:2.0 eth0 (unregistered): Failed to write reg index 0x0002: -19
[45966.031591] ax88179_178a 3-8:2.0 eth0 (unregistered): Failed to write reg index 0x0001: -19
[45966.031596] ax88179_178a 3-8:2.0 eth0 (unregistered): Failed to write reg index 0x0002: -19
[45966.031820] ax88179_178a 3-8:2.1 eth1: unregister 'ax88179_178a' usb-0000:00:14.0-8, ASIX AX88179 USB 3.0 Gigabit Ethernet
[45966.031937] ax88179_178a 3-8:2.1 eth1: Failed to read reg index 0x0002: -19
[45966.031944] ax88179_178a 3-8:2.1 eth1: Failed to write reg index 0x0002: -19
[45966.075553] ax88179_178a 3-8:2.1 eth1 (unregistered): Failed to write reg index 0x0002: -19
[45966.075567] ax88179_178a 3-8:2.1 eth1 (unregistered): Failed to write reg index 0x0001: -19
[45966.075572] ax88179_178a 3-8:2.1 eth1 (unregistered): Failed to write reg index 0x0002: -19
[45967.862773] ax88179_178a 3-8:1.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x0040: -32
[45968.172405] ax88179_178a 3-8:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-8, ASIX AX88179 USB 3.0 Gigabit Ethernet, f8:e4:3b:90:97:0f
[45968.714083] ax88179_178a 3-8:1.0 enxf8e43b90970f: renamed from eth0
[45969.304396] ax88179_178a 3-8:1.0 enxf8e43b90970f: Failed to read reg index 0x0040: -32
[45971.298515] ax88179_178a 3-8:1.0 enxf8e43b90970f: ax88179 - Link status is: 1
[46073.074394] ax88179_178a 3-8:1.0 enxf8e43b90970f: unregister 'ax88179_178a' usb-0000:00:14.0-8, ASIX AX88179 USB 3.0 Gigabit Ethernet

VM (Ubuntu 20.04 Kernel Linux 5.15.0-52-generic):
rkutz@linux02:~$ dmesg |grep ax88
[ 49.404245] ax88179_178a 1-4:1.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x0040: -32
[ 49.727024] ax88179_178a 1-4:1.0 eth0: register 'ax88179_178a' at usb-0000:00:1d.7-4, ASIX AX88179 USB 3.0 Gigabit Ethernet, f8:e4:3b:90:97:0f
[ 49.727049] usbcore: registered new interface driver ax88179_178a
[ 49.728594] ax88179_178a 1-4:1.0 enxf8e43b90970f: renamed from eth0
[ 50.319450] ax88179_178a 1-4:1.0 enxf8e43b90970f: Failed to read reg index 0x0040: -32
[ 2124.862130] ax88179_178a 1-4:1.0 enxf8e43b90970f: ax88179 - Link status is: 1

Revision history for this message
Robie Basak (racb) wrote :

Since Christian agreed this is a valid bug I'm adding this to our backlog and tagging it regression-release to represent that it's a regression compared to 20.04.

I'm sorry I don't know how to progress it though, and unless Christian thinks otherwise then unfortunately I don't expect it to make any progress soon. Volunteers welcome.

summary: - usb-passthrough of network card not working any more on 22.04
+ r8152 driver no longer releases USB NIC for VM passthrough
Changed in libvirt (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Medium
tags: added: regression-release
Revision history for this message
Wayne Manion (treowayne) wrote :

I have also experienced this problem. It took a pretty long time to figure out why my USB Ethernet adapter worked just fine on the Ubuntu host but would never work correctly on the Ubuntu or Home Assistant OS guests.

For whatever its worth, I experienced this problem on several different Realtek 8152 (10/100) and 8153 (Gigabit) USB ethernet adapters from multiple manufacturers. My ASIX Ethernet adapters (88179 and 88772) pass through to guests just fine. I have multiple guest VMs and I wanted to be able to provide a gigabit NIC for each without having to deal with USB paths.

I had to blacklist the r8152, r8153_ecm, and cdc_ether modules on the host to get the passthrough to work correctly. I would like to confirm that the '$ sudo update-initramfs -u' step IS necessary to get this to work.

Thanks Christian Ehrhardt.

Revision history for this message
Rolf Kutz (vzsze) wrote :

The problem is still present with kernel 6.2.0-26-generic.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.