Difference between revisions of "Talk:ACPI Wakeup"

From MythTV Official Wiki
Jump to: navigation, search
m (Location of wakeup file changed (Kernel2.6.35-22))
Line 13: Line 13:
  
 
http://svn.mythtv.org/trac/ticket/2838  Looks like capability for ACPI with MythWelcome is coming.  Hopefully we'll see an update to the WIKI once 0.21 comes out or sooner if someone with svn version gets ambitious.
 
http://svn.mythtv.org/trac/ticket/2838  Looks like capability for ACPI with MythWelcome is coming.  Hopefully we'll see an update to the WIKI once 0.21 comes out or sooner if someone with svn version gets ambitious.
 +
 +
== Different strategies in distro-specific hwclock settings ==
 +
 +
Looking through the distro-specific settings examples, it seems different strategies are adopted, not all of which are right. On Debian and Ubuntu the hwclock updating is simply disabled, but this is not going to work well once the hardware clock has drifted a bit, as the time for waking up will then be out by the degree of drift (which for a typical motherboard clock, can become quite significant as the months pass).
 +
 +
On the other hand, the Fedora scripts do update the hardware clock, and then re-initialize the alarm, which is correct. If the MythTV maintainers agree, I'd be happy to update the recent Ubuntu scripts to reflect this (this is what I use). For Debian and older Ubuntu a different strategy is needed. (By the way, it would be nice if someone would confirm that Debian still works as it used to in the new 6.0 release, or if not, updated its details.)
  
 
== 2.6.22 Kernels ==
 
== 2.6.22 Kernels ==

Revision as of 21:40, 16 February 2011

Quick feedback on the new /usr/bin/setwakeup.sh script in the Mythwelcome section of the page. I have tested it once on an ASUS K8N motherboard with BIOS in local time and it worked perfectly. Thank you to whoever wrote this script, you are awesome. I have been trying for days to get auto wakeup to work on a local time BIOS and this did it for me. I did have to use settings of time_t, sudo shutdown -h now and , sudo sh -c "/usr/bin/setwakeup.sh $time" in the backend settings though to make it work (and yes, I did check that mythshutdown is in the sudoers list)

Does this only work on x86_64?

Works fine on X86_32 for me --Benjsc 12:56, 3 October 2006 (UTC)

It works on 32 bit as well. If you miss /proc/acpi/alarm then it seems that this dissapears if you run smp.


Does anyone have experience with the Via EPIA boards? I'm not able to get it working and thus still use nvram-wakeup...

How do I use ACPI wakeups with MythWelcome? The instructions for it are all for using it with nvram-wakeup. --Turpie 11:09, 29 December 2006 (UTC)

http://svn.mythtv.org/trac/ticket/2838 Looks like capability for ACPI with MythWelcome is coming. Hopefully we'll see an update to the WIKI once 0.21 comes out or sooner if someone with svn version gets ambitious.

Different strategies in distro-specific hwclock settings

Looking through the distro-specific settings examples, it seems different strategies are adopted, not all of which are right. On Debian and Ubuntu the hwclock updating is simply disabled, but this is not going to work well once the hardware clock has drifted a bit, as the time for waking up will then be out by the degree of drift (which for a typical motherboard clock, can become quite significant as the months pass).

On the other hand, the Fedora scripts do update the hardware clock, and then re-initialize the alarm, which is correct. If the MythTV maintainers agree, I'd be happy to update the recent Ubuntu scripts to reflect this (this is what I use). For Debian and older Ubuntu a different strategy is needed. (By the way, it would be nice if someone would confirm that Debian still works as it used to in the new 6.0 release, or if not, updated its details.)

2.6.22 Kernels

I just updated my fedora 7 kernel and apparently the 2.6.22 linux kernel removes the /proc/acpi/alarm feature, see http://lkml.org/lkml/2007/6/22/320 does anyone know the new method for these new kernels? --Vossman 06:18, 23 July 2007 (UTC)




There is no documentation, only some hidden description in the git commit that introduced this feature. So I wrote some short documentation, but it isn't included in the source tree yet, AFAIK.

It can be found here:

http://lkml.org/lkml/2007/6/19/264




There is also a message in the mythtv mailing list here:

http://www.mythtv.org/pipermail/mythtv-users/2007-July/187947.html

I found a note here that says: "Also it seems, that /sys/class/rtc/rtc0/wakealarm only accepts times more than 2h in the future." If you are having problems this might be it.

http://bugzilla.novell.com/show_bug.cgi?id=287539


--Vossman 07:25, 7 September 2007 (UTC)




I am having the same issue as this guy here [1] I have no trouble getting the value into the /sys/class/rtc/rtc0/wakealarm that is all fine and dandy. But my machine does not wake up when I set this value. I use Fedora 7 and /proc/acpi/alarm worked great before. I am thinking of reporting this to bugzilla.kernel.org and bugzilla.redhat.com if other people are experiencing this post a comment. --Vossman 16:01, 8 September 2007 (UTC)




I finally got wakeup working with the 2.6.26 kernel after applying the patch found here. Steps to test:

# echo "+300" > /sys/class/rtc/rtc0/wakealarm
# cat /proc/driver/rtc

The output should look like this:

rtc_time	: 18:14:34
rtc_date	: 2009-02-22
alrm_time	: 18:19:32
alrm_date	: 2009-02-22
alarm_IRQ	: yes
alrm_pending	: no
24hr		: yes
periodic_IRQ	: no
update_IRQ	: no
HPET_emulated	: no
DST_enable	: no
periodic_freq	: 1024
batt_status	: okay

