TerraMaster Forum

F5-221 - TOS 6.0.794:
Anyone seen, or have an explanation for this: (from 'dmesg' and appearing on terminal)

Troubleshooting steps:

1. It is recommended to first try a different LAN port and Ethernet cable for cross-testing, in order to rule out possible issues such as poor port contact, cable aging, link negotiation abnormalities, or network device compatibility problems.

2. Please pay attention to when the error occurs and check whether it mainly happens during high network load scenarios, such as continuous large file transfers, data synchronization, Docker/virtual machine operation, download tasks, or simultaneous multi-client access. Sustained heavy traffic may increase pressure on the NIC transmit queue and trigger driver-related exceptions.

3. It is also recommended to monitor the device’s CPU usage, system load, and memory utilization during operation. If system resources remain under high usage for extended periods, it may affect network packet processing efficiency and potentially lead to network driver timeouts or queue-related issues. You may try reducing the number of simultaneously running applications, containers, or background tasks, and then observe whether the issue still occurs.

4. If possible, please also provide your current network environment and the specific usage scenario when the error occurs, so we can further assist with troubleshooting and issue analysis.

Felix wrote: ↑08 May 2026, 19:33

This is a remote device acting as a backup machine and serving backup copies to (an)other device(s). Mostly it is unattended and automated. I first noticed the batch errors on the remote terminal (on a kvm switch) when I was attending to something else. I would imagine that the time stamps speak for themselves, but I don't know how to interpret them. Apart from the batch listed, there were 2 other consecutive instances of the error at a later date/time. This is not a heavily worked device.

I will occasionally see an error raised by my backup app(s) (Win11 3rd party) for a "network error" but I have not done "2+2=4" analysis (as I didn't know about this error). When I get the chance I will check the cable but there is no error on eth1 which uses the same circuits. Note that this is one of the -221 devices that has enabled 2.5Gbe on lan1 (ETH0) since later TOS6 updates. Lan1 is listed first in the service sequence. LAn1 and Lan2 operate independently. Lan2 is mostly used to connect 'slow' devices eg terminal sessions etc. All switches are 2.5Gbe minimum. All my nas devices utilise fixed-ip setup.

My research leads me to believe this is a failure of the driver incorporated in the linux kernel. There are many supposed fixes available/suggested including loading a different driver and disabling the built-in driver. I had rather hoped that, being a mature system now. @TM would have encountered this already and would have workable fixes already defined for the specifics of TOS. it is quoted as a BUG! From your message, I guess not.

Alternative Ethernet Drivers (LAN)

r8168: A commonly used replacement for the kernel’s stock r8169 driver. This is required for improved compatibility with many Realtek Gigabit controllers.
r8125: If you are using a 2.5G Ethernet Realtek card (RTL8125), the stock r8169 driver is often poor. Using the dedicated r8125 driver is the recommended alternative for higher stability.

Gremlin wrote: ↑08 May 2026, 23:07

We apologize for the inconvenience. The relevant issue has been submitted to our product team, and they are verifying it. However, it will take some time, and we will be able to get back to you later.

Gremlin wrote: ↑08 May 2026, 23:07

Felix wrote: ↑08 May 2026, 19:33

This is a remote device acting as a backup machine and serving backup copies to (an)other device(s). Mostly it is unattended and automated. I first noticed the batch errors on the remote terminal (on a kvm switch) when I was attending to something else. I would imagine that the time stamps speak for themselves, but I don't know how to interpret them. Apart from the batch listed, there were 2 other consecutive instances of the error at a later date/time. This is not a heavily worked device.

I will occasionally see an error raised by my backup app(s) (Win11 3rd party) for a "network error" but I have not done "2+2=4" analysis (as I didn't know about this error). When I get the chance I will check the cable but there is no error on eth1 which uses the same circuits. Note that this is one of the -221 devices that has enabled 2.5Gbe on lan1 (ETH0) since later TOS6 updates. Lan1 is listed first in the service sequence. LAn1 and Lan2 operate independently. Lan2 is mostly used to connect 'slow' devices eg terminal sessions etc. All switches are 2.5Gbe minimum. All my nas devices utilise fixed-ip setup.

My research leads me to believe this is a failure of the driver incorporated in the linux kernel. There are many supposed fixes available/suggested including loading a different driver and disabling the built-in driver. I had rather hoped that, being a mature system now. @TM would have encountered this already and would have workable fixes already defined for the specifics of TOS. it is quoted as a BUG! From your message, I guess not.

Alternative Ethernet Drivers (LAN)

r8168: A commonly used replacement for the kernel’s stock r8169 driver. This is required for improved compatibility with many Realtek Gigabit controllers.
r8125: If you are using a 2.5G Ethernet Realtek card (RTL8125), the stock r8169 driver is often poor. Using the dedicated r8125 driver is the recommended alternative for higher stability.

Thank you very much for your patience. Regarding the device log errors you reported, our technical team has conducted an in-depth review and analysis of the underlying driver code and has compiled the following conclusions for you:
1. This is a "Protective Mechanism," not a "Fault."
This notification is actually a self-protection logic triggered by the system to ensure network stability.
In specific scenarios involving high concurrency or fluctuations in system load, the flow control mechanism within the kernel's network stack may experience a very brief "state synchronization delay." To prevent anomalies caused by data packets being forcibly written when buffer resources are insufficient, the driver actively intercepts these packets and signals the upper-layer network to temporarily "pause sending" (Stop Queue) and retry later.
2. Why does this not affect usability?
The log message you observed is actually proof that the driver is "functioning correctly." It does not result in data loss; rather, much like a traffic police officer, upon seeing congestion at an intersection (the buffer), it immediately signals subsequent vehicles (data packets) to stop and queue up, releasing them only once the path is clear (i.e., the hardware has finished transmitting data). Therefore, this is an inherent design characteristic and does not compromise the device's core functionality or the integrity of data transmission.
3. Recommendations for Next Steps
Routine Use: If you only encounter this message occasionally in the logs, and your network functions (web browsing, file transfers) remain fully operational, please rest assured that the device is working as intended; no further action is required on your part.
Advanced Troubleshooting: If, however, you encounter tangible issues that negatively impact your user experience—such as interrupted file transfers or network disconnections—please be sure to schedule a remote support session via the live chat window on our official website. We will arrange for a senior engineer to conduct a further investigation to determine whether any hardware interrupt anomalies or deeper resource conflicts are present.
Thank you once again for your understanding and support!

Understood.
However, I am not certain I would describe a "bug" error message appearing on the (hdmi) terminal window after login being enabled as a "feature".
Is it possible/feasible that I could load alternative drivers that would survive a reboot? Method(s), configuration files? For my own peace of mind, education, satisfaction.

Gremlin wrote: ↑11 May 2026, 15:22

This error message should not be described as a "feature," but rather understood as a necessary fallback protection mechanism in normal driver design.

Occasionally occurring: This is a "false wake" fallback of the lockless stop/wake mechanism, a normal phenomenon, not a feature, but a brief state allowed by the design.