After upgrading to 5.1.10 Network interface is not working enp0s3: Detected Tx Unit Hang

[vdv]

After upgrading to virtualbox 5.1.10 Network interface is not working after boot unless its manually reset after boot.Downgrading to virtualbox 5.1.8 fixes the problem.However, upgrading to 5.1.11 is mostly working but not 100% of the time. During the testing it didn't work a few times. Linux arch 4.8.10-1-ARCH guest on windows 10 Host.

journalctl -b kernel: e1000 0000:00:03.0 enp0s3: Detected Tx Unit Hang

[jvdv]

I have the same issue here with an Arch Linux guest and Virtualbox 5.1.10 on an Arch Linux host.

I suspect that there is some kind of race condition going on during the initialization of the e1000 interface, because the errors occur intermittently. Sometimes the guest boots up without problems, sometimes it gives a few "Tx unit hang" errors during boot and then recovers, and sometimes it hangs completely. Once the guest's network interface is up and running, the error does not reoccur.

I noticed that I could reproduce the problem by manually bringing up the network and leaving no pause between inserting the e1000 module and configuring the network interface.

If I put it in a script and run it, this will usually trigger the "Tx unit hang" errors:

#!/bin/bash
modprobe e1000
netctl start ethernet-dhcp

While this always works:

#!/bin/bash
modprobe e1000
sleep 2
netctl start ethernet-dhcp

If you use netctl, I suppose a workaround could be to put a short sleep statement in the /usr/lib/network/network initialization script, though I haven't tried this myself. It's a bit of an ugly hack, and future system updates could overwrite your change so you'd have to keep track of it everytime.

If you don't need gigabit ethernet, another workaround is to configure your VM to use one of the PCnet adapter types instead of Intel PRO/1000. You'll be limited to 100Mbps, but at least you'll have reliable networking.

For the time being, I downgraded to VirtualBox 5.1.8.

[Aleksey Ilyushin]

Please try the latest test build 5.1.x from here. It should solve the issue.

[Frank Mehnert]

Fixed in VBox 5.1.12.

[sancelot]

I thought it would solve my problem, I have recurrent tx unit hangs using an nfs client with linux (x86).

e1000 0000:00:03.0 eth0: Detected Tx Unit Hang

Tx Queue <0> TDH <b2> TDT <bb> next_to_use <bb> next_to_clean <b2>

buffer_info[next_to_clean]

time_stamp <10001119c> next_to_watch <ba> jiffies <100011355> next_to_watch.status <0>

[ 583.811563] e1000 0000:00:03.0 eth0: Detected Tx Unit Hang

Tx Queue <0>

[Aleksey Ilyushin]

Can anybody try to reproduce the issue with VirtualBox 5.2?

[Mihai Hanor]

I have seen this with VirtualBox 5.2.0/5.2.1 and Windows 10 64 bit 1703 as host. Guest Debian Sid. I don't know how to reproduce it. I've seen it at VM/guest OS startup.

Later edit: actually, it was Ubuntu 17.10 64 bit as guest.

[Mihai Hanor]

I'm not sure why, but I can reproduce the issue with my Ubuntu 17.10 guest, for now at least. Setting VBOX_RELEASE_LOG to +dev_e1000.e.l.l2.l3.f doesn't seem to add any additional logging with the release build.

[Mihai Hanor]

b

[Mihai Hanor]

Duplicate of #15845
The issue is reproducible with Debian Sid amd64, on guest startup, probably during or after restoring of iptables rules by firehol.