Bug 448846
| Summary: | F9 KDE fails to start with BackingStore=true | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vince Schiavoni <hlingler> | ||||||
| Component: | kdebase-workspace | Assignee: | Than Ngo <than> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 9 | CC: | antonio.bulgheroni, fedora, kevin, knutjbj, ltinkl, rdieter, than | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-08-02 04:40:25 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Vince Schiavoni
2008-05-29 01:00:40 UTC
Created attachment 307004 [details]
Console output from manual attempt to startx/startkde
1. Does problem exist for all users on this box, or just 1 in particular? Please try: 2. $yum groupinstall kde-desktop does problem still occur? if so, 3. $yum install yum-utils $package-cleanup --problems please report output. Hello: 1. All users: already tried as root user, same results; tried just now with new user, same results; also tried (re)moving ~/.kde, .dbus, and .config, same results. Also tried with boot parameter 'selinux=off' (was: permissive), no help. 2. OK, with fedora, updates, and updates-testing repos enabled (had to enable updates-testing due to dependency requirements caused by prior updates/ installs), ran 'yum groupinstall "KDE (K Desktop Environment)": 35 packages in transaction - 4 updated, 31 installed (excerpt from yum.log attached). Then: startx, results same for all users including root. Tried 'mv ~/.kde ~/.kde- bku', startx, results: hard system lock-up, no recovery possible, required hard re-set. Re-booted, tried to graphical log in again, results: same (KDE crash near end of desktop start-up sequence). Next, tried from console login: 'yum groupremove "KDE (K Desktop Environment)"; 49 packages were removed; a whole huge pile of updates and add-ons had to be removed also before I could try again: 'yum groupinstall "KDE (K Desktop Environment)" BUT with only a custom-made temporary repo enabled using mirrors.kernel.org as the "base" install (probably should have just re- installed the whole OS, but then how would we find the problem?); results: same (KDE crash). Added another new user, same results. Checked again for --dupes and --problems - none. At this point, I took an inventory of all non-Fedora/Red Hat packages installed, and began to remove them, starting with ones that seemed likely to cause the problems. Gave up, installed E17 from kriehn repo, will continue to try to diagnose later from working graphical interface. Other suggestions welcome. 3. Already tried (repeatedly), also: 'package-cleanup --dupes' - no problems, no dupes, never, not once. Also repeatedly ran 'updatedb' just in case.... Thanx and Regards, VJS Hello: Update: just to make it clear, E17 DE installed from 3rd-party repo is up and running just fine, so I have to believe that one of the (many) recent updates/ installs caused this problem. Also: when KDE was up and running, ~/.xsession- errors was at one point at 1.6 GB size. !? That's 1.6 GB !!! That's a text file - I didn't attempt to review it.... Currently: ~/.xsession-errors=329 kB after uptime=8.5 hours (E17). Thanx and Regards, VJS Hello: At this point, I've got the non-Fedora/Livna/FreshRPMS/ATRPMs/KDE-RedHat/kriehn packages trimmed to: aim checkinstall cpuid jre libdrm (custom built from source code) libdrm-devel (ditto) opera Q7Z usermin webmin xorg-x11-drv-nouveau (custom built from source code) xorg-x11-drv-nv (ditto) ymessenger Not all of which were installed at the time problems started. Hope that info helps. Regards, VJS Please revert to stock fedora versions of libdrm, and your x11-drv in use, else we'll not have much choice to lay blame there (on items not verifiable or confirmable outside of yourself and your box). Created attachment 307317 [details]
/var/log/kdm.log timestamp 2008-06-01 14:49 375K
Alright, then: libdrm-2.4.0-0.11.fc9.i386 (fedora) libdrm-devel-2.4.0-0.11.fc9.i386 (fedora) xorg-x11-drv-nv-2.1.8-1.fc9.i386 (fedora) xorg-x11-drv-nouveau-0.0.10-2.20080408git0991281.fc9.i386 (fedora) Also removed all proprietary nvidia driver packages from ATRPMs (which didn't work anyhow). If I should erase anything else to isolate this issue, I'll be happy to do so if asked. BTW, none of the above were installed prior to 5-29-2008 (the day after problems started, which is why I tried with video drivers compiled by myself). No change - cannot start KDE. 'package-cleanup --dupes[--problems]' continue to return nothing but blanks. 'rpm -Va' shows only the usual/expected outout. I'm attaching /var/log/kdm.log which goes all the way back to install date 5-26-2008. Not sure what to make of it.... Regards, VJS Could you consider using the f9 kde live iamge? This would determine more conclusively if it's a fundamental problem with f9/kde4 or your box. I'm a little disappointed that I didn't think to try that.... OK, booted the F9-KDE-LiveCD. Removed pulseaudio suite (doesn't work, fries speakers, floods ~/.xsession-errors), also some extraneous misc. gnomic tools and wireless drivers, etc. (same as before), setup display/xorg.conf, then proceded to update packages in small chunks, logging out of desktop and re- starting X-server in between. Got all the way through the alphabet, unfortunately that's all the farther I got: plenty of RAM and SWAP, but I guess this CPU can't handle any more work without installing - basically, the GUI ground to a halt, due to slow CPU. However, I found this in /var/log/messages: [...] Jun 2 03:16:04 micron-pc-rb kernel: klauncher[7698]: segfault at 8048814 ip 00a69da8 sp bfbb9200 error 7 in libX11.so.6.2.0[a54000+fd000] Jun 2 03:16:04 micron-pc-rb kdm[3732]: X server for display :0 terminated unexpectedly Jun 2 03:16:04 micron-pc-rb acpid: client connected from 7756[0:0] Jun 2 03:25:10 micron-pc-rb hddtemp[3239]: /dev/sda: WDC WD800JB-00JJC0: 102 F Jun 2 03:25:10 micron-pc-rb hddtemp[3239]: /dev/sdb: WDC WD1600AAJB-00PVA0: 109 F Jun 2 03:32:01 micron-pc-rb ntpd[3115]: synchronized to 138.23.180.126, stratum 2 Jun 2 03:55:37 micron-pc-rb ntpd[3115]: synchronized to 217.160.254.116, stratum 2 Jun 2 04:25:10 micron-pc-rb hddtemp[3239]: /dev/sda: WDC WD800JB-00JJC0: 102 F Jun 2 04:25:10 micron-pc-rb hddtemp[3239]: /dev/sdb: WDC WD1600AAJB-00PVA0: 107 F Jun 2 04:34:56 micron-pc-rb kernel: prelink[836]: segfault at a81 ip 0806a61f sp bfae6ec0 error 4 in prelink[8048000+107000] [...] There are many dozens more of the klauncher segfault errors logged since install, all the same except for PID number. libX11.so.6.2.0 (package libX11-1.1.4-1.fc9.i386) has not been altered in any way since install. BTW, I had also re-installed mesa-libGL (which had been replaced with the other Xorg stuff). Also FYI, the re-build Xorg stuff worked fine, it just didn't help with the KDE problem. Hope this helps. Thanx and Regards, VJS OK, I finally got the second install of F9 to boot (turns out that it was an update to F8 GRUB dealing with "Inode size" that was the problem). Now I have _two_ extra F9 OS installs to test with (total of [3] F9's on that machine). The second F9 OS started a KDE session without any issues that I can see. I did also notice that ~/.xsession-errors is already quite large. Both of these two extra F9 installs are completely new and clean at the moment. I'm going to start updating packages on the first one. Any suggestions as to what else to try ? Anything in particular I should do / not do or look at ? Regards, VJS Got it ! It's the 'nouveau' video driver (xorg-x11-drv-nouveau). Use 'nouveau', and KDE crashes - the farthest I got was to an active, loaded KDE desktop, but as soon as I tried to select anything with the mouse, bang! Crash, right back to the login screen - which also crashed if I tried to use the menus there: only typing the password and hit <Enter> actually did something besides cause a lock- up and re-start X. Also, could not switch to a VT from the login screen - locked up on all six VTs, but VT7 was still alive and OK (I could press ALT-CTL- F7 and get back a live login screen). Same results for all (3) users. I actually had to boot into the other OS and change xorg.conf there. Switched the driver back to 'nv', and now all is well. Still doesn't explain why the first F9 OS is still screwed up, because I've tried other video drivers on it too. Whatever happened to the first F9 install must have done a good job of messing things up. Nor does it explain why Enlightenment/E17 is immune to the 'nouveau' effect. Must not be many people using 'nouveau' on F9, or I would think there would be more reports of this.... Of course, I can't prove definitively that it is in fact 'nouveau', but the results of these attempts to track this down sure look make it look like that's the culprit. Regards, VJS And the clue to solving the final piece of the puzzle came from this thread: http://forums.fedoraforum.org/forum/showthread.php?t=195131 The Culprit (in this case): xorg.conf 'Option "BackingStore" "true" ' Using the 'nv' video driver without "BackingStore" on allows KDE4 to succesfully launch a desktop session. All F9-KDE-Live OS installs now start KDE desktop sessions successfully, including the first one that hasn't worked now for almost two months.... "Warp power has been restored, Captain!" Which leaves the questions unanswered: > Why does video driver 'nouveau' cause KDE4 to lock-up/crash? > Why does Xorg option "BackingStore" on cause KDE4 to lock-up/crash? All other DEs/Window Managers are immune to these two phenomenon. Since a root cause and solution have been found (as far as I'm concerned), I'll be removing the extra F9-KDE-Live OS installs very shortly, unless someone needs more info (and gets back to me before I nuke them). Thanx and Regards, VJS Glad to hear it. The BackingStore issue is likely an X server problem. *** This bug has been marked as a duplicate of 457377 *** |