Bug 482997 - GDM freezes on user switching with 2.6.28.1
Summary: GDM freezes on user switching with 2.6.28.1
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-29 08:54 UTC by cblaauw
Modified: 2009-05-31 06:58 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-05-23 10:38:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description cblaauw 2009-01-29 08:54:23 UTC
Description of problem:
If a user switch is tried gdm doesn't show up completely and system is no longer usable. VT switching does not work, ctrl-alt-backspace does not work.

Mouse does still move.

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

kernel 2.6.28.1-17.fc10.x86_64

How reproducible:

every time

Steps to Reproduce:
1. in gnome menu click on logout
2. click sitch user
3.
  
Actual results:
Gdm crashes

Expected results:

another user can be chosen in gdm
Additional info:

Graphics adapter in Intel GMA-3100

Logout a user and logging in another user does work as expected

Comment 1 cblaauw 2009-01-30 15:28:18 UTC
Error occurs also with 2.6.27.12 and 2.6.29 RC3

Comment 2 cblaauw 2009-02-02 18:12:58 UTC
Using the vesa driver solves the problem

Comment 3 cblaauw 2009-02-02 18:41:35 UTC
Trace if hung:

Feb  2 19:30:44 m7 kernel: gdm-binary    S ffff88012cd8aa40     0  2033      1
Feb  2 19:30:44 m7 kernel: ffff880126c33a78 0000000000000082 ffff8800a6942000 ffff88012cdf2e18
Feb  2 19:30:44 m7 kernel: 0000000000000001 ffffffff816fd300 ffffffff816fd300 ffff880126c9c4d0
Feb  2 19:30:44 m7 kernel: ffff88012cdf2de0 ffff880126c9c850 000000002cdf2e18 ffff88002802f300
Feb  2 19:30:44 m7 kernel: Call Trace:
Feb  2 19:30:44 m7 kernel: [<ffffffff81038818>] ? enqueue_task+0x50/0x5b
Feb  2 19:30:44 m7 kernel: [<ffffffff8103808d>] ? resched_task+0x2e/0x74
Feb  2 19:30:44 m7 kernel: [<ffffffff8136c557>] ? _spin_unlock_irqrestore+0x27/0x3e
Feb  2 19:30:44 m7 kernel: [<ffffffff8136b253>] schedule_hrtimeout_range+0x3f/0xfa
Feb  2 19:30:44 m7 kernel: [<ffffffff8102ac4f>] ? default_spin_lock_flags+0x9/0xe
Feb  2 19:30:44 m7 kernel: [<ffffffff8105d843>] ? add_wait_queue+0x3c/0x45
Feb  2 19:30:44 m7 kernel: [<ffffffff810e16d6>] ? __pollwait+0xc1/0xca
Feb  2 19:30:44 m7 kernel: [<ffffffff810e056d>] poll_schedule_timeout+0x36/0x56
Feb  2 19:30:44 m7 kernel: [<ffffffff810e0934>] do_sys_poll+0x31e/0x3cc
Feb  2 19:30:44 m7 kernel: [<ffffffff810e1615>] ? __pollwait+0x0/0xca
Feb  2 19:30:44 m7 kernel: [<ffffffff810e16df>] ? pollwake+0x0/0x51
Feb  2 19:30:44 m7 kernel: [<ffffffff810e16df>] ? pollwake+0x0/0x51
Feb  2 19:30:44 m7 kernel: [<ffffffff812c5258>] ? __sock_sendmsg+0x59/0x62
Feb  2 19:30:44 m7 kernel: [<ffffffff812c5349>] ? sock_aio_write+0xe8/0xf8
Feb  2 19:30:44 m7 kernel: [<ffffffff812c53c6>] ? __sock_recvmsg+0x6d/0x7a
Feb  2 19:30:44 m7 kernel: [<ffffffff812c5261>] ? sock_aio_write+0x0/0xf8
Feb  2 19:30:44 m7 kernel: [<ffffffff810d35ab>] ? do_sync_readv_writev+0xe3/0x12b
Feb  2 19:30:44 m7 kernel: [<ffffffff812c54c3>] ? sock_aio_read+0xf0/0x100
Feb  2 19:30:44 m7 kernel: [<ffffffff8105d640>] ? autoremove_wake_function+0x0/0x38
Feb  2 19:30:44 m7 kernel: [<ffffffff8136c35d>] ? _spin_lock+0x9/0xc
Feb  2 19:30:44 m7 kernel: [<ffffffff810d339e>] ? fsnotify_modify+0x62/0x6a
Feb  2 19:30:44 m7 kernel: [<ffffffff810d3d47>] ? do_readv_writev+0x10c/0x121
Feb  2 19:30:44 m7 kernel: [<ffffffff81158e50>] ? selinux_file_permission+0xbd/0xc6
Feb  2 19:30:44 m7 kernel: [<ffffffff81151aa0>] ? security_file_permission+0x11/0x13
Feb  2 19:30:44 m7 kernel: [<ffffffff810e0b77>] sys_poll+0x50/0xba
Feb  2 19:30:44 m7 kernel: [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b

Comment 4 Brian J. Green 2009-02-07 05:13:54 UTC
I started experiencing this same problem after my most recent yum update.
When using 2.6.27.12-170.2.5.fc10.x86_64, the system will completely hang when using the switch user feature.  My workaround has been to use my previous kernel (2.6.27.9-159.fc10.x86_64).

Comment 5 cblaauw 2009-02-11 11:48:11 UTC
Hi Brian,

do you also use an Intel graphics adapter?

This bug is there since around 2.6.27.10 and still persists into 2.6.28 and 2.6.29.

I cant' use 2.6.27.9-159 because that does not resume my network at all times after resume, this bug is there since 2.6.27.8 RT8169 adapter.

So for me 2.6.27.7-134 is the one to use.

Comment 6 Brian J. Green 2009-02-12 04:09:19 UTC
Yes I do.  The relevant lines from /sbin/lspci are:

00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)

