I managed to recompile the kernel. Here is what I see in the logs:
kernel: ACPI : EC: acpi_ec_clear: EC_SC 0x20
kernel: ACPI : EC: acpi_ec_clear: EC_SC 0x08
kernel: ACPI : EC: 1 stale EC events cleared
I hope this will help
Regards,
Nicolas Porcel
Le 01/04/2014 20:18, Nicolas Porcel a écrit :
Sure, I understand that you need to test it, that's why I am asking. I
don't want an untested patch to be included in the kernel either. We
also have to make sure that the patch fix the regression for all the
affected Samsung laptops.
For the EC_SC code, I am using the first version of the
On Tue, Apr 1, 2014 at 10:06 PM, Nicolas Porcel
wrote:
> Do you have any idea of how much time will it take to merge it to the
> mainline ?
Apologies for the breakage. The key here is that we want a patch which
works 100% on all Samsung systems. If we rush a fix for this
regression, we may risk
Hello,
Thank you for the patch. Since the update from 3.13.6 to 3.13.7, I have
the same problem with the lid opening that is not detected on my Samsung
N210. This patch fixes the problem.
I think this problem may affect more Samsung netbooks with similar
hardware (N220, and maybe others).
On Sat, Mar 29, 2014 at 1:51 AM, D. G. Jansen wrote:
>
> This patch (processing events) works for me on Samsung 535.
Hi Dennis and others,
Thank you for testing. I have also been testing this patch for a
couple of days, and have not encountered any problems.
I have now submitted a request for
On Sat, Mar 29, 2014 at 1:51 AM, D. G. Jansen d.g.jan...@gmail.com wrote:
This patch (processing events) works for me on Samsung 535.
Hi Dennis and others,
Thank you for testing. I have also been testing this patch for a
couple of days, and have not encountered any problems.
I have now
Hello,
Thank you for the patch. Since the update from 3.13.6 to 3.13.7, I have
the same problem with the lid opening that is not detected on my Samsung
N210. This patch fixes the problem.
I think this problem may affect more Samsung netbooks with similar
hardware (N220, and maybe others).
On Tue, Apr 1, 2014 at 10:06 PM, Nicolas Porcel
nicolasporce...@gmail.com wrote:
Do you have any idea of how much time will it take to merge it to the
mainline ?
Apologies for the breakage. The key here is that we want a patch which
works 100% on all Samsung systems. If we rush a fix for this
Sure, I understand that you need to test it, that's why I am asking. I
don't want an untested patch to be included in the kernel either. We
also have to make sure that the patch fix the regression for all the
affected Samsung laptops.
For the EC_SC code, I am using the first version of the
I managed to recompile the kernel. Here is what I see in the logs:
kernel: ACPI : EC: acpi_ec_clear: EC_SC 0x20
kernel: ACPI : EC: acpi_ec_clear: EC_SC 0x08
kernel: ACPI : EC: 1 stale EC events cleared
I hope this will help
Regards,
Nicolas Porcel
Le 01/04/2014 20:18, Nicolas Porcel a écrit :
Am 26.03.2014 23:36, schrieb Kieran Clancy:
On Thu, Mar 27, 2014 at 6:26 AM, Stefan Biereigel wrote:
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
On Thu, Mar 27, 2014 at 6:26 AM, Stefan Biereigel wrote:
> 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"
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
On Thursday, March 27, 2014 01:08:58 AM Kieran Clancy wrote:
> On Wed, Mar 26, 2014 at 9:12 PM, Stefan Biereigel 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
On Wed, Mar 26, 2014 at 9:12 PM, Stefan Biereigel 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
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)?
But after all, it would be better to find the command to tell the EC to
stop
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)?
But after all, it would be better to find the command to tell the EC to
stop
On Wed, Mar 26, 2014 at 9:12 PM, Stefan Biereigel ste...@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
On Thursday, March 27, 2014 01:08:58 AM Kieran Clancy wrote:
On Wed, Mar 26, 2014 at 9:12 PM, Stefan Biereigel ste...@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
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
On Thu, Mar 27, 2014 at 6:26 AM, Stefan Biereigel ste...@biereigel.de wrote:
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
Am 26.03.2014 23:36, schrieb Kieran Clancy:
On Thu, Mar 27, 2014 at 6:26 AM, Stefan Biereigel ste...@biereigel.de wrote:
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
Just tested with 3.13.7 which contains the EC fix, and I get the same
discarded event as your pastbin shows, but instead my LID status is
correctly reported as "open" always.
So now I'm sure it boils down to your _WAK method not rechecking the LID state
(mine
does, I have a Samsung Series 5
I can see a LID event being discarded here on resume:
[ 728.861983] ACPI : EC: <--- command = 0x84
[ 728.864062] ACPI : EC: ---> status = 0x09
[ 728.864070] ACPI : EC: ---> data = 0x5f
[ 728.864075] ACPI : EC: <--- command = 0x84
[ 728.868054] ACPI : EC: --->
Alright - as I have some spare time tonight, here is the dmesg of one
sleep/resume cycle on an unpatched 3.14-rc8 tree with my usual config +
dynamic debug enabled. After resuming, lid state was still "closed", so
the bug was triggered (and the stale event is removed as stated).
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.
Hello,
I can see the same acpi_listen events with a working kernel (patch
applied or kernels before rc5), but the lid open is not there with rc6
and rc7 (unpatched).
You can find my _WAK below. It seems not to do anything with LIDS, so I
guess this is the cause for the problem.
Method (_WAK, 1,
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
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
Sorry, I sadly do not have any of these machines. If I get my hands on
one, I will post dmidecode.
Thanks for your help,
Stefan
Am 25.03.2014 10:34, schrieb Lan Tianyu:
> 2014-03-24 19:19 GMT+08:00 Stefan Biereigel :
>> Hi,
>> thank you for the suggestion. The patch resolves the issue on my
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
2014-03-24 19:19 GMT+08:00 Stefan Biereigel secur...@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
Sorry, I sadly do not have any of these machines. If I get my hands on
one, I will post dmidecode.
Thanks for your help,
Stefan
Am 25.03.2014 10:34, schrieb Lan Tianyu:
2014-03-24 19:19 GMT+08:00 Stefan Biereigel secur...@biereigel-wb.de:
Hi,
thank you for the suggestion. The patch resolves
On Tue, Mar 25, 2014 at 8:04 PM, Lan Tianyu lantianyu1...@gmail.com wrote:
2014-03-24 19:19 GMT+08:00 Stefan Biereigel secur...@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
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
Hello,
I can see the same acpi_listen events with a working kernel (patch
applied or kernels before rc5), but the lid open is not there with rc6
and rc7 (unpatched).
You can find my _WAK below. It seems not to do anything with LIDS, so I
guess this is the cause for the problem.
Method (_WAK, 1,
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.
Alright - as I have some spare time tonight, here is the dmesg of one
sleep/resume cycle on an unpatched 3.14-rc8 tree with my usual config +
dynamic debug enabled. After resuming, lid state was still closed, so
the bug was triggered (and the stale event is removed as stated).
I can see a LID event being discarded here on resume:
[ 728.861983] ACPI : EC: --- command = 0x84
[ 728.864062] ACPI : EC: --- status = 0x09
[ 728.864070] ACPI : EC: --- data = 0x5f
[ 728.864075] ACPI : EC: --- command = 0x84
[ 728.868054] ACPI : EC: --- status
Just tested with 3.13.7 which contains the EC fix, and I get the same
discarded event as your pastbin shows, but instead my LID status is
correctly reported as open always.
So now I'm sure it boils down to your _WAK method not rechecking the LID state
(mine
does, I have a Samsung Series 5
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?
Regards,
Stefan
Am 24.03.2014 10:30, schrieb
Please try the following patch.
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d7d32c2..9239527 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1027,8 +1027,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer
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
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
Please try the following patch.
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d7d32c2..9239527 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1027,8 +1027,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTek Computer
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?
Regards,
Stefan
Am 24.03.2014 10:30, schrieb
46 matches
Mail list logo
