# ACPI AC_ADAPTER Issue

## JokerF15

OK,

I finally got ACPI semi-working according to this guide: http://www.gentoo.org/doc/en/power-management-guide.xml

Basically working in the 'Prereq' section. I created a battery runlevel and I can get the system to go into 'battery' runlevel when the battery cable is removed, however I can't get it back into default by plugging it in. When I monitor my logs for when I plug my ac_adapter cable in, The same message is passed through:

"battery BAT1 ......."

I don't get a "ac_adapter...." message.

How am I supposed to get myself back into default runlevel? I don't know how to setup the /etc/acpi/events/pmg_ac_adapter file.

Any help is appreciated. 

-JokerF15

----------

## kitano

i got it working with the guide.

i'm sure we can fix this. since it's been a while since i done that, maybe i cannot remember any detail, but we'll see.

what should be in events/pmg_ac_adapter is the following:

```
event=ac_adapter.*

action=/etc/acpi/actions/pmg_ac_adapter.sh %e

```

in events/pmg_battery:

```
event=battery.*

action=/etc/acpi/actions/pmg_battery.sh %e

```

and in actions/pmg_ac_adapter.sh:

```
#!/bin/bash

source /etc/acpi/switch_runlevel.sh

SwitchRunlevel
```

as well as in actions/pmg_battery.sh:

```
#!/bin/bash

source /etc/acpi/switch_runlevel.sh

SwitchRunlevel
```

how did you set up your default.sh?

maybe you can post the whole file, since any error in there makes acpi infunctional ...

greetz,

kitano

----------

## JokerF15

Ok Here's my files:

pmg_switch_runlevel.sh

```
#!/bin/bash

# BEGIN configuration

RUNLEVEL_AC="default"

RUNLEVEL_BATTERY="battery"

# END configuration

if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ]

then

        logger "${0}: Runlevel ${RUNLEVEL_AC} does not exist. Aborting."

        exit 1

fi

if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ]

then

        logger "${0}: Runlevel ${RUNLEVEL_BATTERY} does not exist. Aborting."

        exit 1

fi

if on_ac_power

then

    if [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]

  then

            logger "Switching to ${RUNLEVEL_AC} runlevel"

            /sbin/rc ${RUNLEVEL_AC}

        fi

elif [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]

then

        logger "Switching to ${RUNLEVEL_BATTERY} runlevel"

        /sbin/rc ${RUNLEVEL_BATTERY}

fi

```

Here's pmg_ac_adapter

```

event=ac_adapter.*

action=/etc/acpi/actions/pmg_switch_runlevel.sh %e

```

Here's pmg_battery:

```

event=battery.*

action=/etc/acpi/actions/pmg_switch_runlevel.sh %e

```

Here's the last couple lines of /var/log/acpid:

```
[Wed May 25 10:42:51 2005] starting up

[Wed May 25 10:42:51 2005] 3 rules loaded

[Wed May 25 10:43:37 2005] received event "battery BAT1 00000081 00000001"

[Wed May 25 10:43:37 2005] executing action "/etc/acpi/default.sh battery BAT1 00000081 00000001"

[Wed May 25 10:43:37 2005] BEGIN HANDLER MESSAGES

[Wed May 25 10:43:37 2005] END HANDLER MESSAGES

[Wed May 25 10:43:37 2005] action exited with status 0

[Wed May 25 10:43:37 2005] executing action "/etc/acpi/actions/pmg_switch_runlevel.sh battery BAT1 00000081 00000001"

[Wed May 25 10:43:37 2005] BEGIN HANDLER MESSAGES

 * Stopping acpid ...                                                     [ ok ]

[Wed May 25 10:43:38 2005] END HANDLER MESSAGES

[Wed May 25 10:43:38 2005] action exited with status 0

[Wed May 25 10:43:38 2005] executing action "/etc/acpi/actions/pmg_switch_runlevel.sh battery BAT1 00000081 00000001"

[Wed May 25 10:43:38 2005] BEGIN HANDLER MESSAGES

[Wed May 25 10:43:38 2005] END HANDLER MESSAGES

[Wed May 25 10:43:38 2005] action exited with status 0

[Wed May 25 10:43:38 2005] exiting

```

