# ACPI "button/lid" event repeat indefinitely

## chentianran

I recently noticed this quite annoy problem: as soon as a close the lid of my laptop, the ACPI event "button/lid LID0" start to repeat indefinitely at the rate about 2~3 times per second, even though there are no actual movement (not even very slight movement) of the lid.

The output looks like this (from acpi_listen):

```

button/lid LID0 00000080 00000bd5

button/lid LID0 00000080 00000bd6

button/lid LID0 00000080 00000bd7

button/lid LID0 00000080 00000bd8

button/lid LID0 00000080 00000bd9

button/lid LID0 00000080 00000bda

button/lid LID0 00000080 00000bdb

button/lid LID0 00000080 00000bdc

button/lid LID0 00000080 00000bdd

button/lid LID0 00000080 00000bde

button/lid LID0 00000080 00000bdf

button/lid LID0 00000080 00000be0

button/lid LID0 00000080 00000be1

button/lid LID0 00000080 00000be2

button/lid LID0 00000080 00000be3

button/lid LID0 00000080 00000be4

button/lid LID0 00000080 00000be5

button/lid LID0 00000080 00000be6

button/lid LID0 00000080 00000be7

button/lid LID0 00000080 00000be8

button/lid LID0 00000080 00000be9

button/lid LID0 00000080 00000bea

button/lid LID0 00000080 00000beb

```

This is quite annoy because it keeps my CPU and harddrive busy, and thus eat up my battery very quickly. Also goes hand in hand with that, the "dmesg" are filled with:

```

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

ide: failed opcode was: 0xec

hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }

hdc: drive_cmd: error=0x04 { AbortedCommand }

```

Kernel: 2.6.12-suspend2-r6

----------

## dagsorter

For what its worth... I have exactly the same problem with my Acer Aspire 1692.

I wonder if it is to do with the type of switch used, the dsdt thingumy, or some configuration problem.

Maybe its a bug. I presume it works for everyone else?  :Rolling Eyes: 

----------

## dhunt

Did you guys figure out what was happening?

My Aspire 1641 does the same thing although it doesn't give event's infinetely. As I can stop acpid and cat /proc/acpi/event and after a couple seconds it runs out of lid events. This is on a 2.6.16 kernel

----------

## mroconnor

I have the same issue on my Acer TM 8104. Really driving me mad. Anyone fix this yet?

Be well  :Wink: 

----------

## gami

I had a similar problem on a Dell Inspiron 5000e. It turned out to be a faulty ACPI in the bios. I managed to find a fixed ACPI DSDT and built this into the kernel for that machine.

----------

## mroconnor

My DSDT compiles clean and error free. But I might just recompile it to be sure and then redo all of my ACPI related scripts/emerges and see what happens.

Cheers

----------

## gami

 *progresso wrote:*   

> My DSDT compiles clean and error free. But I might just recompile it to be sure and then redo all of my ACPI related scripts/emerges and see what happens.

 

Well, a DSDT that compiles without errors does not necessarily mean it is a working one   :Wink:  . Previously I had fixed mine so that the DSDT compiler no longer returned any errors; it still didn't work with the lid button, though.

If you are lucky one of the custom DSDTs available at ACPI4Linux solves your problem. This is where I got my working one from.

----------

## mroconnor

SO right you are gami!

I know there are few fixed DSDTs for this machine @ ACPI4Linux so I will experiment some more. Isn't this why I we use gentoo and not another distro?!?!     :Rolling Eyes: 

cheers

----------

## theRealMorpheu5

Was anybody able to find a solution? I'm still having this weird issue  :Rolling Eyes: 

----------

## swimmer

 *theRealMorpheu5 wrote:*   

> Was anybody able to find a solution? I'm still having this weird issue 

 It depends on the kernel you're using but I simply disabled all lid events in the source code  :Wink:  If you want I can set the patches online ... (will take some time though)

Greetz

swimmer

----------

## theRealMorpheu5

I'm using 2.6.22-suspend2-r2 and my problem is slightly different, indeed: the system properly enters the sleep mode but when I wake it up it just goes back to sleep mode since it has queued events to process. This thing repeats several times until the event queue is empty.

----------

## theRealMorpheu5

Any news? I managed to make a video of this issue, here it is: http://it.youtube.com/watch?v=WAMK8kaNpNc

----------