Comment 7 cblaauw 2009-02-12 09:33:53 UTC
Mine is G33, hope that they fix it soon. I know not to change users right now, but rather log off first (that works). But my wife dosen't know about this

Comment 8 Tim Wegener 2009-02-16 13:33:00 UTC
Me too...

$ /sbin/lspci |grep Graph
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

xorg-x11-drv-i810-2.5.0-4.fc10.i386
mesa-libGL-7.2-0.15.fc10.i386
xorg-x11-server-Xorg-1.5.3-6.fc10.i386
gdm-user-switch-applet-2.24.0-12.fc10.i386
kernel-2.6.27.12-170.2.5.fc10.i686

Managed to ssh in from another machine, but not always. Here is the interesting part of 'ps auxww':

root      3773  0.0  0.0   7260  1884 ?        S    17:16   0:00 /usr/libexec/gd
m-simple-slave --display-id /org/gnome/DisplayManager/Display2
root      3776  0.1  0.1  12516  5176 tty7     Ss+  17:16   0:00 /usr/bin/Xorg :
1 -br -verbose -auth /var/run/gdm/auth-for-gdm-6hY7je/database -nolisten tcp
root      3802 99.9  0.0   4780   488 tty7     R+   17:16  13:19 sh -c "/usr/bin
/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compil
er (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the 
X server" "/var/lib/xkb/server-1.xkm"

The following bug looks similar:
https://bugzilla.redhat.com/show_bug.cgi?id=450197

Comment 9 Brian J. Green 2009-03-01 18:16:19 UTC
I did a little more investigation on this this morning.  For me, this definitely seems like a problem with the graphics driver.  After the freeze up, i am consistently able to ssh into the frozen machine.  I observe that XOrg is consuming the 100% of one cpu.

I did a 'tail -f /var/log/messages' and a 'tail -f /var/log/XOrg.0.log' from a remote machine while performing the switch user operation and observed the following output:

XOrg.0.log
-----------
exaCopyDirty: Pending damage region empty!
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0

messages
--------
Mar  1 10:06:53 gf0 acpid: client connected from 3538[0:0]
Mar  1 10:06:54 gf0 kernel: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining

Comment 10 Christopher Beland 2009-03-10 20:14:21 UTC
Just a note that there are now several similar reports with different hardware: Bug 482997, Bug 484516, Bug 450197, and Bug 439294.

Comment 11 Thiago 2009-04-09 14:58:22 UTC
And bug 481679 too. I have a T400 with Intel graphics, and get a similar error.

First I click on switch users applet. The screen turns black and then a gdm screen appears with all the buttons disabled and no users on the list. Mouse still works, can't change to terminal (ALT+Fx), can't reboot (CTRL+ALT+DEL), only hard-reset works.

I think the applet should be removed from default panel configuration until this problem is solved. Bug 439294 is more than 1 year old now.

Comment 12 cblaauw 2009-05-23 10:38:54 UTC
Problem is solved with Fedora 11


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