You can see how I only get the event 'battery BAT1 0000....' I don't get a AC_Adapter event

Also last end of /var/log/messages:

```

May 25 10:40:01 furqan_laptop /usr/sbin/cron[15921]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

May 25 10:41:26 furqan_laptop dhcpcd[16565]: terminating on signal 2

May 25 10:41:46 furqan_laptop gdm[9896]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0

May 25 10:41:46 furqan_laptop gdm-autologin(pam_unix)[9896]: session closed for user jokerf15

May 25 10:41:47 furqan_laptop su(pam_unix)[12457]: session closed for user root

May 25 10:41:47 furqan_laptop su(pam_unix)[11071]: session closed for user root

May 25 10:41:50 furqan_laptop gdmgreeter[16644]: No default session link found. Using Failsafe GNOME.

May 25 10:41:58 furqan_laptop gdm[9895]: Master rebooting...

May 25 10:41:58 furqan_laptop shutdown[9895]: shutting down for system reboot

May 25 10:41:58 furqan_laptop init: Switching to runlevel: 6

May 25 10:42:01 furqan_laptop sshd[8740]: Received signal 15; terminating.

May 25 10:42:02 furqan_laptop syslog-ng[9442]: syslog-ng version 1.6.7 going down

May 25 10:42:52 furqan_laptop syslog-ng[9490]: syslog-ng version 1.6.7 starting

May 25 10:42:53 furqan_laptop syslog-ng[9490]: Changing permissions on special file /dev/tty12

May 25 10:42:53 furqan_laptop nmbd[9647]: [2005/05/25 10:42:53, 0] nmbd/nmbd_subnetdb.c:create_subnets(217)

May 25 10:42:53 furqan_laptop nmbd[9647]:   create_subnets: No local interfaces !

May 25 10:42:53 furqan_laptop nmbd[9647]: [2005/05/25 10:42:53, 0] nmbd/nmbd_subnetdb.c:create_subnets(218)

May 25 10:42:53 furqan_laptop nmbd[9647]:   create_subnets: Waiting for an interface to appear ...

May 25 10:42:53 furqan_laptop /usr/sbin/cron[9810]: (CRON) STARTUP (V5.0)

May 25 10:42:53 furqan_laptop rc-scripts: WARNING:  "xdm" has already been started.

May 25 10:42:53 furqan_laptop init: Activating demand-procedures for 'A'

May 25 10:42:59 furqan_laptop gdmgreeter[10168]: No default session link found. Using Failsafe GNOME.

May 25 10:43:13 furqan_laptop ieee80211: eth1: Unknown management packet: 0

May 25 10:43:13 furqan_laptop ifplugd(eth1)[7738]: Link beat detected.

May 25 10:43:14 furqan_laptop ifplugd(eth1)[7738]: Executing '/usr/sbin/ifplugd.action eth1 up'.

May 25 10:43:16 furqan_laptop ieee80211: eth1: Unknown management packet: 0

May 25 10:43:17 furqan_laptop dhcpcd[11074]: infinite IP address lease time. Exiting

May 25 10:43:17 furqan_laptop ifplugd(eth1)[7738]: Program executed successfully.

May 25 10:43:31 furqan_laptop gdm-autologin(pam_unix)[10095]: session opened for user jokerf15 by (uid=0)

May 25 10:43:37 furqan_laptop logger: ACPI group battery / action battery is not  defined

May 25 10:43:38 furqan_laptop logger: Switching to battery runlevel

May 25 10:44:13 furqan_laptop su(pam_unix)[11272]: session opened for user root by jokerf15(uid=1000)

May 25 10:44:29 furqan_laptop (jokerf15-11301): starting (version 2.8.1), pid 11301 user 'jokerf15'

May 25 10:44:29 furqan_laptop (jokerf15-11301): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0

May 25 10:44:29 furqan_laptop (jokerf15-11301): Resolved address "xml:readwrite:/home/jokerf15/.gconf" to a writable configuration source at position 1

May 25 10:44:29 furqan_laptop (jokerf15-11301): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2

May 25 10:45:49 furqan_laptop su(pam_unix)[11317]: session opened for user root by jokerf15(uid=0)

May 25 10:48:53 furqan_laptop nmbd[9647]: [2005/05/25 10:48:53, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(396)

May 25 10:48:53 furqan_laptop nmbd[9647]:   *****

May 25 10:48:53 furqan_laptop nmbd[9647]:   

May 25 10:48:53 furqan_laptop nmbd[9647]:   Samba name server FURQAN-LAPTOP is now a local master browser for workgroup FURQAN on subnet 192.168.0.3

May 25 10:48:53 furqan_laptop nmbd[9647]:   

May 25 10:48:53 furqan_laptop nmbd[9647]:   *****

May 25 10:50:01 furqan_laptop /usr/sbin/cron[11328]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

```

