Bug 5809
| Summary: | Status/state for LID is _close_ while the lid is open - Samsung X20 1730 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Michael Braun (charlysnews) |
| Component: | Config-Interrupts | Assignee: | Steffen Pankratz (kratz00) |
| Status: | REJECTED INVALID | ||
| Severity: | normal | CC: | acpi-bugzilla, bunk, djuvec, kratz00, trenn |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.15-rc7 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
acpi dump
acpidump output dmesg output dmesg.output_complete dmesg.output dmesg_after interrupts_before interrupts_after lspci_-vvxxx acpi_event test2 dmesg_before test2 dmesg_after test2 interrupts_before test2 interrupts_after test2 patch: disable ec gpe in gpe handler try the debug patch dmesg output with new patch try the custom DSDT dmesg_with_custom_dsdt the custom DSDT |
||
|
Description
Michael Braun
2006-01-02 03:08:35 UTC
1. When you boot the system with the lid open, what does state say? 2. When you then press the lid button down (or actually close the lid and check the state from a serial console or network connection) what does state say? 3. when you release or open the lid, what does state say? does it work properly from there forward? Hi, thanks for your answer. I'll try to answer your questions... 1. When you boot the system with the lid open, what does state say? ******************************************************************* # cat /proc/acpi/button/lid/LID0/state state: closed 2. When you then press the lid button down (or actually close the lid and check the state from a serial console or network connection) what does state say? ******************************************************************* The state is still closed when the LID is closed. # sleep 5 && cat /proc/acpi/button/lid/LID0/state state: closed 3. when you release or open the lid, what does state say? ******************************************************************* When I wait up to 20 seconds with a closed LID and open it afterwards, the status changed to open, after opening the lid. # cat /proc/acpi/button/lid/LID0/state state: open does it work properly from there forward? ***************************************** Not really. The state remains up to 10 seconds in state "open" and changed then to "closed" (lid is closed). But no suspend activity happens after the change to "close". But when I open the lid the system powers down for suspending. So it looks like that the system did not see the status change until I've opened the lid. Why does the status changed so late after I've closed the lid? # sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state state: open state: open state: closed state: closed state: closed state: closed If you need further information please contact me. Regards, Michael >1. When you boot the system with the lid open, what does state say? >******************************************************************* ># cat /proc/acpi/button/lid/LID0/state >state: closed Does the state change to open after a longer time, or just keep closed ? e.g,20 seconds . >2. When you then press the lid button down (or actually close the lid >and check the state from a serial console or network connection) >what does state say? >******************************************************************* >The state is still closed when the LID is closed. > ># sleep 5 && cat /proc/acpi/button/lid/LID0/state >state: closed The same question.:) And please attach your acpidump:). When the system is up and I do not close the LID, the status just keep "closed". When I close the LID the 1st time, I get the following result: [mb@neo ~]$ cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state state: closed state: closed state: closed state: closed state: closed state: closed state: closed When I open the LID, the system tries to get into suspend, because as you can see after I've opened the LID, the status has changed to "open". [mb@neo ~]$ cat /proc/acpi/button/lid/LID0/state state: open After this, the state will be still "open" when the LID is open. When I close the LID, the status changes after a few seconds to closed as I've writen in my last posting. I'll attach my acpidump. Created attachment 8780 [details]
acpi dump
lets not get user-space acpid and suspend mixed up in the state of the lid. Try this: # /etc/init.s/acpid stop # cat /proc/acpi/event And report if you see the LID events come out of this file when they actually happen, or with a delay like you are seeing with the state file. Also, the line for acpi in /proc/acpi/events should increment at the same time as each lid event. Here comes my results. If I close the LID and reopen it after 3 seconds, no event is written. But when I wait 20 seconds I get the foloowing: -----------8<--------- # /etc/init.d/acpid stop Stoppen des acpi D re: Here comes my results. If I close the LID and reopen it after 3 seconds, no event is written. But when I wait 20 seconds I get the foloowing: with the same process, can you check if /proc/interrupt has acpi interrupt increment? I'd like to know if the event is delayed as some software issues I hope I understood you correct.
My result with open LID:
# cat /proc/interrupts
CPU0
0: 1666601 IO-APIC-edge timer
1: 8074 IO-APIC-edge i8042
8: 3 IO-APIC-edge rtc
9: 39535 IO-APIC-level acpi
12: 1014050 IO-APIC-edge i8042
14: 166984 IO-APIC-edge ide0
16: 0 IO-APIC-level yenta, uhci_hcd:usb4
17: 31710 IO-APIC-level Intel ICH6, ohci1394
18: 220265 IO-APIC-level ipw2200
19: 0 IO-APIC-level sdhci:slot0, uhci_hcd:usb3
20: 0 IO-APIC-level ehci_hcd:usb5, uhci_hcd:usb1
21: 0 IO-APIC-level uhci_hcd:usb2
22: 66368 IO-APIC-level eth0
NMI: 0
LOC: 1666553
ERR: 0
MIS: 0
With closed LID (after 20 seconds):
# sleep 20 && cat /proc/interrupts
CPU0
0: 1674264 IO-APIC-edge timer
1: 8160 IO-APIC-edge i8042
8: 3 IO-APIC-edge rtc
9: 39681 IO-APIC-level acpi
12: 1014050 IO-APIC-edge i8042
14: 167266 IO-APIC-edge ide0
16: 0 IO-APIC-level yenta, uhci_hcd:usb4
17: 31710 IO-APIC-level Intel ICH6, ohci1394
18: 220592 IO-APIC-level ipw2200
19: 0 IO-APIC-level sdhci:slot0, uhci_hcd:usb3
20: 0 IO-APIC-level ehci_hcd:usb5, uhci_hcd:usb1
21: 0 IO-APIC-level uhci_hcd:usb2
22: 66674 IO-APIC-level eth0
NMI: 0
LOC: 1674216
ERR: 0
MIS: 0
Ha, I mean 'If I close the LID and reopen it after 3 seconds,'. See if there is interrupt increment. Isn't: 9: 39681 IO-APIC-level acpi this a too high value for ACPI interrupts? possibly noapic or pci=noacpi might workaround the problem? to comment #10 After a fresh reboot ******************** [root@neo ~]# cat /proc/interrupts CPU0 0: 1251719 IO-APIC-edge timer 1: 1741 IO-APIC-edge i8042 8: 3 IO-APIC-edge rtc 9: 41364 IO-APIC-level acpi 12: 422365 IO-APIC-edge i8042 14: 79963 IO-APIC-edge ide0 16: 0 IO-APIC-level uhci_hcd:usb4, yenta 17: 11518 IO-APIC-level ohci1394, Intel ICH6 18: 66706 IO-APIC-level ipw2200 19: 0 IO-APIC-level uhci_hcd:usb3, sdhci:slot0 20: 0 IO-APIC-level uhci_hcd:usb1, ehci_hcd:usb5 21: 0 IO-APIC-level uhci_hcd:usb2 22: 49825 IO-APIC-level eth0 NMI: 0 LOC: 1251678 ERR: 0 MIS: 0 [root@neo ~]# /etc/init.d/acpid stop Stoppen des acpi D to comment #11 I've tried both "noapic" and "pci=noacpi" but both does not solve the problem. please have a try with a boot option ec_intr=polling :) Thanks for this tip, but also "ec_intr=polling" does not change anything on the status. It seems you have some kind of interrupt storm on the acpi interrupt.
Just an idea (I've never saw this and never used this one), but this boot
parameter sounds as it may help on your system:
(from Documentation/kernel-parameters.txt):
acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
Format: { level | edge | high | low }
I've tried every option for "acpi_sci=" but with no success. Its still the same beahvior. Looks like the ACPI SCI is actually working properly, and the problem with the huge storm of interrupts might be due to the underlying GPE's screaming. There are quite possibly two independent problems on this box. the interrupt storm on the acpi SCI interrupt, and the lid state issue. in the responses above about the following parameters noapic acpi_sci=level acpi_sci=high acpi_sci=level acpi_sci=low acpi_sci=edge acpi_sci=high acpi_sci=edge acpi_sci=low while they did not have an effect on the lid problem, did any of them have any effect on the storm of acpi interrupts? Re: comment #15 try "ec_intr=0" -- i believe the syntax you used above was a no-op. You can confirm it worked by looking for a change in dmesg: > EC polling mode. (if you use ec_intr=1, it should print "EC interrupt mode", which is the default) Re: the delay I suspect that the interrupt storm is getting in the way of processing the lid event in a timely manner. Unclear why _LID doesn't immediately return the proper value, unless a delayed event is necessary to update that too. Re: suspend There is only 1 type of event for the lid -- 0x80 means the lid _changed_. acpid gets this event via /proc/acpi/event, goes off and looks at /proc/acpi/.../lid and it says "closed", then it will interpret that as a lid close event and suspend. So if there is a delay between the event and the lid status, you'll see this kind of symptom. For the time being, disable acpid -- or at least its lid handler. Looking at the DSDT:
Device (LID0)
{
Name (_HID, EisaId ("PNP0C0D"))
Method (_LID, 0, NotSerialized)
{
Return (LIDS)
}
}
OperationRegion (ECR, EmbeddedControl, Zero, 0xFF)
Field (ECR, ByteAcc, Lock, Preserve)
{
Offset (0x18),
SPTR, 8,
SSTS, 8,
SADR, 8,
SCMD, 8,
SBFR, 256,
SCNT, 8,
Offset (0x80),
B1EX, 1,
, 1,
ACEX, 1,
Offset (0x81),
SWBE, 1,
DCBE, 1,
Offset (0x82),
WLST, 1,
Offset (0x83),
LIDS, 1,
Offset (0x84),
...
Method (_Q5E, 0, NotSerialized)
{
Store (LIDS, \LIDS)
Notify (LID0, 0x80)
}
Method (_Q5F, 0, NotSerialized)
{
Store (LIDS, \LIDS)
Notify (LID0, 0x80)
}
So the EC handlers _Q5E and _Q5F read the EC LIDS
and apparently copy it to a global \LIDS that the _LID
method simply returns that as its status.
ec_intr=0 remains the key knob to turn.
Please reopen this bug if: - it is still present in kernel 2.6.18 and - you can provide the requested data. I have he same problem as described with kernel 2.6.18.2-34 (openSuSE 10.2). Hi Robert please try 2.6.19 and attach the dmesg and acpidump at the same time. Please reopen this bug if: - it is still present with kernel 2.6.20 and - you canprovide the requested information. Created attachment 13848 [details]
acpidump output
Created attachment 13849 [details]
dmesg output
I have the same problem and it seems it's not fixed yet. Hardware: Samsung M50 Tested with: 2.6.23.9 and 2.6.24-rc4 See attachments for acpidump and dmesg output. *** Bug 9666 has been marked as a duplicate of this bug. *** The acpidump for Steffen's Samsung M50-2130 in bug #9666 shows the same EC mechanism for updating _LID: Device (H_EC) { Name (_HID, EisaId ("PNP0C09")) ... OperationRegion (ECR, EmbeddedControl, Zero, 0xFF) Field (ECR, ByteAcc, Lock, Preserve) { Offset (0x18), SPTR, 8, SSTS, 8, SADR, 8, SCMD, 8, SBFR, 256, SCNT, 8, Offset (0x80), B1EX, 1, , 1, ACEX, 1, Offset (0x81), SWBE, 1, DCBE, 1, Offset (0x82), WLST, 1, Offset (0x83), LIDS, 1, Offset (0x84), ... Method (_Q5E, 0, NotSerialized) { Store (LIDS, \LIDS) Notify (LID0, 0x80) } Method (_Q5F, 0, NotSerialized) { Store (LIDS, \LIDS) Notify (LID0, 0x80) } Steffen,
> 9: 2758 XT-PIC-XT acpi
Looks like you see a lot of ACPI interrupts also.
While perhaps not directly related tot the problem at hand,
you are running in PIC mode -- does your kernel have IOAPIC
support enabled? Also, to get the full dmesg back to the
beginning, you need to do something like "dmesg -s64000"
re: lots of ACPI interrupts It would be best to execute the tests on the lid in single-user mode. That will get various user-space utilities that poke /proc/acpi files and cause events out of the picture so we can focus on just the lid and the events it causes. Created attachment 14243 [details]
dmesg.output_complete
grep APIC .config CONFIG_X86_GOOD_APIC=y # CONFIG_X86_UP_APIC is not set Not sure if it's the same you asked for? I attached new and complete dmesg output 'dmesg.output_complete'. > # CONFIG_X86_UP_APIC is not set
Yes, you want to enable that, as your system has an IOAPIC:
ACPI: APIC 7FEAFF0A, 005A (r1 INTEL ALVISO 6040000 LOHR 5F)
(While IOAPIC mode is the proper way to run this hardware,
I don't expect it to have an effect on the problem at hand.)
So please boot up into single user mode and...
grep acpi /proc/interrupts
cat /proc/acpi/event &
# press the power button to see an event come out
# you can also use the sleep button, if you have one,
# or plug/unplug the AC/DC adapter
grep acpi /proc/interrupts
# and now try the lid button to see it provokes events
# and if the LCD backlight comes back even after you wait,
# then type "reboot" to the blank screen...
Created attachment 14247 [details]
dmesg.output
New kernel now running with: CONFIG_X86_GOOD_APIC=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y and new dmesg output is also attached. here is the output you wanted: 9: 146 IO-APIC-fasteoi acpi button/power PWRF 00000080 00000001 9: 147 IO-APIC-fasteoi acpi state: closed button/lid LID0 00000080 00000001 button/lid LID0 00000080 00000002 state: open 9: 155 IO-APIC-fasteoi acpi For the lid part: initial state is closed then I really closed the lid for about 15 seconds and opened it afterwards. can you add some timing detail to that? ie. does the button/lid even happen immediately upon hitting the lid switch? (i expect yes). And it looks like the state file catches up with reality -- how long does it take to switch between incorrect to correct? 9: 147 IO-APIC-fasteoi acpi state: closed # 2 lines above show the inital state, lid is closed and count is 147 button/power PWRF 00000080 00000002 Sat Jan 5 13:08:25 CET 2008 9: 148 IO-APIC-fasteoi acpi state: closed # after pressing the power button, lid state is still closed and count was incremented Sat Jan 5 13:09:06 CET 2008 # circa the time I closed the lid button/lid LID0 00000080 00000001 Sat Jan 5 13:09:18 CET 2008 9: 152 IO-APIC-fasteoi acpi state: closed # so it took about 12 seconds till the event occurred button/lid LID0 00000080 00000002 Sat Jan 5 13:09:44 CET 2008 9: 156 IO-APIC-fasteoi acpi state: open # the lid is now open but it's hard to say if the event occurred while opening the lid because there is no button I could press, I really have to close the lid I hope this helps you further I added some audio output to my script (echo -e "\a") :) When opening the lid again the event is dispatched immediately. So the main problems are: 1. Initial state of the lid is always 'closed' 2. It takes arround 12 seconds to recognise the lid was closed. Hi, Steffen Will you please try the latest kernel(2.6.24-rc8) and do the following test ? It is noted that the acpi debug function should be enabled in kernel configuration. a. use the command of "lsof /proc/acpi/event" to get the PID who is using /proc/acpi/event. Kill -9 PID b. cat /proc/interrupts > interrupts_before and dmesg > dmesg_before c. echo 0x04 > /sys/module/acpi/parameters/debug_layer and echo 0x08000010 > /sys/module/acpi/parameters/debug_level d. cat /proc/acpi/event > acpi_event e. close LID and reopen it. Then cat /proc/interrupts > interrupts_after and dmesg > dmesg_after After the test , will you please attach the above test? Thanks. Here we go: acpi_event is totally empty and dmesg_before and dmesg_after are identical afterwards. Maybe I did something wrong? Debugging is enabled: CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUG_FUNC_TRACE=y Created attachment 14549 [details]
dmesg_after
Created attachment 14550 [details]
interrupts_before
Created attachment 14551 [details]
interrupts_after
Hi, Steffen Thanks for the info and what you have done is right. From the comment #44 and #45 it seems that no acpi interrupt happens when lid is closed and opened. It is very strange. In theory acpi interrupt should be triggered. Will you please attach the output of "lspci -vvxxx"? Thanks. This is right there was no acpi event when i opened and closed the lid. I have done the tests again but this time I waited arround 12 seconds (see Comment #40) before opening the lid and now I got some events. I will attach the new files and the lspci output. Created attachment 14558 [details]
lspci_-vvxxx
Created attachment 14559 [details]
acpi_event test2
Created attachment 14560 [details]
dmesg_before test2
Created attachment 14561 [details]
dmesg_after test2
Created attachment 14562 [details]
interrupts_before test2
Created attachment 14563 [details]
interrupts_after test2
Thanks for the info. What Steffen said in comment #40 is very right. The remaing two problems are >1. Initial state of the lid is always 'closed' >2. It takes arround 12 seconds to recognise the lid was closed. For the problem 1: It is caused by the following: Method (_LID, 0, NotSerialized) { Return (LIDS) // LIDS is declared in the ACPI_NVS memory and initial value is zero. } Method (_Q5E, 0, NotSerialized) //Only when the EC triggers acpi interrupt and Q5E/Q5F method is executed , the state of the LID will be update. { Store (LIDS, \LIDS) Notify (LID0, 0x80) } For the problem 2: From the log in comment #44 and #45 there is no ACPI interrupt when LID is closed and opened in case of no waiting 12 seconds. But after waiting about 12 seconds, there is EC interrupt and the state of the lid can be update when LID is closed/opened. Maybe this issue is related to EC hardware. Thanks. What's next? Can I do anything else, helping you to fix this problem? The problem is related with BIOS. Can you upgrade BIOS first and see whether the problem still exists? There is no BIOS update available :( See: http://www.samsungpc.com/products/m50/m50_bios.htm Why does it work in Windows then? Created attachment 15039 [details]
patch: disable ec gpe in gpe handler
Please try the latest kernel with this patch applied. :)
I patched Linux 2.6.24.3, which is the latest stable kernel at the moment. Here are my observations: - initial lid state is still closed - power-button still produces acpi events - closing the lid does not generate events anymore, even if waiting for more than 12 seconds nothing happend With your patch the "Fn" key combinations stopped working and unplugging my notebook from ac doesn't lower the display brightness anymore too. Please obsolete the patch in #58. Anything else I can do, to help you to fix this problem? Created attachment 16020 [details]
try the debug patch
Will you please try the debug on the latest kernel and do the following test?
a. use the command of "lsof /proc/acpi/event" to get the PID who is using
/proc/acpi/event. Kill -9 PID
b. echo 0x04 > /sys/module/acpi/parameters/debug_layer and echo 0x08000010 >
/sys/module/acpi/parameters/debug_level && echo 1 > /sys/module/printk/parameters/time
c. close LID (waiting for 10 seconds) and reopen it .
After the test, please attach the output of dmesg.
It is noted that the acpi debug function should be enabled in kernel
configuration.
Thanks.
I had to wait at least for 12 seconds before seeing something in dmesg. Created attachment 16024 [details]
dmesg output with new patch
Thanks for so quick response. From the log in comment #65 the LID event can be received after the LID is closed and reopened. >[ 49.984539] ACPI: EC: Evaluate _Q5e object >[ 52.186157] ACPI: EC: Evaluate _Q5f object And the above two objects will send notification event(0x80) to LID device. > Store (LIDS, \LIDS) > Notify (LID0, 0x80) Will you please confirm whether the windows enter the standby mode immediately after closing the lid? > the initial state of the LID is closed. IMO the windows doesn't care the initiail state of the LID. Only when the LID is closed will windows receive the LID event and enter the standby mode. And when the LID is reopened, the windows will be waked from the sleeping state. Thanks. Created attachment 16026 [details] try the custom DSDT Will you please try the custom DSDT and see whether the initial state of the lid is correct? In the custom DSDT the state of LID is stored to the global variable of LIDS in the course of EC initialization. > Store(LIDS, \LIDS) How to use the custom DSDT can be found in the following website: http://www.lesswatts.org/projects/acpi/faq.php I'm not sure what do you mean by "the windows"? Do you mean Microsoft Windows? I have no MS Windows on this notebook but I can ask my sister, she has the same, if it's this what you are asking for. I tried the custom dsdt: I compiled the attachment with iasl and configured the kernel and so one, I had the following problems booting the new kernel: I couldn't boot because the laptop was shut down: May 5 18:04:43 hermes kernel: Critical temperature reached (77 C), shutting down. May 5 18:13:07 hermes kernel: Critical temperature reached (53 C), shutting down. May 5 18:18:22 hermes kernel: Critical temperature reached (76 C), shutting down. May 5 18:22:09 hermes kernel: Critical temperature reached (69 C), shutting down. This never happened before. Linux console was nearly unusable, hard to describe. Nvidia driver (blob) could not be loaded anymore May 5 18:13:17 hermes kernel: NVRM: RmInitAdapter failed! (0x12:0x2b:1550) May 5 18:13:17 hermes kernel: NVRM: rm_init_adapter(0) failed I saw some irg problems which also never happened before: May 5 18:22:09 hermes kernel: irq 16: nobody cared (try booting with the "irqpoll" option) May 5 18:22:09 hermes kernel: Pid: 1944, comm: S30checkfs Tainted: P A 2.6.25.1 #3 May 5 18:22:09 hermes kernel: [__report_bad_irq+0x24/0x90] __report_bad_irq+0x24/0x90 May 5 18:22:09 hermes kernel: [note_interrupt+0x2c8/0x300] note_interrupt+0x2c8/0x300 May 5 18:22:09 hermes kernel: [handle_IRQ_event+0x25/0x60] handle_IRQ_event+0x25/0x60 May 5 18:22:09 hermes kernel: [handle_fasteoi_irq+0xbb/0x100] handle_fasteoi_irq+0xbb/0x100 May 5 18:22:09 hermes kernel: [do_IRQ+0x45/0x80] do_IRQ+0x45/0x80 May 5 18:22:09 hermes kernel: [sys_rt_sigprocmask+0x83/0x100] sys_rt_sigprocmask+0x83/0x100 May 5 18:22:09 hermes kernel: [common_interrupt+0x23/0x28] common_interrupt+0x23/0x28 May 5 18:22:09 hermes kernel: ======================= May 5 18:22:09 hermes kernel: handlers: May 5 18:22:09 hermes kernel: [<f8929f20>] (usb_hcd_irq+0x0/0x60 [usbcore]) May 5 18:22:09 hermes kernel: Disabling IRQ #16 I will attach the dmesg output but one good think happened, the lid state was right :) Created attachment 16029 [details]
dmesg_with_custom_dsdt
Hi, Thanks for the test. It seems that the LID initial state is right after the custom DSDT is used. But it brings some new problems. Will you please confirm whether the problems in comment #68 exists if not using the custom DSDT? Maybe what I said in comment #66 is not very clear. a. About the initial state of the LID even when the LID is open Maybe the microsoft windows doesn't care the initial state of the LID. It only cares whether the LID button is pressed and the LID event is received. When it receivces the LID event that the LID is pressed, it will enter the standby mode. In fact the problem is caused by the broken bios. If the state of LID is stored to the global variable of LIDS in the course of EC initialization, we can get the correct state of the LID using /proc/acpi/button/lid/LID0/state. b. takes 12 seconds to receive the LID event when the LID is pressed. From the log in comment #65 the LID event can be received when LID is pressed. But it need wait for 12 seconds to recognize the state of the LID. We had better confirm whether the windows enter the standby mode immedidately after the LID is pressed. If no, I think that it is related with BIOS. Please test it on your sister's laptop. Thanks. Just to make sure, maybe you mixed something up, did you use my acpi dump to create the custom DSDT, there are two attached to this bug report? All problems I described in #c86 only occur if I boot the kernel which was patched with the custom DSDT. I called my sister and she had to perform some tests with her notebook :) It's the same on MS Windows, after closing the lid it takes about 12 seconds before the notebook starts to enter suspend mode. Maybe this delay is a feature? Hi, Steffen
Thanks for the test.
Sorry for my fault. I mixed the acpidump file on your laptop with another. But anyway it points the root cause that the initial state of the LID is closed when using the interface of /proc/acpi/button/LID0/state. It is caused by the following:
> Method (_LID, 0, NotSerialized)
{
> Return (LIDS) // LIDS is declared in the ACPI_NVS memory and
initial value is zero.
> }
When the LID button is pressed, the _Q5E/_Q5F object will be executed and the state of the LID can be updated correctly.
> Store (LIDS, \LIDS)
> Notify (LID0, 0x80)
And if the LID state is stored to the global variable \LIDS in the custom DSDT, we will get the correct LID state using /proc/acpi/button/LID0/state.
> Method (_REG, 2, NotSerialized) {
> If (LAnd (LEqual (Arg0, 0x03), LEqual (Arg1, One)))
> {
> Store(LIDS, \LIDS)
b. takes 12 seconds to receive the LID event when the LID is pressed
According to the test on Windows it seems that it also takes about 12 seconds before the notebook starts to enter suspend mode after closing the LID. IMO this is related with the BIOS. Maybe the delay is a feature of this laptop.
Since the two above issuse are caused by BIOS and can't be fixed in Linux ACPI, IMO this bug can be closed.
Thanks.
Thank you very much for your help Yakui, but could you do me a last favour and fix the DSDT for me, as I have now knowledge of this stuff. This can be closed then, thanks. Created attachment 16062 [details] the custom DSDT Hi, Steffen The attached is the custom DSDT based on your ACPIDUMP. The lid state is stored to the global \LIDS variable in the course of EC initialization. > Method (_REG, 2, NotSerialized) { > If (LAnd (LEqual (Arg0, 0x03), LEqual (Arg1, One))) { > Store(LIDS, \LIDS) > Store (One, ECON) > Store (ACEX, PWRS) And thanks for your help. Thank you very much Yakui, everything is still working fine with the patched DSDT and the lid state is also correct. I will close this bug report now. |