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

[Kieran Clancy]

On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu <lantianyu1986@xxxxxxxxx> wrote:
> 2014-03-24 19:19 GMT+08:00 Stefan Biereigel <security@xxxxxxxxxxxxxxx>:
>> 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@xxxxxxxxxxxxxxx>:
>>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/