Sometimes i come across the following kernel print while driving the system to mem state. I use the command "systemctl stop wpa_supplicant" before going to sleep.
Please note that this is a very rare occurence. Any ideas as to why this happens?
[64480.039038] intel_scu_watchdog_evo: watchdog_stop
[64480.085933] pci_pm_suspend(): sdhci_pci_suspend+0x0/0xd0 returns -16
[64480.085950] dpm_run_callback(): pci_pm_suspend+0x0/0x1d0 returns -16
[64480.085965] PM: Device 0000:00:01.3 failed to suspend async: error -16
[64480.107247] PM: Some devices failed to suspend
Thanks in advance,
Thanks for reaching out!
I tried to replicate this behavior on my Edison but I was not able to do so. I would like to ask you about your environment and how you are able to see this behavior. Are you running any specific application when you try this? What exactly are the steps you take when attempting this?
Let me know.
My system has a custom board having Intel Edison and another controller(STM) working in parallel. The device goes in and out of sleep frequently. So there is a need of waking up Edison from the controller. Earlier we used serial interrupts to wake up Edison from "mem" state. But since we had few experiences of Edison not waking up consistently made me think of using the reset line for the same. Later, whenever i wanted to wake up Edison, i toggled the reset line of Edison from controller for about 200ms. This really works for most of the time, but seldom i see "some devices failed to suspend" error from kernel. Our system uses Wifi in its active mode and it is switched off before entering sleep.
Another useful info: During fast wake up, reset line of Edison is toggled by controller, during which Edison might be in the process of switching into sleep mode. I dont know if this is the correct way to do this, Please help and let me know if you want further information.
Firmware version: 3.10.98-poky-edison+
Thanks in advance,
First of all, I would like to point out that since you are using a custom board, the issue is out of the support scope. However, I'll do my best effort to help you, just keep in mind that since I don't have access to the specific hardware, it will be very difficult for me to replicate the behavior on your board and to provide accurate suggestions.
Anyway, you mentioned that you are using the reset line to wake the board. Are you referring to the line mapped to the power button? The other thing I'm interested in asking is, how exactly do you put your Edison to sleep? What your exact commands? When this happens, does the sleep abruptly interrupts any running application? Or, are all your applications closed safely before you make the Edison sleep?
I'll be waiting for your response.
Thanks for the reply. Yes, i was referring to the line mapped to the power button. These are the commands that i use for making Edison sleep:
system("ifconfig wlan0 down");
system("systemctl stop wpa_supplicant");
system("echo -n ""mem"" > /sys/power/state");
After moving Edison into low power mode, i use the reset line to wake it up from sleep. This reset can occur at any time. Even while Edison is transitioning into sleep mode.
Thank you for sharing this information, I've got a few questions:
How are you programming the board? Is this in a C/C++ script or in an Arduino sketch?
Which image are you using? What's the output of cat /etc/version?
Let me know.
This behavior seems very weird, but I have some comments that may help you. Let me summarize first what I understood from your description. Please correct me if I'm wrong.
1. You are running your application normally, but at some point you configure the Edison to enter in sleep mode. Before doing this, you disable Wi-Fi. This process is done by running these commands:
system("ifconfig wlan0 down"); system("systemctl stop wpa_supplicant"); system("echo -n ""mem"" > /sys/power/state");
Here is where you get the messages you mentioned in your first post, right? The ones about some devices failed to suspend. As far as I understood you, this doesn't happen all the times, just in some few times, correct? At this point, when you get that message, does the system go into sleep mode anyways or that message prevents the system from going into sleep mode? If the message prevents the system from going into sleep mode, it could be because at that specific moment the system was performing a particular task that cannot be ended. I'd suggest to try to run again the system("echo -n ""mem"" > /sys/power/state"); command to see if the system goes into sleep mode some few seconds later.
2. To wake up the system, you use the reset line that goes to the power button. I suppose you don't have this "power button" in your custom board. Instead, you have this signal connected to the other controller, right? I don't see any issue in the "waking up" part, unless I had misunderstood something. The only detail is with the "fast wake up" you mentioned. I'm not entirely sure about this since I haven't tested it, but you should wait until the Edison ends the process of switching into sleep mode, otherwise, the Edison won't read this wake up signal since he is performing other tasks at that moment, or it may read it but the system may not return properly from the sleep mode. As I said, I'm not sure about this behavior because I haven't tested it before, so I could be wrong. If you haven't faced any issue with this part so far, then I'd say that there is no problem in waking up the Edison using the way you describe.
We have more information on this bug. The problem is mmc (Device 0000:00:01.3) not suspending properly . However, during this error situation Edison does go into low power mode , but after around 10 to 15 seconds to enter mem state. At this point it shows the following kernel print :
[ 1042.042253] intel_scu_watchdog_evo: watchdog_stop
[ 1042.089258] pci_pm_suspend(): sdhci_pci_suspend+0x0/0xd0 returns -16
[ 1042.089275] dpm_run_callback(): pci_pm_suspend+0x0/0x1d0 returns -16
[ 1042.089289] PM: Device 0000:00:01.3 failed to suspend async: error -16
[ 1042.110486] PM: Some devices failed to suspend
Is this bug fixed in the latest yocto image ?
Unfortunately no, this issue is not fixed on the current image. We will report this issue with the development team. But please keep in mind that sadly, as you can see in https://communities.intel.com/docs/DOC-112093 https://communities.intel.com/docs/DOC-112093, there are no further software releases planned for Edison.
We apologize for any inconvenience this might cause.
We've reached out to the development team but sadly, due to the announcement of Edison's discontinuance, they have confirmed that there will not be any new releases addressing any of Edison's bugs present in the current image.
We can confirm that this bug was not reported before you did and unfortunately there are no workarounds to it.
We would like to apologize for the inconveniences this might bring to your team.
Its very disappointing to know that there wont be any updates in future. Am i the first user to report this bug? I know that this is out of your scope, but is there any other way to sort out this issue or a workaround. Is there any forums out there to reach out for a fix? Please note that we are in the final stage of our product development which is in field trials now. If you can consider this as a special case and help us out , it would be really helpful.