Defective onboard RTL8127 NIC on DGX Spark

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
1

Hello,

My DGX Spark’s onboard Realtek RTL8127 Ethernet NIC (r8127 driver
11.014.00-NAPI) has persistent, intermittent packet loss and link
instability that I have been unable to resolve through software. I
believe this is a hardware defect and would like to request an
RMA/replacement.

Symptoms

  • Bursty packet loss up to ~21% to the local gateway (confirmed via ping).
  • Link flaps — observed the link go fully down for ~12 minutes
    (r8127: enP7s7: link down → link up), and it continues to flap even
    after a fresh OS update (see logs below, link down at 11:23 today).
  • rx_errors counter accumulating continuously (1,180,000+ on the previous
    boot; already 140,000+ within one hour on the current boot).
  • ethtool reports the link negotiated at 1000 Mb/s while the PHY
    advertises ONLY 10baseT — an abnormal, inconsistent state.

Proof it is this unit, not my network
I run FOUR identical DGX Spark units on the same switch/gateway. The
other three show ~0.00% packet loss over a 13-hour overnight ping; THIS
unit alone shows 9-21% loss under identical conditions. (Screenshot
attached: three machines pinging the same gateway 192.168.0.1 — a086 and
0077 at ~0.00%, da01 at 9.03% loss.)

Everything I have already tried (problem persists after each)

  1. Disabled Energy Efficient Ethernet (EEE) — the documented NVIDIA
    workaround.
  2. Replaced the cable with a brand-new CAT6.
  3. Updated DGX OS to the latest (OTA 7.5.0, kernel 6.17.0-1029-nvidia) —
    NIC driver unchanged, issue unchanged.
  4. Disabled all NIC offloads and flow control (ethtool -K / -A) — only
    briefly helped, loss returns.
  5. Ruled out any software/intrusion cause (clean process and connection
    audit).

Since EEE-off, a new cable, an OS update, and offload changes all fail to
fix it, and three identical units on the same network are perfectly
stable, this points to a hardware fault in the onboard RTL8127 NIC of
this specific unit.

Serial number: 1983725002404

Please advise on the RMA process. Full ethtool and kernel-log dumps are
included below.

Thank you.

TECHNICAL EVIDENCE (attach / paste as needed)

[System]
DGX OS OTA version : 7.5.0 (was 7.3.1 before update; issue predates and
survives the update)
SW build : 7.2.3
Kernel : 6.17.0-1029-nvidia
NIC driver : r8127 11.014.00-NAPI
Serial number : 1983725002404
Interface : enP7s7 (192.168.0.35)

[ethtool enP7s7 — abnormal link negotiation]
Advertised link modes : 10baseT/Half 10baseT/Full ← abnormal
Link partner advertised : 10baseT/Half 10baseT/Full
Speed : 1000Mb/s ← inconsistent
Duplex : Full
Link detected : yes

[ethtool -S enP7s7 — error counters, current boot ~1h uptime]
rx_errors : 140356 (was 1,180,000+ on previous boot)
rx_mac_missed : 7138
rx_pause_on : 336
rx_pause_off : 333

[Kernel log — link flapping, STILL occurring after 7.5.0 update]
Jul 28 11:23:41 spark-da01 kernel: r8127: enP7s7: link up
Jul 28 11:23:41 spark-da01 kernel: r8127: enP7s7: link down
Jul 28 11:23:44 spark-da01 kernel: r8127: enP7s7: link up
(earlier boot: 12-minute outage 10:10:48 → 10:22:53)

[Overnight ping comparison — same gateway 192.168.0.1, ~13.7 h]
spark-a086 : 48603 sent, 48599 recv, 0.0082% loss
spark-0077 : 48763 sent, 48761 recv, 0.0041% loss
spark-da01 : 48318 sent, 43953 recv, 9.0339% loss ← THIS UNIT

12,14,35 인터넷비교
12,14,35 인터넷비교1920×1080 492 KB

2

Sounds like a hardware issue. Just RMA it.

3

Hello,

Thanks so much for providing useful technical background. While the networking information is helpful evidence, the RMA process specifically requires running the field diagnostics toolset (Docs: https://docs.nvidia.com/pdf/userguide-dgx-spark-fieldiag.pdf ). This will help narrow down whether this networking issue is hardware related or if there’s a potential software bug in play.

Thanks,
Zeke

4

Do I just return my DGX spark, the 1st day the GbE was unstable, after a couple of days It was working. Now it is not working again, I tried rebooting, and waiting, and that didn’t work. Changed cables, purchased better brands, I thought it was resolved. Now the issue reappeared. Check it out modinfo r8127 | grep version

version: 11.014.00-NAPI
srcversion: B8CE8DB6A21E011635749E6
vermagic: 6.17.0-1029-nvidia SMP preempt mod_unload modversions aarch64

ping 192.168.1.10

PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.

64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=1.24 ms

64 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=1.20 ms

64 bytes from 192.168.1.10: icmp_seq=6 ttl=64 time=0.990 ms

64 bytes from 192.168.1.10: icmp_seq=7 ttl=64 time=1.05 ms

64 bytes from 192.168.1.10: icmp_seq=8 ttl=64 time=1.05 ms

64 bytes from 192.168.1.10: icmp_seq=9 ttl=64 time=1.07 ms

64 bytes from 192.168.1.10: icmp_seq=10 ttl=64 time=0.616 ms

64 bytes from 192.168.1.10: icmp_seq=12 ttl=64 time=1.06 ms

64 bytes from 192.168.1.10: icmp_seq=13 ttl=64 time=1.05 ms

64 bytes from 192.168.1.10: icmp_seq=16 ttl=64 time=1.04 ms

^C

-– 192.168.1.10 ping statistics —

16 packets transmitted, 10 received, 37.5% packet loss, time 15230ms

rtt min/avg/max/mdev = 0.616/1.035/1.237/0.157 ms