Re: [gentoo-user] ACPI conflict while loading it87 module
On 08/02/2010 01:02 PM, pk wrote: On 2010-08-02 17:49, Bill Longman wrote: I just saw, this weekend in fact, that the newer Phenoms, in fact most of the recent K10 CPUs, do not work accurately with the atk0110 so when the driver starts to load, it flatly refuses. I have a 9750 Phenom and that one works great. Works fine in my X2 4000+. These are all assus [sic] mobos. But my 940 Phenom II won't work, thusly: k10temp :00:18.3: unreliable CPU thermal sensor; monitoring disabled Isn't k10temp a different/separate module? If I go to lm-sensors site (http://www.lm-sensors.org/wiki/Devices) I see this: k10temp PCI 2.6.33 or standalone driver(2009-12-06) Embedded sensors are known to be unreliable on the DR-BA, DR-B2, DR-B3, RB-C2 and HY-D0 revisions of the family 10h CPU, which will never be supported. Driver contributed by Clemens Ladisch, reviewed by Jean Delvare. So if you have one of those CPU revisions I guess you're out of luck? The chipset on my main rig (Asus m/b) is running a Intel chipset... I have only older AMD CPUs (Athlon X2 BE2400) with Gigabyte motherboards which doesn't have the atk0110 so I'm unfortunately not much of help... Well, I added CONFIG_SENSORS_ATK0110=y to my 940/M4A79DX setup and gkrellm doesn't show anything. That was one test only, so take it with a grain of salt.
Re: [gentoo-user] ACPI conflict while loading it87 module
On 08/01/2010 07:51 AM, Xi Shen wrote: thanks a lot. i am using asus mb, and asus_atk0110 works for me too. :) On Sun, Aug 1, 2010 at 7:52 PM, pk pete...@coolmail.se wrote: On 2010-08-01 11:01, Xi Shen wrote: Aug 1 16:56:03 david-gentoo kernel: [ 715.671669] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver how to fix this problem? Use the ACPI module (appropriate for your motherboard) instead of the it87 module. For example my motherboard (asus P5E64WS) uses the atk0110 (acpi) module... you find it under these conditions (make menuconfig): Depends on: HWMON [=y] ACPI [=y] X86 [=y] EXPERIMENTAL[=y] Location: - Device Drivers - Hardware Monitoring support (HWMON [=y]) I just saw, this weekend in fact, that the newer Phenoms, in fact most of the recent K10 CPUs, do not work accurately with the atk0110 so when the driver starts to load, it flatly refuses. I have a 9750 Phenom and that one works great. Works fine in my X2 4000+. These are all assus [sic] mobos. But my 940 Phenom II won't work, thusly: k10temp :00:18.3: unreliable CPU thermal sensor; monitoring disabled
Re: [gentoo-user] ACPI conflict while loading it87 module
On 2010-08-02 17:49, Bill Longman wrote: I just saw, this weekend in fact, that the newer Phenoms, in fact most of the recent K10 CPUs, do not work accurately with the atk0110 so when the driver starts to load, it flatly refuses. I have a 9750 Phenom and that one works great. Works fine in my X2 4000+. These are all assus [sic] mobos. But my 940 Phenom II won't work, thusly: k10temp :00:18.3: unreliable CPU thermal sensor; monitoring disabled Isn't k10temp a different/separate module? If I go to lm-sensors site (http://www.lm-sensors.org/wiki/Devices) I see this: k10temp PCI 2.6.33 or standalone driver(2009-12-06) Embedded sensors are known to be unreliable on the DR-BA, DR-B2, DR-B3, RB-C2 and HY-D0 revisions of the family 10h CPU, which will never be supported. Driver contributed by Clemens Ladisch, reviewed by Jean Delvare. So if you have one of those CPU revisions I guess you're out of luck? The chipset on my main rig (Asus m/b) is running a Intel chipset... I have only older AMD CPUs (Athlon X2 BE2400) with Gigabyte motherboards which doesn't have the atk0110 so I'm unfortunately not much of help... Best regards Peter K
Re: [gentoo-user] ACPI conflict while loading it87 module
On 08/02/2010 01:02 PM, pk wrote: On 2010-08-02 17:49, Bill Longman wrote: I just saw, this weekend in fact, that the newer Phenoms, in fact most of the recent K10 CPUs, do not work accurately with the atk0110 so when the driver starts to load, it flatly refuses. I have a 9750 Phenom and that one works great. Works fine in my X2 4000+. These are all assus [sic] mobos. But my 940 Phenom II won't work, thusly: k10temp :00:18.3: unreliable CPU thermal sensor; monitoring disabled Isn't k10temp a different/separate module? If I go to lm-sensors site (http://www.lm-sensors.org/wiki/Devices) I see this: k10temp PCI 2.6.33 or standalone driver(2009-12-06) Embedded sensors are known to be unreliable on the DR-BA, DR-B2, DR-B3, RB-C2 and HY-D0 revisions of the family 10h CPU, which will never be supported. Driver contributed by Clemens Ladisch, reviewed by Jean Delvare. So if you have one of those CPU revisions I guess you're out of luck? The chipset on my main rig (Asus m/b) is running a Intel chipset... I have only older AMD CPUs (Athlon X2 BE2400) with Gigabyte motherboards which doesn't have the atk0110 so I'm unfortunately not much of help... You're right, Peter. I have two M4A79 Deluxe mobos, one with the Deneb 940 and that's where I get the error when I try to use the k10temp module. The other runs the 9750 Agena and uses the asus_atk0110 module and works okay. Both are amd64 running 2.6.34. I'll reboot the 940 and see if that module works.
Re: [gentoo-user] ACPI conflict while loading it87 module
On 2010-08-01 11:01, Xi Shen wrote: Aug 1 16:56:03 david-gentoo kernel: [ 715.671669] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver how to fix this problem? Use the ACPI module (appropriate for your motherboard) instead of the it87 module. For example my motherboard (asus P5E64WS) uses the atk0110 (acpi) module... you find it under these conditions (make menuconfig): Depends on: HWMON [=y] ACPI [=y] X86 [=y] EXPERIMENTAL[=y] Location: - Device Drivers - Hardware Monitoring support (HWMON [=y]) Best regards Peter K
Re: [gentoo-user] ACPI conflict while loading it87 module
thanks a lot. i am using asus mb, and asus_atk0110 works for me too. :) On Sun, Aug 1, 2010 at 7:52 PM, pk pete...@coolmail.se wrote: On 2010-08-01 11:01, Xi Shen wrote: Aug 1 16:56:03 david-gentoo kernel: [ 715.671669] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver how to fix this problem? Use the ACPI module (appropriate for your motherboard) instead of the it87 module. For example my motherboard (asus P5E64WS) uses the atk0110 (acpi) module... you find it under these conditions (make menuconfig): Depends on: HWMON [=y] ACPI [=y] X86 [=y] EXPERIMENTAL[=y] Location: - Device Drivers - Hardware Monitoring support (HWMON [=y]) Best regards Peter K -- Best Regards, Xi Shen (David) http://twitter.com/davidshen84/
Re: [gentoo-user] ACPI conflict while loading it87 module
On Sun, Aug 1, 2010 at 1:52 PM, pk pete...@coolmail.se wrote: On 2010-08-01 11:01, Xi Shen wrote: Aug 1 16:56:03 david-gentoo kernel: [ 715.671669] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver how to fix this problem? Use the ACPI module (appropriate for your motherboard) instead of the it87 module. For example my motherboard (asus P5E64WS) uses the atk0110 (acpi) module... you find it under these conditions (make menuconfig): Depends on: HWMON [=y] ACPI [=y] X86 [=y] EXPERIMENTAL[=y] Location: - Device Drivers - Hardware Monitoring support (HWMON [=y]) Best regards Peter K I've the same problem and I solved it by adding acpi_enforce_resources=lax to my kernel parameters in bootloader. I know that it's not safe way, but it's faster then configure lm_sensors by hand. b.r.
Re: [gentoo-user] ACPI problem on Compaq
On Monday, 13. August 2007, Tim wrote: Have you tried just using 'init 0' rather than 'shutdown -h now'? (...) I'd say check in your BIOS to see what power options there are - some BIOSes can change the action on receiving a power button signal. Thanks for your suggestions. Init 0 did not seem to make a change, then I looked at all the BIOS options and turned off some settings that were on, or reverse - not always understanding what they were to do. Now it seems to work correctly. Perhaps it was a setting that said the power button should wake the computer? Thierry -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] ACPI problem on Compaq
On Mon, 2007-08-13 at 09:41 +0200, Thierry de Coulon wrote: On Monday, 13. August 2007, Tim wrote: Have you tried just using 'init 0' rather than 'shutdown -h now'? (...) I'd say check in your BIOS to see what power options there are - some BIOSes can change the action on receiving a power button signal. Thanks for your suggestions. Init 0 did not seem to make a change, then I looked at all the BIOS options and turned off some settings that were on, or reverse - not always understanding what they were to do. Now it seems to work correctly. Perhaps it was a setting that said the power button should wake the computer? Thierry This often happens when the PC is set to power back up after an AC outage -- Regards, Tim Allingham Ph: 0420 605 370 Email:[EMAIL PROTECTED] http://www.datafirst-it.com.au signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] ACPI problem on Compaq
Thierry de Coulon wrote: Hello, I've got an older Compaq EVO D510 desktop that I was thinking to setup as a lab machine (that should be also used by people who basicaly have no Linux knowledge). I've installed Gentoo on it and it works well but for one thing: When I want sto shut it down, it reboots! This happens as well from KDE as from the command line with shutdown -h now: the machine does shut down, then auto-reboots. Have you tried just using 'init 0' rather than 'shutdown -h now'? I've thought it might be linked to ACPI - so I added noacpi acpi=off (I don't know why but it seems I need both to make grub understand) and now it shuts down and stpos, but does not turn off... and if I push the power button, it reboots. I'd say check in your BIOS to see what power options there are - some BIOSes can change the action on receiving a power button signal. Just now I'm thinking I should look if APM is compiled into the kernel, I did a genkernel all so I assume it is. If you have the time, building your own kernel might help. Any idea as to what other possibilities exist to tell that machine just to shut down and turn off? Thierry I'd leave ACPI in place if I were you - it's more modern than APM. Check if there's a newer BIOS for your board. It's always a possibility (albeit a long shot) that the current BIOS has some sort of ACPI bug that prevents it from behaving properly in this situation. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] acpi battery events, Sony FS740
On Tue, 2007-01-02 at 01:27 -0600, »Q« wrote:
I'm nearly a complete newbie to power management. I've been reading
and tinkering for the past three days. I'm not sure I know enough to
explain my problem clearly, but I'll be glad to try to clarify or post
more info if you can steer me a bit.
I have a Sony Vaio FS740 laptop, and I have power management set up
mostly to my liking, but with one problem. ACPI receives battery
events when the AC is connect and when it is unconnected, but also at
other times, and I don't know how to distinguish. If there are no
actions for acpid to take when they happen, the
script /etc/acpi/default.sh sends this to the syslog:
logger: ACPI event unhandled: battery BAT0 0080 0001
logger: ACPI event unhandled: battery BAT0 0080 0001
It could be a number of things - perhaps you have a faulty cable /
connection, which is causing ACPI events because it thinks it's just
been unplugged, and replugged.
Or perhaps your thinkpad sends ACPI events when the battery has reached
certain charge levels... don't know - someone with the same laptop will
have to comment.
Do these spontaneous ACPI events only happen when plugged in? or only
when unplugged, or both?
To get around it, perhaps you could keep state with a file. eg
(untested):
-
BRIGHTNESS_AC=4
BRIGHTNESS_BATTERY=1
ALREADY_PLUGGED_IN=/.power
if on_ac_power
then
if -f ${ALREADY_PLUGGED_IN} then
logger Recieved ACPI power event, but already plugged in!
else
logger Setting LCD to brightness ${BRIGHTNESS_AC}
echo $BRIGHTNESS_AC /proc/acpi/sony/brightness
touch ${ALREADY_PLUGGED_IN}
fi
else
logger Setting LCD to brightness ${BRIGHTNESS_BATTERY}
echo $BRIGHTNESS_BATTERY /proc/acpi/sony/brightness
rm ${ALREADY_PLUGGED_IN}
fi
-
This will only work for the already-plugged-in-acpi-event, you may have
to do a bit of playing if you also get an already-unplugged-acpi-event,
but I have to leave some fun for you!
HTH!
--
Iain Buchanan iaindb at netspace dot net dot au
It is better to have loved and lost -- much better.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ACPI event - thermal_zone TZ1
On Saturday 16 September 2006 18:56, Richard Fish wrote: So this is exactly the same problem/solution as your power button issue. In /etc/acpi/default.sh, you have an etry: *) log_unhandled $* ;; This causes anything that is not button or ac_adapter to log an event unhandled message. So here again, add a case _above_ this for what you want to happen when thermal_zone events occur. In this case, maybe just: thermal_zone) ;; # don't care..fan seems to work Of course, you could get fancy. Looks like the first argument might be the temperature at which the event occurs, so you could for example compare that to some value (100?) and do something like go ahead and log the event as overtemp. Thanks Richard! What is the syntax for e.g. comparing TZ1, and TZ2 and generating a log entry (other than ACPI event unhandled:... ) -- Regards, Mick pgpLsvFTf5lnt.pgp Description: PGP signature
Re: [gentoo-user] ACPI event - thermal_zone TZ1
On 9/16/06, Mick [EMAIL PROTECTED] wrote: Hi All, Every time the fan on my laptop starts I get this in the log: ACPI event unhandled: thermal_zone TZ1 0081 The fan works fine with respect to automatically switching on at two different speeds when the CPU gets hot/hotter and switching down/off when the CPU cools down enough. How is the thermal_zone message explained - why is it there? Thermal zone events are caused when one of the temperature monitors in the system notices that its temp has crossed some threshold. In your case, the reaction to this event is to turn on (or speed up) a fan, but you also get notified of this through the acpi event reporting mechanism in acpid. So this is exactly the same problem/solution as your power button issue. In /etc/acpi/default.sh, you have an etry: *) log_unhandled $* ;; This causes anything that is not button or ac_adapter to log an event unhandled message. So here again, add a case _above_ this for what you want to happen when thermal_zone events occur. In this case, maybe just: thermal_zone) ;; # don't care..fan seems to work Of course, you could get fancy. Looks like the first argument might be the temperature at which the event occurs, so you could for example compare that to some value (100?) and do something like go ahead and log the event as overtemp. You could even do an automatic shutdown if it gets too hot. But that probably isn't necessary, as thermal throttling should kick in before any damage can occur to the CPU. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ACPI
John Dangler schreef: Make sure the acpid daemon is running. rc-update show = acpid | default alsasound | default alsasound~ | apmd | Is this daemon running? Try (as root) /etc/init.d/acpid start (or, change the settings and reboot) Holly -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] ACPI
weird - rc-update show doesn't show acpi at all. /etc/init.d/acpid doesn't exist. /lib/modules/2.6.12-gentoo-r9/kernel/drivers/acpi exists (with battery.ko and some others in it). John D -Original Message- From: Holly Bostick [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 6:45 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] ACPI John Dangler schreef: Make sure the acpid daemon is running. rc-update show = acpid | default alsasound | default alsasound~ | apmd | Is this daemon running? Try (as root) /etc/init.d/acpid start (or, change the settings and reboot) Holly -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ACPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Dangler wrote: weird - rc-update show doesn't show acpi at all. /etc/init.d/acpid doesn't exist. /lib/modules/2.6.12-gentoo-r9/kernel/drivers/acpi exists (with battery.ko and some others in it). John D -Original Message- From: Holly Bostick [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 6:45 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] ACPI John Dangler schreef: Make sure the acpid daemon is running. rc-update show = acpid | default alsasound | default alsasound~ | apmd | Is this daemon running? Try (as root) /etc/init.d/acpid start (or, change the settings and reboot) Holly HI, You'll have to emerge sys-power/acpid to get the daemon. greets Oliver Beowulf Friedrich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDFETXcZpid1GuHxcRAtxbAKCvEjCVL1rt5mXe3YG6EhNCu35GWQCfRU0X ogd6npPVg4xfGDQXNKXofQQ= =WUTZ -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ACPI
John Dangler schreef: weird - rc-update show doesn't show acpi at all. /etc/init.d/acpid doesn't exist. Well, you can't very well run the acpi daemon if you don't have it, can you-- and if you don't have it, how is GNOME supposed to find it? * sys-power/acpid Available versions: 1.0.2-r2 1.0.4-r1 1.0.4-r2 Installed: 1.0.4-r2 Homepage:http://acpid.sourceforge.net Description: Daemon for Advanced Configuration and Power Interface Perhaps acpi is not in your USE flags-- otherwise the daemon would have probably been installed as a dependency of something that could use it, like gnome-applets: emerge -pv gnome-applets These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] gnome-base/gnome-applets-2.10.1 +acpi -apm -debug -doc +gstreamer -ipv6 6,103 kB ... since the battery monitor applet depends on the acpi (or apm) daemon to be running to be able to grab the data and display it. Or are you using apm instead? Sorry, no laptop, so I don't know how to work with that... but I would assume it works the same way, just instead of compiling the kernel with acpi support, building packages with +acpi and using the acpi daemon, you would instead build the kernel with apm support, build packages with +apm and run the apm daemon. HTH, Holly -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] ACPI
ok...
rc-update show _does_ have apmd (although it's not assigned a run level).
And, emerge -pv gnome-applets has
{ebuild R ] gnome-base/gnome-applets-2.10.1 -acpi +apm -debug -doc
+gstreamer +ipv6 0 kb
But --
/etc/init.d/apmd start shows apm support is not compiled into the kernel.
(Which I could interpret as being compiled as a module)
And --
modprobe apm produces FATAL: Error inserting apm
(lib/modules/2.6.12-gentoo-r9/kernel/arch/i386/kernel/apm.ko): no such
device
(this file does exist)
maybe I need to read up more on these two before blowing a lot of time on
the user list (?) or is it a simple fix?
John D
-Original Message-
From: Holly Bostick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 30, 2005 7:47 AM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] ACPI
John Dangler schreef:
weird - rc-update show doesn't show acpi at all.
/etc/init.d/acpid doesn't exist.
Well, you can't very well run the acpi daemon if you don't have it, can
you-- and if you don't have it, how is GNOME supposed to find it?
* sys-power/acpid
Available versions: 1.0.2-r2 1.0.4-r1 1.0.4-r2
Installed: 1.0.4-r2
Homepage:http://acpid.sourceforge.net
Description: Daemon for Advanced Configuration and Power
Interface
Perhaps acpi is not in your USE flags-- otherwise the daemon would have
probably been installed as a dependency of something that could use it,
like gnome-applets:
emerge -pv gnome-applets
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] gnome-base/gnome-applets-2.10.1 +acpi -apm -debug -doc
+gstreamer -ipv6 6,103 kB
... since the battery monitor applet depends on the acpi (or apm) daemon
to be running to be able to grab the data and display it.
Or are you using apm instead? Sorry, no laptop, so I don't know how to
work with that... but I would assume it works the same way, just instead
of compiling the kernel with acpi support, building packages with +acpi
and using the acpi daemon, you would instead build the kernel with apm
support, build packages with +apm and run the apm daemon.
HTH,
Holly
--
gentoo-user@gentoo.org mailing list
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ACPI
John Dangler schreef:
ok...
rc-update show _does_ have apmd (although it's not assigned a run level).
And, emerge -pv gnome-applets has
{ebuild R ] gnome-base/gnome-applets-2.10.1 -acpi +apm -debug -doc
+gstreamer +ipv6 0 kb
But --
/etc/init.d/apmd start shows apm support is not compiled into the kernel.
(Which I could interpret as being compiled as a module)
Why interpret when you could look:
[EMAIL PROTECTED] - grep APM /usr/src/linux/.config
# Power management options (ACPI, APM)
# APM (Advanced Power Management) BIOS Support
# CONFIG_APM is not set
The kernel default is, I believe, to set ACPI static, and to not set APM
at all. But obviously, if you want to reverse that, you can.
And --
modprobe apm produces FATAL: Error inserting apm
(lib/modules/2.6.12-gentoo-r9/kernel/arch/i386/kernel/apm.ko): no such
device
(this file does exist)
The file exists, but the kernel is looking for a 'device', according to
the error message-- many modules won't compile or load if the device
that they are supposed to be controlling doesn't exist. Does your system
support APM, and is it enabled in the BIOS?
maybe I need to read up more on these two before blowing a lot of time on
the user list (?) or is it a simple fix?
Well, the simple fix would be to just install the ACPI daemon, rc-update
to start it at the default runlevel (and start it for the current
session if you don't want to reboot, recompile gnome-applets +acpi and
-apm and *then* read up on whether that's how you want to leave it.
But presumably the problem is caused by the fact that gnome-applets is
looking for apm, but apm is broke on your system.
Holly
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ACPI events config file
GNU nano 1.3.7File:
email
I have got standby working nicely on my notebook. I tried to sleep
(suspend to mem) it seems to suspend (shutdown as such) but than I cant
seem to bring it out of the sleep state. When I press the power button
it starts up but the screen remains blank.
My acpi scripts are as follows, they are pretty much the same as the
ones quoted below:
-
sleep.sh
-
#!/bin/sh
logger Sleep - Going to Standby
touch /tmp/was_sleeping
#echo -n standby /sys/power/state
echo -n mem /sys/power/state
-
-
power.sh
-
#!/bin/bash
if [ ! -f /tmp/was_sleeping ]; then
touch /tmp/was_sleeping
echo -n mem | /sys/power/state
else
logger Coming out of Standby
rm -f /tmp/was_sleeping
/etc/init.d/alsasound restart
/etc/init.d/hotplug restart
fi
-
On 4/6/05, Octavio Ruiz (Ta^3) [EMAIL PROTECTED] wrote:
Ow Mun Heng, who happens to be smarter than you, thinks:
On Sat, 2005-04-02 at 00:51 +, Ryan Viljoen wrote:
Hi
I am setting up my ACPI on my notebook and have come across a small
problem. I am setting the events in the /etc/acpi/events/default
config file. Now I have got the ac_adapter event working nicely with
speedfreq. Now I want to setup my power button and sleep button.
Hope it helps.
The /tmp/was_sleeping file is because the kernel catch when you press the
power button when its on S1 state, so if
you want to use S1 and dont put that lines, you are going to enter in a
infinite loop of start-suspend.
/etc/acpi/default.sh
--
#!/bin/bash
set $*
group=${1/\/*/}
action=${1/*\//}
case $group in
button)
case $action in
power) logger ACPI: $group/$action action
(/etc/acpi/$action.sh was executed)
;;
lid)logger ACPI: $group/$action action
(/etc/acpi/$action.sh was executed)
;;
sleep) logger ACPI: $group/$action action
(/etc/acpi/$action.sh was executed)
;;
*) logger ACPI: action $action is not defined
;;
esac
;;
*)
logger ACPI: group $group / action $action is not defined
;;
esac
--
/etc/acpi/lid.sh
--
#!/bin/bash
if [ `cut -d -f 20 /proc/acpi/ac_adapter/AC/state` = on-line ]
then
logger ACPI: Battery are online. I'm not going to sleep mode
else
echo -n standby /sys/power/state
fi
--
/etc/acpi/power.sh
--
#!/bin/bash
if [ ! -f /tmp/was_sleeping ]
then
touch /tmp/was_sleeping
echo -n standby | /sys/power/state # S1
# echo -n disk | /sys/power/state# Suspend 2 Disk
# /etc/init.d/shutdown.sh
else
rm -f /tmp/was_sleeping
logger ACPI: Was on S1 State. I'm not going to sleep mode
fi
--
/etc/acpi/sleep.sh
--
#!/bin/bash
logger ACPI: Time to sleep
touch /tmp/was_sleeping
echo -n standby /sys/power/state
--
/etc/acpi/events/default
--
event=.*
action=/etc/acpi/default.sh %e
--
/etc/acpi/events/lid
--
event=button/lid.*
action=/etc/acpi/lid.sh
--
/etc/acpi/events/power
--
event=button/power.*
action=/etc/acpi/power.sh
--
/etc/acpi/events/sleep
--
event=button/sleep.*
action=/etc/acpi/sleep.sh
--
/etc/acpi/events/battery
--
event=battery.*
action=echo -e \a
--
--
A joint is just tea for two.
--
gentoo-user@gentoo.org mailing list
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] acpi vs apm
On Thu, 19 May 2005, James wrote: I was just builging a kernel for an intell PIII processor. I initially selected 'ACPI' and not 'APM'. The kernel build failed with this message: UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.text+0x98216): In function `blackbird_load_firmware': : undefined reference to `request_firmware' drivers/built-in.o(.text+0x982c4): In function `blackbird_load_firmware': : undefined reference to `release_firmware' make: *** [.tmp_vmlinux1] Error 1 so I re-compile the kernel deselecting ACPI and selecting APM. This did not fix the problem. Any ideas are most welcome Just curious: what makes you think APM has anything to do with this? -- -- gentoo-user@gentoo.org mailing list
