Bug 856256 - Crash when unlocking screensaver
Crash when unlocking screensaver
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
Depends On:
Blocks: F18Beta/F18BetaBlocker
  Show dependency treegraph
 
Reported: 2012-09-11 10:58 EDT by Kamil Páral
Modified: 2014-09-13 14:57 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-26 15:03:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages (278.44 KB, text/plain)
2012-09-11 15:16 EDT, Brian Lane
no flags Details

  None (edit)
Description Kamil Páral 2012-09-11 10:58:55 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
xorg-x11-drv-qxl-0.0.22-5.20120718gitde6620788.fc18.x86_64
xorg-x11-server-Xorg-1.12.99.904-1.20120808.fc18.x86_64
gdm-3.5.5-2.fc18.x86_64
gnome-shell-3.5.5-2.fc18.x86_64

How reproducible:
always
Comment 1 Kamil Páral 2012-09-11 11:04:44 EDT
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.
Comment 2 Adam Williamson 2012-09-11 13:58:34 EDT
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.
Comment 3 Brian Lane 2012-09-11 15:16:22 EDT
Created attachment 611893 [details]
/var/log/messages

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.
Comment 4 Alon Levy 2012-09-12 08:06:05 EDT
I can't reproduce this with an account that has no password and with one that does. I'm using:

gnome-shell-3.5.91-1.fc18.x86_64
gdm-3.5.91-1.fc18.x86_64
xorg-x11-drv-qxl-0.0.22-5.20120718gitde6620788.fc18.x86_64
xorg-x11-server-Xorg-1.13.0-3.fc18.x86_64

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
Comment 5 Kamil Páral 2012-09-12 08:29:27 EDT
(In reply to comment #4)
Alon, what's your hardware? Bare-metal? VM? Which graphical driver?
Comment 6 Kamil Páral 2012-09-12 09:16:44 EDT
I don't see this problem on a bare-metal machine with nouveau driver.
Comment 7 Adam Williamson 2012-09-12 14:22:15 EDT
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).
Comment 8 Adam Williamson 2012-09-12 14:23:39 EDT
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.
Comment 9 Martin 2012-09-17 08:22:47 EDT
I have similar crash with Nouveau: https://bugzilla.redhat.com/show_bug.cgi?id=857886
Comment 10 Adam Williamson 2012-09-26 14:42:33 EDT
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.
Comment 11 Kamil Páral 2012-09-26 15:03:19 EDT
This no longer happens with
xorg-x11-drv-qxl-0.0.22-5.20120718gitde6620788.fc18.i686
xorg-x11-server-Xorg-1.13.0-5.fc18.i686
gdm-3.5.92.1-1.fc18.i686
gnome-shell-3.5.92-1.fc18.i686

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