Bug 657589 - NV43 crash when enabling OpenGL based desktop effects for kde (using mesa-experimental-drivers)
Summary: NV43 crash when enabling OpenGL based desktop effects for kde (using mesa-exp...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 14
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-26 16:46 UTC by info@kobaltwit.be
Modified: 2018-04-11 10:10 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-04-25 12:55:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg log file holding the backtrace of the crash (59.34 KB, text/plain)
2010-11-26 16:46 UTC, info@kobaltwit.be
no flags Details
dmesg output after reboot with drm.debug=0x04 (91.31 KB, text/plain)
2010-11-29 13:06 UTC, info@kobaltwit.be
no flags Details
Contents of /var/log/messages since last reboot (with drm.debug=0x04) (84.93 KB, text/plain)
2010-11-29 13:07 UTC, info@kobaltwit.be
no flags Details
Xorg log file after kwin crashed (62.31 KB, text/plain)
2010-12-03 11:49 UTC, info@kobaltwit.be
no flags Details
dmesg output after kwin crash (96.31 KB, text/plain)
2010-12-03 12:02 UTC, info@kobaltwit.be
no flags Details
Xorg log file after desktop effects got automatically suspended (57.72 KB, text/plain)
2010-12-03 16:01 UTC, info@kobaltwit.be
no flags Details
dmesg output after desktop effects got autmatically suspended (123.95 KB, text/plain)
2010-12-03 16:03 UTC, info@kobaltwit.be
no flags Details

Description info@kobaltwit.be 2010-11-26 16:46:18 UTC
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.

Comment 1 Matěj Cepl 2010-11-28 00:27:21 UTC
[ 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.

Comment 2 info@kobaltwit.be 2010-11-29 13:06:48 UTC
Created attachment 463480 [details]
dmesg output after reboot with drm.debug=0x04

Comment 3 info@kobaltwit.be 2010-11-29 13:07:45 UTC
Created attachment 463481 [details]
Contents of /var/log/messages since last reboot (with drm.debug=0x04)

Comment 4 info@kobaltwit.be 2010-11-29 13:10:10 UTC
# rpm -q mesa-dri-drivers-experimental
package mesa-dri-drivers-experimental is not installed

Comment 5 info@kobaltwit.be 2010-11-29 13:10:51 UTC
I don't have an xorg.conf file in /etc/X11

Comment 6 Matěj Cepl 2010-11-29 15:25:35 UTC
(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?

Comment 7 info@kobaltwit.be 2010-11-29 16:25:17 UTC
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...

Comment 8 Matěj Cepl 2010-11-30 13:29:47 UTC
(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.

Comment 9 info@kobaltwit.be 2010-12-01 09:19:06 UTC
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 ?

Comment 10 info@kobaltwit.be 2010-12-01 11:18:42 UTC
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.

Comment 11 info@kobaltwit.be 2010-12-01 11:28:35 UTC
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.

Comment 12 Matěj Cepl 2010-12-01 16:58:53 UTC
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?

Comment 13 info@kobaltwit.be 2010-12-03 11:49:15 UTC
Created attachment 464553 [details]
Xorg log file after kwin crashed

Comment 14 info@kobaltwit.be 2010-12-03 12:02:17 UTC
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 ;)

Comment 15 info@kobaltwit.be 2010-12-03 16:01:21 UTC
Created attachment 464600 [details]
Xorg log file after desktop effects got automatically suspended

Comment 16 info@kobaltwit.be 2010-12-03 16:03:02 UTC
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.

Comment 17 info@kobaltwit.be 2011-04-23 10:40:02 UTC
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.

Comment 18 Ben Skeggs 2011-04-25 12:55:35 UTC
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.


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