# [SOLVED] No ACPI event on Toshiba Tecra M2

## dgaffuri

I can't see any event in /proc/acpi/event, while status is correctly reported in acpi/button, battery, etc. Toshiba Tecra M2 with 1.40 BIOS, 2.6.11-r9 kernel, relevant config is:

```

#

# ACPI (Advanced Configuration and Power Interface) Support

#

CONFIG_ACPI=y

CONFIG_ACPI_BOOT=y

CONFIG_ACPI_INTERPRETER=y

# CONFIG_ACPI_SLEEP is not set

CONFIG_ACPI_AC=y

CONFIG_ACPI_BATTERY=y

CONFIG_ACPI_BUTTON=y

CONFIG_ACPI_VIDEO=y

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=y

CONFIG_ACPI_BLACKLIST_YEAR=0

CONFIG_ACPI_DEBUG=y

CONFIG_ACPI_BUS=y

CONFIG_ACPI_EC=y

CONFIG_ACPI_POWER=y

CONFIG_ACPI_PCI=y

CONFIG_ACPI_SYSTEM=y

CONFIG_X86_PM_TIMER=y

# CONFIG_ACPI_CONTAINER is not set

```

BTW, I've enabled CONFIG_ACPI_DEBUG but I see no output at all in dmesg. Where does it go?

Any help will be appreciated.Last edited by dgaffuri on Sun Jun 26, 2005 5:49 pm; edited 1 time in total

----------

## ekutay

Have you installed acpid?

```
emerge acpid
```

It locks in /var/log/acpid.log

regards

----------

## dgaffuri

Yes, acpid is installed, but it reports no event at all. Stopping it and catting /proc/acpi/event doesn't show any event too.

----------

## ekutay

 *ekutay wrote:*   

> It locks in /var/log/acpid.log

 

sorry, a  typo. acpid logs in /var/log/acpid.

----------

## dgaffuri

No events logged

Only

```

[Thu Jun  9 04:08:05 2005] starting up

[Thu Jun  9 04:08:05 2005] 4 rules loaded

```

I remove the AC adapter and close display, status is correctly reported but no event is generated.

----------

## ekutay

Have a look in /etc/acpi/events where events must be defined. You should have a default.sh in /etc/acpi/default.sh.

Actually a default event too. In case not create a default event.

```

touch /etc/acpi/events/default

echo "event=*" >> /etc/acpi/events/default

echo "action=/etc/acpi/default.sh %e" >> /etc/acpi/events/default

/etc/init.d/acpid restart
```

Also check http://www.gentoo.org/doc/en/power-management-guide.xml

----------

## dgaffuri

It's all OK there. I think the problem is that kernel doen't post anything in /proc/acpi/event, not that scripts don't handle events correctly.

In the meantime, thank for your interest

----------

## glr

Also running a Tecra M2, kernel 2.6.11-r9; BIOS 1.40.  I haven't looked at this recently, but at some point when I was playing with power management I had the same trouble.  I've wondered if the Tecra BIOS is doing something odd with the way it handles ACPI.  For example, in general I find that the fan state doesn't register correctly in /proc/acpi/fan/FAN/state, even though the fan is correctly turning on and off in response to the system temperature.

glr

----------

## dgaffuri

Now that you say it I notice  :Embarassed: : correct fan state is reported in

```
/proc/acpi/toshiba/fan
```

but not in

```
/proc/acpi/fan/FAN/state
```

Any idea out there? Thanks in advance

----------

## ekutay

 *dgaffuri wrote:*   

> I think the problem is that kernel doen't post anything in /proc/acpi/event, not that scripts don't handle events correctly.

  The file /proc/acpi/event is opened by acpid and you cannot read /proc/acpi/event when acpid is running. It is possible to connect a client application to a socket created by acpid and read events notifications from there if one likes to. 

If you suspect that there is a bogus behaviour raise the debug parameter which allows to start acpid in foreground.

----------

## dgaffuri

Of course I stopped acpid before trying to cat /proc/acpi/event. Tried to set debug option on acpid too (-dddddddddddd). Nothing different happens. No event reported at all.

----------

## ekutay

IMHO this looks like either a BIOS or a kernel bug. Interesting in this context is maybe http://bugme.osdl.org/show_bug.cgi?id=1752, but unfortunately not really helpful.