Notice how I switched to battery runlevel but didn't switch back. That's the issue =\.

Any help is greatly appreciated.

-JokerF15

----------

## Earthwings

Looks like acpid is not in your battery runlevel (see the "Stopping acpid ..." message in your logs). Therefore it correctly switches to the battery runlevel, but acpid is stopped and doesn't report any events anymore. Execute 

```
rc-update add acpid battery
```

 to fix it.

It would be so great to have runlevel inheritance. Problems like that could not occur then.

----------

## JokerF15

You my friend are awesome  :Wink: .

Works now.

I actually had to make another change though: for the pmg_ac_adapter I had to change it to event = battery.* since that's the only event that's passed through

-JokerF15

----------

## Tsuna

I have the same problem and although I do have acpid in my battery runlevel

here's my files:

```
# cat /etc/acpi/events/pmg_ac_adapter 

event=ac_adapter.*

action=/etc/acpi/actions/pmg_ac_adapter.sh %e

```

```
# cat /etc/acpi/events/pmg_battery    

event=battery.*

action=/etc/acpi/actions/pmg_battery.sh %e

```

```
# cat /etc/acpi/actions/pmg_ac_adapter.sh 

#!/bin/bash

source /etc/acpi/switch_runlevel.sh

SwitchRunlevel

```

```
# cat /etc/acpi/actions/pmg_battery.sh    

#!/bin/bash

source /etc/acpi/switch_runlevel.sh

SwitchRunlevel

```

```
# cat /etc/acpi/switch_runlevel.sh 

#!/bin/bash

RUNLEVEL_AC="default"

RUNLEVEL_BATTERY="battery"

                                

function on_ac() {              

    if which on_ac_power &> /dev/null

    then                        

        on_ac_power             

    else                        

        grep --quiet on-line /proc/acpi/ac_adapter/*/state

    fi                          

}                               

                                

function SwitchRunlevel() {     

    if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ]

    then                        

        logger "${0}: Runlevel ${RUNLEVEL_AC} does not exist. Aborting."

        exit 1                  

    fi                          

                                

    if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ]

    then                        

        logger "${0}: Runlevel ${RUNLEVEL_BATTERY} does not exist. Aborting."

        exit 1                  

    fi                          

                                

    if on_ac                    

    then                        

        if [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]

        then                    

            logger "Switching to ${RUNLEVEL_AC} runlevel"

            /sbin/rc ${RUNLEVEL_AC}

        fi                      

    elif [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]

    then                        

        logger "Switching to ${RUNLEVEL_BATTERY} runlevel"

        /sbin/rc ${RUNLEVEL_BATTERY}

    fi                          

}                               

```

When I ma on AC, this is what I get in /var/log/acpid when I unplug the AC Adapter

