Red Hat Bugzilla – Bug 856256
Crash when unlocking screensaver
Last modified: 2014-09-13 14:57:05 EDT
Description of problem:
Lock the screen, then hit Esc, provide password, hit Enter. You are logged back in for one second, then screen flickers and you end up back in GDM (Xserver is probably restarted).
I found this in Xorg.0.log.old:
[ 121.278] (EE) Backtrace:
[ 121.278] (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x46c266]
[ 121.279] (EE) 1: /usr/bin/Xorg (0x400000+0x71a19) [0x471a19]
[ 121.279] (EE) 2: /lib64/libpthread.so.0 (0x3c03800000+0xf000) [0x3c0380f000]
[ 121.279] (EE) 3: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7fe6a8237000+0xa755) [0x7fe6a8241755]
[ 121.279] (EE) 4: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7fe6a8237000+0x895e) [0x7fe6a823f95e]
[ 121.280] (EE) 5: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7fe6a8237000+0x6965) [0x7fe6a823d965]
[ 121.280] (EE) 6: /usr/bin/Xorg (0x400000+0x34ddf) [0x434ddf]
[ 121.280] (EE) 7: /usr/bin/Xorg (0x400000+0x395aa) [0x4395aa]
[ 121.280] (EE) 8: /usr/bin/Xorg (0x400000+0x2805a) [0x42805a]
[ 121.280] (EE) 9: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3c03021a05]
[ 121.281] (EE) 10: /usr/bin/Xorg (0x400000+0x2839d) [0x42839d]
[ 121.281] (EE)
[ 121.281] (EE) Segmentation fault at address 0x7f398f5a2398
This indicates it could be a problem in qxl driver. But I tried cirrus driver as well and it behaves very similarly, there are just more redrawing issues (gnome-shell and gdm seem to be drawn simultaneously as you move your cursor).
So there are either two different issues or it influences both qxl and cirrus.
Version-Release number of selected component (if applicable):
F18 Alpha RC2
I can't provide any more logs right now but this is extremely easy to reproduce. Just try it in a VM.
Proposing for blocker-bug discussion.
Reproduced with qxl. ajax says the trace looks specific to qxl; if cirrus has a bug with similar symptoms it's still probably not the same bug.
on the cirrus situation: RC2 appears to be using the 'vesa' driver. it's supposed to use the 'modesetting' driver, but there appears to be a problem with the 'cirrus' KMS module which is stopping this working. The behaviour when locking/unlocking with cirrus/vesa seems very unpredictable - one time I saw it crash back to gdm just like this bug, one time it worked perfectly, and one time it appeared to hang X entirely.
Created attachment 611893 [details]
I've seen this on the RC2 Desktop Live installed onto BTRFS.
After dragging the screensaver up and entering password to unlock it got stuck with a cursor on all the consoles but no desktop. Xorg log shows no errors, and Xorg was still running. Sending it a HUP resulted in a X cursor on a black screen.
I can't reproduce this with an account that has no password and with one that does. I'm using:
I'm running in a kvm vm,
1. I boot as multiuser non X,
2. login as root,
3. systemctl start gdm.service,
4. login as a user,
5. User menu (top right)->Lock
6. press Escape
7. Enter password, press <enter>
8. repeat 5-7 a few times
No crash, only wierd thing in dmesg is some atkbd serio0 unknown key pressed.
[ 9727.471398] atkbd serio0: Use 'setkeycodes 00 <keycode>' to make it known.
[ 9728.191237] atkbd serio0: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
Nothing in .xsession-errors, nothing in Xorg.0.log
(In reply to comment #4)
Alon, what's your hardware? Bare-metal? VM? Which graphical driver?
I don't see this problem on a bare-metal machine with nouveau driver.
Discussed at 2012-09-12 blocker review meeting. Agreed this mainly seems to affect VMs (though there's one potential report on metal) and there's an obvious workaround (disable screen locking), and it doesn't directly hit any criteria. So it's rejected as a blocker, accepted as NTH (as obviously crashes are bad).
Alon, I think the rest of us were just booting straight to gdm, which I guess *could* affect this somehow. Also, you're using far too new GNOME; Alpha is using much older packages because of the freeze. please try from a clean Alpha RC2 install without updating.
I have similar crash with Nouveau: https://bugzilla.redhat.com/show_bug.cgi?id=857886
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . Accepted as a blocker, per criterion "after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention." in the case of a qxl-using VM (we consider a desktop that crashes when you unlock it not to be a 'working graphical environment').
We believe this is very likely fixed in current stable f18, neither kparal nor myself can reproduce it on updated VMs. We'll do a bit more testing and then probably close this.
This no longer happens with