----------

## dgaffuri

Indeed I find that my power button works correctly

```

[Fri Jun 10 02:57:56 2005] received event "button/power PWRF 00000080 00000001"

[Fri Jun 10 02:57:56 2005] executing action "/etc/acpi/default.sh button/power PWRF 00000080 00000001"

[Fri Jun 10 02:57:56 2005] BEGIN HANDLER MESSAGES

[Fri Jun 10 02:57:56 2005] END HANDLER MESSAGES

[Fri Jun 10 02:57:56 2005] action exited with status 0

[Fri Jun 10 02:57:56 2005] completed event "button/power PWRF 00000080 00000001"

```

and the laptop shuts down.

No action at all when unplugging AC adapter. If  I close the lid backlight goes off but no event is reported by acpid.

Probably a BIOS problem.

Thanks for the help, anyway.

----------

## ekutay

You could try to patch the dsdt table in your kernel or decompile, modify and compile it again, but that's quite elaborate. Maybe google with DSDT and you laptop model to see whether this could help in your case.

----------

## dgaffuri

I've tried this too

```

Intel ACPI Component Architecture

ASL Optimizing Compiler / AML Disassembler version 20050309 [Jun  5 2005]

Copyright (C) 2000 - 2005 Intel Corporation

Supports ACPI Specification Revision 3.0

dsdt.dsl  2700:                                 Notify (\_PR.CPU0, 0x80)

Error    1022 -                           Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  2821:                                 Notify (\_PR.CPU0, 0x80)

Error    1022 -                           Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  2959:                                 Notify (\_PR.CPU0, 0x80)

Error    1022 -                           Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  3725:                     Notify (\_PR.CPU0, Local0)

Error    1022 -               Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  3919:                 \_PR.CPU0

Error    1022 -   Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  3968:                     Notify (\_PR.CPU0, 0x80)

Error    1022 -               Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  4059:                     Notify (\_PR.CPU0, 0x80)

Error    1022 -               Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  4077:                     Notify (\_PR.CPU0, 0x80)

Error    1022 -               Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  4125:                     Notify (\_PR.CPU0, 0x80)

Error    1022 -               Object does not exist ^  (\_PR.CPU0)

dsdt.dsl  4443:                 Notify (\_PR.CPU0, 0x80)

Error    1022 -           Object does not exist ^  (\_PR.CPU0)

ASL Input:  dsdt.dsl - 4652 lines, 161480 bytes, 2323 keywords

Compilation complete. 10 Errors, 0 Warnings, 0 Remarks, 1124 Optimizations

```

Scope \_PR is not even defined in source file  :Sad: . I really don't know how it could be possible to fix. I googled a lot before posting the message, but I found only the bug cited in last reply, which don't seem to apply.

Anyway I don't receive any error from ACPI during bootup, and everything else works well.

----------

## glr

 *dgaffuri wrote:*   

> Now that you say it I notice : correct fan state is reported in
> 
> ```
> /proc/acpi/toshiba/fan
> ```
> ...

 

It seems likely to me that the reporting of ACPI events in acpi/toshiba/.. would be a result of the ACPI_TOSHIBA kernel option, which, if I'm thinking about things correctly, is just saying "use the Toshiba-specific mechanisms for dealing with ACPI events".  In which case the problems with the reporting of ACPI events in general definitely sounds like a problem with the Toshiba BIOS being nonstandard, and it seems that anything that's showing up under acpi/toshiba/.. wouldn't be correctly reported by acpid.

Of course, we've seen problems with Toshiba's BIOS before, so this may not be a surprise.

glr

----------

## dgaffuri

Just as an additional info. Removing the

```
Object does not exist ^  (\_PR.CPU0)
```

by adding

```
External (\_PR.CPU0)
```

(I think it's defined in SSDT) to dsdt.dsl before compiling leave 0 errors and 0 warnings.

----------

## dgaffuri

OK, after two days of work and reading about one million of ASL and kernel code lines I've found that passing the kernel argument

```
acpi_wake_gpes_always_on
```

allow events to be reported. This means (at least I think)  that BIOS reports wake and normal events in the same place (buggy DSDT?), while the kernel by default disable wake events when in running state. I don't know if this will be a solution, I've to check if spurious events are generated. Anyway, thanks to all who helped.

----------

