TOS 7.0.1278 (x86) Official Release Update

[nolan39]

After the most recent update, I cannot get Plex to open. The port refuses to connect. O have tried uninstalling and reinstalling plex and even going back to an older version that worked and it still doesn't work.

[Crashoveride]

We tested this on TOS 7.0.1278 hardware. Your port isn't failing — it re-links fine at 5G. What's stuck is the data path (the MAC), which doesn't re-arm after your Mac's bus-powered adapter disappears overnight.

The main suspect is EEE (energy-saving Ethernet) at 5G: Realtek's own driver deliberately avoids advertising 5G EEE due to compatibility issues, but TOS ships it enabled.

Note: jumbo frames / MTU 8192 is almost certainly a red herring — a 42-byte ARP can't be affected by MTU, and your Mac captured 0 packets, meaning nothing ever left the NAS.

Please run this and leave it overnight:

Code: Select all

ethtool --set-eee eth1 eee off

Then power the Mac off/on as usual and check in the morning. Please report back:

• Did traffic work without a down/up?
• Output of

  Code: Select all

  ethtool --show-eee eth1

• If it still fails, the

  Code: Select all

  dmesg

  output covering the link flap

If this fixes it, we'll make the setting persistent.

EEE off did not fix it.

ethtool --set-eee eth1 eee off was applied yesterday and was still disabled this morning. After the Mac was powered off overnight and powered on again, ping 10.10.10.1 from the Mac failed with 100% packet loss. No interface reset was done before the test.

Code: Select all

ethtool --show-eee eth1
EEE status: disabled
Tx LPI: 13 (us)
Supported EEE link modes: 100baseT/Full 1000baseT/Full 2500baseT/Full 5000baseT/Full
Advertised EEE link modes: Not reported
Link partner advertised EEE link modes: Not reported

Code: Select all

ethtool eth1
Speed: 5000Mb/s
Duplex: Full
Link detected: yes

Code: Select all

arping -c 3 -I eth1 10.10.10.2
Sent 3 probes (3 broadcast(s))
Received 0 response(s)

dmesg, driver r8169 on 0000:03:00.0. Relevant link flaps only:

Code: Select all

[27931.143299] r8169 0000:03:00.0 eth1: Link is Down
[81148.354685] r8169 0000:03:00.0 eth1: Link is Up - 5Gbps/Full - flow control off
[84050.642164] r8169 0000:03:00.0 eth1: Link is Down
[84055.152361] r8169 0000:03:00.0 eth1: Link is Up - 5Gbps/Full - flow control off
[96331.414010] r8169 0000:03:00.0 eth1: Link is Down
[96335.907982] r8169 0000:03:00.0 eth1: Link is Up - 5Gbps/Full - flow control off
[114807.225693] r8169 0000:03:00.0 eth1: Link is Down
[167167.330801] r8169 0000:03:00.0 eth1: Link is Up - 5Gbps/Full - flow control off

The last pair is the overnight cycle: link down when the bus-powered adapter powered off, link up at 5Gbps/Full the next morning. No MAC or PHY error is logged, but ARP/ping still failed until ip link set eth1 down/up. 5G EEE was not advertised, so this is not only an EEE advertisement issue. Please check the MAC re-arm path in r8169 after a long link-down.

[Crashoveride]

Which drive bays on the F4-425 Pro are wired to the CPU’s native SATA controller, and which are wired to the ASMedia ASM1062?
The bays are numbered 1 to 4 from left to right when looking at the front. The power button is on the right, next to bay 4. Please say which bay numbers are on the CPU SATA ports and which are on the ASM1062.

[EriChan]

Looking at the front of the unit (numbered 1 to 4 from left to right):

• Bay 1 & Bay 2: Connected to the CPU's native SATA controller.

• Bay 3 & Bay 4: Connected to the ASMedia controller.

Hope this helps!

[TMjack]

Please perform the following verifications:

1. MTU verification: Change the MTU from 8192 to 1500 to determine whether the issue is related to Jumbo Frame configuration;
2. Link speed verification: Confirm whether the issue occurs only at 5Gbps, and test whether the same problem reproduces at 2500Mbps and 1000Mbps.

[Crashoveride]

Please perform the following verifications:

1. MTU verification: Change the MTU from 8192 to 1500 to determine whether the issue is related to Jumbo Frame configuration;
2. Link speed verification: Confirm whether the issue occurs only at 5Gbps, and test whether the same problem reproduces at 2500Mbps and 1000Mbps.

MTU 1500 did not fix it either.

Last night both sides were set to MTU 1500, and EEE on eth1 was still disabled. The Mac was powered off overnight and powered on this morning. No interface reset was done before the test.

ping 10.10.10.1 from the Mac: 100% packet loss.

Code: Select all

ifconfig en10
en10: mtu 1500

Code: Select all

ip link show eth1
eth1: mtu 1500 state UP

Code: Select all

ethtool --show-eee eth1
EEE status: disabled
Advertised EEE link modes: Not reported

Code: Select all

ethtool eth1
Speed: 5000Mb/s
Duplex: Full
Link detected: yes

So the failure reproduces with jumbo off and with 5G EEE disabled. The link returns at 5Gbps/Full, but the data path stays dead until ip link set eth1 down/up. This points to the r8169 MAC re-arm after a long link-down at 5Gbps, not to MTU or EEE.

I can test 1000Mbps next if you still want that comparison.

[apvm]

Just want to ask support if system and app are on the NVME m.2 ssd drive as volume 1 and hdd is volume 2 and is jsut storage not system or app, is it better and less errors?

[Gremlin]

If your system drive is on nvme, you don't want to have it on hdd as well. That would be mixing ssd and hdd on raid (raid1) array which is certainly not recommended. The only way to improve might be to have a second nvme to match the one carrying system+Vol1 and have at least the system mirrored (via the system drive migration tool.) Keeping your apps on the nvme is imo a good idea as it means if the apps have activity that does not need data, the hard drives don't need to spin up. (Although that can be hard to avoid if you are using the GUI and the system needs to display usage stats, etc.)

[MacStainless]

Is anyone else having issues with TimeMachine completing since this update? My "preparing to back up" statuses last a REALLY long time and backups keep failing after a while with little-to-no data getting copied over.

[Argonautica]

Is anyone else having issues with TimeMachine completing since this update? My "preparing to back up" statuses last a REALLY long time and backups keep failing after a while with little-to-no data getting copied over.

Just initiated a manual triggered backup to check:

"preparing" phase took about five minutes, and the copy was done in about 10 minutes (data copied was only about 18 GB)
"cleaning up" phase took another few minutes.

macOS Sequoia 15.8.1 and TOS 7.0.1278,
Time Machine config was newly setup on TOS 7, and not upgraded from earlier TOS versions.

What OS are you running, and did you upgrade from TOS 6 or earlier? It might help to setup another user on macOS and test a clean config.
If that works, you can try the same thing for your main account.