| Summary: | Geforce 7025: nouveau driver issue | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | papoteur <yvesbrungard> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | UPSTREAM --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | cae, davidwhodgins, fri, ghibomgx, lovaren, mageia, marja11, ouaurelien |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| URL: | https://gitlab.freedesktop.org/mesa/mesa/-/issues/4398 | ||
| Whiteboard: | |||
| Source RPM: | x11-driver-video-nouveau | CVE: | |
| Status comment: | |||
| Attachments: |
Xorrg.0.log
dmesg after crash |
||
|
Description
papoteur
2016-03-13 16:31:32 CET
Marja Van Waes
2016-03-14 09:36:19 CET
Assignee:
bugsquad =>
mageia would be useful with a backtrace ;) look in /var/log/Xorg.log* Created attachment 7575 [details]
Xorrg.0.log
Hi Nicolas
I think this file is the one just after the crash. It seems to be corrupted.
For a backtrace I don't know how to get one.
The same situation with 6sta1. To which process should I attach the gdb to get backtrace? Need I to install some debug packages before? Keywords:
(none) =>
6sta1
Marja Van Waes
2016-05-12 21:01:41 CEST
Attachment 7575 mime type:
application/octet-stream =>
text/plain
Samuel Verschelde
2016-08-25 16:23:48 CEST
Assignee:
mageia =>
kde Again problem in RC, but different. After login, the plasmashell is displayed for some seconds, then crashes and I get a black screen, although the applications already launched are still running. If I restart the session, then logon, I get the screen friezed as before. I provide the dmesg after the plasmashell crash. Created attachment 8366 [details]
dmesg after crash
papoteur
2016-08-25 19:22:34 CEST
Keywords:
6sta1 =>
6RC Does adding modprobe.blacklist=nouveau to the kernel boot commandline work? CC:
(none) =>
hamnisdude Hmm... Why I report is against nouveau. If I blacklist it, if it works or not doesn't depend on nouveau. At the moment, nvidia 304 driver works fine. What I noticed in dmesg is that nouveau has many FAULT, then plasmashell crashes: ... [ 120.928506] nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b060 [ 122.639751] nouveau 0000:00:0d.0: bus: MMIO write of 010e0001 FAULT at 00b010 [ 122.745702] plasmashell[6064]: segfault at 0 ip 00007f6c170f2008 sp 00007ffe04221f30 error 4 in nouveau_dri.so[7f6c16ca3000+8d6000] ... Tried with sta2, from LiveDVD. In Live session, the display is readable, allthough some triangles with the same colour are displayed at moments. Setting to Xrender seems to work better, but plasma-shell is freezed. After installation, I get the same problems as before : system is freezed after SDDM connection. I don't get a crash or freeze but I do have 1 system with a Geforce GTX 750 Ti. If I use the nouveau driver I have to boot to init 3 and rm -f /etc/X11/xorg.conf and then start the DM or I get "Good luck" error and X refuses to start. There is no issue if I use the nvidia driver. CC:
(none) =>
cae (In reply to Charles Edwards from comment #9) > I don't get a crash or freeze but I do have 1 system with a Geforce GTX 750 > Ti. > > If I use the nouveau driver I have to boot to init 3 and rm -f > /etc/X11/xorg.conf > and then start the DM or I get "Good luck" error and X refuses to start. > > There is no issue if I use the nvidia driver IF you add modprobe.blacklist=nouveau on the kernel boot command line, does that change the situation? It helps only if I want to boot to init 3 and change the video driver and not have to reboot. Then I can do service service dm start with the New driver and get the login screen. Otherwise the boot just simply stops at init 3. I got a backtrace ============== Core was generated by `/usr/bin/plasmashell --shut-up'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xab5fd54c in ?? () [Current thread is 1 (LWP 5978)] (gdb) thread apply all bt full Thread 7 (LWP 5988): #0 0xb77afd09 in __kernel_vsyscall () No symbol table info available. #1 0xb4d70ceb in ?? () No symbol table info available. #2 0xb44ac000 in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 6 (LWP 5982): #0 0xb77afd09 in __kernel_vsyscall () No symbol table info available. #1 0xb4d70ceb in ?? () No symbol table info available. #2 0xb44ac000 in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 5 (LWP 5980): #0 0xb77afd09 in __kernel_vsyscall () No symbol table info available. #1 0xb4d70ceb in ?? () No symbol table info available. Thread 4 (LWP 5991): #0 0xb77afd09 in __kernel_vsyscall () No symbol table info available. #1 0xb4d70ceb in ?? ()
papoteur
2016-12-18 22:07:34 CET
Keywords:
6sta1.5 =>
6sta2 With the end =================== ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #2 0xb44ac000 in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 3 (LWP 5990): #0 0xb77afd09 in __kernel_vsyscall () No symbol table info available. #1 0xb4c2460b in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. Thread 2 (LWP 5985): #0 0xb77afd09 in __kernel_vsyscall () No symbol table info available. #1 0xb4d70ceb in ?? () No symbol table info available. #2 0xb44ac000 in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 1 (LWP 5978): #0 0xab5fd54c in ?? () No symbol table info available. Still valid with sta2/32bits
I get a segfault in plasma-shell just at boot:
janv. 21 11:39:41 localhost plasmashell[14765]: Plasma Shell startup completed
janv. 21 11:39:41 localhost plasmashell[14765]: Both point size and pixel size set. Using pixel size.
janv. 21 11:39:41 localhost audit[14765]: ANOM_ABEND auid=500 uid=500 gid=500 ses=5 pid=14765 comm="plasmashell" exe="/usr/bin/plasmashell" sig=11
janv. 21 11:39:41 localhost kernel: plasmashell[14765]: segfault at 0 ip ab6090cc sp bfcbb364 error 4 in nouveau_dri.so[ab1a0000+a20000]
janv. 21 11:39:41 localhost kernel: audit: type=1701 audit(1484995181.384:195): auid=500 uid=500 gid=500 ses=5 pid=14765 comm="plasmashell" exe="/usr/bin/plasmashell" sig=11
In the same time, nouveau reports multiple errors like:
janv. 21 11:39:40 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b090
janv. 21 11:39:40 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b0c0
janv. 21 11:39:41 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 027a0001 FAULT at 00b090
janv. 21 11:39:41 localhost kernel: plasmashell[14765]: segfault at 0 ip ab6090cc sp bfcbb364 error 4 in nouveau_dri.so[ab1a0000+a20000]
janv. 21 11:39:51 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 03170001 FAULT at 00b090
janv. 21 11:40:00 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b090
[reboot launched from commandline]
x11-driver-video-nouveau x11-driver-video-nvidia304 dkms-nvidia304
janv. 21 11:47:19 localhost kernel: NVRM: This can occur when a driver such as nouveau, rivafb,
janv. 21 11:47:19 localhost kernel: NVRM: This can occur when a driver such as nouveau, rivafb,
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b000
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b010
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b020
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b030
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b040
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b050
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b060
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b070
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b080
janv. 21 11:47:19 localhost kernel: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at 00b0a0
can you report this upstream ? this may be a qt or plasma bug CC:
(none) =>
mageia The problem is still valid in cauldron I reported it upstream, with no effect. https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/520 Keywords:
6sta2 =>
(none) Not a Plasma bug. Even I know the heavy use of GL by Plasma, try set "Compositor" to XRender instead of OpenGL in Compositor KCM. Driver issue tracked upstream here now: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4398 Passing nouveau.noaccel=1 to kernel command line is a temporary workaround. Assigning back. Summary:
Geforce 7025: crashes with Plasma/nouveau =>
Geforce 7025: nouveau driver issue This hardware is 17! years old. Upstream wont fix anything as no serious developer spends time on such historic hardware (there is no hardware existing anymore to test fixes on...) (In reply to sturmvogel from comment #19) > This hardware is 17! years old. Upstream wont fix anything as no serious > developer spends time on such historic hardware (there is no hardware > existing anymore to test fixes on...) Don't speak on something about what you don't know. I have this card on hardware from 2012, this is not 17 years old as you say. Now, the Nvidia driver 304 is no more usable (perhaps already from Mageia 6 or 7). I use this hardware from time to time, it still crashes for the same problem, not too often with LXQt. Perhaps, the problem won't be solved in any time, but there is no reason to consider it to close. (In reply to papoteur from comment #20) > Don't speak on something about what you don't know. > I have this card on hardware from 2012, this is not 17 years old as you say. Im heartbroken to tell you that you are wrong at this point. The Geforce 7025 +nForce 630a was released in 2006...17 years ago. That is easy to check by simply googling "Geforce 7025 release date" Facts for you: https://askgeek.io/en/gpus/NVIDIA/GeForce-7025-nForce-630a https://www.techpowerup.com/gpu-specs/geforce-7025-nforce-630a.c1958#:~:text=The%20GeForce%207025%20%2B%20nForce%20630a,launched%20on%20February%201st%2C%202006. A few notes. For the older NV cards it can be used either 'kernel modesetting' (there is even an alias entry in drakx11 NVIDIA section) or 'nouveau'. I don't know if specifically supports this card, but might be worthwhile a test with modesetting. For the proprietary drivers, AFAIK the newest supporting Nforce 630a was 304.xx, which we already retired in mga7. Outside official support (either from upstream and us and from us) and not considering security problems, AFAIK in newer 390.xx is possible to get it compiling with latest kernel 6.3 (I've found a successful set of patchset and a local working spec file). On 3D it's still 2, 2.5x times faster than nouveau or modesetting. Anyway we are speaking of 390.xx (and here we would need 304.xx which is another story). But then even with 390.xx it arises a 2nd problem. I.e. xorg being too old because of newer ABI. It's possible to add "IgnoreABI" "1" in the ServerFlags of xorg.conf to ignore the ABI mismatch, but from what I could test myself Xorg is pretty unstable under this conditions (not at kernel level of the nvidia modules, but at X level, because of missed stuff). Some other distro (e.g. debian) provides a xorg-legacy, with an older ABI. I tried a quick backport of an older xorg version, but even the 1.20.13 fails to build under mga9, then I let it go. And last but not least, the driver might expose only a too old OpenGL level for the modern desktops (at least 3.3). A 2nd workaround (already suggested here by Aurelien) is also to disable the 3D acceleration (there is now an option in drakx11/Option) and rely on the software LLVMpipe only; it might work and it also exposes OpenGL level up to 4.5. CC:
(none) =>
ghibomgx (In reply to sturmvogel from comment #21) > (In reply to papoteur from comment #20) > > Don't speak on something about what you don't know. > > I have this card on hardware from 2012, this is not 17 years old as you say. > Im heartbroken to tell you that you are wrong at this point. The Geforce > 7025 +nForce 630a was released in 2006...17 years ago. > That is easy to check by simply googling "Geforce 7025 release date" Please keep in mind that both can be true. The card was originally released in 2006, and it was present in a video card purchased in 2012. All that matters is whether or not Mageia can support it. CC:
(none) =>
davidwhodgins (In reply to sturmvogel from comment #19) > no serious developer spends time on such historic hardware In my profession we prefer to buy stuff from vendors who keep supporting their stuff. I know software business often suck, especially the home crap computer business, but we should keep up expecting serious vendors to care for their reputation. Some do guarantee production for decades of their chips and compilers still works too. If we stop expecting support for reasonable lifetime we will soon end up with crap that is only supported for a few years. (In reply to Morgan Leijström from comment #25) > (In reply to sturmvogel from comment #19) > > no serious developer spends time on such historic hardware > > In my profession we prefer to buy stuff from vendors who keep supporting > their stuff. > > I know software business often suck, especially the home crap computer > business, but we should keep up expecting serious vendors to care for their > reputation. > > Some do guarantee production for decades of their chips and compilers still > works too. > > If we stop expecting support for reasonable lifetime we will soon end up > with crap that is only supported for a few years. You want to compare industry computer systems with a cheap customer graphic card like Geforce 7025? Even professional operating systems for industry computers have only a support lifetime of ~10 years. After that you need to replace the hardware. If you expect support for cheap customer hardware after 17 years when even professionell paid support in industry ends in most cases after 10 years...well, good luck. Somebody who wants to have such hardware after 17 years still supported needs to step up and maintain the no longer buildable software. But as comment 23 shows impressive, this is hardly possible...so good luck with that :) I am not denying the sad state of the consumer market. I say we should not accept or amplify the low intentions of manufacturers. Especially i see the low expectations spilling over to i.e home appliances. Laundry and dishwashing machines can last decades as long as a few can-be-cheap wearing parts can be replaced. The unnecessary replacing of whole machines cost is enourmous on the global scale - both economic, resource, and environmental. OK enough politics... We can not fix everything others brake, just learn and educate :) |