VirtualBox

Opened 7 years ago

Last modified 4 years ago

#16221 reopened defect

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

Reported by: vdv Owned by:
Component: network Version: VirtualBox 5.1.10
Keywords: Cc:
Guest type: Linux Host type: Windows

Description

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

Attachments (2)

Logs.7z (155.3 KB ) - added by Mihai Hanor 6 years ago.
LogsDebug.7z (128.0 KB ) - added by Mihai Hanor 6 years ago.
b

Download all attachments as: .zip

Change History (11)

comment:1 by jvdv, 7 years ago

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

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.

Version 0, edited 7 years ago by jvdv (next)

comment:2 by Aleksey Ilyushin, 7 years ago

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

comment:3 by Frank Mehnert, 7 years ago

Resolution: fixed
Status: newclosed

Fixed in VBox 5.1.12.

comment:4 by sancelot, 7 years ago

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>

Last edited 7 years ago by sancelot (previous) (diff)

comment:5 by sancelot, 7 years ago

Resolution: fixed
Status: closedreopened

comment:6 by Aleksey Ilyushin, 6 years ago

Can anybody try to reproduce the issue with VirtualBox 5.2?

comment:7 by Mihai Hanor, 6 years ago

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.

Last edited 6 years ago by Mihai Hanor (previous) (diff)

by Mihai Hanor, 6 years ago

Attachment: Logs.7z added

comment:8 by Mihai Hanor, 6 years ago

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.

by Mihai Hanor, 6 years ago

Attachment: LogsDebug.7z added

b

comment:9 by Mihai Hanor, 4 years ago

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

Last edited 4 years ago by Mihai Hanor (previous) (diff)
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use