Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #204012 > unrolled thread

kernel regression from stable to testing (acpi lid / EEEpc 1215p)

Back to article view | Back to linux.debian.user

Contents

  kernel regression from stable to testing (acpi lid / EEEpc 1215p) Andrea Borgia <andrea@borgia.bo.it> - 2019-01-04 20:20 +0100
    Re: kernel regression from stable to testing (acpi lid / EEEpc 1215p) Andrea Borgia <andrea@borgia.bo.it> - 2019-01-06 19:30 +0100
    Re: kernel regression from stable to testing (acpi lid / EEEpc  1215p) Michael Lange <klappnase@freenet.de> - 2019-01-07 20:20 +0100
      Re: kernel regression from stable to testing (acpi lid / EEEpc 1215p) Andrea Borgia <andrea@borgia.bo.it> - 2019-01-08 17:50 +0100
        Re: kernel regression from stable to testing (acpi lid / EEEpc  1215p) Michael Lange <klappnase@freenet.de> - 2019-01-09 00:20 +0100
          Re: kernel regression from stable to testing (acpi lid / EEEpc 1215p) Andrea Borgia <andrea@borgia.bo.it> - 2019-01-12 12:20 +0100
            Re: kernel regression from stable to testing (acpi lid / EEEpc 1215p) Andrea Borgia <andrea@borgia.bo.it> - 2019-01-13 22:30 +0100

#204012 — kernel regression from stable to testing (acpi lid / EEEpc 1215p)

Hi.


On my EEEpc 1215p laptop, the upgrade from stable to testing broke the 
lid switch detection, since
* another OS detects it just fine and acts on it;
* the kernel from stable (4.9.0-7) does too
Therefore, HW is ok (not obvious on an old laptop...)


If I use the current kernel in testing (4.19.0-1), or really any 
"testing" kernel from december onwards (when I upgraded), this is the 
situation:
* the sleep keycombo Fn+F1 works
* pm-suspend works
* pm-hibernate works
If I observe the state of /proc/acpi/button/lid/LID/state from a remote 
shell and close the lid, it shows "open". Indeed, the fact that I can 
still use the system is a dead giveaway it's not suspended :P

/etc/default/acpi-support is fine: LID_SLEEP=true is active, both acpid 
and the system itself were restarted multiple times.

Closest bug I could find witha similar issue is not relevant, since it's 
way older than my working kernel: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820422


dmesg has this interesting warning:
ACPI: button: The lid device is not compliant to SW_LID.

Digging around, the common reply was along the lines of "meh, just a 
warning, ignore it if it works". Well, guess what, it doesn't :(


What's the best way to handle this? IMHO it's quite likely a kernel 
issue, most likely upstream.
Should I file a bug on linux-image-amd64 or directly on bugzilla.kernel.org?


Thanks,
Andrea.

[toc] | [next] | [standalone]

#204135

Il 04/01/19 20:11, Andrea Borgia ha scritto:


> What's the best way to handle this? IMHO it's quite likely a kernel 
> issue, most likely upstream.
> Should I file a bug on linux-image-amd64 or directly on 
> bugzilla.kernel.org?

No comments?


Meanwhile, I've been testing the kernels archived on snapshot.debian.org:
4.9.0-7: OK (last known working, see previous msg)
4.10.0-trunk: fails
4.11.0-2: fails
4.14.0-1: fails
4.19.0-1: fails (first failure detected, see previous msg)
(those versions which are failing all have the "SW_LID" warning)


In Documentation/acpi/acpi-lid.txt, I saw the newer kernels have added a 
button.lid_init_state and I have tried the possible values on 4.19.0-1:
method: fails
open: fails
ignore: fails


To recap, so far the last known working kernel for the lid switch was 
the one currently in "stable", that is 4.9.0-7, and I'm out of ideas :/


Andrea.

[toc] | [prev] | [next] | [standalone]

#204191 — Re: kernel regression from stable to testing (acpi lid / EEEpc 1215p)

Hi,

On Fri, 4 Jan 2019 20:11:53 +0100
Andrea Borgia <andrea@borgia.bo.it> wrote:

(...)
> 
> dmesg has this interesting warning:
> ACPI: button: The lid device is not compliant to SW_LID.

oddly, here with my Lenovo Ideapad 100s the lid switch stopped working,
too. However, this is totally different hardware and I do not get the above
error message, but instead dmesg says after booting:

   ACPI Error: Method parse/execution failed \_SB.LID0._LID, AE_NOT_EXIST (20180810/psparse-516)

