When it has finished to boot everything works correctly: I can move the Pidgin window or I can lock the screen: boxes are drawn correctly. Yet after resume from s2ram/suspend you can see a black box as the background of the status bar tray instead of a filled one, moving pidgin leads to box-shaped screen distortions and the background box of the login dialogue is not drawn any more. Note that the graphics output of Pidgin only works under i586/nouveau because I have installed the patches from Karol Herbst which are referenced under Bug 30568. The issue that it did not draw the background box of the login dialogue had once, at the time before Bug 30568 popped up, already been resolved: see Bug 30300. I have tested whether this could be a kernel regression. It didn´t work with the current kernel 5.15.79-desktop586-1. With kernel 5.15.46, the oldest that is still installed at me the problem is the same but additionally the mouse pointer gets garbled after resume from suspend/s2ram. It can also be observed that with 5.15.46 the console font at bootup is big and of low resolution in contrast to current kernels. Kernel 5.15.46 is exactly the kernel at the time of when I had filed and finally tested for Bug 30568. It is yet unknown whether this is a kernel issue or whether it could be related to the patches of Karol Herbst, instead. I´d still suppose it a kernel issue but to test for it I would need to know with what version of the kernel Mageia had shipped at the time bug 30300 was resolved. Alternatively I could temporarily uninstall the patches from Carol Herbst which would require me to disable the respective mesa repo and replace all packages that were installed from that repo with their elder genuinge Mageia versions. I would welcome some advice on how to do that.
Created attachment 13544 [details] after resume from s2ram: screen distortions in the status tray and on moving the Pidgin window
Created attachment 13545 [details] after resume from s2ram: the background box of the login screen is not drawn
Created attachment 13546 [details] before resume from s2ram: background box of login screen is drawn correctly
elder kernels won´t help: the reason why there is a regression on Bug 30300 is a newly missing environment variable and not an elder kernel.
I have just tested suspend to disk and same issue there. Likely this bug is also independent from Bug 30568, i.e. the patches by Karol Herbst. At least I can´t find any reason no more why these two issues would be realted. The gtk3-bug is different and xscreensaver is non-gtk which proves it shall be distinct from 30568.
upstream kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=216780
Thank you for the report; and the upstream bug references. It applies to Nvidia Geforce4 420 Go. It is for i586; do you know whether it happens on x86? Ask on a forum, please. It happens for both s2ram and s2disk (pkg 'suspend'). There are other ways to suspend, desktop dependant [with pkg 'suspend' *not* installed, using Mate, it offers 'suspend' & 'hibernate'; as do others]; do you know whether the problem happens with them also? What desktop are you using?
Summary: i586: mesa doesn´t draw boxes correctly after resume from s2ram => i586: mesa doesn´t draw boxes correctly after resume from s2ram or suspend to disc, Nvidia Geforce4 420 GoCC: (none) => lewyssmithURL: (none) => https://gitlab.freedesktop.org/drm/nouveau/-/issues/194
x86_32: it runs on a PentiumIV, i586 using LXDE; I suppose it does not depend on the desktop environment; I could test with: 'systemctl suspend' and 'systemctl hibernate' instead of the desktop buttons but I guarantee you the effect will be the same since to my knowledge all desktop environemnts call the same mechanism.
Except that you cited explicitly 's2ram', which comes with pkg 'suspend', which I do not have. Yet all the desktops offer suspend|hibernate, so maybe they do have their own different way. Do please confirm with the commands you suggest above; and desktop suspend. This will probably change nothing, but it at least eliminates the exact suspend mechanism as a pôssible cause. TIA
No, I have just used normal suspend and hibernate. I had just called it s2ram because I know that term from ancient times. There is no s2ram on today´s computers, or is there? - at least there is none at the Gericom SilverSeraph, where I have tested.
$ urpmq -i suspend Name : suspend Summary : Userland tools for suspend-to-disk and suspend-to-RAM Description : ... Currently suspend-to-ram and suspend-to-disk are handled by two different program, s2ram and s2disk. 'suspend' provides: /usr/sbin/resume /usr/sbin/s2both /usr/sbin/s2disk none of which are present on my (probably also your) system. So you understand my question. It turned out to be irrelevant. Another question: if you logout/in, possibly reset X with Ctl/Alt/Bksp/Bksp at the login screen, does that fix things? Not that you would want to do that.
Keywords: (none) => UPSTREAM
login/out + restarting X: I am going to test this as soon as I am back home which will be by Monday.
No, restarting the X-server does not help. I have also tried to unload nouveau by first issuing an "echo 0 >/sys/class/vtconsole/vtcon1/bind" but that has crashed the SilverSeraph the way it did no more respond to SysRq keys. Interestingly I get a big console font until I log in as user on vt1; then the graphics mode changes to a higher resolution. If that graphics mode switch on login could be avoided maybe I could rmmod nouveau & drm. It also crashes on an unbind with a fresh boot.
Hmm, there is no suspend rpm package installed on that computer and neither an s2disk, s2ram or s2both executable. I wonder how it suspends here. 'systemctl suspend' works and it has the described effects (Just wanted to test hibernate without platform suspend but that is only offered by the suspend package utils.). Shall I install 'suspend' and see whether that can resolve some or all of the issue?
zgrep on /proc/config.gz reveals the kernel was translated with CONFIG_VT_HW_CONSOLE_BINDING=y. Perhaps another bug? - https://www.kernelconfig.io/config_vt_hw_console_binding / "echo 0 >/sys/class/vtconsole/vtcon1/bind"
systemctl suspend triggers /usr/lib/systemd/system/suspend.target See "man systemd-suspend.service". The suspend package should be dropped as it's not needed anymore.
CC: (none) => davidwhodgins
vesa driver: Now I have tested it with the Xorg-vesa driver and see it awakes well from suspend. That is to be expected though since vesa doesn´t know any glx. Noveau & dri modules were unloaded by booting with nouveau.modeset=0. fbdev driver did not start: Xorg.log: FBIOPUT_VSCREENINFO: Invalid argument - mode initialization failed - tested with nouveau modesetting as is the default
"man systemd-suspend.service" comes out to execute /usr/lib/systemd/systemd-sleep which is an ELF-executable. To me it is somewhat untasty to mount suspend functionality into systemd as a systemd module. What if you want to test it without systemd? At least /etc/systemd/sleep.conf gives me some interesting options and I will most likely test for them tomorrow.
* setting mode shutdown instead of platform (afaik the default) makes it awake from suspend to disk without distortions * suspend mode standby and mem both lead to the described distortions while freeze halts/hangs the system without any recovery at me * using the vesa driver seems to resolve not only the suspend problems but apparently also the glx problems for which we have a patch by Karol Herbst (Bug 30568). However it has several drawbacks: No xrandr configuration of an external monitor and only 800x600 instead of 1024x768, although 1024x768 shall be a Vesa mode, too. The nouveau and drm modules must be unloaded which requires booting with nouveau.modeset=0 and removing nouveau and drm from the initrd.
(In reply to Dave Hodgins from comment #16) > The suspend package should be dropped as it's not needed anymore. Do you want to put that in the TRACKER https://bugs.mageia.org/show_bug.cgi?id=30163 Ask first in devML ?
To me I don´t really care whether the suspend package is obsoleted. To me it is still of value though; it references some quirks I could try and would offer an additional possibility to test for platform mode s2disk. Unfortunately it was not possible to install that on Mageia 8 i586 (although here on Mageia 8 x86_64 it is installed).
Elmar, are there any features you're using from the suspend package that are not covered by systemd? $ apropos systemd|grep -e suspend -e hibernate systemd-hibernate-resume (8) - Resume from hibernation systemd-hibernate-resume-generator (8) - Unit generator for resume= kernel parameter systemd-hibernate-resume@.service (8) - Resume from hibernation systemd-hibernate.service (8) - System sleep state logic systemd-suspend-then-hibernate.service (8) - System sleep state logic systemd-suspend.service (8) - System sleep state logic xscreensaver-systemd (1) - lock the screen when the machine suspends.
(In reply to Elmar Stellnberger from comment #18 comment #19) > /etc/systemd/sleep.conf gives me some interesting options > * setting mode shutdown instead of platform (afaik the default) makes it > awake from suspend to disk without distortions > * suspend mode standby and mem both lead to the described distortions while > freeze halts/hangs the system without any recovery at me Can you post this file, and show what alteration(s) you made? Having looked at the file, it was not clear where you were applying the keywords. I think your interest in the 'suspend' pkg is misplaced, since you did not have it. Is the following not the essential point (the line in question being identified)? : "* setting mode shutdown instead of platform (afaik the default) makes it awake from suspend to disk without distortions" which seems to resolve the problem.
/usr/share/doc/suspend/HOWTO (d) [optionally] install libsplashy-dev or fbsplash (for user space splash screens) For now you need the experimental version of splashy, which can be found at svn://svn.debian.org/svn/splashy/branches/0.3 . fbsplash may be found at http://fbsplash.berlios.de . --enable-splashy Enable splashy support --enable-fbsplash Enable fbsplash support I don´t think that there are additional programs to save and restore the video state like splashy and fbsplash appear to be with systemd. Nonetheless I haven´t downloaded or examined these so I don´t know whether they could be of help here. I have not looked into this, yet. I know from ancient times that there were such helper programs at least for ATI cards. Basically I would believe that some structure is not re-initialized after resume which is initialized on module load. My thought was that a helper program could do that as well.
Created attachment 13568 [details] /etc/systemd/sleep.conf test-1-4) show the individual lines I had added on every test (and deleted thereafter again before the next test).
Thank you for that detailed information. From your comment 19 - the first sentence - can we take it that test4 resolved the problem? : #HibernateMode=platform shutdown test-4) HibernateMode=shutdown and that tests1-3 offered no benefit.
test-1 & test-2 offered no benefit, test-3 hung my system and test-4 resolved the problem although only for suspend to disk.
As it appeared. From comment 10: "I have just used normal suspend and hibernate" The desktop 'leave' choices 'Suspend' or 'Hibernate' do not talk fof 'to-disc' or 'to-ram'. For which one does test4 solve the problem; but not for the other?
AFAIK suspend to disk = hibernate, suspend to ram or standy = called suspend
(In reply to Lewis Smith from comment #20) > (In reply to Dave Hodgins from comment #16) > > The suspend package should be dropped as it's not needed anymore. > Do you want to put that in the TRACKER > https://bugs.mageia.org/show_bug.cgi?id=30163 > Ask first in devML ? It is already on the tracker bug 30163#c10 since march...
Created attachment 13581 [details] bash script used to unload and modprobe nouveau I have great news!: If you unload/rmmod nouveau and then insmod it again, all screen distortions are gone. The initialization code of nouveau resets things correctly. Note that the other kernel modules that I tried to rmmod here actually stayed loaded due to the output of rmmoded.lsmod: $ cat /root/rmmod.log rmmod: ERROR: Module drm_ttm_helper is in use by: nouveau rmmod: ERROR: Module ttm is in use by: drm_ttm_helper nouveau rmmod: ERROR: Module drm_kms_helper is in use by: nouveau rmmod: ERROR: Module drm is in use by: drm_ttm_helper nouveau ttm drm_kms_helper $ grep nouveau rmmoded.lsmod (no output)
Created attachment 13582 [details] rmmoded.lsmod - only nouveau got unloaded Here is the proof that nouveau got unloaded correctly.
confirmed with Mageia 9, including the undesirable fix to unload and reload the nouveau kernel module: mesa-22.3.1-1.mga9, kernel-desktop586-latest-6.0.13-1.mga9
Well done for your detective work. Could this bug now be renamed "need to reload neauveau after hibernate/sleep"? (In reply to Elmar Stellnberger from comment #8) > x86_32: it runs on a PentiumIV, i586 Do you know whether it is specific to that, or applies also to 64-bit? > using LXDE; I suppose it does not depend on the desktop environment; Have you tried other desktops? > It applies to Nvidia Geforce4 420 Go Do we think it is specific to this hardware?
Keywords: (none) => FOR_ERRATA9
No, the bug is far from resolved. You can not simply unload nouveau unless you have shut down your X-server and opened no other tty. That is why the script is needed - and it needs to be executed with "disown %1" so that the script is not killed when the X-server shuts down. The way to resolve this would AFAIK be to place a suspend hook in the nouveau kernel module that calls part of the glx initialization code on resume from suspend which is normally only called on module loading. If you know where to put a request for that (freedesktop/kernel dev), it may help us forth.
Now I have re-tested hibernation with shutdown mode for kernel 6.1.0-desktop586-2.mg9 and somehow similar glx and mouse pointer distortions like for platform mode hibernation and suspend to ram/standby have appeared. Apparently there is some issue with the save/restore code of nouveau.
You have only talked about nouveau. Did you ever try with the native Nvidia driver?
No, the problem is that you would need a very ancient version class of the native driver. The version class shipped with Mageia is to my knowledge only usable with newer hardware.
The geforce 420 should be supported by x11-driver-video-nvidia390. If you run XFdrake, what driver does it want to use?
Discrepancy: This bug is set to mga8, but For errata 9. Is it valid for both mga8 & 9?
CC: (none) => fri
Good point... I was not wanting to lose sight of it.
Keywords: FOR_ERRATA9 => (none)
Originally filed for Mageia 8 and now confirmed and further tested on Mageia 9; gonna test the nv driver in the weekend.
Confirmed with kernel 6.1.1-desktop586-2.mga9. There was some notable improvement for 6.1.0-desktop586 only in that the screen content was preserved directly after resume, already before the X-server started to run again. With 6.1.1 you get a distorted screen directly after resume which is then fixed when the X-server continues to run.
XFdrake did not seem to recommend anything. It has displayed my graphics card ("Nvidia Geforce 2 MX to Geforce 4") and LCD monitor and there were some options like start X-server on boot but no menu to select whether you want the Nvidia driver or Nouveau. > lspci 01:00.0 VGA compatible controller: NVIDIA Corporation NV17M [GeForce4 420 Go] (rev a3)
Created attachment 13598 [details] Xorg.0.log with nvidia390: Geforce 420 Go requires nvidia96.43 I knew it: The nvidia390 driver is for newer Nvidia cards only. It says that nvidia96.43 would be required. Not unlikely that driver won't compile with a current kernel, so nouveau is the only option. I have also added bug 31325 documenting an uninstall-fallacy of nvidia390.
Thank you for all your tests, which confirm that you have to use Nouveau. And that the exact nature of the problem varies with kernels. (In reply to Elmar Stellnberger from comment #42) > Originally filed for Mageia 8 and now confirmed and further tested on Mageia > 9 I think now the M9 ERRATA flag is justified. Changing 'hardware' to 32-bit until it gets reported also for x64. It could just be sensitive to that. (In reply to Elmar Stellnberger from comment #43) > Confirmed with kernel 6.1.1-desktop586-2.mga9. There was some notable > improvement for 6.1.0-desktop586 only in that the screen content was > preserved directly after resume, already before the X-server started to run > again. With 6.1.1 you get a distorted screen directly after resume which is > then fixed when the X-server continues to run. This rather implies that the problem sorts itself out, and all ends well. True?
Summary: i586: mesa doesn´t draw boxes correctly after resume from s2ram or suspend to disc, Nvidia Geforce4 420 Go => i586: mesa doesn´t draw boxes correctly after suspend/resume, Nvidia Geforce4 420 Go, nouveauHardware: All => i586Keywords: (none) => FOR_ERRATA9
No, there are two different issues here: a.) distortion supposedly of a glx initialization area: doesn´t draw boxes after resume b.) directly after resume the screen stays distorted until the X-server resumes. This is a minor and temporary issue that does not inhibit any functionality. It was already resolved with 6.1.0-desktop586 and is an issue which is completely different from this report. I just had no other space to report about it. - and it may be of concern here since apparently anyone has tinkered with the suspend support and done something well, but the code for it seems to have been disabled/removed again later on since there was no confirmation on the resolved issue.
I am unsure that either mesa or glx are involved here, since both seem to be concerned with 3D: "Mesa is an OpenGL 4.6 compatible 3D graphics library" and nothing for glx itself, but a couple of pkgs with it in their name. Given that other post-resume distortions happen, it would be interesting to see how these graphics test programs fare: glxspheres, glmark2. Recap of the essential: > distortion supposedly of a glx initialization area: > doesn´t draw boxes after resume These attachments best illustrate your problem: https://bugs.mageia.org/attachment.cgi?id=13546 before resume: background box of login screen is drawn correctly and https://bugs.mageia.org/attachment.cgi?id=13545 after resume: the background box of the login screen is not drawn What component is responsible? No choice but to assign this globally hoping that somebody will have an idea.
Assignee: bugsquad => pkg-bugsKeywords: UPSTREAM => (none)
In deed both programs glxspheres and glmark2 work well before and after suspend. It is only the mouse pointer and drawing boxes which get distorted.
Summary: i586: mesa doesn´t draw boxes correctly after suspend/resume, Nvidia Geforce4 420 Go, nouveau => i586: drawing boxes and mouse pointer distorted after suspend/resume, Nvidia Geforce4 420 Go, nouveau
It is not so much about drawing boxes, but more about which rectangular screen region gets shown; also: latest 6.1.1-desktop586-3.mga9 tested, whatever git-commit it is based on: https://gitlab.freedesktop.org/drm/nouveau/-/issues/194#note_1699827
CC: lewyssmith => (none)
confirmed with kernel 6.1.9-desktop586-2 (kernel-desktop586-6.1.9-2.mga9, 2023-02-04 05:41:59 AM), mesa-23.0.0-0.rc4.2.mga9
I have just tested kernel-desktop586-6.1.10-1.mga9 (2023-02-06 07:44:44PM) and s2ram got worse: After a while when normally the undistorted screen image comes back it now flashes to a pixel soup with white vertical lines and coloured strips in between. You can see it from a rectangular region where the mouse pointer should be. System seems to stop, then. Last known good was 6.1.9-desk586-2 from above.
Can you try on mga9 using drakx11 to select xorg modesetting?
Hi Morgan! I hope you don´t mind me having posted the response for you at https://gitlab.freedesktop.org/drm/nouveau/-/issues/194 . The modesetting driver does not work well enough due to DRM calls which can not even be avoided fully by 'nodrm' in xorg.conf (X crashing). Also drakx does not allow to select a video driver like modestting or vesa; it appears to use nouveau always (after you select GeForce 4 420 it returns to the main menu and there is nothing more at choice). It would thus be really classy if anyone from Mageia could assist or hint me in building Mesa for the Amber branch, if you don´t ship it with Mageia yourself (I suggested, it could at least be an install option for i686): The Mageia Cauldron and openSUSE Tumbleweed builds have failed with exit code!=0, but as far as I have seen without an error message (warnings not counted): https://build.opensuse.org/project/show/home:estellnb:mageiaupdtst The only thing I had to do to build for Amber (DRI support for P4 and graphics cards of similar age) was not executing the commands for the hw-video (%with_vdpau, see at the .spec-file) related packages by a conditional %if. It then built as well as before under Mageia 8. Since I have Mageia 9 on my i686 machine that was of little help for me though. For Cauldron and Tumbleweed I had to require a newer g++ to avoid some llvm-y errors but the conditional with %mgaversion (or %mgaver) seems not defined in the openSUSE Build Service for versions from mga9 on, so that this build target now remains unresolvable.
(In reply to Elmar Stellnberger from comment #54) > Hi Morgan! I hope you don´t mind me having posted the response for you at > https://gitlab.freedesktop.org/drm/nouveau/-/issues/194 For modesetting, from that gitlab thread: >> Can you try on mga9 using drakx11 to select xorg modesetting? > You can´t do that with drakx11. It gives no option to select a video driver, neither vesa, nor modesetting it just keeps to use nouveau after selecting Geforce 4 420 Go. In drakx11, after having clicked graphic card button, scroll down to bottom: Xorg, and under it you find a long list including both nouveau and modesetting. Choose modesetting there. --- (from comment #54) > it appears to use > nouveau always (after you select GeForce 4 420 it returns to the main menu > and there is nothing more at choice). hmmm... please when booted to desktop, start drakx11 from a terminal, so you can see messages in the terminal After having selected a nvidia card, there is usually a question to use proprietary driver, answer yes, go further, and the output shall show it is building the driver. But this is if we have not dropped the proprietary driver - Nvidia use to stop maintaining them too early... I guess yours is one abandoned by nvidia? https://wiki.mageia.org/en/Mageia_8_Release_Notes#Proprietary_NVIDIA_driver https://wiki.mageia.org/en/Mageia_9_Release_Notes#Proprietary_NVIDIA_driver
Created attachment 13819 [details] xorg.conf as produced by drakx11 In deed you can do that with drakx11! The resulting xorg.conf is virtually the same and X11 crashes at the same place (on login and when you launch pidgin) with similar backtrace. As argued some time before for mcc/package-source-selection I have an issue with the user interface here: If there is a button that says what video card is currently selected everyone will believe it to be for selecting the video card. Nobody (at least not me) would catch the idea to hit on searching to the very bottom for a software graphics driver selection if the right hardware is already marked; at least you don´t do that if it doesn´t say something like "(select(ed) graphics driver)" next to that button.
Created attachment 13820 [details] lxdm.log containing the two similar backtraces from to different X-crash incidents
It would also help to say "Nvidia driver, proprietary" instead of just "Nvidia" in the tree where "Geforce 4" is selected. Nvidia is then not understood as the manufacturer of the pci-card but as the author of the graphics driver. However that kind of a UI-fix would require to output a message like "no proprietary Nvidia driver provided for this card, selecting the open source nouveau driver, instead", otherwise people may be more happy about editing (or at least viewing) xorg.conf. If you don´t do that a novice would believe to be using the proprietary driver, then.
Yes, we could need more total manpower to improve and maintain a lot of things. And nvidia too apparently... and nouveau and modesetting developers...
Created attachment 13840 [details] Xorg.0.log with crash on launching pidgin, mesa-23.1.0-2.mga9 nothing apparently different with 6.3.2-desktop586-2.mga9, kernel-desktop586-latest-6.3.2-2.mga9.i586, Friday, 12 May, 2023 07:05:05 AM, Key ID b742fa8b80420f66, mesa-23.1.0-2.mga9, 11 May, 2023 03:51:53 AM, Key ID b742fa8b80420f66, x11-server-xorg-21.1.8-1.mga9, 04 April, 2023 06:03:00 PM, Key ID b742fa8b80420f66 & modesetting. As always you can find related results with nouveau and the same new setup at gitlab.freedesktop.org.
Created attachment 13841 [details] xorg.conf nodri, modesetting, mesa-23.1.0-2.mga9 - test
Created attachment 13842 [details] Xorg.0.log.xinit when you try to use xinit, mesa-23.1.0-2.mga9 Also the issue that you can not launch X with xinit from the console persists with mesa-23.1.0-2.mga9. I described earlier that you need to launch /usr/libexec/Xorg rather than /usr/bin/Xorg; just setting nodri in your xorg.conf does not help.
Created attachment 13843 [details] Xorg.0.log for Mesa/amber Just tested things with nouveau_vieux/DRI from Mesa-Amber (this package: https://build.opensuse.org/package/show/home:estellnb:mageiaupdtst/mesa, bug 31921) but the issue with the modesetting driver seems unaffected (as the issue of bug 31227, https://gitlab.freedesktop.org/drm/nouveau/-/issues/194). The backtrace looks virtually the same for me. Should I open an issue here at the Mageia bugzilla or at gitlab.freedesktop?
Created attachment 13844 [details] Xorg.0.log with Mesa-amber including DRI-backtrace Oops, that was an Amber-log without backtrace, here comes the right one.
Removing FOR_ERRATA9 because I find no substantial *general* enough symptom or remedy. Maybe we can add some note in https://wiki.mageia.org/en/Setup_the_graphical_server If you can make a clear text on symptom / remedy, please suggest.