Samsung N150 lid does not "open" after suspend to RAM.

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.

Best regards,
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Please try the following patch.

drivers/acpi/ec.c +7 -2

index d7d32c2..9239527 100644
@@ -1027,8 +1027,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
        DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
        DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
        {
-       ec_clear_on_resume, "Samsung hardware", {
-       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
+       ec_clear_on_resume, "Samsung NP530U3B", {
+       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+       DMI_MATCH(DMI_PRODUCT_NAME, "530U3BI/530U4BI/530U4BH"),}, NULL},
+       {
+       ec_clear_on_resume, "Samsung NP530U3C", {
+       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+       DMI_MATCH(DMI_PRODUCT_NAME, "530U3C/530U4C/532U3C"),}, NULL},
        {},
 };
 

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 36 lines

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.

Best regards,
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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 Lan Tianyu:

Quoted 65 lines

Please try the following patch.

drivers/acpi/ec.c +7 -2

index d7d32c2..9239527 100644
@@ -1027,8 +1027,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
        DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
        DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
        {
-       ec_clear_on_resume, "Samsung hardware", {
-       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
+       ec_clear_on_resume, "Samsung NP530U3B", {
+       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+       DMI_MATCH(DMI_PRODUCT_NAME, "530U3BI/530U4BI/530U4BH"),}, NULL},
+       {
+       ec_clear_on_resume, "Samsung NP530U3C", {
+       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+       DMI_MATCH(DMI_PRODUCT_NAME, "530U3C/530U4C/532U3C"),}, NULL},
        {},
 };
 

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 36 lines

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.

Best regards,
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 6 lines

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.

Quoted 70 lines

Regards,
Stefan

Am 24.03.2014 10:30, schrieb Lan Tianyu:

Quoted 65 lines

Please try the following patch.

drivers/acpi/ec.c +7 -2

index d7d32c2..9239527 100644
@@ -1027,8 +1027,13 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
        DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
        DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
        {
-       ec_clear_on_resume, "Samsung hardware", {
-       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
+       ec_clear_on_resume, "Samsung NP530U3B", {
+       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+       DMI_MATCH(DMI_PRODUCT_NAME, "530U3BI/530U4BI/530U4BH"),}, NULL},
+       {
+       ec_clear_on_resume, "Samsung NP530U3C", {
+       DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+       DMI_MATCH(DMI_PRODUCT_NAME, "530U3C/530U4C/532U3C"),}, NULL},
        {},
 };
 

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 36 lines

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.

Best regards,
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 5 lines

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?

Quoted 1 line

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.

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 11 lines · Lan Tianyu

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 6 lines

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).

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

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 Samsung Series 5 NP530U3C in which the patch works fine:

Manufacturer: SAMSUNG ELECTRONICS CO., LTD. Product Name: 530U3C/530U4C

"sudo acpi_listen" shows the following on resume:

      video GFX0 00000080 00000000
      button/lid LID0 00000080 00000001
      button/lid LID0 00000080 00000002

"cat /proc/acpi/button/lid/LID0/state" shows its open always on resume. I suspended several times, and on each time it was open.

I bet that that system's _WAK method doesn't recheck the lid, I might be wrong. *Stefan*: Can you extract that method and send it? Something like this:

sudo cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.bin
cd /tmp/dsdt.bin
iasl -d dsdt.bin
# AND EDIT the resulting dsdt.dsl and search for and send us the _WAK method

Also, on my system, the DSDT Q event for lid state change reads it from the EC to the LIDS var, instead of just toggling the "LIDS" variable (Lid Status). My own dsdt is downloadable from my blog, at http://zenstep.com.ar/files/DSDT_SamsungSeries5-NP530U3c-AB1_WithBios_P14AAJ.dsl

Cheers!
--
Juan Manuel Cabo

Quoted 90 lines · Kieran Clancy

Quoted 11 lines · Lan Tianyu

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 6 lines

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).

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 6 lines

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 5 lines

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?

Quoted 6 lines

Quoted 1 line

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).

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 6 lines

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 5 lines

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?

Quoted 6 lines

Quoted 1 line

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).

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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).

http://pastebin.ca/2679209

You can find the "EC: 1 stale EC events cleared" Line @ Line 316. I really did not expect that much traffic from the EC, interesting to get some insight into that!

Regarding other actions: The system notices removal of the AC cord when in sleep (xfce4-power-manager reports the correct symbol after the wakeup), so I guess this is working as it should (as it is handled by the _WAK-Routine??).

Hope that helps!
Stefan

Am 25.03.2014 14:23, schrieb Kieran Clancy:

Quoted 95 lines · Lan Tianyu

