From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754085AbaCYQiw (ORCPT ); Tue, 25 Mar 2014 12:38:52 -0400 Received: from moutng.kundenserver.de ([212.227.17.13]:54179 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754027AbaCYQis (ORCPT ); Tue, 25 Mar 2014 12:38:48 -0400 Message-ID: <5331B10F.3050402@biereigel.de> Date: Tue, 25 Mar 2014 17:38:39 +0100 From: Stefan Biereigel User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kieran Clancy , Lan Tianyu CC: Stefan Biereigel , "linux-acpi@vger.kernel.org" , "linux-kernel@vger kernel org" , Len Brown , "Rafael J. Wysocki" , San Zamoyski , Juan Manuel Cabo , "D. Jansen" , "Maurizio D'Addona" Subject: Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM. References: <532FE3B2.9060808@biereigel-wb.de> <533014B1.4030307@biereigel-wb.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:gAmKDsagTXYiDTGuHs7/t9mNEn1wX8/wzESD6bJpl+u 5BtXjFJQeBtb1+b7C+BhYpofgP2kzEOipZ94CKmZAiAmqKNU46 j8+/v4P1otzevRnzG1SH5q5aULF0YdAaHXT2WeHncAE66tBH4j FUZQ6Lo8QYgH+7IO8Q6OZsQ4m08SwhdExdNt/jy3nJcpMoCzj+ HOOZBsuCzaJ5L7mHOOGUeqU2U3NgfVilS+ERp3QUSEA3y9dtI3 2Xtx2S4V2CS9R6gU6nqZGtP1Fv9ogE4GKFLIjlgiucyIR9VEEd YoYnw7qj4De6FcjXeoc3spPxFekWWwJYjG/VPzhp4oKb0ER6kp 370nBSfYKgkJykRldh1Y= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Kieran, thanks for the input. I use /proc/acpi/button/lid/LID0/state as an indicator - whenever I resume from sleep on a bad kernel, state is "closed" afterwards, until i close and re-open the lid. I will build a kernel with dynamic debug enabled and grab the output if it is of any help. Until then - my DSDT is uploaded here: http://filebin.ca/1GkDaYm5U1lp/dsdt-samsung-n150 Stefan Am 25.03.2014 14:23, schrieb Kieran Clancy: > On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu wrote: >> 2014-03-24 19:19 GMT+08:00 Stefan Biereigel : >>> 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 : >>>>> 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. >