Hide Forgot
Created attachment 463101 [details] Xorg log file holding the backtrace of the crash Description of problem: I have installed Fedora 14 on my system. Whenever I try to enable KDE's desktop effects with OpenGL as a backend, I get an instant Xorg crash. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.9.1-3.fc14.i686 kdebase-workspace-4.5.3-3.fc14.i686 (contains kwin which may be related) How reproducible: Always Steps to Reproduce: 1. Open kde's System Settings window 2. Select Desktop Effects 3. In the Advanced tab, select OpenGL as compositing type 4. In the General tab, check "Enable Destkop Effects" 5. Hit apply Actual results: Instant Xorg crash, which shows as a black screen with blinking cursor in the top-left corner. After a couple of seconds, the login screen is presented again, suggesting Xorg has automatically been restarted. Expected results: Desktop effects should simply work with OpenGL as compositing type. Additional info: * I can enable desktop effects if I choose XRender as compositing type, but this is really slow. * My graphics card is an NVidea GForce 6600GT. * I have attached the previous Xorg.log file which reveals most of my X video configuration and the backtrace of the crash in the end. * I have looked at some other bugs in bugzilla regarding nouveau: there was a workaround in bug 624208 comment 22 that fixes opengl in other circumstances (there was no crash involved there). I tried the workaround anyway, but that changed nothing. Let me know if you require more information.
[ 28047.492] (II) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed (/usr/lib/dri/nouveau_dri.so: cannot open shared object file: No such file or directory) [ 28047.492] (II) AIGLX: reverting to software rendering ---- Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * version of mesa-dri-drivers-experimental (that's where /usr/lib*/dri/nouveau_dri.so lives)? rpm -q mesa-dri-drivers-experimental would tell you, * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 463480 [details] dmesg output after reboot with drm.debug=0x04
Created attachment 463481 [details] Contents of /var/log/messages since last reboot (with drm.debug=0x04)
# rpm -q mesa-dri-drivers-experimental package mesa-dri-drivers-experimental is not installed
I don't have an xorg.conf file in /etc/X11
(In reply to comment #4) > # rpm -q mesa-dri-drivers-experimental > package mesa-dri-drivers-experimental is not installed If you install this package does anything improves?
Yes, when I install this package I can enable desktop effects with OpenGL. Great ! So the solution is already available, yet not automatically installed. I guess that's due to the "experimental" part in the package name ? I wonder if this should be considered a bug or not ? I mean, as an ordinary user, I doubt I would have easily found a solution for this. IMHO for ordinary users either it should not have been possible to enable desktop effects with openGL if OpenGL support for the driver is experimental or if you can enable the effects based on experimental OpenGL support, the experimental package should have been installed, right ? The even more sophisticated solution could allow the user to enable experimental stuff with a nice warning and then install whatever is necessary to actually activate it. But I realize that is more than complicated... Just probing if the typical user experience can be improved here...
(In reply to comment #7) > So the solution is already available, yet not automatically installed. I guess > that's due to the "experimental" part in the package name ? yes, it is. I have to remind you, that noveau is the only driver which is pure magic^H^H^H^H^H^H^Hreverse-engineered without any cooperation from its manufacturer. So, we are trying to be extra cautious with introducing support for new capabilities of the card, and so far it has paid off ... in my opinion nouveau is more stable than both radeon and intel drivers. That experimental mesa drivers worked for you. Feel lucky. > IMHO for ordinary users either it should not have been possible to enable > desktop effects with openGL if OpenGL support for the driver is experimental or > if you can enable the effects based on experimental OpenGL support, the > experimental package should have been installed, right ? The even more > sophisticated solution could allow the user to enable experimental stuff with a > nice warning and then install whatever is necessary to actually activate it. > But I realize that is more than complicated... Yes, desktop-effects should be probably more investigative about the state of the system.
Hmm, I seem to have problems with the experimental driver as well: I can start the desktop effects just fine and they work nicely for some time, say an hour or two. Then the mouse movement starts to get choppy and a little later I get notification that desktop effects is temporarily suspended because they are too slow. I can restart the desktop effects by hitting alt-shift-f12 and the cycle starts again. It works for a while and then desktop effects are suspended again. When mousemovement gets choppy, I see via top that X is taking 80%-95% of cpu time (luckily only on one core in my dual core system). Any information I can provide that would help you guys find the cause of this ?
I ran some more tests. The Xorg cpu usages below are taken from top, so these are only rough indications. - just looking at the desktop, not moving the mouse: 2% - continuously moving the mouse inside a terminal window: 9-12% - continuously moving the mouse inside a blank firefox window: 20-30% - moving the mouse over and out a hyperlink in firefox repeatedly: 25-30% - moving the mouse across the firefox bookmarks bar: 30-40% - moving the mouse up and down in a dolphin window, showing a folder in detailed view (the folders get highlighted when the mouse moves over them): 30-35% - moving the mouse across the task bar below (which highlights the task while moving over them: around 60% - quickly opening and closing the kickoff menu (fedora button in bottom-left): about 90% These readings give me the impression the desktop effects are being performed by the cpu instead of the graphics card.
Not all of the above may be relevant though. With desktop effects suspended, Xorg still reports about 10% for simple mouse movement. But moving the mouse over the task bar is definitely different: with DE suspended, Xorg takes only about 30% and plasma-desktop about 60%. In the test with DE enabled, I didn't even see plasma-desktop in top, so its cpu usage must have been very low. I discovered another interesting cpu usage difference while posting the previous comment: when firefox is loading a page it shows a small running circle animation in the loading tab. This animation alone takes about 70% Xorg cpu usages with DE enabled and only 25% with DE suspended.
I am afraid you have discovered by experiment why we have this nouveau driver still in experimental package :(. Could we get /var/log/Xorg.0.log and the output of dmesg AFTER the slowdown happens and BEFORE reboot, please?
Created attachment 464553 [details] Xorg log file after kwin crashed
Created attachment 464556 [details] dmesg output after kwin crash Yesterday kwin crashed while the desktop effects were getting extremely slow again. I'm attaching Xorg's log and dmesg output right after the crash. Perhaps they are completely unrelated to this bug. I'll leave that judgement up to you. P.S. I understand perfectly fine I'm using experimental software here and I'm ok with its irregular behaviour. I continue to use it anyway hoping that my reports will help someone improve on it ;)
Created attachment 464600 [details] Xorg log file after desktop effects got automatically suspended
Created attachment 464601 [details] dmesg output after desktop effects got autmatically suspended The last two log files are copied right after I got the message that desktop effects were suspended due to being too slow. No crash this time.
Tested OpenGL enabled compositing in kwin on F15 beta today. That version seems to work fine. I don't mind if this only works on F15 and not on F14 so as far as I'm concerned, this bug can be considered as fixed.
Yes, there's far too many potentially relevant changes to narrow this down for F14, and it's likely there's many inter-dependant changes that'd make it a "risky" thing to do in F14. Closing as NEXTRELEASE as it's fixed in f15.