Here on a PowerMac G5 with a NVIDIA GeForce 6600LE graphics card, most things run pretty well except for some of the things I wanted to run on the machine resulted in nouveau GPU lock-ups, and consequently a glitched display (artifacts only). When trying to start GDM, SDDM, or Plasma Desktop on the machine, the display locks up, and I was able to salvage an error message as follows: [drm] nouveau 0000:0a:00.0: GPU lockup - switching to software fbcon After a minute or two, the display responds again, but only showing a black background with several randomly colored pixels, and some white blocks. However, this graphics card runs LightDM, XFCE, MATE... and most other applications without such error and lock-ups. I was able to workaround the issue by using the nouveau.noaccel=1 kernel parameter (except in the case of GDM, it returned with the same error), but that simply beats the purpose of owning a graphics card. However, even with the noaccel parameter in place, I was still experiencing bad coloring issues, as reported here: https://bugs.freedesktop.org/show_bug.cgi?id=98630. ---------- Some version info: - Linux Kernel 4.8.6 (with 4K paging in case you are wondering) - Mesa 13.0.0 - Xorg Server 1.18.4 ---------- P.S. I tried on with a Quadro FX4500, which simply shows the lock up error whenever attempting to start X. But I couldn't make sure if it's a hardware issue or not, as the card sparked on the first power up, that's why I have already returned it...
Without trying to defend the suckiness, the nv30 driver is kinda crap and WAY lower quality than what these modern desktops expect. And that's on x86 -- BE PPC is largely untested, although I have made some efforts to get it kinda-working again. Instead of booting with noaccel=1 you could try removing nouveau_dri.so. That way you still get the X-based accel, but nothing tries to use 3D accel.
(In reply to Ilia Mirkin from comment #1) > Without trying to defend the suckiness, the nv30 driver is kinda crap and > WAY lower quality than what these modern desktops expect. And that's on x86 > -- BE PPC is largely untested, although I have made some efforts to get it > kinda-working again. Please accept my applaud with your faster-than-light reply. Where exactly could the latest efforts be obtained? I will be more than happy to test out the results with my machine (also, if you would need SSH access, I would quite happily provide that). > Instead of booting with noaccel=1 you could try removing nouveau_dri.so. > That way you still get the X-based accel, but nothing tries to use 3D accel. I will try that later today, thanks very much!
As a follow up, after removing nouveau_dri.so, I no longer get GPU lock up when starting Plasma desktop. However, I am still getting weird colors (for example, my KSplash setting has a background of dark green color, but it showed up as bright blue, and there is a black border around the KDE logo and the spinner (I will attach a photograph when I get back to my room).
Apropos Xfce 4.12, notice two variants of the Xfwm4: = Xfwm4 4.12.3 "released" - Xrender driven compositor, it can be run on virtually any machine $ xfwm4 --version ... Build configuration and supported features: - Render support: Yes - Embedded compositor: Yes = Xfwm4 "not released" - GL(X) driven compositor, https://git.xfce.org/xfce/xfwm4/commit/?id=fee08ea it can run on NV50 family (Tesla), https://nouveau.freedesktop.org/wiki/CodeNames/#NV50 on e.g. NV30 is slow, i.e. not very useful, although it may have to do with the performance of the CPU. $ xfwm4 --version ... Build configuration and supported features: - Embedded compositor: Yes - Epoxy support: Yes LightDM GTK+ Greeter (lightdm-gtk-greeter) is not accelerated, therefore it can be run on virtually any machine. KF5/KDE5 i.e. KWin also provides two variants of the compositor, GL and XRender driven. One important difference is that Xrender driven compositors aren't tear-free.
For me this sounds like #98039 related
Quote: "After a minute or two, the display responds again, but only showing a black background with several randomly colored pixels, and some white blocks." Yes, this is exactly what i had on x86_64. It would be great if you could create a gdb log. With such a log the developers could see if its the same problem like i had here: https://bugs.freedesktop.org/show_bug.cgi?id=102349 Side note: I had to change from tty to the x-server and move the mouse around to cause a segfault error. Then change back to the tty and read out the gdb log with "thread apply all bt" Thanks
(In reply to caguduzexi from comment #6) > Quote: "After a minute or two, the display responds again, but only showing > a black background with several randomly colored pixels, and some white > blocks." > > Yes, this is exactly what i had on x86_64. > It would be great if you could create a gdb log. With such a log the > developers could see if its the same problem like i had here: > > https://bugs.freedesktop.org/show_bug.cgi?id=102349 > > Side note: I had to change from tty to the x-server and move the mouse > around to cause a segfault error. Then change back to the tty and read out > the gdb log with "thread apply all bt" > > Thanks It will be two weeks before I could get to working with my PowerMac again. Will try and produce one then.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/298.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.