Bug 10485

Created attachment 15817 [details]
output of dmesg

Created attachment 15818 [details]
output of lspci -vvxxx

Created attachment 15819 [details]
output of acpidump

Created attachment 15828 [details]
try the custom DSDT

Will you please try the custom DSDT and see whether the problem still exists?
How to use the custom DSDT can be found in the following:
http://www.lesswatts.org/projects/acpi/faq.php

Thanks.

Wow thanks!

This DSDT fixes the problem - a problem which has meant i have been unable to close my laptop lid with the power on for >2 years!.

Now there is one event for lid closed and one for lid open. Does this mean that the bug is in the bios for the machine ? If so, what do you think are the chances of getting Acer to fix this (The bug seems to affect many different models of laptop from them). Or is it something which can be worked around in the kernel ?

Hi,Jools
   Thanks for the test. It is obvious that the problem is caused by the broken BIOS.
   On this laptop the lid device is connected with the GPIO(0x0B) , which controls the status bit (0x1B) of GPE status register. (Of course the LID polarity control bit should be defined).In such cases the correct flowchart of lid event handler should be following: 
   a. flip the polarity of LIDP bit
   b. send the notify event(0x80) to the LID device
  
   Unfortunately the polarity of LIDP bit is not flipped in the lid event handler. And after the LID is pressed, the correspond GPE status bit is always set, which causes the ACPI interrupt storm. In the custom DSDT the polarity of LIDP bit is flipped in the LID event handler.
 >   Method (_L1B, 0, NotSerialized)     {
  >          Not (LIDP, LIDP)
   >         Notify (\_SB.LID, 0x80)
    >    }

   IMO this is a BIOS bug and it is appropriate to fix it by upgrading BIOS.( It is difficult to write the work around patch in kernel).

Will you please confirm whether windows can work on this laptop?

It does work with windows. Some bits of the laptop still only work on windows (the MMC reader - unsupported o2micro unit on linux and the smartcard reader with shipped smartcard)

Unfortunately this is the latest bios version already on the laptop. All the versions seem to have this bug, and other Acer models of laptop also seem to have it. Perhaps someone in the kernel development has some contact with the devs at Acer?

when you said windows work, does it work with a fresh windows installation without any drivers provided by Acer?

It does work yes. Although you don't of course get full chipset support until you download the intel chipset drivers, the gfx card drivers and so on. Or are you after some other information?

Thanks for the test.
Will you please confirm whether the lid still works after the lid is closed/reopend?

On Linux the lid works perfectly/opening/closing/opening/closing etc.
Or do you mean for me to test it on windows ?

Yes. Please test it on windows. 
It will be great if you confirm whether the LID event is received on windows when the LID is reopened.
Thanks.

Hi, Jools
    This bug is related with bios bug. But it is very strange that windows can work well on it.
    Will you please try to do the following test on windows?
    a. change the Power option for LID :the default action is to enter standby mode. Please choose to do nothing when close the lid. 
    b. press the LID several times and see whether the system can work well.
    c. restore the power default option for the LID.( the default option is to enter stand by). And then press the lid switch to check whether the system can enter the standby mode.
    
    Thanks.
    

Sorry for this delayed reply. Finally I had the courage to boot into windows ;-)

I removed all the acer epowermanagement software. and set lid closed to "do nothing". I then pressed the lid button for 10 seconds. then let it go and repeated the process a few times. The machine did nothing (apart from backlight turning off - which is done in hardware)

I then changed the lid button to "go into standby" mode and pressed the lid button. The machine went into standby correctly, and i was able to return from sandby mode fine. I could also repeat this process and it worked ok.

Hi, Jools
    Thanks for test. 
    Will you please do the following test again on windows again?
   a. change the Power option for LID :the default action is to enter standby
mode. Please choose to do nothing when close the lid. 
   b. Open the windows task manager and switch to the Performance property sheet. 
   c. close the LID button for 10 seconds and reopen it. Please check whether the cpu usage is very high in cpu uage history diagram.
   
    Thanks.

Thanks for your reply. I have tested this. There was no noticeable high cpu on the graph. There were tiny bumps (2-4% cpu use) at the point the lid button was pressed/released, but nothing while it was being held down.

Hi, Jools
    Thanks for the test. From your description it seems that windows can work well on this laptop. But the result is different with what I have tested.
    There is a laptop in hand on which the GPIO is used by the LID device. The AML code related with the LID event is listed in the following:
 >   Method (_L1B, 0, Serialized)
        {
      >        TGPP (0x0B) // flip the LID polarity
     >         Notify (\_SB.LID, 0x80) // send the LID notification
    >    }
    Because the LID polarity is flipped, windows/Linux can work well on this laptop. But if the custom DSDT is used on windows(delete the AML code in BIOS that flips the LID polarity), there also exists the interrupt storm  when the LID is closed. And the CPU usage is very high.
    
    I don't know why windows can work well on your laptop.
    Will you please double check it again?
    thanks.    

I can verify that DSDT provided fixes the continuous lid event problem on an Acer Travelmate 8104 WLMi running linux-2.6.18-gentoo-r6. A single event is generated when the lid button is pressed and again when released. Many thanks. (I've written a brief article on how to apply the DSDT: http://mindspill.net/computing/linux-notes/acpi/custom-dsdt.html)

As this is an obvious BIOS bug, it had better be fixed by upgrading BIOS. IMO this bug can be rejected. 
Of course the problem can be fixed by the custom DSDT.

unfortunately there is no bios upgrade though to fix it. And it does seem to work ok under windows. However, having a patch for the DSDT is appreciated.

Hi, Jools
    Will you please attach the output of dmidecode?
    Thanks.