Wake on Lan doesnt work with Etherwake but works OK with Windows based Tool (ECHO Type)

Hi,

We tried to enable wake on lan on the Orin. Following the guidelines of Nvidia , we tried to use Etherwake to wake up the Orin after putting it in Suspend. We are not able to wake the Orin up.

sudo ethtool -s eno1 wol g
→ Check the status in eno1 confirmed it is turned on.

sudo systemctl suspend

Using another Orin ,

sudo etherwake -i eno1 MAC_ADDR

We have tried to use other Host PC ,Windows Store tools that send ECHO type packet instead, and using ECHO type packet it works, we were able to wake up the system.

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I’ll address the question about enabling Wake on LAN (WOL) on the Jetson AGX Orin.

Wake on LAN (WOL) on Jetson AGX Orin

The question mentions that the user followed NVIDIA’s guidelines to enable WOL on the Orin, but they were unable to wake up the device using Etherwake. However, using a Windows Store tool that sends an ECHO-type packet, they were able to wake up the system.

Analysis

The provided context does not explicitly mention WOL or Etherwake. However, it does mention the Jetson Orin NX Series and Jetson AGX Orin Series, which suggests that the question is related to these devices.

The Jetson Orin NX Series and Jetson AGX Orin Series Product Design Guide (DG-10931-001_v1.4) provides information on the module’s power management features, including sleep modes. Specifically, it mentions the MOD_SLEEP* pin (Pin #178), which indicates when the module has gone to Sleep (SC7) mode.

Comparison with Other Devices

The question mentions that using a Windows Store tool that sends an ECHO-type packet worked, while Etherwake did not. This suggests that the issue might be specific to the Etherwake tool or the way it is configured.

Recommendations

To troubleshoot the issue, I recommend the following:

  1. Verify that the MOD_SLEEP* pin is properly configured and that the module is indeed in Sleep (SC7) mode when trying to wake it up using Etherwake.
  2. Check the Etherwake configuration and ensure that it is sending the correct magic packet to the Orin’s MAC address.
  3. Try using a different tool or method to send the magic packet, such as the Windows Store tool that worked previously.
  4. Consult the NVIDIA documentation and forums for any known issues or workarounds related to WOL on the Jetson AGX Orin.

Conclusion

While the provided context does not provide a direct answer to the question, it suggests that the issue might be related to the configuration or tool used to send the magic packet. By verifying the MOD_SLEEP* pin configuration, checking the Etherwake configuration, and trying alternative tools or methods, the user may be able to resolve the issue and successfully wake up the Jetson AGX Orin using WOL.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

Is it a custom board or NV devkit? Which Jetpack is in use?

It is the standard dev kit AGX Orin with Jetpack 6.2.1.

May I check your full uart log when trying with etherwake?

echo_wol_ok.txt (11.6 KB)

etherwake_wol_fail.txt (1.5 KB)

Hi Wayne,

Attached is the UART log of the targetted Orin device that trying to be waken up from.

One log is using the Etherwake command , and another one is using a Echo packet type from Windows Host PC.

please give me the log includes the full boot up log too but not just logs after SC7…

poweron-boot-wol-suspend.txt (80.7 KB)

This is the full log from power on → suspend

@WayneWWW
Any updates ? Let me know if you would need some other logs.

Hi,

We tested the rel-36.4.4 and we could see WOL to wake device with Linux host.

Would you able to deduce any missing settings on our ends in the UART log ?
I believe our team didnot modify any settings after installing the rel-36.4.4

What is the method you used to trigger the suspend?

We were using

systemctl suspend

Also tested using the Ubuntu Power Option → Suspend.

Hi Wayne,

Would you mind providing your test steps so that I can try to mimic again on my end?

Hi Wayne,

Is there a way to read from any UART log to check the corresponded Wake Event that triggers SC7 Exit ? Base on some experiments, disabling the Ethernet TX signals from the Host side can also triggers SC7 Exit.

WAKE_MASK[63:32] = 0x1000000

It is the wake mask showing in your log.

STATUS_R[63:32] = 0x1000000

It is the wake status showing in your log.

STATUS_R[63:32] = 0x1000000 => It means that it is waken by Bit 56.

You can simply find the following line in pmc.c to know it is caused by mgbe.

static const struct tegra_wake_event tegra234_wake_events[] = {
  	..
  	TEGRA_WAKE_GPIO("mgbe", 56, 0, TEGRA234_MAIN_GPIO(Y, 3)),

Please simply refer to the following steps to verify WoL.

[AGX-Orin]

$ sudo ethtool -s eno1 wol g
$ sudo systemctl suspend

[Host PC]

$ sudo apt-get install wakeonlan
$ wakeonlan -i <DUT-IP-Address> <DUT-HW-Address>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.