Bug 60526

Summary: laptop: Dell Inspiron 6400: screen power and lid open/close issues
Product: ACPI Reporter: Paul Wise (pabs3)
Component: Power-VideoAssignee: Zhang Rui (rui.zhang)
Status: REOPENED ---    
Severity: normal CC: aaron.lu, lenb, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
URL: http://bugs.debian.org/606713
Kernel Version: Debian 3.10 rc7 Subsystem:
Regression: No Bisected commit-id:
Attachments: debug logs from the issue
debug logs from the issue
debug logs from the issue
debug logs from the issue

Description Paul Wise 2013-07-06 04:53:50 UTC
Created attachment 106816 [details]
debug logs from the issue

Forwarding my Debian bug, slightly more info there:

http://bugs.debian.org/606713

My laptop has broken lid close behaviour, when I close the lid, the screen stays on (Windows XP and Linux). When I open the lid, the screen turns off at a low lid angle and then at a higher angle it turns back on.

With Windows XP it always turns back on at the higher angle. With Linux it only turns on if I open the lid very slowly. I discovered that workaround while gathering the data for this bug. This behaviour happens in Xorg and on virtual consoles, even if I boot in single user mode and X has not started.

When the screen is off in Linux, the system is still available, I can SSH in or blindly hit Ctrl+Alt+F1 to login as root. If I suspend and resume afterwards, the screen turns back on.

I've since switched to a Thinkpad for my main system so this issue does not affect me often but it would be nice to get it fixed for when I need to fall back on my old laptop and for other users of this laptop, which was fairly common a few years ago.
Comment 1 Paul Wise 2013-07-06 04:56:37 UTC
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.
Comment 2 Aaron Lu 2013-07-17 06:40:15 UTC
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.
Comment 3 Paul Wise 2013-07-17 12:21:29 UTC
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.
Comment 4 Aaron Lu 2013-07-18 01:45:37 UTC
I can't extract any table from the acpidump, please generate the dump like this:
# acpidump > acpidump.txt
Comment 5 Paul Wise 2013-07-18 07:00:29 UTC
Ok, I'll do that when I get home in October.
Comment 6 Zhang Rui 2013-10-14 11:10:18 UTC
Hi, Paul,
wish you have a nice travel.
is there any chance that you can provide the information requested in commetn#4?
Comment 7 Paul Wise 2013-10-16 06:45:20 UTC
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.
Comment 8 Aaron Lu 2014-02-18 01:55:33 UTC
Do you still have the problem on latest upstream kernel?
Comment 9 Paul Wise 2014-02-19 09:25:36 UTC
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.
Comment 10 Zhang Rui 2014-06-03 03:47:50 UTC
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.
Comment 11 Zhang Rui 2014-06-03 03:53:35 UTC
FYI, please file your bug at https://bugs.freedesktop.org/.
Comment 12 Paul Wise 2014-06-03 05:20:45 UTC
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.
Comment 13 Aaron Lu 2014-11-10 04:48:26 UTC
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.
Comment 14 Zhang Rui 2014-12-02 06:40:46 UTC
ping...
Comment 15 Paul Wise 2021-06-05 11:41:50 UTC
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.
Comment 16 Paul Wise 2021-06-05 11:43:09 UTC
Created attachment 297173 [details]
debug logs from the issue
Comment 17 Zhang Rui 2021-06-16 06:59:09 UTC
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?
Comment 18 Paul Wise 2021-06-17 09:08:07 UTC
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.
Comment 19 Len Brown 2021-06-24 14:15:37 UTC
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.
Comment 20 Paul Wise 2021-06-24 14:35:46 UTC
The issue doesn't happen with Windows XP running on the same machine, so I do think this is a Linux specific bug.