Bug 505371 - Monitor suspends immediately on gdm startup when laptop 'lid' is closed
Summary: Monitor suspends immediately on gdm startup when laptop 'lid' is closed
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: jmccann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-11 16:36 UTC by Tom London
Modified: 2015-01-14 23:23 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-07-08 22:15:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg.0.log booting with laptop lid open (149.60 KB, text/plain)
2009-06-11 16:36 UTC, Tom London
no flags Details

Description Tom London 2009-06-11 16:36:43 UTC
Created attachment 347436 [details]
Xorg.0.log booting with laptop lid open

Description of problem:
I was having difficulty getting Rawhide gdm to start with my system docked and the laptop lid closed (with external display connected).

System is Thinkpad X200 (Intel graphics).

When booting into runlevel 5, the display would almost immediately blacken and the monitor would suspend. I could not recover except to hard reboot.

I "worked around" this by booting into runlevel 3, logging in, running "startx", and constantly keeping the mouse in motion until the desktop was displayed.  Then all was fine.

After some head scratching, I tried booting with the laptop lid open, and the system booted just fine.

I'm at a loss as to what info to provide.  Please let me know.....

I attach /var/log/Xorg.0.log booting with lid open.  Not sure what else is useful.

This only started occurring when I updated FC11 system to FC12-Rawhide.

Sorry if this is the wrong component.  Please redirect!

Version-Release number of selected component (if applicable):
gdm-user-switch-applet-2.26.1-8.fc12.x86_64
gdm-2.26.1-8.fc12.x86_64
xorg-x11-server-Xorg-1.6.1.901-5.fc11.x86_64
xorg-x11-server-utils-7.4-7.fc11.x86_64
xorg-x11-drv-intel-2.7.0-7.fc11.x86_64
xorg-x11-server-common-1.6.1.901-5.fc11.x86_64


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Tom London 2009-06-12 15:47:06 UTC
What seems to be happening here is that the laptop LCD is active, not the external monitor, even though plymouth is quite happy using the external monitor.

I can login through the laptop LCD afterwhich gdm happily "switches" to the external monitor....

Comment 2 Tom London 2009-06-13 18:49:53 UTC
Notice errors like this:

Jun  8 06:33:24 tlondon kernel: [drm:gm45_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1

Just about when "gdm-simple-greeter" starts.

Here is a bit more context:

Jun  7 13:04:23 tlondon kernel: [drm:gm45_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1
Jun  7 13:04:23 tlondon nscd: 22657 Access Vector Cache (AVC) started
Jun  7 13:04:23 tlondon NetworkManager: <info>  Policy set 'System eth0' (eth0) as default for routing and DNS.
Jun  7 13:04:23 tlondon dnsmasq[1913]: reading /etc/resolv.conf
Jun  7 13:04:23 tlondon dnsmasq[1913]: using nameserver 68.87.69.146#53
Jun  7 13:04:23 tlondon dnsmasq[1913]: using nameserver 68.87.78.130#53
Jun  7 13:04:23 tlondon dnsmasq[1913]: using nameserver 68.87.76.178#53
Jun  7 13:04:25 tlondon ntpd[1759]: Deleting interface #9 wlan0, 192.168.1.103#123, interface stats: received=0, sent=0, dropped=0, active_time=10140 secs
Jun  7 13:04:31 tlondon gdm-simple-greeter[22776]: WARNING: Unable to parse history: (null)   4#012


Related?

Comment 3 Tom London 2009-06-16 17:11:03 UTC
Some more (possibly useful?) data:

I have two different external monitors, an not too old HP LCD and an quite old Mitsubishi LCD.

Entries from Xorg.0.log for both monitors:

(II) intel(0): Manufacturer: HWP  Model: 265e  Serial#: 16843009
(II) intel(0): Year: 2006  Week: 20
(II) intel(0): EDID Version: 1.3

and
(II) intel(0): EDID for output VGA1
(II) intel(0): Manufacturer: MEL  Model: 4341  Serial#: 525
(II) intel(0): Year: 1999  Week: 31
(II) intel(0): EDID Version: 1.1


I connected the Thinkpad X200 (via dock) to each monitor, opened the laptop lid, and booted (with KMS).

The behavior is not quite the same.  Below shows which screen(s) are active at each of the booting stages:

        HP                      Mitsubishi

BIOS    External only           External only
Grub    External only           External only
Plymouth Both ext & laptop      Both ext & laptop
gdm     Both                    laptop LCD only
gnome   Both                    External only

So the "problem" is that booting with the Mitsubishi, gdm "deactivates" the external "pipe".

[With the laptop lid closed, both configurations suspend the display and the system.  I hard reset to recover.]

Comment 4 Tom London 2009-06-30 13:41:09 UTC
This issue continues with:

xorg-x11-server-common-1.6.99-7.20090618.fc12.x86_64
xorg-x11-server-utils-7.4-7.fc11.x86_64
xorg-x11-server-Xorg-1.6.99-7.20090618.fc12.x86_64
gdm-user-switch-applet-2.26.1-10.fc12.x86_64
gdm-2.26.1-10.fc12.x86_64
xorg-x11-drv-intel-2.8.0-0.1.fc12.x86_64


I have to boot with laptop lid open, even though plymouth has no problem detecting my external monitor.

In fact, the system immediately suspends, not just the monitor....

Comment 5 Tom London 2009-07-07 13:30:57 UTC
This issues seems to have gone away with latest rawhide/koji packages:

xorg-x11-server-common-1.6.99-9.20090706.fc12.x86_64
gdm-plugin-fingerprint-2.26.1-13.fc12.x86_64
xorg-x11-server-utils-7.4-9.fc12.x86_64
kernel-2.6.31-0.39.rc1.git9.fc12.x86_64
xorg-x11-server-Xorg-1.6.99-9.20090706.fc12.x86_64
xorg-x11-drv-intel-2.8.0-0.1.fc12.x86_64
kernel-2.6.31-0.38.rc1.git7.fc12.x86_64
gdm-user-switch-applet-2.26.1-13.fc12.x86_64
gdm-2.26.1-13.fc12.x86_64
kernel-2.6.31-0.42.rc2.fc12.x86_64
GConf2-2.26.2-3.fc12.x86_64
gnome-settings-daemon-2.27.3-2.fc12.x86_64

Boots up fine now (into 1280x1024) with the laptop lid shut. Gdm first boots up in reduced resolution (800x600?) for password entry, and then transitions to 1280x1024.

I'll monitor, and close this if it is stable for a few days....

Comment 6 Tom London 2009-07-08 22:15:32 UTC
Looks like this is gone....

Not sure what caused it, or what fixed it, but ....

Closing.


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