@non_space so nothing else, your suspending to ram then as no resume entry and no other options? No mitigations etc?
And nouveau blacklisted? fgrep -r nouveau /etc/modprobe.d/
I did do a resume from suspend move while checking the system via ssh, nothing seemed to error out there . . . but not sure what you mean by “options” and “mitigations” . . . . Since I’m a multi-booter I have enough stuff to do to keep 7 installs running as box stock installations. Only doing stuff to keep the system going . . . .
I don’t want nouveau blacklisted . . . I prefer it to be “the driver” . . . is that fgrep command just something to just check the status of nouveau?? The “-r” makes me nervous.
I’m now wondering if some recent error in the system or kernel upgrade has done something so that it “solved” the problem by “modesetting” itself???
I ran that " ```
fgrep -r nouveau /etc/modprobe.d/
And the cursor just comes back, so I'm assuming that it "did" something, like "blacklist" nouveau?? But I want nouveau to be the video driver . . . .@non_space the -r is for recursive (fgrep --help), so nouveau is not blacklisted then…
So, if you add modeset=0 to the kernel boot options via YaST Bootloader and see if that kicks in nouveau.
With no mitigations on, what does the output from lscpu show you in the output for Vulnerabilities:?
1 Like
Do you mean in Kernel parameters > optional kernel command line parameter??
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushe
s, SMT vulnerable
Mds: Vulnerable: Clear CPU buffers attempted, no microcode;
SMT vulnerable
Meltdown: Mitigation; PTI
Mmio stale data: Unknown: No mitigations
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer
sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIB
P conditional, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected
Do you mean in Kernel parameters > optional kernel command line parameter?? Trying to add that “modeset=0” into the boot params via YaSt errored out "EFI variables are not supported on this system, efibootmgr failed to register the boot entry, no such file or directory. I ran “sudo update-bootloader” after that w/o error. I’ll try a reboot just for kicks.
@non_space it’s sounds like you have some fundamental install issues if that is happening… or not using the default grub bootloader or is it chain loaded?
Yes, optional kernel command line parameter
CPU output looks fine… however /proc/cmdline output should show mitigations=auto?
I have the 7 systems listed in grub . . . TW is the “grub controller” system, don’t know what “chain loaded” is?? There were some issues with efibootmgr awile back when I had a few more systems installed, cut them down to 7 and it seemed to clean up.
Just about out of time for this machine today . . . what are you saying, that I should "nano /proc/cmdline and add “mitigations=auto” as a line??
¨Just the modeset one" is still a bit cryptic . . . what exactly does that mean?
Today is Gecko rolling day, so a stack on TW . . . so I ran, and here I believe it is as it should be, nouveau is the driver:
inxi -Gxxz
Graphics:
Device-1: NVIDIA GK110 [GeForce GTX 780] vendor: eVga.com. driver: nouveau
v: kernel arch: Kepler pcie: speed: 2.5 GT/s lanes: 16 ports:
active: DVI-I-1 empty: DP-1,DVI-D-1,HDMI-A-1 bus-ID: 05:00.0
chip-ID: 10de:1004 temp: 35.0 C
Display: x11 server: X.org v: 1.21.1.8 compositor: marco v: 1.26.2 driver:
X: loaded: nouveau unloaded: fbdev,modesetting failed: nv
alternate: nvidia,vesa dri: nouveau gpu: nouveau display-ID: :1 screens: 1
Screen-1: 0 s-res: 1280x1024
Monitor-1: DVI-I-1 model: ViewSonic VA951S res: 1280x1024 dpi: 86
diag: 482mm (19")
API: OpenGL v: 4.3 Mesa 23.1.7 renderer: NVF0 direct-render: Yes
@non_space so nouveau is back? Or is this a different release?
If it’s different, can we please stick with Tumbleweed, I’m not interested in third party releases.
Different release, as mentioned . . . Gecko stack on TW . . . today is Gecko rolling day. Iḿ just showing it as a comparo to what showed on the straight TW, wherein somehow nouveau was aced out of its job, messing up log in and suspend times. As of last night the problem continues on the TW install.
I have the benefit of being able to see how different distros are running on the same machine, maintained in the same way, via zypper dup -l and so forth. Everybody else is running fine.
I wasn´t clear on understanding where I could nano and add ẗhe modeset one"data, since it errored out in the YaSt Bootloader method?? Is there another way to try to get nouveau operational in TW??
Following up . . . there was some issue with the G06-nvidia package a few months back, that caused some problems for my older 780 card . . . . In filing another bug report I did see that there was a bug report or reports dealing with that, I had G05 locked and loaded, but somehow zypper flipped me up to G06 and that required some effort to get something going again??
Perhaps that is when some ¨modesetting"took place?? Still, this recent slowness issue just showed up in what is now a couple weeks back . . . .
@non_space So could still be something lurking from the nvidia install
If you run as root user;
lsinitrd | grep nouveau
It there any output?
For the modeset option, you add via YaST Bootmanager under the Kernel Parameters tab.
You had mentioned this a few posts up in the thread, this is what I was asking about, “should I nano that into that file?”
Thanks for the reply, I would not know what happened “under the hood” with that G06 issue . . . guess it took a while for it to bubble up in an overt manner. I’ll run that command tomorrow and check it for output.
As far as that “modeset=0” option via YaST, as posted above that would not go through, citing an “EFI problem” . . . data posted above. I took a screenshot of the error if more of the report is needed. I took the “modeset=0” out of the kernel options bar and then ran “sudo update-bootloader” and on reboot TW was . . . slowly booted.
Once booted now it seems like apps are launching OK, it’s when I want to suspend that the “mate-session” applet launches . . . spinning beachball cursor . . . applet disappears . . . a few more seconds go by . . . and then, the “suspend” or “shut down” window opens and I can then do that . . . . Which usually I want that to be “fast” rather than now having a “Stumbleweed” system . . . to coin a phrase. : - ))))
# lsinitrd | grep nouveau
drwxr-xr-x 2 root root 0 Sep 15 11:29 usr/lib/modules/6.5.3-1-default/kernel/drivers/gpu/drm/nouveau
-rw-r--r-- 1 root root 1321306 Sep 14 09:15 usr/lib/modules/6.5.3-1-default/kernel/drivers/gpu/drm/nouveau/nouveau.ko.zst
Have to amend the previous, “apps launch OK” comment . . . in this case launching the terminal app was the same as the suspend operation . . . .
@non_space So that looks fine, it’s not blacklisted, but present…
So you have updated to the latest snapshot and kernel 6.5.4?
What is the output now from;
cat /proc/cmdline
inxi -SGxz
Yes, ran the zypper dup -l for 190 package upgrades, after posting the “lsinitrd” data, which includes 6.5.4.1 kernel. On cold boot after shutting down, I would say that the slowness problem has survived . . . . inxi data still seems to show “modesetting,” but, what is interesting is the “modeset=0” data made it into the /proc/cmdline ??? YaSt errored out on that, and I didn’t nano it in, etc???
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.4-1-default root=UUID=929e9949-2d18-424c-be4a-80166827335b modeset=0
no:~ # inxi -SGxz
System:
Kernel: 6.5.4-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
Desktop: MATE v: 1.26.1 Distro: openSUSE Tumbleweed 20230921
Graphics:
Device-1: NVIDIA GK110 [GeForce GTX 780] vendor: eVga.com. driver: nouveau
v: kernel arch: Kepler bus-ID: 05:00.0 temp: 41.0 C
Display: x11 server: X.org v: 1.21.1.8 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: zink gpu: nouveau resolution: 1280x1024~60Hz
API: OpenGL v: 4.5 Mesa 23.1.7 renderer: llvmpipe (LLVM 16.0.6 128 bits)
direct-render: Yes
This is one of the bug reports on G06 deal that I have tabbed in my browser:
It’s there, but really have no idea about the modesetting… @mrmazda may have some advice.
If you remove the modeset=0 what does the output show…