Bug 814912 - Macbook Pro doesn't suspend on lid shut
Summary: Macbook Pro doesn't suspend on lid shut
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: lid suspend
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-21 10:01 UTC by gareth foster
Modified: 2013-03-14 18:13 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-14 18:13:48 UTC
Type: Bug


Attachments (Terms of Use)

Description gareth foster 2012-04-21 10:01:56 UTC
Description of problem:
When I shut the lid on Fedora 17, it doesn't suspend.

Version-Release number of selected component (if applicable):
Latest

How reproducible:
Every time

Steps to Reproduce:
1. Shut lid
2. Open lid
3.
  
Actual results:
Laptop is still awake

Expected results:
Laptop is asleep

Additional info:

Comment 1 buzilla 2012-05-30 19:49:36 UTC
I'm seeing this on a fresh install of fedora 17 on a dell latitude D531.

Suspend works from the user menu and the laptop promptly locks the desktop when the lid closes but won't suspend even though the settings in gsettings or gnome-tweak-tool appear correct.


If I manually suspend, opening the lid wakes it. 
If I watch acpid output it definitely sees the lid open and close. 

I'm not sure what more to try.

Comment 2 Leon Keijser 2012-05-31 11:10:08 UTC
Getting this as well on a Dell Precision M4500

Comment 3 bericson 2012-05-31 16:03:09 UTC
I am also seeing this on a Lenovo W510.

I have confirmed that the ACPI recognizes that the lid is closed (via /proc/acpi/button/lid/LID/state), have confirmed that KDE suspends with the lid closed, and have verified that a new user account also does not suspend when closing the lid in Gnome.

I ran gnome-settings-daemon in debug mode, and it appears the problem is that Gnome is convinced I've got an active external monitor:

(gnome-settings-daemon:4293): power-plugin-DEBUG: lid is closed; not suspending nor hibernating since some external monitor outputs are still active

This is untrue -- I have only my laptop screen.  Googling suggests the issue is related to how the nVIDIA driver reports the laptop screen (as a "default" screen) and how Gnome interprets it (despite there being only one screen and despite getting a lid closed event, Gnome 3.4 figures the monitor is an external one).  Other distributions have had the same issue.  In particular, https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/949296 may be of some assistance.

Comment 4 Josh Boyer 2012-07-10 17:20:36 UTC
Is everyone in this bug using the nVidia module?  We have 4 different machine types here now, so this bug is getting rather useless as there is very little info except for comment #3.  Suspend/resume issues can be highly machine/driver dependent.

Comment 5 Leon Keijser 2012-07-18 07:27:11 UTC
Yes I'm using the nvidia module provided by the rpmfusion repository. This is the output of lspci:

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express x16 Root Port (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 05)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05)
00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 05)
00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 05)
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 05)
01:00.0 VGA compatible controller: nVidia Corporation GT216 [Quadro FX 880M] (rev a2)
01:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev a1)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
04:00.0 CardBus bridge: Ricoh Co Ltd Device e476 (rev 02)
04:00.1 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 03)
04:00.4 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 03)
3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02)
3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02)
3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
3f:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
3f:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)

Comment 6 bericson 2012-08-05 03:32:22 UTC
This appears to have "fixed itself" with kernel 3.5.0/nVidia module 304.32.


Note You need to log in before you can comment on or make changes to this bug.