Ubuntu
linux package

lid close simply turns off laptop screen

Bug #1865170 reported by Colton Donnelly
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-session (Ubuntu)
Confirmed
Undecided
Unassigned
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

OS: Ubuntu 18.04 LTS (beaver-three-eyed-raven X92.1)
ubuntu-session version: 3.28.1-0ubuntu3
Expected behavior: On laptop screen close, system should suspend
Actual behavior: On laptop screen close, laptop screen disabled

Previously, I triggered 'suspend when laptop lid is closed' in gnome-tweaks. This worked fine until about 2-3 days ago, when I came back to work with a dead laptop (I don't charge overnight, usually, but I do use a dock at work). Now, whenever I close my laptop screen, it doesn't trigger sleep - instead, it simply disables the laptop screen, resulting in my external monitor being used as the only output screen. Once I re-open my laptop, the laptop screen is re-enabled as the primary monitor.

This happens regardless of connection to my dock. I tested this by unplugging my laptop, closing it, letting it sit for 3 minutes, then re-opening it. While the laptop was closed, fans still ran. When I re-opened my laptop, the lock screen didn't appear.

Links to attempted fixes that didn't work:

- https://askubuntu.com/questions/1115572/ubuntu-18-04-dell-xps15-9570-impossible-to-reliably-suspend-hibernate
- https://askubuntu.com/questions/1029474/ubuntu-18-04-dell-xps13-9370-no-longer-suspends-on-lid-close
- https://www.dell.com/community/Laptops-General-Read-Only/Sleep-Issues-and-Wake-Up-Issues-xps-13/td-p/5018369
- https://askubuntu.com/questions/15520/how-can-i-tell-ubuntu-to-do-nothing-when-i-close-my-laptop-lid

Results of attempted fixes:
- mem_sleep: no behavior change (files correctly modified)
- pm-hibernate: first run, hangs until I kill the process. future runs result in exit code 1.
- update bios: already on latest bios
- logind.conf: no behavior change
- gnome tweaks: no behavior change

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubuntu-session 3.28.1-0ubuntu3
ProcVersionSignature: Ubuntu 4.15.0-1073.83-oem 4.15.18
Uname: Linux 4.15.0-1073-oem x86_64
ApportVersion: 2.20.9-0ubuntu7.11
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Feb 28 10:23:52 2020
DistributionChannelDescriptor:
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-bionic-amd64-20180608-47+beaver-three-eyed-raven+X92+beaver-three-eyed-raven+X92.1
InstallationDate: Installed on 2020-01-08 (51 days ago)
InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/usr/bin/zsh
SourcePackage: gnome-session
UpgradeStatus: No upgrade log present (probably fresh install)
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.11
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: colton 4205 F.... pulseaudio
 /dev/snd/controlC0: colton 4205 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
DistributionChannelDescriptor:
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-bionic-amd64-20180608-47+beaver-three-eyed-raven+X92+beaver-three-eyed-raven+X92.1
DistroRelease: Ubuntu 18.04
InstallationDate: Installed on 2020-01-08 (53 days ago)
InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38
MachineType: Dell Inc. XPS 13 7390
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1073-oem root=UUID=ef2a7f80-1cfd-48d6-a2be-0875e4832f2f ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-1073.83-oem 4.15.18
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-1073-oem N/A
 linux-backports-modules-4.15.0-1073-oem N/A
 linux-firmware 1.173.15
Tags: bionic
Uname: Linux 4.15.0-1073-oem x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dialout dip docker libvirt lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/25/2019
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.4.0
dmi.board.name: 0377MH
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.4.0:bd11/25/2019:svnDellInc.:pnXPS137390:pvr:rvnDellInc.:rn0377MH:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 7390
dmi.sys.vendor: Dell Inc.

See original description
Revision history for this message
Colton Donnelly (donnellycolton) wrote :
Colton Donnelly (donnellycolton)
description: updated
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1865170

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Colton Donnelly (donnellycolton) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected
description: updated
Revision history for this message
Colton Donnelly (donnellycolton) wrote : CRDA.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : CurrentDmesg.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Colton Donnelly (donnellycolton) wrote : IwConfig.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : Lspci.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : Lsusb.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : ProcEnviron.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : ProcModules.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : PulseList.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : RfKill.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : UdevDb.txt

apport information

Revision history for this message
Colton Donnelly (donnellycolton) wrote : WifiSyslog.txt

apport information

Revision history for this message
Andrea Righi (arighi) wrote :

Thanks for reporting this.

The CurrentDmesg.txt that you posted doesn't seem to include the part when you close the lid, am I correct?

In that case could you run `dmesg -w` on a console session, close the lid and post what you get in dmesg?

Another interesting test could be to check if the ACPI events are properly handled by the kernel and passed to user-space. For this you can try to run `acpi_listen` (as root) in another console session, close the lid, re-open it, and you should see something like:

 button/lid LID close
 button/lid LID open

Then, I'm not sure if you tried it already, but what happens if you try to suspend manually via `echo mem > /sys/power/state`. Does it actually suspend? Do you get any error in dmesg?

Revision history for this message
Colton Donnelly (donnellycolton) wrote :

Hi Andrea,

Results running in gnome session:
Test 1: (dmesg -w) See attached. No output after closing lid.
Test 2: (acpi_listen) `button/lid LID close`, `button/lid LID open`
Test 3: (echo mem > /sys/power/state) laptop froze for 20s, recovered by pressing power button. Terminal output: `echo write error: device or resource busy`.

Results running in separate TTY session:
Test 1: (dmesg -w) Same as previous results
Test 2: (acpi_listen) Same as previous results
Test 3: (echo mem > /sys/power/state) laptop froze, unable to recover. Had to do a hard reset. Output from before crash: `[time] PM: suspend entry (s2idle)\n[time] PM: Syncing filesystems ... done.`

For what it's worth, I'm now noticing my laptop hangs when I try to power off via the ubuntu power menu. `sudo shutdown now` is also coin toss as to whether the shutdown will succeed or not (although it does succeed, unlike the ubuntu power menu). `sudo reboot` consistently works, as with the power menu option.

Revision history for this message
Andrea Righi (arighi) wrote :

Hi Colton, thanks for testing it! It looks like the kernel correctly receives and delivers the ACPI events, but then it fails to perform the actual suspend to mem.

Can you try one more test?

 echo 1 > /sys/power/pm_debug_messages
 echo 0 > /sys/power/pm_async
 echo mem > /sys/power/state

The first setting simply increases the PM debugging level (...and hopefully we can get more info from dmesg -w).

The second one disables the asynchronous execution of the PM suspend and resume callbacks. If the problem is a race condition in some of those callbacks, this should prevent the race.

Thanks.

Revision history for this message
Colton Donnelly (donnellycolton) wrote :

Here is the relevant output from `dmesg -w`. I just realized I forgot to attach the log output from my last message (and I just overwrote it for this attachment), but after inspection there was no output (I guess that was apparent).

It seems that you're right - the async is the problem. The behavior was as expected with these tests.

Revision history for this message
Colton Donnelly (donnellycolton) wrote :

For clarity: the no output was from the last round of tests. I did receive output for this test (as you can see).

Revision history for this message
Alex Hung (alexhung) wrote :

There are a few s2idle fixes and workaround in mainline kernel, and it may worth a try. If it can fix your problem, fixes can be backported to bionic

latest mainline kernel: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6-rc4/

instructions: https://askubuntu.com/questions/879888/how-do-i-update-kernel-to-the-latest-mainline-version

Revision history for this message
Colton Donnelly (donnellycolton) wrote :

Sorry for the delay, I've been rather busy. I was finally able to try a newer build of the latest mainline tonight, so I just tried it.

I tried using v5.6-rc4 but that failed to install, and it seems like v5.6-rc6 isn't building properly, so I went with v5.6-rc5.

The issue actually seems worse. In the dmesg output attached, you can see that the desync is much more spread out.
~47s close laptop lid
~57s open laptop lid
~60s password entered (GNOME did lock)
~70s laptop goes to sleep
~84s I wake laptop using power button

I'm having a few additional issues with my laptop that weren't quite happening out of the box, so I'm going to go ahead and do a full reinstall of my system -- I suspect I may have gone digging deep into some system configurations in my sleep.

I'll do a full system backup before the reinstall, though, so that I can do further bug hunting, when I'm available?field.comment=Sorry for the delay, I've been rather busy. I was finally able to try a newer build of the latest mainline tonight, so I just tried it.

I tried using v5.6-rc4 but that failed to install, and it seems like v5.6-rc6 isn't building properly, so I went with v5.6-rc5.

The issue actually seems worse. In the dmesg output attached, you can see that the desync is much more spread out.
~47s close laptop lid
~57s open laptop lid
~60s password entered (GNOME did lock)
~70s laptop goes to sleep
~84s I wake laptop using power button

I'm having a few additional issues with my laptop that weren't quite happening out of the box, so I'm going to go ahead and do a full reinstall of my system -- I suspect I may have gone digging deep into some system configurations in my sleep.

I'll do a full system backup before the reinstall, though, so that I can do further bug hunting, when I'm available

Revision history for this message
Colton Donnelly (donnellycolton) wrote :

Update: after doing a full system reinstall, the bug persists (even made sure that the bios settings are the factory defaults). It's interesting that the bug only cropped up over the last month or so...

Revision history for this message
Colton Donnelly (donnellycolton) wrote :

Ok I just got a grub update and I decided to see if dmesg would have any new information for me, and found it did!
See: gnome-shell segfault, Mutex release error, ACPI parsing issue

Not sure if these are related to this bug, but since they happen around the time I close the laptop lid, it might help.

Revision history for this message
Alex Hung (alexhung) wrote :

It looks like BIOS issue. An acpidump log will help (sudo acpidump > acpi.log)

Revision history for this message
Colton Donnelly (donnellycolton) wrote :

It seems that one of the updates that just happened via apt might have fixed the issue? attached is dmesg log... does it look like expected behavior? My fans are properly turning off, and when I open my laptop lid, I'm not getting the delayed sleep mode. BIOS update

I'm not sure exactly which package solved it. I've attached the most recent list of packages upgraded by apt, as well. I'm curious if it's the rfkill update that solved it?

Revision history for this message
Colton Donnelly (donnellycolton) wrote :
Revision history for this message
Colton Donnelly (donnellycolton) wrote :
Revision history for this message
Colton Donnelly (donnellycolton) wrote :

Nevermind, I just saw the rfkill changelog. Since I'm no longer able to reproduce the bug, should it be closed?

Revision history for this message
Alex Hung (alexhung) wrote :

Thanks for opening a bug and testing. Let's mark it fix released. Please re-open if you have found it fails again.

Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Changed in gnome-session (Ubuntu):
status: New → Fix Released
Revision history for this message
Colton Donnelly (donnellycolton) wrote :

The bug is back, and all packages are up to date.

Revision history for this message
Colton Donnelly (donnellycolton) wrote :
Colton Donnelly (donnellycolton)
Changed in gnome-session (Ubuntu):
status: Fix Released → Confirmed
Changed in linux (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Colton Donnelly (donnellycolton) wrote :

I'm also experiencing this bug in Focal

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.