```
[Wed May 25 23:08:11 2005] received event "battery BAT1 00000080 00000001"

[Wed May 25 23:08:11 2005] executing action "/etc/acpi/actions/pmg_battery.sh battery BAT1 00000080 00000001"

[Wed May 25 23:08:11 2005] BEGIN HANDLER MESSAGES

/usr/bin/on_ac_power: line 23: acpi_available: command not found

/usr/bin/on_ac_power: line 40: apm_available: command not found

[Wed May 25 23:08:11 2005] END HANDLER MESSAGES

[Wed May 25 23:08:11 2005] action exited with status 0

[Wed May 25 23:08:11 2005] executing action "/etc/acpi/default.sh battery BAT1 00000080 00000001"

[Wed May 25 23:08:11 2005] BEGIN HANDLER MESSAGES

[Wed May 25 23:08:11 2005] END HANDLER MESSAGES

[Wed May 25 23:08:11 2005] action exited with status 0

[Wed May 25 23:08:11 2005] completed event "battery BAT1 00000080 00000001"

```

And this is what I get when I plug it back:

```
[Wed May 25 23:08:24 2005] received event "battery BAT1 00000080 00000001"

[Wed May 25 23:08:24 2005] executing action "/etc/acpi/actions/pmg_battery.sh battery BAT1 00000080 00000001"

[Wed May 25 23:08:24 2005] BEGIN HANDLER MESSAGES

/usr/bin/on_ac_power: line 23: acpi_available: command not found

/usr/bin/on_ac_power: line 40: apm_available: command not found

[Wed May 25 23:08:24 2005] END HANDLER MESSAGES

[Wed May 25 23:08:24 2005] action exited with status 0

[Wed May 25 23:08:24 2005] executing action "/etc/acpi/default.sh battery BAT1 00000080 00000001"

[Wed May 25 23:08:24 2005] BEGIN HANDLER MESSAGES

[Wed May 25 23:08:24 2005] END HANDLER MESSAGES

[Wed May 25 23:08:24 2005] action exited with status 0

[Wed May 25 23:08:24 2005] completed event "battery BAT1 00000080 00000001"
```

Notice the error messages, they appeared some time ago, I didn't have them before...

This is my current kernel config:

```
# grep ACPI /boot/config.map-`uname -r`

# Power management options (ACPI, APM)

# ACPI (Advanced Configuration and Power Interface) Support

CONFIG_ACPI=y

CONFIG_ACPI_BOOT=y

CONFIG_ACPI_INTERPRETER=y

CONFIG_ACPI_SLEEP=y

CONFIG_ACPI_SLEEP_PROC_FS=y

CONFIG_ACPI_AC=y

CONFIG_ACPI_BATTERY=y

CONFIG_ACPI_BUTTON=y

CONFIG_ACPI_VIDEO=m

CONFIG_ACPI_FAN=y

CONFIG_ACPI_PROCESSOR=y

CONFIG_ACPI_THERMAL=y

# CONFIG_ACPI_ASUS is not set

# CONFIG_ACPI_IBM is not set

# CONFIG_ACPI_TOSHIBA is not set

CONFIG_ACPI_BLACKLIST_YEAR=0

# CONFIG_ACPI_DEBUG is not set

CONFIG_ACPI_BUS=y

CONFIG_ACPI_EC=y

CONFIG_ACPI_POWER=y

CONFIG_ACPI_PCI=y

CONFIG_ACPI_SYSTEM=y

# CONFIG_ACPI_CONTAINER is not set

# CONFIG_X86_ACPI_CPUFREQ is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y

# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set

CONFIG_PNPACPI=y

```

Of course I have acpid installed and running:

```
# qpkg -I | grep -i acpi

sys-power/acpid *

# /etc/init.d/acpid status

 * status:  started

```

And I have another problem

My laptop keeps losing time, it seems this is due to SpeedStep which require a particular kernel configuration for time source, but I don't know exactly how to fixe it / what to include in or remove from my kernel

```
# tail -n 200 /var/log/kern.log | egrep "(time|tick)"

May 25 21:01:44 localhost kernel: oprofile: using timer interrupt.

May 25 21:01:44 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:01:44 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:01:44 localhost last message repeated 2 times

May 25 21:01:44 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64

May 25 21:01:44 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64

May 25 21:01:44 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64

May 25 21:01:44 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64

May 25 21:01:44 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:01:44 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:01:44 localhost kernel: PCI: Setting latency timer of device 0000:00:1f.5 to 64

May 25 21:01:44 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:01:47 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:01:56 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:01:57 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:02:10 localhost last message repeated 4 times

May 25 21:02:16 localhost kernel: Losing some ticks... checking if CPU frequency changed.

May 25 21:02:51 localhost last message repeated 13 times

May 25 21:02:56 localhost last message repeated 2 times

May 25 21:02:56 localhost kernel: Losing too many ticks!

May 25 21:02:56 localhost kernel: TSC cannot be used as a timesource.  

May 25 21:02:56 localhost kernel: Falling back to a sane timesource now.

```