Quoted 11 lines

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 6 lines

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).

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 = 0x09
      [  728.868061] ACPI : EC: ---> data = 0x00
      [  728.868066] ACPI : EC: 1 stale EC events cleared
      [  728.868079] ACPI: Waking up from system sleep state S3

the 0x5F event means it's a LID change event (both in your dsdt and mine, look for: Q5F)

But there is still something I'm not sure of. So I will test that RC8 kernel tonight on my laptop and let you all know. If RC8 still works on my laptop, then I guess the best would be to make the EC fix specific to series 5, 7, 9 laptops, so your N150 is not affected anymore. Thank you so much Stefan for your in-depth tests!

Cheers!
--
Juan Manuel Cabo

Quoted 116 lines · Stefan Biereigel

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).

http://pastebin.ca/2679209

You can find the "EC: 1 stale EC events cleared" Line @ Line 316. I really did not expect that much traffic from the EC, interesting to get some insight into that!

Regarding other actions: The system notices removal of the AC cord when in sleep (xfce4-power-manager reports the correct symbol after the wakeup), so I guess this is working as it should (as it is handled by the _WAK-Routine??).

Hope that helps!
Stefan

Am 25.03.2014 14:23, schrieb Kieran Clancy:

Quoted 95 lines · Lan Tianyu

Quoted 11 lines

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 6 lines

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).

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 NP530U3C).
If it did recheck the LID state and issue, then it wouldn't have mattered whether
an accumulated LID event was discarded.

So I see two possible fixes:
1) Modify the EC fix so that it doesn't discard events and instead processes them.
or
2) Restrict the models to which the EC fix applies, as in Lan Tianyu patch, but it needs to be broather.

Lan Tianyu patch contains just these DMI_PRODUCT_NAME matches:

            530U3BI/530U4BI/530U4BH
            530U3C/530U4C/532U3C

These two should at least be added:
530U3C/530U4C (reported by my laptop)
535U3C (reported by D. G. Jansen laptop)

and also, at least all the ones needed for:

    Samsung Series 5 (models NP530U3C, NP535U3C, NP530U3B, NP550P5C)
    Samsung Series 9 (models NP900X3F, NP900X4B, NP900X4C, NP900X4D, NP900X3C)

I hope this helped,

Cheers!
--
Juan Manuel Cabo

Quoted 141 lines · Juan Manuel Cabo

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 = 0x09
      [  728.868061] ACPI : EC: ---> data = 0x00
      [  728.868066] ACPI : EC: 1 stale EC events cleared
      [  728.868079] ACPI: Waking up from system sleep state S3

the 0x5F event means it's a LID change event (both in your dsdt and mine, look for: Q5F)

But there is still something I'm not sure of. So I will test that RC8 kernel tonight on my laptop and let you all know. If RC8 still works on my laptop, then I guess the best would be to make the EC fix specific to series 5, 7, 9 laptops, so your N150 is not affected anymore. Thank you so much Stefan for your in-depth tests!

Cheers!
--
Juan Manuel Cabo

Quoted 116 lines · Stefan Biereigel

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).

http://pastebin.ca/2679209

You can find the "EC: 1 stale EC events cleared" Line @ Line 316. I really did not expect that much traffic from the EC, interesting to get some insight into that!

Regarding other actions: The system notices removal of the AC cord when in sleep (xfce4-power-manager reports the correct symbol after the wakeup), so I guess this is working as it should (as it is handled by the _WAK-Routine??).

Hope that helps!
Stefan

Am 25.03.2014 14:23, schrieb Kieran Clancy:

Quoted 95 lines · Lan Tianyu

Quoted 11 lines

2014-03-24 19:19 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 6 lines

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).

Quoted 24 lines

Quoted 24 lines

Quoted 24 lines

2014-03-24 15:50 GMT+08:00 Stefan Biereigel <[email protected]>:

Quoted 23 lines

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)

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

Quoted 4 lines · Stefan Biereigel

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

Quoted 4 lines

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)

Quoted 5 lines

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.

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.

Quoted 5 lines

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.

That was quick - thanks for testing!

For the product name match then, it matches substrings not whole strings, so "N150" should be sufficient (my mistake putting P on the end).

Quoted 8 lines

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.

I won't be able to test ec_clear_process patch until tomorrow because I have a full day today.

On my machine, _QXX events are all something like:

if (AC_PLUGGED_IN) {
     do_something();
}

So if (for example) AC_PLUGGED_IN has changed since the event was produced (e.g. no longer plugged in), nothing bad should happen. That's not necessarily a guarantee that this wouldn't introduce new bugs on other machines though.

I think the ideal fix would be to distinguish between events which are "jammed" and won't be processed (like on Series 5/7/9), and events which will be processed normally with GPEs (N150). I am not sure how to do this or if it's even possible.

