Created attachment 99361 [details]
acpidump output

Laptop specification can be found here: http://www.gigabyte.us/products/product-page.aspx?pid=2034

Hi:
       LID state com from bios and ACPI driver expose the result to user space. Just check the acpi table, the LID state is from MNVS operation region, LIDS field. So this maybe a bios or hardware issue.

    OperationRegion (MNVS, SystemMemory, 0x4FF7BE7D, 0x40)
    Field (MNVS, AnyAcc, Lock, Preserve)
    {
      ...
      LIDS
      ...
    }

        Name (_HID, EisaId ("PNP0C0D"))
            Method (_LID, 0, NotSerialized)
            {
                If (LIDS)
                {
                    Return (0x01)
                }
                Else
                {
                    Return (0x00)
                }
            }



And about gpe10, I have not seen any info about it in the acpi table and it should not be used. Invalid state seems correct. Does I miss something?

(In reply to comment #3)
> Hi:
>        LID state com from bios and ACPI driver expose the result to user
>        space.
> Just check the acpi table, the LID state is from MNVS operation region, LIDS
> field. So this maybe a bios or hardware issue.

Right, the LIDS symbol used to track lid's status is just a variable in memory space, and it's not set anywhere. Either the hardware does not support reporting LID status, or the BIOS asl code has a bug.

> 
>     OperationRegion (MNVS, SystemMemory, 0x4FF7BE7D, 0x40)
>     Field (MNVS, AnyAcc, Lock, Preserve)
>     {
>       ...
>       LIDS
>       ...
>     }
> 
>         Name (_HID, EisaId ("PNP0C0D"))
>             Method (_LID, 0, NotSerialized)
>             {
>                 If (LIDS)
>                 {
>                     Return (0x01)
>                 }
>                 Else
>                 {
>                     Return (0x00)
>                 }
>             }
> 
> 
> 
> And about gpe10, I have not seen any info about it in the acpi table and it
> should not be used. Invalid state seems correct. Does I miss something?

I asked Sergey to file a new bug report instead of describing his problem in bug #25802, where that bug reporter's EC uses gpe 10. Of course gpe10 doesn't make any sense here, so please ignore this information here.

(In reply to comment #4)
> (In reply to comment #3)
> > Hi:
> >        LID state com from bios and ACPI driver expose the result to user
> space.
> > Just check the acpi table, the LID state is from MNVS operation region,
> LIDS
> > field. So this maybe a bios or hardware issue.
> 
> Right, the LIDS symbol used to track lid's status is just a variable in
> memory
> space,

It is in NVS area, so it may has been initialized by BIOS before booting into OS.

But anyway, this seems like a BIOS problem we can not cover, Sergey, is there any chance that you can check if lid works properly on this laptop in Windows?

Some years ago lid works fine (2009-2010). 1-2 years ago laptop goto sleep on removing external power but not closing lid. I will try Windows...

is there a BIOS update between 2010 and now?
if no, this seems like a software regression, so whether Windows works or not does not matter now in this case.

I have update BIOS 2 weeks ago. But problem was early (see bug #25802). Update is not fix problem.
I will try WindowsXP at this weekend if can find HDD with this OS in my garage :-)

I do not know, may it help or not. But laptop is going to sleep when I unplug external power. I can wake up it and it will work some long time (30-60 min).

Today I check in Windows XP Home. All works fine. I have only install: Intel Inf driver, Intel 2200BG WLAN, and ATI Catalyst 9.3.

(In reply to comment #10)
> Today I check in Windows XP Home. All works fine. I have only install: Intel
> Inf driver, Intel 2200BG WLAN, and ATI Catalyst 9.3.

What if you do not install any third party driver?

In this case sleep and hibernate modes are unavailable.

Without any drivers power cable unplugging detected correctly and available option to change behaviour on closing lid in power settings. But only one behaviour present - "do nothing".

(In reply to comment #12)
> In this case sleep and hibernate modes are unavailable.
What meaning of this case? You don't load some windows's driver?

> Without any drivers power cable unplugging detected correctly and available
> option to change behaviour on closing lid in power settings. But only one
> behaviour present - "do nothing".

See. I only install Windows XP Home SP3 (no any additional drivers). Now I go to Control Panel - Power management - Advanced (or additional - I do not know how it looks in English version). Here is behaviours for: power button press, lid close, sleep button press (hibernate - I do not know how it in English version). Possible behavious are: Do nothing, Ask user and Shutdown (sorry I do not know correct English text for these values). For lid close combobox available only 'Do nothing' value.
After installing three drivers listed above (chipset, VGA, WLAN) additional options are available: hibernate mode and sleep (standby) mode.
So I cannot test lid without installing these drivers.

Please run acpi_listen durng lid opening and closing to check whether Bios produces LID event correctly.
LID state and LID event are produced by different way.

button/lid LID0 00000080 00000001
button/lid LID0 00000080 00000002
button/lid LID0 00000080 00000003
ac_adapter ADP1 00000080 00000000
battery BAT0 00000080 00000001
ac_adapter ADP1 00000080 00000001
battery BAT0 00000080 00000001
battery BAT0 00000081 00000001


Here I 3 times close and open lid and then unplug and plug power cable.

(In reply to comment #16)
> button/lid LID0 00000080 00000001
> button/lid LID0 00000080 00000002
> button/lid LID0 00000080 00000003
You enabled system suspend on Lid? Since you said close and open lid tree times,
both open and close should have events.

I think no. Only monitor switches off when I close lid (hw function, I think). Event generated for close action. For open nothing is generated.

Sorry for later reply.
From the result, there is no open lid event.
No idea about how Windows works. Reassign to Bios catagory.

As stated in comment #4, Linux kernel just reads from Memory to get the Lid status, while it is actually updated by firmware.
Plus, vanilla windows can not handle Lid events properly as well.

So, this is either a firmware bug, or we're missing some vendor driver to make lid work in a specific way.
In any case, this is not an ACPI Lid problem, bug Closed.