I always have time drifts, sometime they are quite important (once I lost 1 hour and half in less than one afternoon) so this is a real problem

If anyone can advise as to how to fixe this, please

thanks

----------

## Earthwings

@JokerF15: Great  :Smile: 

@Tsuna:

You can get runlevel switching working by running 

```
emerge powermgmt-base
```

This installs the missing program on_ac_power.

You *might* get rid of the "losing too many ticks" error messages by enabling the following kernel option:

```
  │ CONFIG_X86_PM_TIMER:                                                                    │

  │                                                                                         │

  │ The Power Management Timer is available on all ACPI-capable,                            │

  │ in most cases even if ACPI is unusable or blacklisted.                                  │

  │                                                                                         │

  │ This timing source is not affected by powermanagement features                          │

  │ like aggressive processor idling, throttling, frequency and/or                          │

  │ voltage scaling, unlike the commonly used Time Stamp Counter                            │

  │ (TSC) timing source.                                                                    │

  │                                                                                         │

  │ So, if you see messages like 'Losing too many ticks!' in the                            │

  │ kernel logs, and/or you are using this on a notebook which                              │

  │ does not yet have an HPET, you should say "Y" here.
```

For the clock skew, check two things. First, if you use hibernate, make sure to enable it with the sys-power/hibernate-script tool and *not* by echoing to some file in /proc or /sys. The hibernate-script has an option to restore the right time. Second, check /etc/adjtime. A search for "clock skew" in kernel & hardware will bring up more threads on this problem.

----------

## Tsuna

yeah I will try to enable this

from what I understood, CONFIG_X86_PM_TIMER is not required if your BIOS supports the HPET timer and CONFIG_X86_PM_TIMER is provided as a sure replacement although HPET is recommanded if you can use it instead of CONFIG_X86_PM_TIMER

am I right?

----------

## Tsuna

CONFIG_HPET_TIMER does not seem to be sufficiant, so either the BIOS of my laptop doesn't support it, or it's not a replacement of CONFIG_X86_PM_TIMER

i'll try CONFIG_X86_PM_TIMER tonight

----------

## Tsuna

CONFIG_X86_PM_TIMER fixed it

----------

## Tsuna

 *Earthwings wrote:*   

> 
> 
> @Tsuna:
> 
> You can get runlevel switching working by running 
> ...

 

I still don't get it to work:

Removing the AC cable:

```
[Fri May 27 00:05:11 2005] received event "battery BAT1 00000080 00000001"

[Fri May 27 00:05:11 2005] executing action "/etc/acpi/actions/pmg_battery.sh battery BAT1 00000080 00000001"

[Fri May 27 00:05:11 2005] BEGIN HANDLER MESSAGES

[Fri May 27 00:05:11 2005] END HANDLER MESSAGES

[Fri May 27 00:05:11 2005] action exited with status 0

[Fri May 27 00:05:11 2005] executing action "/etc/acpi/default.sh battery BAT1 00000080 00000001"

[Fri May 27 00:05:11 2005] BEGIN HANDLER MESSAGES

[Fri May 27 00:05:11 2005] END HANDLER MESSAGES

[Fri May 27 00:05:11 2005] action exited with status 0

[Fri May 27 00:05:11 2005] completed event "battery BAT1 00000080 00000001"
```

Pluging it back:

