Hello all,
Following up on my previous post, I have conducted further testing and have new, reproducible findings I believe strongly suggests a hardware-level issue.
I can consistently reproduce a NIC failure on my GTR9 unit, and this failure appears to be directly correlated with the unit’s operating temperature. The failure occurs reliably from a cold boot but is completely absent when the unit is hot.
Evidence
I have attached several images to document this behavior:
- Failure State (Images 1 & 2): From a cold boot (ambient temperature), the NICs consistently crash within 5 minutes of operation.
- Workaround (Image 3): After applying my previously mentioned workaround, the NICs are stable and function correctly.
- Extended Testing (Images 4 & 5): These images show the NICs operating successfully under load for an extended period. Image 5 includes a CPU stress test for completeness, which does cause a minor expected drop in NIC performance.
The Critical Finding
Here is the most significant part of my testing:
- Cold Boot: I can reproduce the NIC failure 100% of the time by power-cycling the unit from a cold, ambient temperature state (with Ethernet cable plugged in of course).
- Hot Boot: After running an extended burn-in test (with the unit reaching and maintaining approx. 75°C), the issue completely disappears. If I power-cycle the unit while it is still hot, the NICs are perfectly stable, and I can no longer reproduce the crash.
- Cool-Down: After letting the unit cool a bit the NICs became unstable but did not crash. Only after the unit was closer to ambient temperature was I once again able to consistently reproduce the failure.
Conclusion
This thermal-dependent behavior is highly uncharacteristic of a firmware issue. The fact that the fault is present when cold but absent when hot points clearly toward a hardware or manufacturing-level defect that is sensitive to thermal expansion/effect.
While it is possible this issue is isolated to my specific GTR9, it would be useful to know if others can replicate these findings.
Gathering a body of evidence is the best way to move this situation forward. This data would be crucial in urging Beelink to conduct a full hardware-level investigation, rather than relying on future NIC firmware to mitigate what is most likely a hardware fault. Identifying the root cause is essential for ensuring it is corrected in the manufacturing chain and for providing a solution to those with affected units.
My previous post details the workaround: kstuart
—
No workaround, NIC failure 1
No workaround, NIC failure 2
Workaround applied
Burn-in 1 hour
Burn-in 2 hours
