[mythtv-users] WakeOnAlarm: Searching for the cause of failure

Craig Huff huffcslists at gmail.com
Thu Oct 4 18:47:57 UTC 2007


On 10/4/07, Peter Carlsson <maillist.peter at home.se> wrote:
>
> >> I am struggling to have my motherboard (Gigabyte GA-K8N51PVMT-9)
> >> WakeOnAlarm. I have been in contact with the Gigabyte support
> >
> > Peter,
> >
> > What linux kernel version are you using?  There is a known bug that got
> > introduced around version 2.6.21 that seems to affect multiple
> platforms,
> > but AFAIK, isn't universally inoperative.  Search the list archives for
> > more details.
> >
> > Craig.
>
> Craig,
>
> I'm running on 2.6.18-5-k7. Apart from the WakeOnAlarm issue my
> system works fine. Therefore, I'm a little bit reluctant to remove
> the TV-card and other parts to see if they cause the problem.
>
> I forgot to mention in my original post that it doesn't even work
> when I set the wakeup time directly in BIOS.
>
> Is this the thread that you meant?
> http://mythtv.org/pipermail/mythtv-users/2007-September/193326.html
>
> Reading the thread made me think what my /proc/acpi/wakeup file looked
> like, and here is what I have:
>
> htpc:~# cat /proc/acpi/wakeup
> Device  Sleep state     Status
> HUB0       5            disabled
> XVRA       5            disabled
> XVRB       5            disabled
> XVRC       5            disabled
> USB0       3            disabled
> USB2       3            disabled
> AZAD       5            disabled
> MMAC       5            disabled
> MMCI       5            disabled
> UAR1       5            disabled
>


Peter,

I will send more this evening if I find anything relevant when I get home,
but for now, see if this sheds any light:

I am running Fedora Core 6 and for the kernel version you're running, the
old ACPI alarm system applies, but
if you're not running FC, some of the following issues I encountered getting
it to work may not apply.

I found that /etc/init.d/halt included code to write the system clock back
to the hardware RTC on shutdown and
an article on the web led me to understand that many (if not all) mobo's
cancelled RTC alarms when this was
done until the alarm was set again.  I proceeded to modify my
/etc/init.d/halt script to add code that saved the
value of the alarm setting before the system clock was written out to the
RTC and then immediately reset the
alarm.  There should be e-mail traffic about this misadventure of mine in
the archives.

I then had to add code to detect an arbitrarily selected time value (in my
case midnight UTC) to be used as a
flag that I **didn't** want a wakeup to occur because otherwise my system
would keep waking up every day
at the time of the last selected alarm time. ;-(

With that code in place, then when I echoed a UTC time into
/proc/acpi/alarm, it worked, even with a simple
"# shutdown -h now".

Note that I am pointed about mentioning UTC because I have my system
configured to handle DST switching
automatically.  IIRC, using local time for the RTC results in disabling the
DST processing.

I tested the alarm with time settings automatically computed using the
"date" command and told it to add 60
or 120 seconds to the current time before stuffing the output into
/proc/acpi/alarm, after which I would shut
the system down and wait.

Once I had the alarm wakeup working, I pursued getting hibernation and
suspend to RAM working with
TuxOnIce (aka suspend2).  I have been very happy with its flexibility and
ease of control.

I can't recall if I needed to fiddle with anything in /proc/acpi/wakeup for
the ACPI alarm.  I **did** have to
work with it for successful WOL and wake-on-keyboard/mouse, and unsuccessful
wake-on-USB testing,
but that's a whole 'nother story.

HTH.

Craig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20071004/d44e7197/attachment.htm 


More information about the mythtv-users mailing list