```
[Fri May 27 00:05:20 2005] received event "battery BAT1 00000080 00000001"

[Fri May 27 00:05:20 2005] executing action "/etc/acpi/actions/pmg_battery.sh battery BAT1 00000080 00000001"

[Fri May 27 00:05:20 2005] BEGIN HANDLER MESSAGES

[Fri May 27 00:05:20 2005] END HANDLER MESSAGES

[Fri May 27 00:05:20 2005] action exited with status 0

[Fri May 27 00:05:20 2005] executing action "/etc/acpi/default.sh battery BAT1 00000080 00000001"

[Fri May 27 00:05:20 2005] BEGIN HANDLER MESSAGES

[Fri May 27 00:05:20 2005] END HANDLER MESSAGES

[Fri May 27 00:05:20 2005] action exited with status 0

[Fri May 27 00:05:20 2005] completed event "battery BAT1 00000080 00000001"

```

by the way, I do confirm that with CONFIG_X86_PM_TIMER I no longer have time drifts due to SpeedStep, thank you

----------

## Earthwings

the above looks good - does it change runlevels? You can see that in syslog.

----------

## GarG

Hi,

At the beginning after reading this thread, thinking my problem was not exactly the same as those described here, I created a new topic named "ACPI - no events shown for ac_adapter and battery" : https://forums.gentoo.org/viewtopic-t-341776.html. But as Tsuna suggested it to me, problems are related, so it was better to expose my problem here.

So, a quit reminder about the acpid problem on my laptop :

