Anyway, I've been in pitbull mode on this for too long. I've got my own things to do, and I can't spend time screwing around with this for now.
Two things I feel need further investigation. - First, changing /sys/power/state default value to "mem" only. This may fix things. but I'm not sure. - Second, I did a little reading about debugging power states, then did the minimalist test that can be done( freezer). The board still hung, and in fact I had to pull the power to get it out of suspend. On Wed, May 4, 2016 at 7:40 AM, William Hermans <[email protected]> wrote: > *Might be another rt bug? ;)* >> >> *Regards,* >> > > According to Documentation/power/states.txt, "disk" suspends to swap, > which we do not have . . . > > I'm convinced if I can somehow change /sys/power/state to just "mem", > without the system immediately going into suspend > . That I should make progress. > > On Wed, May 4, 2016 at 4:42 AM, <[email protected]> wrote: > >> I have 2 boards that I've been testing on that give the same results. One >> is a A5C 2 GB board (?) and the other is a 0C0 4 GB board (Element14). I'm >> not using any capes, just the bare board. >> >> I've been comparing 3.14 and 4.x code, but have not found any key >> differences other than code moving around from refactoring. I've tried >> looking at device tree stuff also, but I don't have the hardware background >> to fully understand most of that. >> >> In addition to trying rtcwake, I've also tried "echo mem > >> /sys/power/state" after setting a wakealarm through /sys and also trying to >> use the serial console as wakeup sources... I get the same frozen system >> with 4.x TI kernels. BUT, the system does respond to pushing the reset >> button to reboot from the "frozen" state. >> >> /sys/class/rtc/rtc0/device/power/wakeup <-- 3.14 is enabled >> /sys/class/rtc/rtc0/device/power/wakeup <-- 4.x is enabled >> >> When trying a mem sleep on 4.x kernels, user LED's 1 and 3 remain lit in >> the "frozen" state >> >> strace results for rtcwake on 3.14 TI kernel... >> >> root@beaglebone:~# tail test.txt >> sync() = 0 >> open("/sys/power/state", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4 >> fstat64(4, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 >> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) >> = 0xb6f8c000 >> write(4, "mem\n", 4) = 4 >> close(4) = 0 >> munmap(0xb6f8c000, 4096) = 0 >> ioctl(3, PHN_GET_REGS or RTC_AIE_OFF, 0) = 0 >> close(3) = 0 >> exit_group(0) = ? >> >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/b182222c-e834-46bd-8acf-f3058f818285%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/b182222c-e834-46bd-8acf-f3058f818285%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORprGkpfa9%3Do1kdoXbBjzKJbB4%3D46FXNrqnhGrJVtaAUqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
