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.
Will you please add the boot option of "nomodeset" and attach the output of dmidecode? Thanks.
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.
Created attachment 24426 [details] Binary DMI dump In case this is more helpful.
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.
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.
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.
Created attachment 24441 [details] dmesg output
Created attachment 24442 [details] acpidump output
Created attachment 24443 [details] Output of grep -R . /sys/firmware/acpi/interrupts/ Assuming that the command had one "grep -R ." too many.
Created attachment 24444 [details] Contents of /proc/interrupts
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!
*** This bug has been marked as a duplicate of bug 14957 ***
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.
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.
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."
(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.
ping....
close this bug as there is not response for more than a month.