When I plug or unplug my AC Adapter, nothing is reported in the acpid log file, not the smallest event, nor in dmesg (so it means no events were caught and past to default.sh, which couldn't handle them). But closing the lid raises an event stored in acpid log, and causes the extinction of the screen.

Therefore, if anybody could help me, I would appriciate a lot  :Very Happy: 

----------

## bino

Hello all,

Having similar problems. Have set up ACPI and nothing happens when I switch power supplies. /var/log/messages gives the following:

```

Jul 22 17:12:47 laptop logger: ACPI group ac_adapter / action ac_adapter is not defined

Jul 22 17:12:47 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:13:02 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:13:02 laptop logger: ACPI group ac_adapter / action ac_adapter is not defined

Jul 22 17:13:14 laptop logger: ACPI group ac_adapter / action ac_adapter is not defined

Jul 22 17:13:14 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:14:06 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:18:25 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:20:02 laptop cron[7224]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Jul 22 17:22:08 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:25:13 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:25:13 laptop logger: ACPI group ac_adapter / action ac_adapter is not defined

Jul 22 17:30:01 laptop cron[7380]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Jul 22 17:30:42 laptop logger: ACPI group ac_adapter / action ac_adapter is not defined

Jul 22 17:30:42 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:35:01 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:35:04 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:35:08 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:36:13 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:36:17 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:38:13 laptop logger: ACPI group battery / action battery is not defined

Jul 22 17:38:13 laptop logger: ACPI group ac_adapter / action ac_adapter is not defined

```

I know the event is happening because /var/log/acpid says so.

Thanks for any help...

Bino

----------

## mesmer

bino: I'm having the exact same problem.  After checkint out Gentoo Wiki ( http://gentoo-wiki.com/TIP_ACPI_basic_configuration ) I'm convinced it's an issue with /etc/acpi/default.sh.  I'm going to try merging the Power Management Guide with the guidelines set forth in the Wiki article...  hopefully it'll work.

EDIT: This is my slightly modified /etc/acpi/default.sh file...

```
# Default acpi script that takes an entry for all actions

set $*

group=${1/\/*/}

action=${1/*\//}

case "$group" in

        button)

                case "$action" in

                        power)  /sbin/init 0

                                ;;

                        *) logger "ACPI action $action is not defined"

                                ;;

                esac

                ;;

        ac_adapter) logger "ACPI group $group / action $action is not defined"

                ;;

        battery) logger "ACPI group $group / action $action is not defined"

                ;;

        *) logger "ACPI group $group / action $action is not defined"

                ;;

esac
```

Specifically:

```
*) logger "ACPI group $group / action $action is not defined"
```

should look very familiar...

/etc/var/log output:

```
Jul 23 02:26:48 aeternus logger: ACPI group ac_adapter / action ac_adapter is not defined

Jul 23 02:26:48 aeternus logger: ACPI group battery / action battery is not defined
```

I don't know what the hell the Power Management Guide is trying to tell me to do, but it doesn't look like it has anything to do with the way ACPI is set up.  Shouldn't the ac_adapter and battery actions be in /etc/acpi as .sh scripts?  The ac_adapter and battery events are definitely passing through default.sh, as altering the return strings has effect on /var/log/syslog.

ie:

```
battery) logger "ACPI group $group / action $action is not defined because someone is dumb."
```

will produce

```
Jul 23 02:48:16 aeternus logger: ACPI group battery / action battery is not defined because someone is dumb.
```

----------

## Tsuna

look with rc-status, you will see that the script is properly working, in fact (RTFM man acpid) when you unplug the AC adapter, an event is created to tell the system is now running on battery. This event is catched by the files under /etc/acpi/events. Those files have a simple format: they consist of two lines, one defining the event(s) to catch, and the other the action to execute when such events are caught. The thing is, /etc/acpi/events/default catches ALL events and send them to /etc/acpi/default.sh. One event can be caught by multiple files under /etc/acpi/events which is what's happening here. When the battery event is created, it goes through every action it matches from /etc/acpi/events. So it's caught by the default event and sent to default.sh which doesn't know to handle it, so it says something in syslog about the event not being defined. Then the event is also caught by /etc/acpi/events/pmg_battery and sent to /etc/acpi/actions/pmg_battery.sh which changes the runlevel as expected.

I hope I made this clear  :Rolling Eyes: 

----------

## bino

 *Quote:*   

> look with rc-status, you will see that the script is properly working

 

Nope its not! However, I understand what you are trying to say Tsuna, thanks for that. I think perhaps my scripts are set up slightly wrong. I'll spend a bit of time going through my scripts and look at what mesmer says (thanks). I'll let you know what I come up with,

Thanks for the help, 

Bino

----------

## Tsuna

weird then, because it's working for me, and I haven't edited the script I took on the web (either here or on Gentoo-Wiki, cant remember)

----------

## bino

Ok I think I have worked it out. Firstly I didn't have all the correct filenames etc. The real problem is that my ACPI system generates a battery event and a ac_adaptor event when you plug/unplug the ac. So what I think was happeng was that it was changing runlevels back and forth without a chance for me to see. So I need to change the regex in the pmg_battery and pmg_ac_adaptor so they take into account the whole line of the ACPI event (the last digit determines the presence of the battery/ac adaptor).

Here is the log of inserting the power cord to my laptop (/var/log/acpi):

```

[Thu Jul 28 19:23:18 2005] received event "ac_adapter ACAD 00000080 00000001"

[Thu Jul 28 19:23:18 2005] executing action "/etc/acpi/default.sh ac_adapter ACAD 00000080 00000001"

[Thu Jul 28 19:23:18 2005] BEGIN HANDLER MESSAGES

[Thu Jul 28 19:23:18 2005] END HANDLER MESSAGES

[Thu Jul 28 19:23:18 2005] action exited with status 0

[Thu Jul 28 19:23:18 2005] completed event "ac_adapter ACAD 00000080 00000001"

[Thu Jul 28 19:23:18 2005] received event "battery BAT1 00000080 00000001"

[Thu Jul 28 19:23:18 2005] executing action "/etc/acpi/default.sh battery BAT1 00000080 00000001"

[Thu Jul 28 19:23:18 2005] BEGIN HANDLER MESSAGES

[Thu Jul 28 19:23:18 2005] END HANDLER MESSAGES

[Thu Jul 28 19:23:18 2005] action exited with status 0

[Thu Jul 28 19:23:18 2005] completed event "battery BAT1 00000080 00000001"

```

My regex knowledge is nonexistent so if anyone has anything it would be most appreciated...

Cheers

Bino

----------

## gustafson

Hi,

I just had the same problem, where the acpi log didn't register and ac adapter event.  I checked and found out the ac kernel module was failing to load during boot (improperly specified in /etc/modules.autoload/kernel-2.6).  When I loaded it with modprobe -i ac, then it was in the kernel and registered an acpi event.

Perhaps you could check that?

----------

