Bug 891140 - blank and unresponsive console after X exit
Summary: blank and unresponsive console after X exit
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 18
Hardware: i386
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 893295
TreeView+ depends on / blocked
 
Reported: 2013-01-02 00:57 UTC by Guido
Modified: 2013-01-12 15:33 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
: 893295 (view as bug list)
Environment:
Last Closed: 2013-01-12 15:32:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
test bash script xkillx.sh (214 bytes, text/plain)
2013-01-02 20:47 UTC, Guido
no flags Details
Xorg log (26.32 KB, application/octet-stream)
2013-01-03 19:04 UTC, Guido
no flags Details
X log v 1.12.3 (a functioning X server) (22.64 KB, text/plain)
2013-01-07 21:28 UTC, Guido
no flags Details
X log v 1.13.1 (a defective X server) (23.68 KB, text/plain)
2013-01-07 21:30 UTC, Guido
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 58174 0 None None None Never

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.


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