search

alexdupre / rtl_bsd_drv

19 stars 3 forks source link

Working wol? #8

Open gpz1100 opened 11 months ago

gpz1100 commented 11 months ago

How does one do the debian equivalent of "ethtool -s interface wol g" to enable the wol flag on bsd?

ifconfig INT wol or ifconfig INT up wol appears to have no effect as far as enabling wol.

Is this even supported by the driver?

alexdupre commented 10 months ago

Never tested personally, but the WOL support via the magic packet (wake(8)) should be automatically enabled on FreeBSD, you can verify the existence of the WOL_MAGIC capability via ifconfig. With that being said, you might need to enable the hw.re.s5wol and/or hw.re.s0_magic_packet sysctl variables to make it working. Let me know if you'll be successful.

gpz1100 commented 10 months ago

Thanks for suggesting those. These parameters are very scarcely documented. Wish I knew about this 3 weeks ago when changing the nas over to TN scale simply because I needed working WOL.

hw.re.s5wol is required and works hw.re.s0_magic_packet appears to be optional when the s5wol is set true. Used by itself (s5wol not used), wol doesn't work at all.

My interpretation would be s5wol sets wol enabled, while the magic_packet option sets what wol should respond to. However, even without magic packet, system did not turn on when pinged or it's ip address accessed in some way. I left both enabled just in case.

For truenas core 13, they entered as loader types under tunables.

PS. Also noticed improved performance with the 1.99 driver over the TN included 1.96. Was able to *achieve line speed (2.37 gbps) per iperf3 in both send/receive.

* Strangely, after a reboot, doing the send test first (where rtl8125 was on the receiving end), speeds were all over the place (1.5 - 1.8 gbps). Performing a receive test (where rtl8125 was sending), set what ever had to be set so now both send/recv were full speed (2.37gbps). Client used for testing is a win10 box with a rtl8125B. Host is a truenas vm with rtl8125 in passthrough mode under proxmox (older version of the nic).

In further testing, 1.99.04 appears to be unstable. After a while of running iperf3 tests and moving files back and forth, the driver would just stop working. Dropping down to 1.96.04 would restore connectivity, but going back to 1.99 would not. Rebooting the truenas vm not enough, have to reboot the proxmox host to get 1.99 working again.

alexdupre commented 10 months ago

Can you check if you experience the issue with the 1.98 version, too?

Thanks for the feedback, I've updated the port's pkg-message with the WoL info.

gpz1100 commented 10 months ago

Alex, I don't recall seeing this issue in the brief 1.98 testing. I did notice speeds were similar to 1.96_04 with 1.98.

Are there key differences in the codebase between the two? The stall is a really bizarre in that there's nothing in dmesg to indicate any kind of fault.