[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <533330D6.3070808@biereigel.de>
Date: Wed, 26 Mar 2014 20:56:06 +0100
From: Stefan Biereigel <stefan@...reigel.de>
To: Kieran Clancy <clancy.kieran@...il.com>
CC: Juan Manuel Cabo <juanmanuel.cabo@...il.com>,
Stefan Biereigel <security@...reigel-wb.de>,
Lan Tianyu <lantianyu1986@...il.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r kernel org" <linux-kernel@...r.kernel.org>,
Len Brown <lenb@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
San Zamoyski <san@...snet.pl>,
"D. Jansen" <dennis.jansen@....de>,
Maurizio D'Addona <mauritiusdadd@...il.com>
Subject: Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after
suspend to RAM.
Hi,
I tested both of your patches. The processing of events works well on my
N150, the lid is reported open correctly after resume.
For the second patch (the whitelisting-approach), I had to change the
Product Name to "N150/N210/N220" instead of "N150P", because that is
what dmidecode reports for my netbook.
So, all three approaches work equally well for me (whitelisting my
broken N150, blacklisting the broken Series 5/7/9, processing all the
stale events). I personally would prefer a solution which needs to
handle (best case) no custom cases, because there are always n+1 of
them. But, as I don't know if there may be any problems with the
approach that needs no special handling (processing all stale events) in
the future, I'm not the one to decide the correct solution.
What would you do? Do any of these patches create issues for you?
Greetings
Stefan
Am 26.03.2014 15:38, schrieb Kieran Clancy:
> On Wed, Mar 26, 2014 at 9:12 PM, Stefan Biereigel <stefan@...reigel.de> wrote:
>>
>> I don't know if it is a valid idea, but maybe it would be ok to process
>> events after resume in general, and only throw away events on those
>> platforms that continue to log events while in standby (Samsung 5/7/9)?
>
> We can give it a shot!
>
> It may even be that on Samsung 5/7/9 there is no harm in processing
> the events instead of discarding them.
>
> Here's a patch that we can try for that:
>
> http://kieranclancy.com/tmp/2014/03/ec_clear_process.patch
>
> I'm going to have to clear up some hard drive space before I can
> compile a kernel with it (curse this tiny SSD), but if anyone else
> wants to give it a shot please feel free.
>
> One thing I am still trying to think about is that Stefan's system
> must be about to check and process this EC event anyway, but we
> discard it first. I wonder if there is some difference in state (e.g.
> EC status bits) here that we might detect.
>
> Failing all that, it might be easier to just whitelist this product
> rather than try to find every series 5/7/9/?/... Samsung product name.
> Something like this:
>
> http://kieranclancy.com/tmp/2014/03/ec_clear_exclude_N150P.patch (not
> intended for use with other patch, they are mutually exclusive
> approaches)
>
>> But after all, it would be better to find the command to tell the EC to
>> stop recording events and issue that before going to sleep. Is there any
>> way to find that command (for example on Windows)? Maybe that one is so
>> generic that we can issue it to all ECs, regardless of if it would
>> continue to log events during sleep.
>
> It would be great to know what Windows does here, but even then we
> still need to be able to clear a jammed EC. You can still find posts
> around the internet where Windows users who've never touched Linux
> have these same kind of problems with their Samsung laptops. My guess
> is it only takes one blue screen of death or something where the EC
> isn't shut down properly, the EC fills up and then it's more or less a
> permanent state until the EC is cleared manually.
>
> Thanks again for your testing, Stefan.
>
> Kieran.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists