On 10/4/07, <b class="gmail_sendername">Peter Carlsson</b> <<a href="mailto:maillist.peter@home.se">maillist.peter@home.se</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>> I am struggling to have my motherboard (Gigabyte GA-K8N51PVMT-9)<br>>> WakeOnAlarm. I have been in contact with the Gigabyte support<br>><br>> Peter,<br>><br>> What linux kernel version are you using? There is a known bug that got
<br>> introduced around version 2.6.21 that seems to affect multiple platforms,<br>> but AFAIK, isn't universally inoperative. Search the list archives for<br>> more details.<br>><br>> Craig.<br><br>Craig,
<br><br>I'm running on 2.6.18-5-k7. Apart from the WakeOnAlarm issue my<br>system works fine. Therefore, I'm a little bit reluctant to remove<br>the TV-card and other parts to see if they cause the problem.<br><br>
I forgot to mention in my original post that it doesn't even work<br>when I set the wakeup time directly in BIOS.<br><br>Is this the thread that you meant?<br><a href="http://mythtv.org/pipermail/mythtv-users/2007-September/193326.html">
http://mythtv.org/pipermail/mythtv-users/2007-September/193326.html</a><br><br>Reading the thread made me think what my /proc/acpi/wakeup file looked<br>like, and here is what I have:<br><br>htpc:~# cat /proc/acpi/wakeup<br>
Device Sleep state Status<br>HUB0 5 disabled<br>XVRA 5 disabled<br>XVRB 5 disabled<br>XVRC 5 disabled<br>USB0 3 disabled<br>USB2 3 disabled
<br>AZAD 5 disabled<br>MMAC 5 disabled<br>MMCI 5 disabled<br>UAR1 5 disabled<br></blockquote></div><br><br>Peter,<br><br>I will send more this evening if I find anything relevant when I get home, but for now, see if this sheds any light:
<br><br>I am running Fedora Core 6 and for the kernel version you're running, the old ACPI alarm system applies, but <br>if you're not running FC, some of the following issues I encountered getting it to work may not apply.
<br><br>I found that /etc/init.d/halt included code to write the system clock back to the hardware RTC on shutdown and<br>an article on the web led me to understand that many (if not all) mobo's cancelled RTC alarms when this was
<br>done until the alarm was set again. I proceeded to modify my /etc/init.d/halt script to add code that saved the<br>value of the alarm setting before the system clock was written out to the RTC and then immediately reset the
<br>alarm. There should be e-mail traffic about this misadventure of mine in the archives.<br><br>I then had to add code to detect an arbitrarily selected time value (in my case midnight UTC) to be used as a <br>flag that I **didn't** want a wakeup to occur because otherwise my system would keep waking up every day
<br>at the time of the last selected alarm time. ;-(<br><br>With that code in place, then when I echoed a UTC time into /proc/acpi/alarm, it worked, even with a simple <br>"# shutdown -h now".<br><br>Note that I am pointed about mentioning UTC because I have my system configured to handle DST switching
<br>automatically. IIRC, using local time for the RTC results in disabling the DST processing.<br><br>I tested the alarm with time settings automatically computed using the "date" command and told it to add 60
<br>or 120 seconds to the current time before stuffing the output into /proc/acpi/alarm, after which I would shut <br>the system down and wait.<br><br>Once I had the alarm wakeup working, I pursued getting hibernation and suspend to RAM working with
<br>TuxOnIce (aka suspend2). I have been very happy with its flexibility and ease of control.<br><br>I can't recall if I needed to fiddle with anything in /proc/acpi/wakeup for the ACPI alarm. I **did** have to <br>
work with it for successful WOL and wake-on-keyboard/mouse, and unsuccessful wake-on-USB testing,<br>but that's a whole 'nother story.<br><br>HTH.<br><br>Craig.<br>