And when I close and re-open the lid dmesg|tail says:

 ACPI Error: No handler for Region [ECRE] (00000000cad769b9) [GenericSerialBus] (20180810/evregion-132)
 ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180810/exfldio-265)
 ACPI Error: Result stack is empty! State=000000005069dd47 (20180810/dswstate-65)
 ACPI Error: Method parse/execution failed \_SB.LID0._LID, AE_NOT_EXIST (20180810/psparse-516)
 ACPI Error: No handler for Region [ECRE] (00000000cad769b9) [GenericSerialBus] (20180810/evregion-132)
 ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180810/exfldio-265)
 ACPI Error: Result stack is empty! State=00000000fdc80083 (20180810/dswstate-65)
 ACPI Error: Method parse/execution failed \_SB.LID0._LID, AE_NOT_EXIST (20180810/psparse-516)

Since the error message looks different from yours I guess that this is
probably a completely different issue, though. 


> What's the best way to handle this? IMHO it's quite likely a kernel 
> issue, most likely upstream.
> Should I file a bug on linux-image-amd64 or directly on
> bugzilla.kernel.org?

I believe reporting to debian is the best so long as you use a debian kernel.
If you want to report to kernel.org probably they'll expect that you
compile and try their kernel first.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Schshschshchsch.
		-- The Gorn, "Arena", stardate 3046.2

[toc] | [prev] | [next] | [standalone]

#204211

Il 07/01/19 20:09, Michael Lange ha scritto:


> Since the error message looks different from yours I guess that this is
> probably a completely different issue, though.

Most likely you're right, however there was quite a big rewrite of ACPI 
in 4.10 and I wouldn't rule it out completely.


> I believe reporting to debian is the best so long as you use a debian kernel.
> If you want to report to kernel.org probably they'll expect that you
> compile and try their kernel first.

That wouldn't be a problem: the thing is so old that it probably makes 
no difference. Anyhow, since my laptop is running the stock debian 
kernel I'll go along with your suggestion, once I'm done with another 
round of tests.

I've discovered a few bugreport that contain useful information:
https://bugzilla.kernel.org/show_bug.cgi?id=192231
https://bugzilla.kernel.org/show_bug.cgi?id=195455
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863257


See if you can find something useful to debug your issue and please let 
me know if you discover anything interesting.


Regards,
Andrea.

[toc] | [prev] | [next] | [standalone]

#204223 — Re: kernel regression from stable to testing (acpi lid / EEEpc 1215p)

Hi,

On Tue, 8 Jan 2019 17:44:04 +0100
Andrea Borgia <andrea@borgia.bo.it> wrote:

> Il 07/01/19 20:09, Michael Lange ha scritto:
> 
> 
> > Since the error message looks different from yours I guess that this
> > is probably a completely different issue, though.
> 
> Most likely you're right, however there was quite a big rewrite of ACPI 
> in 4.10 and I wouldn't rule it out completely.

I forgot to mention that the lid did not stop working here between 4.9 and
4.10. Actually here it works with a Siduction 4.16 kernel, but does not
with the Liquorix 4.19. Just for the fun of it I tried the Debian 4.19
kernel from Sid and the lid happens to work again. Maybe this is due to
some (possibly faulty) driver modules missing from the Debian kernel, but
that's of course just guesswork. 
I think for now I will just stick with 4.16 and see if in the course of
time the missing modules will be picked up by debian.

> > I believe reporting to debian is the best so long as you use a debian
> > kernel. If you want to report to kernel.org probably they'll expect
> > that you compile and try their kernel first.
> 
> That wouldn't be a problem: the thing is so old that it probably makes 
> no difference.

Just because it is old does not necessarily mean that no one bothers.
After I upgraded to Stretch I filed a bug report because my 20 year old
sound card suddenly had stopped working and after a couple of weeks they
had this fixed so now the card works as good as new. As far as Win 10 is
concerned that card is as dead as a doorknob :-)

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

It would seem that evil retreats when forcibly confronted.
	-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5

[toc] | [prev] | [next] | [standalone]

#204346

Il 09/01/19 00:07, Michael Lange ha scritto:



> Just because it is old does not necessarily mean that no one bothers.

Sorry, that's not what I meant: I wanted to say the kernel is so old 
that it probably doesn't really matter if it is the debian or the 
upstream version I am using. That is, whatever patches Debian might have 
added back then have gone mainline for the most part.


Andrea.

[toc] | [prev] | [next] | [standalone]

#204389

quick note, the bug report has been filed: 919227

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web