I made a mistake with the kernel version.

Created attachment 24779 [details]
custom _LID method

please try the custom _LID method attached.
Note that the test must be done in 2.6.33-rc kernel.
Please read Documentation/acpi/method-customizing.txt to see how to override an ACPI control method.

it would be good if you can cat the content of /proc/acpi/button/lid/*/state when the lid is closed.

Any suggestion on how to get this information for you?  Especially if the laptop is suspended.

please run "lsof /proc/acpi/event" as root user and kill the process that opens this file. The laptop should not go to suspend when you close the lid. so you can get the lid state using something like remote login/external keyboard, etc.

BTW, I think you should do the test in comment #2 first to see if the problem still exists.

Since Rui suspects an AML bug, it would be great if you can investigate
how the LID works with Windows to make sure the bug is common
to all operating systems.

Alright, after spending 4 days fixing issues with Debian and re-configure/re-building I got 2.6.33-rc5 compiled and running on my laptop. 

I did the following from as per Documentation/acpi/method-customizing.txt:
1) mount -t debugfs none /sys/kernel/debug
2) cat asl.aml > /sys/kernel/debug/acpi/custom_method


I than ran the same test pattern I initially performed with the following results:

1)  After a fresh boot AND loading the AML custom method:
cat /proc/acpi/button/lid/*/state gives me:
State: open

2) Close (successful suspend) and Reopen the lid:
cat /proc/acpi/button/lid/*/state gives me:
State: open

3) Close the lid (successful suspend) and Reopen the lid
cat /proc/acpi/button/lid/*/state gives me:
State: open

4) Close (successful suspend) and Reopen the lid:
cat /proc/acpi/button/lid/*/state gives me:
State: open

I know it is working at this point, so my first question is:  was this related to the new kernel driver OR was it the AML that I loaded?  If so, will this AML have to be loaded every time OR is there a way to "unload" it and test again. (I should have done this first, but I was too anxious to try this out)

Robin

(In reply to comment #6)
> Since Rui suspects an AML bug, it would be great if you can investigate
> how the LID works with Windows to make sure the bug is common
> to all operating systems.

That is an odd request, could you elaborate.  Under Windows XP (my laptop dual-boots) the suspend function works perfectly.  Although, at the same time after a month or two without a full restarts it eventually fails to come out of the suspend state properly.

Robin

When should I expect this fix to be integrated?  I can currently loading the aml script on-boot so the lid open/close functionality works correctly.

Thanks!

well, I think this is a AML code bug and my fix works for you.
But windows works well on this laptop, which means Linux should work as well, without any firmware code changes.
Here is the original _LID method,
            Method (_LID, 0, NotSerialized)
            {
                If (LDWK)
                {
                    Store (Zero, LDWK)
                    Return (One)
                }
                Else
                {
                    Return (LIDF)
                }
            }
So the LID state should be stored in LIDF.
comment #0 shows that LDWK is 0 every other time, when the Lid is opened.
                    Method (_Q10, 0, NotSerialized)
                    {
                        Store (LIDS, Local0)
                        If (LEqual (Local0, One))
                        {
                            Store (Zero, LIDF)
                        }
                        Else
                        {
                            Store (One, LIDF)
                        }

                        If (LDWK)
                        {
                            Store (0x10, PO80)
                            Store (One, LIDF)
                            Store (Zero, LDWK)
                        }

                        Notify (LID, 0x80)
                    }


So I change it to:
    Method (\_SB.LID._LID, 0, NotSerialized)
    {
        Store (\_SB.PCI0.LPCB.EC0.LIDS, Local0)
        If (LEqual (Local0, One))
        {
            Return (Zero)
        }
        Else
        {
            Return (One)
        }
    }
because IMO, \_SB.PCI0.LPCB.EC0.LIDS should always report the correct Lid state.

But the problem is that this doesn't seems like an AML issue because windows works well on this machine.

Is there a long term solution?

well, in order to make clear how the AML code works in Linux, please
1. rebuild your kernel with CONFIG_ACPI_DEBUG set
2. reboot with boot option acpi.debug_layer=0x80 acpi.debug_level=0x02.
3. apply the three custom ACPI methods I attached below, and then attach the dmesg output after the same test in comment #7.

Created attachment 25230 [details]
_LID method with debug info

Created attachment 25231 [details]
_Q10 method with debug info

Created attachment 25232 [details]
_Q14 method with debug info

Note that please follow the documentation to load the three custom methods one by one.

ping ....

I apologize for the delay.

After setting the requested boot options from comment #12 than rebooting and loading the custom methods in the order they are attached I get the following results:

1)  After a fresh boot AND loading the AML custom method:
cat /proc/acpi/button/lid/*/state gives me:
State: open

2) Close (successful suspend) and Reopen the lid:
cat /proc/acpi/button/lid/*/state gives me:
State: closed

I will attach my the complete output of dmesg.

Created attachment 48372 [details]
dmesg output

This is the output requested from dmesg after repeating the relevant tests (previous comment) with the listed custom methods applied.

Please let me know if you need more testing done or need more details.

Thanks

It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?

Unfortunately this laptop has died on me so I have no way to test this.  Thanks for your effort!