TL;DR: Since moving to Unraid 7.1.x (both 7.1.4 and 7.1.3), my server periodically “falls off” the network: GUI and SSH are dead, sometimes containers are still reachable, sometimes not. Syslog shows the Aquantia 10 GbE NIC (atlantic driver) dropping link (old 10000 new 0) and the bridge disabling. Later I also hit a kernel oops, after which the box is totally unresponsive until a hard reboot.

---

Hardware

• MB: Gigabyte Z790 AORUS MASTER (BIOS F16f – 05/27/2025)

• CPU: Intel i9‑14900KS

• RAM: 96 GB DDR5 (Corsair)

• NIC: Onboard Marvell/Aquantia AQC113C 10 GbE (driver: atlantic)

• Unraid versions tested: 7.1.4 (current), rolled back to 7.1.3 (same issue eventually)

---

Symptoms

• Web GUI becomes unreachable.

• SSH can’t connect.

• Docker containers: sometimes accessible, sometimes not.

• Only way back is a manual reboot at the console/IPMI.

• Issue can reappear within a day or after several days of uptime.

---

What I’ve Done / Observed

1. Version shuffle: Upgraded to 7.1.4 → saw issue. Downgraded to 7.1.3 → thought it was better, but it reoccurred.

2. Syslog server enabled (pointed to itself, so I have logs leading up to the crash).

3. Log review shows:

   • Link flaps on eth0 (Aquantia):

     Jul 25 23:51:11 kernel: atlantic 0000:02:00.0 eth0: link change old 10000 new 0
     Jul 25 23:51:12 kernel: br0: port 1(eth0) entered disabled state
     

   • After link down, Samba/nmbd complains it can’t send broadcasts.

   • Later (hours) a kernel BUG/Oops occurs in a Plex helper process (“Plex Commercial”), with “irqs disabled” in the trace. After that, the system is effectively hung.

4. Compared other users’ diagnostics (7.1.4 forum posts) – several with atlantic NICs report similar drops/bridge disable messages.

5. No obvious scheduled Unraid task (mover, parity check, TRIM) lines up perfectly—seems load-related but not triggered by a specific built‑in schedule.

---

Log Snippets (trimmed)

atlantic 0000:02:00.0 eth0: link change old 10000 new 0
br0: port 1(eth0) entered disabled state
...
BUG: unable to handle page fault...
Tainted: P  O  (proprietary/out-of-tree module loaded)
note: Plex Commercial[32039] exited with irqs disabled

(Full diagnostics & syslog attached.)

---

Ask / Help Wanted

• Is there a known issue with the atlantic driver (AQC113C) on the 6.12.x kernel shipped with 7.1.x?

• Any recommended ethtool settings or kernel parameters that have stabilized this NIC for others? (e.g. disabling EEE/offloads, pcie_aspm=off, etc.)

• Is a fix queued in an upcoming 7.1.x point release?

• Anything else I should capture (netdump, sysrq-trigger before reboot) to help diagnose?

---

unraid-diagnostics-20250728-0814.zip syslog-192.168.2.115.log

AI wrote the post, I did compare others logs, and it found similar NIC flapping. however, they were likely on slightly different hardware. The above post says they were on Atlantic NICs also. Which those posts were actually on different hardware.

Link is going down, and typically this is a hardware issue, but it's also coming back up:

Jul 28 08:10:46 unraid kernel: atlantic 0000:02:00.0 eth0: atlantic: link change old 0 new 10000

Jul 28 08:10:46 unraid rc.atd: AT daemon... Started.

Jul 28 08:10:46 unraid rc.wireguard: iptables -N WIREGUARD

Jul 28 08:10:46 unraid rc.wireguard: iptables -A FORWARD -j WIREGUARD

Jul 28 08:10:46 unraid rc.wireguard: ip6tables -N WIREGUARD

Jul 28 08:10:46 unraid rc.wireguard: ip6tables -A FORWARD -j WIREGUARD

