Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM.

[Juan Manuel Cabo <juanmanuel.cabo@gmail.com>]

I bet that his _WAK dsdt method isn't re-checking the lid state on resume
(maybe I'm wrong).

I retested on my system just to make sure, and the lid is correctly reported open
always after resume from a sleep by closing the lid, using a different kernel with that same patch.

My system is the Samsung Series 5 NP530U3C in which the patch works fine:
      
           Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
           Product Name: 530U3C/530U4C

"sudo acpi_listen" shows the following on resume:

      video GFX0 00000080 00000000
      button/lid LID0 00000080 00000001
      button/lid LID0 00000080 00000002

"cat /proc/acpi/button/lid/LID0/state" shows its open always on resume. I suspended
several times, and on each time it was open.

I bet that that system's _WAK method doesn't recheck the lid, I might be wrong.
*Stefan*: Can you extract that method and send it? Something like this:

           sudo cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.bin
           cd /tmp/dsdt.bin
           iasl -d dsdt.bin
           # AND EDIT the resulting dsdt.dsl and search for and send us the _WAK method

Also, on my system, the DSDT Q event for lid state change reads it from the EC to the LIDS var,
instead of just toggling the "LIDS" variable (Lid Status). My own dsdt is downloadable from my
blog, at http://zenstep.com.ar/files/DSDT_SamsungSeries5-NP530U3c-AB1_WithBios_P14AAJ.dsl

Cheers!
--
Juan Manuel Cabo


On 03/25/2014 10:23 AM, Kieran Clancy wrote:
> On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu <lantianyu1986@gmail.com> wrote:
>> 2014-03-24 19:19 GMT+08:00 Stefan Biereigel <security@biereigel-wb.de>:
>>> Hi,
>>> thank you for the suggestion. The patch resolves the issue on my N150
>>> when applied to a clean 3.14-rc7. Anyways I'm wondering if similar
>>> problems to mine now exist on the Samsung Series 7/9 notebooks?
>>>
>>> Is any further action from my part required?
>> Do you have these machines? If yes, please provide the output of
>> dmidecode command.
>>
>> Cc guys  of commit ad332c8a.
> Hi guys,
>
> That's a surprising side-effect, although I guess I shouldn't be
> surprised by Samsung ACPI weirdness anymore.
>
> If we can, I'd like to get to the bottom of this rather than just turn
> off this fix (which we know works for series 5, 7 and 9 without
> problems).
>
>>>> 2014-03-24 15:50 GMT+08:00 Stefan Biereigel <security@biereigel-wb.de>:
>>>>> Hi,
>>>>>
>>>>> starting with 3.14-rc6, the lid on my Samsung N150 behaves weird: My
>>>>> system is set up, so that it should suspend to RAM as soon as the lid is
>>>>> closed. Beginning with 3.14-rc6, the lid goes from "open" to "closed"
>>>>> correctly the first time (and the system suspends), but after resuming
>>>>> from standby (by opening the lid), the lid does not change to "open" again.
>>>>> Of course, closing the lid again does not induce suspend to RAM then.
>>>>> Opening the lid now (while not sleeping), makes ACPI notify the opening,
>>>>> so I guess ACPI "misses" or discards the lid open event from the EC when
>>>>> coming from sleep.
>>>>> Now, closing the lid again does induce suspend to RAM. This behaviour is
>>>>> reproducible: every other time, suspending works.
>>>>>
>>>>> This behaviour seems to be introduced by commit ad332c8a: ACPI / EC:
>>>>> Clear stale EC events on Samsung systems.
>>>>> Which was introduced after 3.14-rc5.
>>>>>
>>>>> When opening the lid to resume from standby, i see in dmesg:
>>>>> Mar 23 22:12:04 little1 kernel: [ 7630.932074] ACPI : EC: 1 stale EC
>>>>> events cleared
>>>>> (which comes from drivers/acpi/ec.c)
>>>>>
>>>>> Seems to me, that the "open" event is cleared from the EC, but also
>>>>> discarded instead of passed on. Shouldn't the correct behaviour be to
>>>>> report all the pending events, read from the EC, as ACPI events? Can you
>>>>> point me in a direction for fixing the issue cleanly, then I will try to
>>>>> find a solution and prepare a patch for this issue.
> Stefan, thank you for reporting this issue.
>
> Our rationale for discarding the events was that events queued during
> sleep are probably no longer relevant. There could also be other
> unwanted side-effects of blindly executing all of the old
> instructions. But in your case, this assumption might be wrong.
>
> What command are you using to check if the lid is "open" or "closed"?
> Is it because the screen is not waking up, or some other effect, or
> just because it won't suspend again when it's re-closed?
>
> Do other events like AC plug/unplug affect any of this if you do them
> during this bad state?
>
> I'd like to see exactly which EC command byte is being thrown away
> here. If you do something like this (with dynamic debug enabled)
>
> echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
>
> You should get massively verbose EC stuff filling your dmesg, but I am
> just interested in the EC read/write bytes just before and around the
> "1 stale EC events cleared" message. Grab this out of dmesg before it
> fills with other stuff.
>
> This will tell us what command we are being asked to run. If you can,
> please do it a few times to see if it's the same command each time or
> something different.
>
> You can turn the debug output off again with:
>
> echo -n 'file ec.c -p' | sudo tee /sys/kernel/debug/dynamic_debug/control
>
> I might also need a copy of your DSDT, if you can send me that
> separately in another email (not to the list):
>
> cat /sys/firmware/acpi/tables/DSDT > .DSDT.aml
>
> Thank you,
> Kieran.
>