Hide Forgot
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?
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)?
(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.
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.)
Created attachment 671690 [details] test bash script xkillx.sh
systemd is not involved in this. This is between X and the kernel. Reassigning. Guide, which graphics driver are you using?
(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.
Created attachment 672155 [details] Xorg log When evdev, etc unloads, it seems that the console drivers do not reload.
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.
(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?
See <https://bugs.freedesktop.org/show_bug.cgi?id=58174> Someone needs to get the Xorg Xserver maintainer to address this bug ASAP.
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.
Created attachment 674354 [details] X log v 1.12.3 (a functioning X server)
Created attachment 674355 [details] X log v 1.13.1 (a defective X server)
can you run a server under valgrind and get the trace? it looks like a use after free or some other memory corruption alright
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
okay I think I tracked it down, try getting that update and hopefully it should be fixed.
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
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).
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?
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.
(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.
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.