Jul 28 08:10:46 unraid rc.wireguard: mkdir -p /boot/config/wireguard

Jul 28 08:10:46 unraid rc.wireguard: ln -sf /boot/config/wireguard /etc

Jul 28 08:10:46 unraid rc.wireguard: ip -4 rule add from 172.31.200.0/24 table 200

Jul 28 08:10:46 unraid rc.wireguard: ip -4 route add unreachable default table 200

Jul 28 08:10:46 unraid dhcpcd[1947]: br0: carrier acquired

Jul 28 08:10:46 unraid kernel: bond0: (slave eth0): link status definitely up, 10000 Mbps full duplex

Jul 28 08:10:46 unraid kernel: bond0: (slave eth0): making interface the new active one

Jul 28 08:10:46 unraid kernel: atlantic 0000:02:00.0 eth0: entered promiscuous mode

Jul 28 08:10:46 unraid kernel: atlantic 0000:02:00.0 eth0: entered allmulticast mode

Jul 28 08:10:46 unraid kernel: bond0: active interface up!

Does the issue occur right after these down/up logs? It may be a red herring. I see that you have a 14900KS, and that is one of the most affected models by the Intel 13/14 gen issues; multiple cases of stability issues confirmed with that and similar CPUs.

I believe that is when I restarted the server at 810 this morning. That's when I captured the logs and uploaded shortly after

If the crashes/hanging don't happen after those lines, and most likely they don't, the issue is unlikely to be related to the network, take note of the time it next happens, as accurately as possible, and post a new syslog.

Attached are the latest files. It crashed between 5-630 this morning. I had to reboot it several times afterwards in order for it to come back fully online.

Timeline of manual power / reboot events

#	Local time (EDT)	Log evidence	Notes
A	20:00 (≈)	―	You finished the Uncle Buck playback here (no playback errors logged).
B	05:00	Syslog line shows rsyslog restart after scheduled log‑rotation; server otherwise healthy.
C	06:30	No new log lines after 06:04 → system appears frozen.
D	08:05	First kernel line after gap: Linux version 6.12.24‑Unraid … boot → confirms a manual power‑button reboot.
E	08:12	Another abrupt boot record only ~7 min later – second power‑cycle.
F	08:19	Third boot – you said you “had to restart several more times”; logs show one more here.
G	09:45	Final reboot that produced the diagnostics zip you sent.

syslog-192.168.2.115 (1).log unraid-diagnostics-20250730-0945.zip

30 minutes ago, CSeK said:

No new log lines after 06:04 → system appears frozen.

This and this:

30 minutes ago, CSeK said:

I had to reboot it several times afterwards in order for it to come back fully online.

Suggest more of a hardware issue.

Hey @JorgeB ,

Thanks for your help in this. Normally, I would agree with you. However, when I purchased this a year ago it was the time they announced the chip issues with this line. I awaited for the bios update before I even put the chip in the rig and powered it online. It has been stable for the entire time until the 7.1.x releases. I also thought hey maybe it is hardware and ran memtest86 test on the memory to ensure nothing was going on with that as well. That passed. I'm going to downgrade to a 7.0.x release since I know that the 7.1.x has been plagued with network related issues.

I will keep you updated. Until then, my logs are still here for some perusing.

1 hour ago, CSeK said:

I'm going to downgrade to a 7.0.x release

That's a good test to make, downgrade and see if it remains stable there.

Hey @JorgeB

to give you an update, I downgraded, same issue persisted, upgraded to the beta, same issue persisted. Tested all various software issues I could come to the conclusion of testing. End result it was the CPU microcode bug despite me not installing the CPU until I had the August 2024 Gigabyte update that was supposed to fix the issue. I bought a new CPU and swapped it, and it has been running perfectly smooth now for over a week straight with no issues at all. I've also started the RMA process with intel and they've agreed on the replacement.

Live and learn, BIOS updates early on did NOT actually fix the microcode issue.