linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Biereigel <stefan@biereigel.de>
To: Kieran Clancy <clancy.kieran@gmail.com>
Cc: Juan Manuel Cabo <juanmanuel.cabo@gmail.com>,
	Stefan Biereigel <security@biereigel-wb.de>,
	Lan Tianyu <lantianyu1986@gmail.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger kernel org" <linux-kernel@vger.kernel.org>,
	Len Brown <lenb@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	San Zamoyski <san@plusnet.pl>, "D. Jansen" <dennis.jansen@web.de>,
	"Maurizio D'Addona" <mauritiusdadd@gmail.com>
Subject: Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM.
Date: Wed, 26 Mar 2014 20:56:06 +0100	[thread overview]
Message-ID: <533330D6.3070808@biereigel.de> (raw)
In-Reply-To: <CAGf84QJU+RKXV4AyQ7QBTKjpdPm3AYLtWTFio+-r3j8wyoEokA@mail.gmail.com>

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@biereigel.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.
> 

  parent reply	other threads:[~2014-03-26 19:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24  7:50 [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM Stefan Biereigel
2014-03-24  9:30 ` Lan Tianyu
2014-03-24 11:19   ` Stefan Biereigel
2014-03-25  9:34     ` Lan Tianyu
2014-03-25  9:43       ` Stefan Biereigel
2014-03-25 13:23       ` Kieran Clancy
2014-03-25 13:53         ` Juan Manuel Cabo
2014-03-25 16:07           ` Stefan Biereigel
2014-03-25 16:38         ` Stefan Biereigel
2014-03-25 20:24         ` Stefan Biereigel
2014-03-25 20:41           ` Juan Manuel Cabo
2014-03-25 22:56             ` Juan Manuel Cabo
2014-03-26 10:42               ` Stefan Biereigel
2014-03-26 14:38                 ` Kieran Clancy
2014-03-26 15:01                   ` Rafael J. Wysocki
2014-03-26 19:56                   ` Stefan Biereigel [this message]
2014-03-26 22:36                     ` Kieran Clancy
2014-03-26 22:41                       ` Stefan Biereigel
     [not found]                   ` <CAM6oVw2v9ptr0c08uPiB_3z3e41VO+Vp3OhoHXiBxagAOfPBZA@mail.gmail.com>
2014-04-01  9:53                     ` Kieran Clancy
2014-04-01 11:36                       ` Nicolas Porcel
2014-04-01 11:58                         ` Kieran Clancy
2014-04-01 12:18                           ` Nicolas Porcel
2014-04-01 18:02                             ` Nicolas Porcel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533330D6.3070808@biereigel.de \
    --to=stefan@biereigel.de \
    --cc=clancy.kieran@gmail.com \
    --cc=dennis.jansen@web.de \
    --cc=juanmanuel.cabo@gmail.com \
    --cc=lantianyu1986@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mauritiusdadd@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=san@plusnet.pl \
    --cc=security@biereigel-wb.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).