Bug 891140

Summary: blank and unresponsive console after X exit
Product: [Fedora] Fedora Reporter: Guido <rds1944>
Component: xorg-x11-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 18CC: airlied, johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, systemd-maint, vpavlin, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 893295 (view as bug list) Environment:
Last Closed: 2013-01-12 15:32:59 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: 893295    
Attachments:
Description Flags
test bash script xkillx.sh
none
Xorg log
none
X log v 1.12.3 (a functioning X server)
none
X log v 1.13.1 (a defective X server) none

Description Guido 2013-01-02 00:57:52 UTC 
In Fedora 18 beta, any logout (quit, exit, etc) from any WM (kwin, fvwm, fluxbox, etc) that booted initially into the multi-user target, does NOT restore the drivers for the keyboard, mouse, or screen. (A boot to the graphical target does not exhibit this behavior.)

However, the system IS running without errors, as can be seen from the logs in /var dir after reboot OR by writing a simple bash script that launches X, waits, kills X, & then restarts X without a "hitch".

This has never occurred in prior versions (17, 16, ...).

Is this an xserver (v1.13) bug or a systemd function that was not properly executed?
Comment 1 Bill Nottingham 2013-01-02 18:31:12 UTC 
What do you mean by 'restore the drivers for the keyboard, mouse or screen'? 

Are you on a blank tty1 (does <alt>-F1, <alt>-F2, etc. find other ttys)?
Comment 2 Guido 2013-01-02 18:51:37 UTC 
(In reply to comment #1)
> What do you mean by 'restore the drivers for the keyboard, mouse or screen'?

If I run a simple background bash script (... &) that appends some text to /var/log/messages every few seconds, I can see after a manual reboot that the system IS running at all times. 
 
> Are you on a blank tty1 (does <alt>-F1, <alt>-F2, etc. find other ttys)?

After a Xorg logout, tty1,... is blank except for a frozen cursor in the upper left corner. <Alt F1,...> do NOT find other ttys. I cannot find a single responsive key except for the power button.

Hence I conclude that the drivers for console screen (VT), keyboard, & mouse are not reloaded when X quits.

An hour ago I loaded up a gnome desktop environment, that exhibited the same behavior as all previous WM tests. On gnome-session launch, there was a pop window that stated "Xorg killed by signal 6 (SIGABRT)". Aside from this notification, gnome seemed fine until I logged out.

F17 uses xserver v1.12 without issues; F18b uses v1.13.1. Of course, the kernel is different, too.
Comment 3 Guido 2013-01-02 20:46:40 UTC 
Try this bash script, xkillx.sh, shown below.

From a console tty, run it.

It launches a X GUI (any WM will do, kde, gnome ,fvwm) that functions properly for 30 sec. It then kills xinit (X) to leave a dead keyboard, mouse, & blank screen. After another 15 sec, it starts X again (xinit) & everything is behaving correctly. Look at var/log/messages & you will see no errors (except from the deliberate kill.)
Comment 4 Guido 2013-01-02 20:47:37 UTC 
Created attachment 671690 [details]
test bash script xkillx.sh
Comment 5 Lennart Poettering 2013-01-03 18:47:01 UTC 
systemd is not involved in this. This is between X and the kernel. Reassigning.

Guide, which graphics driver are you using?
Comment 6 Guido 2013-01-03 19:02:31 UTC 
(In reply to comment #5)
> systemd is not involved in this. This is between X and the kernel.
> Reassigning.
> 
> Guido, which graphics driver are you using?

Intel i965.

evdev is loaded to catch key & mouse events.

Below I attach the latest Xorg log.
Comment 7 Guido 2013-01-03 19:04:57 UTC 
Created attachment 672155 [details]
Xorg log

When evdev, etc unloads, it seems that the console drivers do not reload.
Comment 8 Guido 2013-01-07 16:33:29 UTC 
I started X with startx, instead of xinit, & got some useful debug info on the failures after quitting X. Echoed to the screen was the following:

    dispatch.c : 3944

    DetachOutputGPU

    Assertion `slave->isGPU' failed

Then there is a frozen screen, dead keyboard & mouse.

I did a web search & found this error recently, December 2012, reported on both Xorg & FreeDesktop bug sites for xserver v1.3.99.

This is an important bug that needs to be fixed by Xorg before Fedora 18 is finally released. It affects X with any WM that does not use a GDM.
Comment 9 Michal Schmidt 2013-01-07 17:07:07 UTC 
(In reply to comment #8)
> I did a web search & found this error recently, December 2012, reported on
> both Xorg & FreeDesktop bug sites for xserver v1.3.99.

Could you provide the relevant URLs?
Comment 10 Guido 2013-01-07 17:32:16 UTC 
See

<https://bugs.freedesktop.org/show_bug.cgi?id=58174>

Someone needs to get the Xorg Xserver maintainer to address this bug ASAP.
Comment 11 Guido 2013-01-07 21:27:09 UTC 
Last line of Xorg log for v1.12.3
    Server terminated successfully (0). Closing log file.

Last line of Xorg log for v1.13.1
    X: dispatch.c:3944: DetachOutputGPU: Assertion `slave->isGPU' failed.

Attached below are full session X logs of 1.12.3 & 1.13.1.
Comment 12 Guido 2013-01-07 21:28:59 UTC 
Created attachment 674354 [details]
X log v 1.12.3 (a functioning X server)
Comment 13 Guido 2013-01-07 21:30:13 UTC 
Created attachment 674355 [details]
X log v 1.13.1 (a defective X server)
Comment 14 Dave Airlie 2013-01-09 03:58:40 UTC 
can you run a server under valgrind and get the trace?

it looks like a use after free or some other memory corruption alright
Comment 15 Fedora Update System 2013-01-09 03:59:35 UTC 
xorg-x11-server-1.13.1-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.13.1-4.fc18
Comment 16 Dave Airlie 2013-01-09 04:45:53 UTC 
okay I think I tracked it down, try getting that update and hopefully it should be fixed.
Comment 17 Guido 2013-01-09 21:05:29 UTC 
Dave

Could you attach the i386 relevant x server pkg(s) for your fix, 1.13.1-4, to this RH Bugzilla thread?

I can only find the previous build, 1.13.1-3, which does NOT work.

Thanks.

Guido
Comment 18 Fedora Update System 2013-01-09 22:50:37 UTC 
Package xorg-x11-server-1.13.1-4.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.13.1-4.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-0509/xorg-x11-server-1.13.1-4.fc18
then log in and leave karma (feedback).
Comment 19 Guido 2013-01-10 01:15:31 UTC 
Anxiously awaiting build #4!

'Karma' to both sites, this one & that admin URL will be posted.

Thanks for the effort.

Will the fix be in the formal/official F18 release next week?
Comment 20 Dave Airlie 2013-01-10 01:23:29 UTC 
no that tree is frozen weeks ago.

It'll be in the updates soon after release.

the build should be in updates-testing now I think.
Comment 21 Guido 2013-01-10 17:34:02 UTC 
(In reply to comment #20)
> no that tree is frozen weeks ago.
> 
> It'll be in the updates soon after release.
> 
> the build should be in updates-testing now I think.

It WORKS! Thank you.
Comment 22 Fedora Update System 2013-01-12 15:33:02 UTC 
xorg-x11-server-1.13.1-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.