Bug 60526

PS: I am going travelling soon, the laptop is available for debugging during the next week but I will leave it behind when I go. I will be back in October and add any needed info then.

Please attach acpidump and dmesg.

ACPI LID driver is not responsible for turning on/off the LID, instead, it will receive a notification from firmware once the LID status has changed and then send out this event to user space for proper following operation like triggering suspend on close, etc. The real operation is done in GPU driver like i915 if you are using an Intel graphics card.

So let's figure out if the event is sent out correctly first.

Both acpidump and dmesg are already in the attached tarball. 

I'm no longer physically near the laptop so I won't be able to add any more info until October.

I can't extract any table from the acpidump, please generate the dump like this:
# acpidump > acpidump.txt

Ok, I'll do that when I get home in October.

Hi, Paul,
wish you have a nice travel.
is there any chance that you can provide the information requested in commetn#4?

Created attachment 111251 [details]
debug logs from the issue

Thanks for the ping. Here is a new tarball containing a text version of the acpidump as well as the other files.

Do you still have the problem on latest upstream kernel?

Created attachment 126731 [details]
debug logs from the issue

I still experience this issue with Linux 3.13, which is the latest version available from Debian. The attached tarball contains two instances when the screen turned on after opening due to slow opening and two instances of when it did not turn on after opening due to quick opening.

from the dmesg, it looks like that kernel performs an successful suspend-to-mem cycle every time you close/open the lid, no matter if the screen is actually turned on or not after lid opened.

So, this looks like a graphics problem rather an ACPI/Suspend problem to me.
And freedesktop.org is the proper place to report this issue.
Bug closed.

FYI, please file your bug at https://bugs.freedesktop.org/.

Suspend/resume has nothing to do with the bug, it is just a convenient way to fix the problem after it occurs.

The issue is that the Linux kernel does not turn the screen back on after I open and close the lid in specific circumstances (opening quickly instead of slowly). There are no freedesktop components involved in this bug, nothing was running during this test except the Linux kernel and a shell. Windows XP does not have this problem.

Take a look at the dmesg before you try to reproduce this issue, then reproduce this issue, now the screen should be black, suppose the system is still running fine(except the screen is black), record the dmesg now. Check the dmesg later to verify if the system undergoes a suspend-resume cycle. Let's make this clear before any further investigation.

ping...

Firstly, apologies for leaving this reply for so long.

I am still able to reproduce the issue with Linux 5.10.28-1 from Debian bullseye.

The screen is no longer turned on while the lid is closed.

The workaround of opening the screen slowly no longer works.

The workaround of suspending the system and resuming still works.

Regarding the last comment by Aaron Lu, the system definitely does not undergo a suspend-resume cycle until after the test has completed.

I have updated the script to dump all data to the systemd journal and split the journal into during the test and after the test when the workaround happens.

Please see the attached tarball for the new script and the new data.

Created attachment 297173 [details]
debug logs from the issue

hmm, the laptop is still alive after seven years, :)
can you please tell the model of your laptop and also the dmesg output after boot?

(In reply to Paul Wise from comment #15)
> Firstly, apologies for leaving this reply for so long.
> 
> I am still able to reproduce the issue with Linux 5.10.28-1 from Debian
> bullseye.
> 
> The screen is no longer turned on while the lid is closed.
> 
> The workaround of opening the screen slowly no longer works.
> 
> The workaround of suspending the system and resuming still works.
> 
What about the following scenarios?
1. with lid opened, is the screen on after a normal suspend/resume?
2. with lid opened, run suspend, close the lid, and then open the lid, does the system resume? if yes, is the screen on after the resume?
3. system suspend when lid closed seems like a userspace setting, are you able to figure out if it is some userspace daemon that suspends the system? if yes, can you kill that daemon and retry with lid closed and opened, without system suspend/resume?

BTW, given this is a really old platform, I will consider this as low priority, and will put more effort on further debugging only when I have enough time. what do you think?

The laptop is from 2007 and is indeed barely alive now :)

The bug title contains the laptop model: Dell Inspiron 6400

I think some of the earlier debugging info posted here on the Debian bug contains the full dmesg for a much older Linux kernel.

I will gather the updated full dmesg and other requested details soon.

Regarding 3, if you look at the script, you will see that suspend on lid closure is the default under systemd logind but I disabled that feature for the tests and the only suspends happening in the tests are the ones I manually did with `systemctl suspend`, and the logs from the suspend are separate to and *after* the logs from the lid closure and opening.

Agreed that this is a *very* low priority issue.

Hi Paul,
I used to have a Dell Inspiron 6400.
I recall it was problematic,
but it died before I could debug it further.

I don't think there is a Linux specific bug here.
I think there are problems specific to this platform.

I recommend you download and install the latest BIOS from Dell.
And work with that.

The issue doesn't happen with Windows XP running on the same machine, so I do think this is a Linux specific bug.