For example, on my machine, the EC status byte (EC_SC) seems to be 0x29 for jammed events, which means the SCI_EVT bit is set but we never got/get the interrupt. On your N150, your status byte was 0x09 which means the SCI_EVT was not set - it was not yet asking for the OS to attend to this.

I wonder if something as simple as this would work (in acpi_ec_clear):

                 if (!(acpi_ec_read_status(ec) & ACPI_EC_FLAG_SCI))
                         break;
                 status = acpi_ec_query_unlocked(ec, &value);
                 if (status || !value)
                         break;

This would make it only clear events while the SCI_EVT bit is set. I am not sure that it would entirely remove the race condition you are seeing, but it might be enough to fix it.

If we cant come up with a generally applicable solution, whitelisting is the lesser of two evils when compared with blacklisting here. A jammed EC won't function _at all_, while losing one or two EC events on boot/resume doesn't prevent future events and is easier to work around (though still not ideal).

This patch (processing events) works for me on Samsung 535.

Quoted 1 line · D. G. Jansen

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 testing on the kernel bugzilla entry for the bug fixed by the earlier patch in question:

https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173

The CC list has 62 users, so hopefully we will get some more testers. The comment I posted is repeated below:

--------------

Created attachment 131151 [details]
process rather than discard events in acpi_ec_clear

Hi all,

If you have a machine that was (previously) affected by this bug, could you please take the time to try a new patch for this issue?

A user with an older Samsung machine found that the earlier patch introduced some issues for them, so this is a new patch designed to be a better solution to the problem.

Currently the new patch has only been tested on 2 affected machines (to my knowledge), so I would be very grateful if anyone else can test this patch (especially users with Samsung series 5 or 7 machines).

You will need to use a recent kernel source like 3. (one which includes the earlier acpi_ec_clear patch), or otherwise apply the previous patch first:

https://github.com/torvalds/linux/commit/ad332c8a45330d170bb38b95209de449b31cd1b4.patch

Then apply the attachment ec_process_stale_events.patch

Please test to see if your lid closing / suspending / etc. still work as intended with this patch.

This new patch also provides some debug information after every resume/boot which will show up in dmesg something like:

[ 1192.208056] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.217844] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.218844] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.222835] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.223834] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.224833] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.227833] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.228834] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.229832] ACPI : EC: acpi_ec_clear: EC_SC 0x28
[ 1192.230828] ACPI : EC: 8 stale EC events cleared

Please report if you get any EC_SC bytes here _other than_ 0x28. I only get 0x28 on my machine but I am very interested to know if other affected machines produce something else.

If you test it, please also report your system's product code, e.g.:

# dmidecode -s system-product-name
900X3F
# dmidecode -s baseboard-product-name
NP900X3F-K01AU

Many thanks,
Kieran
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Do you have any idea of how much time will it take to merge it to the mainline ?

Quoted 2 lines · Nicolas Porcel

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 breaking things on other systems.

Fortunately, the work-around in the case of this regression is very simple (just repeat whatever event was ignored the first time, be it lid open, ac plug, etc) compared to the bug which the original patch fixed (which had no real workaround and caused near-permanent malfunction).

This is why I am asking people with Samsung systems to test the patch (with the debug output I added in the kernel bugzilla attachment) and confirm that it is working. I am also asking them to report EC_SC data because we may be able to create a more targeted patch with this information.

Speaking of which, can you please let me know the EC_SC bytes you see when you test it on your system, and if it is always the same?

Once I hear back from users on a range of Samsung systems, I will submit a patch. It should have enough time to land before 3.15. I will also ask for it to be included in other stable branches.

Kind regards,
Kieran

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 patch without the pr_info line, so I need to recompile the kernel. I'll let you know as soon as it's done.

Best regards,

Nicolas Porcel

Quoted 29 lines · Kieran Clancy

Quoted 2 lines · Nicolas Porcel

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 breaking things on other systems.

Fortunately, the work-around in the case of this regression is very simple (just repeat whatever event was ignored the first time, be it lid open, ac plug, etc) compared to the bug which the original patch fixed (which had no real workaround and caused near-permanent malfunction).

This is why I am asking people with Samsung systems to test the patch (with the debug output I added in the kernel bugzilla attachment) and confirm that it is working. I am also asking them to report EC_SC data because we may be able to create a more targeted patch with this information.

Speaking of which, can you please let me know the EC_SC bytes you see when you test it on your system, and if it is always the same?

Once I hear back from users on a range of Samsung systems, I will submit a patch. It should have enough time to land before 3.15. I will also ask for it to be included in other stable branches.

Kind regards,
Kieran