|Summary:||ACPI lid button state incorrect, slow to respond|
|Product:||ACPI||Reporter:||Philipp Kohlbecher (xt28)|
|Component:||Other||Assignee:||Zhang Rui (rui.zhang)|
|Severity:||normal||CC:||lenb, rjw, rui.zhang, vasyl.demin, yakui.zhao|
Output of dmidecode
Binary DMI dump
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 220.127.116.11, 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
Comment 18 Zhang Rui 2010-02-21 07:08:41 UTC
close this bug as there is not response for more than a month.