To test edison watchdog, I killed the watchdog-sample prgram, and after five minutes, the edion doesn't reboot.
So I disable the watchdog-sample service, and write an simple program to init watchdog, and don't feed the dog,
but the system still not reboot.
the init code:
int wdt_fd = open("/dev/watchdog", O_WRONLY);
int timeout = 60;
ioctl(wdt_fd, WDIOC_SETTIMEOUT, &timeout);
int prop = WDIOS_ENABLECARD;
ioctl(wdt_fd, WDIOC_SETOPTIONS, &prop);
after init the watchdog, no code to feed watchdog, and the edison system doesn't reboot at all.
So, how to use Edison watchdog?
I have found the source code of watchdog-sampl
the program is a sample service to show how to using sd_notify to watch a service.
It is not using hardware watchdog.
how to use the hardware watchdog? the file "/dev/watchdog"? why open the file fail?
the process runing include the following :
Should I use the watchdog configure file to config the systemd service to do some watchdog checking?
But threre are no such files in edison disk?
Currently, there are no official documents on how to configure the watchdog for the Edison. We are working on more documentation about the SOC and different features but there is no ETA yet.
Have you already tried with the files in /sys/devices/virtual/misc/watchdog ?
Do you want to disable the wathdog or you which is the goal you have?
I want to use hardware watchdog.
As a embeded device, need a hardware watchdog to keep the device stable.
I have check the folder /sys/devices/virtual/misc/watchdog, but don't know what to do with it.
So Need a document about watchdog.
CMata_Intel, Thank you very much.
We are facing some weird unexpected reboots on the Edison that might have to do with the watchdog.
We are doing the following loop:
1 Put the atom to sleep with the 'echo "mem" > /sys/power/state' command.
2 The MCU will kick in and gather some data from i2c sensors.
3 MCU will wake up the atom processor using host_send directive, and transfer all gathered data.
4 The atom will process data
After a few hours of doing the cycle (each last about 40s), eventually the Edison crashes and reboots. On the 'panic' file of crashlog_XXX.tar.gz we find the following:
[11281.958722] PM: Entering mem sleep
[11281.959002] Suspending console(s) (use no_console_suspend to debug)
[11282.088594] snd_intel_sst: runtime_resume called
[11282.111794] snd_intel_sst: runtime_suspend called
[11282.112128] bcmsdh_sdmmc_suspend Enter
[11282.112134] bcmsdh_sdmmc_suspend Enter
[11282.112144] bcmsdh_sdmmc_suspend Enter
[11282.113477] bcove_thrm bcove_thrm: suspend called.
[11282.179938] PM: suspend of devices complete after 70.328 msecs
[11282.181254] PM: late suspend of devices complete after 1.300 msecs
[11282.408502] PM: noirq suspend of devices complete after 227.153 msecs
[11282.408511] Disabling non-boot CPUs ...
[11282.410939] smpboot: CPU 1 is now offline
[11282.412218] SC device/devices not in d0i3!!
[11282.412229] pmu2_states = FFFFFFFC
[11282.412236] pmu2_states = FFFFFFFF
[11282.412242] pmu2_states = FFFFFF3F
[11282.412247] pmu2_states = FFFFFFFF
[11313.565492] wakeup from IRQ 47
[11313.565507] IRQ 47,action name:intel_psh_ipc
[11332.589347] PM: Entering mem sleep
[11332.589619] Suspending console(s) (use no_console_suspend to debug)
[11332.719107] snd_intel_sst: runtime_resume called
[11407.297842] intel_scu_watchdog_evo: [SHTDWN] watchdog_warning_interrupt, WATCHDOG TIMEOUT!
[11407.299437] Kernel panic - not syncing: Kernel Watchdog
The first part of the log shows when the atom is going to sleep and is waked up due to IRQ47, as expected. But the on the last time we issue the sleep command the watchdog interruption is triggered and the Edison crashes and reboots.
Any insights of what is happening? I feel that the watchdog is getting misconfigured somehow...
Which image are you using on the board?
The mem and freeze states are not working so the problems you have could be related with the usage of these states.
If you process the data from i2c withouth putting the atom to sleep, do you still have issues?
Thanks for the response Charlie,
We are using the image-280915 version along with the patch from this other thread . If we process the data without putting the edison to sleep no issues are present. With the sleep part included, the crashes are generated 3 to 5 hours after starting the edison and the program.
I think the 3.0 release is out now, do you know if the sleep support is working out of the box?
I'm able to run the mem and freeze states on the 3.0 release only it I stop & disable the wpa_supplicant with systemctl. If you want to use WiFi you will need to use connman to configure the interface, so you will have to start & enable the service with systemctl.
$sytemctl stop wpa_supplicant
$systemctl disable wpa_supplicant
$systemctl start connman
$systemctl enable connman
$echo –n mem > /sys/power/state
Let me know if this works for you too.
Yocto 3.0 image is released and I can put the Edison into sleep mode. However, there is a difference between the first time and the second time sleeping in current consumption. For example, at the first time sleeping, it just consumes about 2mA. But it consumes 5mA at the next time sleeping. So how can I fix this issue ?
I'm able to run the states if I stop and disable the wpa_supplicant service with systemctl, but as I said before the mem and freeze states are not currently working as they should in the image, so this is the reason why you can get some problems while using them.
My application requires to have a wifi connection after waking up the Atom from its sleep state and after rebooting. I used connman to configure the interface, as you had suggested previously, but after typing systemctl start wpa_supplicant or after rebooting the wpa_state was inactive.
So I tried configure_edison --wifi since on the 2.1 release there was no issue establishing a wifi connection after typing systemctl start wpa_supplicant or after rebooting. However, on the 3.0 release I do not get an IP in both cases, and I have to type udhcpc -i wlan0 -n in order to get an IP.
Could there be anything missing on the configure_edison script of the 3.0 release that is preventing getting an IP in the two described cases?
The problem could be that the wpa_supplicant is having conflicts with connman. Try to only use one of the services. Also, check the :/etc/wpa_supplicant/ wpa_supplicant.conf and verify you have the correct information regarding the network you are using.
Run the systemctl status to check the current state of them, and disable the one you are not using.
The mem and freeze states are not currently available on the 3.0 release, if you use them you may have the scenarios you mentioned. Currently, there isn't a workaround for this.
I did use only one of the services at a time when I tested each of them. Also, the network I was connected to was the only one in :/etc/wpa_supplicant/ wpa_supplicant.conf, and the info was correct. There seems to be a bug on the 3.0 release that is preventing to save the wifi setup after rebooting and after stopping the wpa supplicant. I'll keep using the 2.1 release until this issue is fixed.