Hope that someone can help with this issue. 

Currently on 6.12.13. which works fine apart from the disk speed issues on the windows VM. I upgraded to 6.12.15 which worked fine but i lost all network access. The VM's couldn't see the cameras on the LAN. Rolled back and everything was fine. 

Tried again when 7.0.0. came around and seeing the same issue, broken networking post update. So rolled back to 6.12.13 again. 

Not really sure what is causing this or what to do next. 

 

Any ideas on how I can update this machine?

 

security-diagnostics-20250201-1355.zip

There's no link detected on eth0, only on eth1

There are 2 NIC's in the machine but one one is in use. 

The VM's have both br0/1 listed. 

 

 

The main NIC must be eth0, so if eth1 is the only one you use, swap the order, you can do that on the Network settings page, Interface rules, reboot required after.

P.S., there should only be one gateway set, or it can also cause issues.

Tried this, broke everything. Possibly could have fixed it but the wireless mouse didnt want to work with safe mode as it was allocated to the Windows VM who then couldn't see internet so I couldn't remote in. 

 

I think I'm just going to setup eth0 as an additional IP and connect it to the router for the time being. Seems like the best way of going about removing it. 

 

Im still really struggling with this, upgraded to 7.2.2. I've removed all reference to eth1 and br1. The VMs all point to br0. The machine starts just fine, it will run for up to around 40 minutes and then network connectivity will drop dead, internal and external, I cant even see the CCTV cameras on the LAN.

Anyone got any better ideas? Just so frustrating as the networking works perfectly on 6.12.13.

security-diagnostics-20251215-1601.zip

Dec 15 16:02:30 Security kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:

Problem with the NIC, this is a kernel issue, disabling TSO for that NIC should help:

https://bugzilla.kernel.org/show_bug.cgi?id=118721#c11

On 12/16/2025 at 10:49 AM, JorgeB said:

Dec 15 16:02:30 Security kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:

Problem with the NIC, this is a kernel issue, disabling TSO for that NIC should help:

https://bugzilla.kernel.org/show_bug.cgi?id=118721#c11

I tried ethtool -K eth0 tso off in the terminal. Didnt help. Not sure if its normal for there to be no response.

All i can do it further try ethtool eth0 tx off sg off tso off

Edited December 18, 2025Dec 18 by calypsoSA

Your bios is a bit out of date.

https://www.gigabyte.com/Motherboard/H370-HD3-rev-10/support#Support-Bios

Just now, Veah said:

Your bios is a bit out of date.

https://www.gigabyte.com/Motherboard/H370-HD3-rev-10/support#Support-Bios

OK cool, but would this case the NICs to hang? This isn't a problem on Unraid 6.12.13 or earlier.

The NIC issue is a kernel-related, post new diags after using ethtool to see if it's still the same issue.

45 minutes ago, calypsoSA said:

OK cool, but would this case the NICs to hang? This isn't a problem on Unraid 6.12.13 or earlier.

Unlikely, but it is possible. Jorge is really good at deciphering the logs, so I highly recommend pursuing the errors he points out. To me it's more an opportunity to update something that fell 6 years behind.

Tried 'ethtool eth0 tx off sg off tso off' it seemed to make it worse. Now only lasting a few minutes after a reboot instead of a few hours.

Trace attached, I hope it has all the details. I just get locked down which then makes unraid unavailable.

security-diagnostics-20251218-1659.zip

To simplify this a little, go in system devices, bind the unused (unwanted) nic to vfio then reboot. That will make it so only 1 nic shows up in network settings. Then reconfigure the single nic showing up.

It's still the same error. Some suggestions from ChatGPT: failing those, my recommendation would be to get a different NIC:

Important nuance

Bug 118721 is not a single bug with a single fix. It is more accurately:

• A hardware erratum class

• Exposed by different kernel changes over time

• Mitigated (not fully eliminated) by various driver workarounds

That is why the bug is old, reopened multiple times, and referenced by other bugs.

So while your system may be running a newer kernel, the underlying failure mode is the same.

---

Practical implications

If this is affecting you operationally, the mitigations that helped in that bug still apply:

1. Disable ASPM

   pcie_aspm=off
   

   (Very commonly resolves this exact hang.)

2. Disable EEE

   ethtool --set-eee eth0 eee off
   

3. Force a fixed speed/duplex

   ethtool -s eth0 speed 1000 duplex full autoneg off
   

4. Update BIOS / firmware
   Many reports tied this directly to firmware-level power management.

5. As a last resort: switch to igb hardware if reliability is critical.

16 hours ago, JorgeB said:

It's still the same error. Some suggestions from ChatGPT: failing those, my recommendation would be to get a different NIC:

Important nuance

Bug 118721 is not a single bug with a single fix. It is more accurately:

• A hardware erratum class

• Exposed by different kernel changes over time

• Mitigated (not fully eliminated) by various driver workarounds

That is why the bug is old, reopened multiple times, and referenced by other bugs.

So while your system may be running a newer kernel, the underlying failure mode is the same.

---

Practical implications

If this is affecting you operationally, the mitigations that helped in that bug still apply:

1. Disable ASPM

   pcie_aspm=off
   

   (Very commonly resolves this exact hang.)

2. Disable EEE

   ethtool --set-eee eth0 eee off
   

3. Force a fixed speed/duplex

   ethtool -s eth0 speed 1000 duplex full autoneg off
   

4. Update BIOS / firmware
   Many reports tied this directly to firmware-level power management.

5. As a last resort: switch to igb hardware if reliability is critical.

Tried all of these except igb. Still failed in the middle of the night. Will go over to the site a little later in the day and try move over to the PCI NIC, I just hope that I have not deleted too much of it trying to simplify the instance.

Ok Interesting, this time I could still log into the Unraid interface via the browser in the Windows VM. So got the diagnostics from the machine before needing to reboot it.

I have since moved to the PCI Nic, so wait and lets see. One interesting thing i noticed is that that VM cant see the access point 192.168.1.50 (see screenshot) even through after the reboot all the cameras on the LAN are accessible again and internet access restored. Probably has to do with why the App store is not available. (Both PCI and onboard nic)

security-diagnostics-20251219-1446.zip

hmm, the gateway is showing the diags, possibly just a display issue:

GATEWAY[0]="192.168.1.50"