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.