[mythtv-users] can't get wakealarm to write to BIOS

[Marius Schrecker]

On Saturday, December 9, 2017 07:53 CET, Greg Oliver <oliver.greg at gmail.com> wrote:
 On Sat, Dec 9, 2017 at 12:28 AM, Mike Hodson <mystica at gmail.com> wrote:On Fri, Dec 8, 2017 at 7:13 PM, Bill Meek <keemllib at gmail.com> wrote:On 12/08/2017 12:53 PM, Marius Schrecker wrote:$sudo bash -c "echo `date '+%s' -d '+ 6 minutes'` > /sys/class/rtc/rtc0/wakealarm Use: echo `date '+%s' -d '+ 6 minutes'`| sudo tee /sys/class/rtc/rtc0/wakealarm" Bill, normally sudo of echo redirecting will not work; the user-shell is still used for redirection.However, in his case, not only is he running bash -c "full command with redirect", but he also later cats the result in /sys/class/rtc/rtc0/wakealarm and comes up with the proper time/date. >>>> $date>> fr. 08. des. 19:42:53 +0100 2017>> $sudo bash -c "echo `date '+%s' -d '+ 6 minutes'` > /sys/class/rtc/rtc0/wakealarm">> $ cat /sys/class/rtc/rtc0/wakealarm>> 1512758974>> $ date -d @1512758974>> fr. 08. des. 19:49:34 +0100 2017>> I've even performed an empirical test, and indeed as long as the redirect is within the double-quotes of bash -c "command here > file" it works for me in a different scenario: mike at bifrost /root $ sudo bash -c "echo `date '+%s' -d '+ 6 minutes'` > derp"  
Password:  
mike at bifrost /root $ ls -al derp 
-rw-r--r-- 1 root root 11 Dec  9 01:21 derp
mike at bifrost /root $ cat derp 
1512800877
 Thus I have to believe that Marius's shell is indeed writing the exposed rtc device properly, unless there are some syntax quoting issues somewhere else..  I'm puzzled here, and am curious if A:  it has ever worked at all properly, and if not, B: if the BIOS is buggy? Mikeecho $(date +%s -d "+6 minutes")

Hello Greg, Mike and Bill,

 Thanks very much for your responses.

I have never tried this before on this board as the machine was previously on 24/7. The current project is largely to do with splitting the high availability services out into a low-powered device to save power.

The BIOS may be buggy, but I'm pretty sure I updated to what is still the latest version shortly after buying the board. Will check next time I turn it on with a screen attached (don't have time right now).

A couple of things I forgot to mention yesterday:

1. A thing that came up when googling was that back in 2014, quite a few people were complaining that RTC wakeup alarms (on other boards) were only working when HPET is disabled on the startup kernel parameters. I haven't tried that yet, but will.

2. A new
$cat /sys/class/rtc/rtc0/wakealarm
and
$cat /proc/driver/rtc
after reboot confirm that the alarm is set way into the future, confirming the BIOS screen.

3. This is a completely fresh install of Ubuntu 17.10 (originally desktop, but with all the desktop stuff removed). Can anyone think of a service that might be running and resetting the rtc alarm to a diferent value when the machine is shut down?

4. Can anyone explain the following results of catting /proc/driver/rtc?

alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no

Can they indicate that the values of /proc/driver/rtc are not being written by the os into the BIOS?

BR.

--Marius--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20171209/ac33c3eb/attachment.html>