Bug 14977

Summary:	ACPI lid button state incorrect, slow to respond
Product:	ACPI	Reporter:	Philipp Kohlbecher (xt28)
Component:	Other	Assignee:	Zhang Rui (rui.zhang)
Status:	CLOSED INSUFFICIENT_DATA
Severity:	normal	CC:	lenb, rjw, rui.zhang, vasyl.demin, yakui.zhao
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.32.2	Subsystem:
Regression:	Yes	Bisected commit-id:
Attachments:	Output of dmidecode Binary DMI dump dmesg output acpidump output Output of grep -R . /sys/firmware/acpi/interrupts/ Contents of /proc/interrupts

Description Philipp Kohlbecher 2010-01-02 13:51:40 UTC

When I boot my laptop, the ACPI lid button state (/proc/acpi/button/lid/LID0/state) is always reported as "closed", even though the lid is, in fact, open.

When I close the lid and open it again, this state change is not detected.

When I close the lid, keep it close for over ten seconds, and open it again, the state is correctly reported as "open". After that, when I close the lid, it takes about ten seconds before this state change is registered. Opening the lid immediately changes the state to open.

I am using a Samsung X20 laptop with a Phoenix BIOS (version 09ZE).

I didn't know which component to select for this bug report, so please feel free to change it to something more appropriate.

Comment 1 ykzhao 2010-01-04 02:22:25 UTC

Will you please add the boot option of "nomodeset" and attach the output of dmidecode?
Thanks.

Comment 2 Philipp Kohlbecher 2010-01-04 09:19:37 UTC

Created attachment 24425 [details]
Output of dmidecode

Please note that some of the output is wrong, e.g. the Chassis Height or the Processor Max Speed.

Comment 3 Philipp Kohlbecher 2010-01-04 09:20:58 UTC

Created attachment 24426 [details]
Binary DMI dump

In case this is more helpful.

Comment 4 Philipp Kohlbecher 2010-01-04 09:22:48 UTC

In case it matters, setting the "nomodeset" option does not affect this issue. Also, the time it takes until closing the lid is registered is close to 12 seconds.

Comment 5 ykzhao 2010-01-05 00:51:40 UTC

Will you please add the boot option of "printk.time=1 nomodeset" and attach the output of dmesg?
    Will you please also attach the following output?
    1. acpidump
    2. grep -R . grep -R . /sys/firmware/acpi/interrupts/*
    3. cat /proc/interrupts

Thanks.

Comment 6 Len Brown 2010-01-05 03:15:45 UTC

This is marked as failing in 2.6.32.2,
and it is marked as a regression.

What is the latest kernel where this worked properly?
If it is a recent kernel, is it possible to bisect
in drivers/acpi (particularly looking at ec.c?)

Please attach the output from acpidump.

Comment 7 Philipp Kohlbecher 2010-01-05 09:13:38 UTC

Created attachment 24441 [details]
dmesg output

Comment 8 Philipp Kohlbecher 2010-01-05 09:18:23 UTC

Created attachment 24442 [details]
acpidump output

Comment 9 Philipp Kohlbecher 2010-01-05 09:21:18 UTC

Created attachment 24443 [details]
Output of grep -R . /sys/firmware/acpi/interrupts/

Assuming that the command had one "grep -R ." too many.

Comment 10 Philipp Kohlbecher 2010-01-05 09:23:19 UTC

Created attachment 24444 [details]
Contents of /proc/interrupts

Comment 11 Philipp Kohlbecher 2010-01-05 09:29:26 UTC

Len, this is a rather old bug, I fear. It just never bothered me much before bug #14957 made it relevant. I think this stopped working more than a year ago. If I find a live CD with a working kernel version, do you have any hints on bisecting an older kernel (probably too old for my userspace)? Would that even help?

Thank you all for looking into this!

Comment 12 Rafael J. Wysocki 2010-01-11 19:21:14 UTC


*** This bug has been marked as a duplicate of bug 14957 ***

Comment 13 Philipp Kohlbecher 2010-01-11 19:36:25 UTC

Rafael, this is not a duplicate of bug #14957.

This bug is about the ACPI lid status. The incorrect lid status caused the screen to remain blank with KMS enabled (bug #14957). Fixing this bug would also solve the screen-blanking problem, but the reverse is not true: The patch that solved bug #14957 does not change the ACPI lid status, it simply ignores it. So, even after applying that patch, the lid status is still incorrect.

I believe that means that this bug should remain open.

Comment 14 Zhang Rui 2010-01-13 08:32:23 UTC

it seems that this problem is caused by the wrong lid state reported by EC.

this is a duplicate of bug #5809.
But unfortunately, we don't get a solution in that bug report neither.

Comment 15 Philipp Kohlbecher 2010-01-13 18:22:24 UTC

Thanks, Rui. I think you're right. It does look like a duplicate of bug #5809. I will try using the custom DSDT provided in that bug report and see if it helps.

Now, if this is indeed a duplicate--should I mark this as invalid as well? I am asking because http://www.lesswatts.org/projects/acpi/faq.php says that "[...] the stated goal of the Linux ACPI project today is that Linux should run on unmodified firmware."

Comment 16 Zhang Rui 2010-01-14 06:24:41 UTC

(In reply to comment #15)
> Now, if this is indeed a duplicate--should I mark this as invalid as well? I
> am
> asking because http://www.lesswatts.org/projects/acpi/faq.php says that
> "[...]
> the stated goal of the Linux ACPI project today is that Linux should run on
> unmodified firmware."

yes, unless it's a firmware bug that windows doesn't work either.
do you have a windows partition on this laptop? If yes, it would be good to verify if the problem also exists in windows.

Comment 17 Zhang Rui 2010-01-21 08:03:32 UTC

ping....

Comment 18 Zhang Rui 2010-02-21 07:08:41 UTC

close this bug as there is not response for more than a month.