Make sure that alrm_IRQ is set to yes. After that, turn off your computer. It should come back on in about 5 mins (300 seconds).

I'm using an Intel D865PERL motherboard.

--Kroylar 02:16, 23 February 2009 (UTC)

I just added this important information to the page itself, since people probably do not check the discussion page.
--Bullestock 21:40, 18 January 2010 (UTC)

Fedora Core 6 kernel 2.6.22.5 vs kernel 2.6.22.9

I have a backend running FC6 (kernel 2.6.22.5-49.fc6) that shuts down and wakes up just fine using the script mentioned in the article. However, after upgrading to kernel 2.6.22.9-61.fc6, it no longer works. I figured out (thanks to the comment in the article) that a new wakeup mechanism is in place for the new kernel, namely /sys/class/misc/rtc/power/wakeup. I tried using that, but all I get when I try to echo anything into it (as root) is "invalid argument". Even resetting fails (echo 0 > /sys/class/misc/rtc/power/wakeup). As of writing, this article is the *only* place that mentions this path in google's index. I've reverted to the 2.6.22.5 kernel which still works great, using mythtv-0.20.2-167.fc6. Judaz 19:16, 6 November 2007 (UTC)

This is in response to Judaz's post above. /sys/class/rtc/rtc0/wakealarm has NOT been moved to /sys/class/misc/rtc/power/wakeup. The documentation provided with the kernel source explains that the wakeup file is a way to query/set whether a device in the system can wakeup. Here's an excerpt from the 2.6.23.12 kernel source documentation that describes the power/wakeup files in sysfs (found in Documentation/power/devices.txt):

/sys/devices/.../power/wakeup files
-----------------------------------
All devices in the driver model have two flags to control handling of
wakeup events, which are hardware signals that can force the device and/or
system out of a low power state.  These are initialized by bus or device
driver code using device_init_wakeup(dev,can_wakeup).

The "can_wakeup" flag just records whether the device (and its driver) can
physically support wakeup events.  When that flag is clear, the sysfs
"wakeup" file is empty, and device_may_wakeup() returns false.

For devices that can issue wakeup events, a separate flag controls whether
that device should try to use its wakeup mechanism.  The initial value of
device_may_wakeup() will be true, so that the device's "wakeup" file holds
the value "enabled".  Userspace can change that to "disabled" so that
device_may_wakeup() returns false; or change it back to "enabled" (so that
it returns true again).

The wakealarm file should still reside in /sys/class/rtc/rtcN. If that directory does not exist on your system, it means the kernel was compiled without support for /sys/class/rtc/rtcN. If you're building your own kernel, you can enable it in "make menuconfig" via the following:

Device Drivers -> Real Time Clock -> /sys/class/rtc/rtcN (sysfs)

If you're using prebuilt kernel packages and /sys/class/rtc doesn't exist, complain to your distro maintainer. Hope this saves someone else the headache it's put me through! --Ebenblues 22:19, 9 January 2008 (UTC)

strage stript for the wakealarm feature in new kernels

The script is somewhat strange in some parts.

#!/bin/sh
# $1 is the --settime switch that nvram-wakeup normally expects
# $2 is the date/time in seconds since 1970

DATE=`date -d "1970-01-01 $2 sec" "+%F %H:%M:%S" -u`
SECS=`date -d "1970-01-01 $2 sec" "+%s" -u`

Why is the argument $2, which is seconds since epoch, converted into seconds since epoch? I think that part can be scratched. Just echo $2 > /sys/class/rtc/rtc0/wakealarm should do fine (at least it does for me)

# Save the wakeup time
echo "$*"  > /myth.wakeup.args
echo $DATE > /myth.wakeup.time
echo $SECS > /myth.wakeup.secs

Why are files written into the root directory? Just scratching the "> /myth.wakeup.args" should be fine, as the echo output can be seen in the backend log then.

I got this to work in 2.6.24

I'm running Fedora 8, kernel 2.6.24.7-92, and this works. Note that I had to first use the FC6 fix located on this page.

If I run these commands, my pc will wake up in 5 minutes.

su
chmod ugo+rwx /proc/acpi/alarm
echo "+00-00-00 00:05:00" > /proc/acpi/alarm
halt -p

Note that if I use shutdown -h now, or /etc/init.d/halt start, or something else, it DOES NOT work. Only halt -p!

Also, I did not have a /sys/class/rtc folder, but I did have a /proc/rtc file. No /proc/rtc0 either.


Rlbond86 23:14, 22 May 2008 (UTC)

Disable or Enable in BIOS?

The page says wake from RTC alarm (or the like) should be disabled. This seems wrong, and on my motherboard at least I had to enable the setting.

Shane kerr 19:52, 26 May 2008 (UTC)

On most motherboards, you need to disable it in BIOS, because you want to program the RTC from the OS. There used to be notes about almost all motherboards needing to disable it. But if your motherboard is an exception, you should probably add a note to the wiki about some motherboards needing it enabled. BTW, have you tried disabling it to make sure you need it enabled? --Per Olofsson 20:01, 26 May 2008 (UTC)

Wake on USB?

--- I don't understand why Wake on USB isn't mentioned in this Wiki page at all?! --The Daver 07:48 04 Aug 2009 (CDT)

Location of wakeup file changed (Kernel2.6.35-22)

For me, I find it under /sys/class/rtc/rtc0/subsystem/rtc0/power/wakeup

May I changes this on the wiki page?

(Or alternatively

/sys/class/rtc/rtc0/device/power/wakeup, which if I've disentangled the symlinks correctly, is the same thing, and is a shorter and less repetitive name. -Reuben Thomas)