Steps to reproduce:
ifconfig eth0 down
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo +10 > /sys/class/rtc/rtc0/wakealarm
echo mem > /sys/power/state
Expected result: Wake up from suspend after 10 seconds
Actual result: Wake up never happens
Colibri iMX6ULL 512MB IT V1.1A
Linux BSP 5.7.0
Hi @vcds
Welcome to Toradex Community.
Is this a custom Linux image or a default toradex image? Please note wake-on-lan is not enabled in our default Linux image. Enable the fsl,magic-packet flag in Device-tree and update the same in Linux BSP.
Please refer to the linkfor more information.
Hello @ashok.tx
This issue can be reproduced with the stock Linux Reference Minimal Image.
However, please note that this issue is not about wake-on-lan. We are setting the alarm on the real-time clock to wake up the module from suspend. Regardless of the status of the Ethernet interface, it should work.
In fact, this issue does not occur with BSP 5.3.0 or earlier. It seems that something was changed from 5.4.0 onward and since then this issue has carried on to all the later versions.
Hi @vcds ,
Yes , we are also able to see the issue.
It happens only in case we do it down manually (ifconfig eth0 down).
Suspend mode deactivates the ethernet as well, and get resumed after wakeup, so why do you want it do it manually?
Also, in case if LAN is disconnected from the network, then also it is able to wakeup.
Any specific need to do that?
Our application automatically turns the Ethernet interface down whenever it is not required, so as to reduce battery consumption as much as possible. That is, the decision to turn the Ethernet interface down is taken by the application independently of when to enter the suspend state.
Since you have confirmed the reproducibility of the issue, please forward this bug to the maintainers so that it may be fixed in the next patch release of 5.7.
Thanks and regards.
Hi @vcds ,
Apologies for delayed response. This issue is fixed in quarterly release Q1 2023 BSP6.1. Kindly test and let us know if you still face same issue.
Hello @sahil.tx , @henrique.tx , @marcel.tx,
Sorry for my delayed response but I was down with fever after Embedded World. 
Anyway, I just tested this on stock reference BSP6.1 (6.0.17-6.1.0+git.71e1e02850ab) and…it has not been “fixed”, but rather something more twisted is now happening. The system seemingly goes to sleep only for a fraction of a second before waking up, regardless of the value that is written to wakealarm.
The systemd-journald logs look like this when I attempt to run the same script as in my original post in this thread:
Mar 22 09:01:39 systemd-networkd[406]: eth0: Link DOWN
Mar 22 09:01:39 systemd-journald[114]: Forwarding to syslog missed 1 messages.
Mar 22 09:01:39 systemd-networkd[406]: eth0: Lost carrier
Mar 22 09:01:39 kernel: PM: suspend entry (deep)
Mar 22 09:01:39 kernel[193]: [ 1432.658733] PM: suspend entry (deep)
Mar 22 09:01:39 kernel: Filesystems sync: 0.069 seconds
Mar 22 09:01:39 kernel[193]: [ 1432.735638] Filesystems sync: 0.069 seconds
Mar 22 09:01:40 kernel: Freezing user space processes ... (elapsed 0.003 seconds) done.
Mar 22 09:01:40 kernel: OOM killer disabled.
Mar 22 09:01:40 kernel: Freezing remaining freezable tasks ... (elapsed 0.005 seconds) done.
Mar 22 09:01:40 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Mar 22 09:01:40 kernel: PM: suspend devices took 0.090 seconds
Mar 22 09:01:40 kernel: Disabling non-boot CPUs ...
Mar 22 09:01:40 kernel: usb-conn-gpio connector: repeated role: device
Mar 22 09:01:40 kernel: PM: resume devices took 0.360 seconds
Mar 22 09:01:40 kernel: OOM killer enabled.
Mar 22 09:01:40 kernel: Restarting tasks ... done.
Mar 22 09:01:40 kernel: random: crng reseeded on system resumption
Mar 22 09:01:40 kernel[193]: [ 1432.762748] Freezing user space processes ... (elapsed 0.003 seconds) done.
Mar 22 09:01:40 kernel[193]: [ 1432.777458] OOM killer disabled.
Mar 22 09:01:40 kernel[193]: [ 1432.784474] Freezing remaining freezable tasks ... (elapsed 0.005 seconds) done.
Mar 22 09:01:40 kernel[193]: [ 1432.804591] printk: Suspending console(s) (use no_console_suspend to debug)
Mar 22 09:01:40 kernel[193]: [ 1432.903777] PM: suspend devices took 0.090 seconds
Mar 22 09:01:40 kernel[193]: [ 1432.946161] Disabling non-boot CPUs ...
Mar 22 09:01:40 kernel[193]: [ 1433.192672] usb-conn-gpio connector: repeated role: device
Mar 22 09:01:40 kernel[193]: [ 1433.330345] PM: resume devices took 0.360 seconds
Mar 22 09:01:40 kernel[193]: [ 1433.364001] OOM killer enabled.
Mar 22 09:01:40 kernel[193]: [ 1433.370641] Restarting tasks ... done.
Mar 22 09:01:40 kernel: PM: suspend exit
Mar 22 09:01:40 systemd-networkd[406]: usb0: Lost carrier
Mar 22 09:01:40 kernel[193]: [ 1433.404073] random: crng reseeded on system resumption
Mar 22 09:01:40 systemd-networkd[406]: usb0: DHCPv6 lease lost
Mar 22 09:01:40 kernel[193]: [ 1433.438631] PM: suspend exit
Mar 22 09:01:40 systemd-timesyncd[136]: No network connectivity, watching for changes.
Mar 22 09:01:40 systemd-networkd[406]: usb0: Gained carrier
Mar 22 09:01:40 systemd-timesyncd[136]: Network configuration changed, trying to establish connection.
Please tell me if I am doing something wrong or you can also see the same behavior.
Regards,
Vaibhav
@sahil.tx @henrique.tx @marcel.tx
I have retested with BSP 6.1 as well as the latest nightly BSP 6.2 (6.1.21-6.2.0-devel+git.e3a87a10f259). In both the cases, I can reproduce the issue that I described in post #9 every single time.
Hi @vcds ,
We tested it again and not able to reproduce the issue.
Are you using any custom board, rtc ?
Any changes you did in device tree ?
Can you share a video of the issue getting reproduced.
Also send dmesg logs
We are using a custom carrier board, but we are not using any external rtc. The rtc0 device is the same one that is on the Toradex Colibri module itself.
I will prepare a video of the screen recording soon…
Also, we have made no changes to the device tree.
hi @vcds,
We tested with rtc0 as well and it is working as expected.
root@colibri-imx6ull-03073134:~# tdx-info
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 6.1.22-6.2.0+git.3b29299e5f60 #1 SMP Thu Mar 30 10:49:31 UTC 2023
Kernel command line: user_debug=30 ubi.mtd=ubi root=ubi0:rootfs rw rootfstype=ubifs ubi.fm_autoconvert=1 console=tty1 console=ttymxc0,115200n8 consoleblank=0 video=mxsfb:640x480M-16@60
Distro name: NAME="TDX Wayland with XWayland Upstream"
Distro version: VERSION_ID=6.2.0-build.6
Hostname: colibri-imx6ull-03073134
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Colibri iMX6ULL 512MB on Colibri Evaluation Board V3
Toradex version: 0040 V1.0A
Serial number: 03073134
Processor arch: armv7l
------------------------------------------------------------
Can we check it at your end remotely?
I just noticed something: it seems you are testing on V1.0A of the module, whereas we are using specifically V1.1A (IT). Can you please test on V1.1A (IT) at your end let me know the results?
Hi @vcds ,
we tested on V1.1A as well.
Since you are using custom board, one more possibility can be to check state of SODIMM_45.
SODIMM PIN 45 is used as wake-up GPIO on Colibri modules
Hi @vcds ,
This is in continuation to our discussion
Let us know after testing if you still face the issue