Bug 856256
| Summary: | Crash when unlocking screensaver | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||
| Component: | xorg-x11-server | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 18 | CC: | alevy, awilliam, pschindl, robatino, xgl-maint | ||||
| Target Milestone: | --- | Keywords: | CommonBugs | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | https://fedoraproject.org/wiki/Common_F18_bugs#qxl-unlock-crash AcceptedBlocker | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-09-26 19:03:19 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 752660 | ||||||
| Attachments: |
|
||||||
|
Description
Kamil Páral
2012-09-11 14:58:55 UTC
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]
/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.
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 (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 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 |