@hui It does as it has the same comment I quoted in the latest release
@Malcolm: OK, thanks for the data, so, not sure if that is âapples to applesâ in that my card is GTX780 & my machine is '12??
Now the âwild cardâ is that my '12 Mini is able to run with 6.13.5 and revive the display . . . same i7 cpu, etc.
@panorain: Well, that might be the next step, run a fresh install . . . see if things clear up or stay turbid.
@hui: Thanks for that, I think back at the beginning of the thread Malcolm or somebody mentioned â570â . . . but I donât think my card gets me there, Iâm locked at G05??? Proprietary has historically thrown me down the rabbit hole so many times, that I have no need to play with that. Nouveau has been the âbestâ but is not immune to getting pulled into the nvidia vortex. I posted on their âlinuxâ sub-forum a few years back about my 780 having problems and the guy there said, âWe canât waste our time trying to keep up with linux or support OLD cards.â So, he didnât seem to be too concerned about my personal experience trying to keep nvidia card working. I do like they way the card renders the GUI . . . but, not a gamer . . . simple is OK.
Possibly the ultimate solution will be to switch out the graphics card for something that is comfortable with the fast changing environment of linux??
@non_space yes, your driver needs to be the G05 version or 470⊠nothing newer can be used.
For those at home keeping score, so far the newest kernel that will revive the display in TW is 6.12.6 for consistent operation.
In direct comparison in the same machine today is Manjaro day. Their kernel app showed a 6.14 âexperimentalâ . . . a 6.13.0-3-rt5, and a 6.13.5 option.
I installed a bunch of kernels and tested them, the 6.14 did not revive, but the 6.13.0-3-rt5 does. Their 6.12.17 & TWs version of the same name, do not. I installed Manjaroâs 6.12.16-rt9 to see if just under 6.12.17 will work . . . ??
But, then, it is using 6.13xxxx with nouveau . . . working so far.
Might be interesting to try a fresh install of TW and see if it gets up to 6.13.5 like my Mini now seems to be running.
Alrighty, downloaded the online TW installer and ran a fresh install . . . . It installed the 6.13.6-1-default kernel. It ran well, until I suspended the machine. A couple minutes later . . . same problem, in the fresh new install.
Back in the old TW partition with 6âŠ12.6 to type this out.
@non_space So what do the logs indicate journalctl -b -1 -r
to see the last entries from the previous bootâŠ
@non_space also show output from cat /proc/driver/nvidia/params | sort
These lines were repeated numerous times in the output, I copied the last section of it, which seems to be the consensus output . . . . Since the install is brand new I have not yet adjusted terminal prefs to âunlimited linesâ or what have you, but it seemed to show the same basic data repeatedly.
Mar 14 17:31:26 no-pc.home kernel: PM: suspend entry (deep)
Mar 14 17:31:26 no-pc.home systemd-sleep[8722]: Performing sleep operation 'suspend'...
Mar 14 17:31:26 no-pc.home systemd-sleep[8724]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.>
Mar 14 17:31:26 no-pc.home systemd-sleep[8722]: Successfully froze unit 'user.slice'.
Mar 14 17:31:26 no-pc.home systemd[1]: user@1000.service: Unit now frozen-by-parent.
Mar 14 17:31:26 no-pc.home systemd[1]: user-1000.slice: Unit now frozen-by-parent.
Mar 14 17:31:26 no-pc.home systemd[1]: user.slice: Unit now frozen.
Mar 14 17:31:26 no-pc.home systemd[1]: session-3.scope: Unit now frozen-by-parent.
Mar 14 17:31:26 no-pc.home systemd[1]: Starting System Suspend...
Mar 14 17:31:26 no-pc.home systemd[1]: Reached target Sleep.
Mar 14 17:31:26 no-pc.home NetworkManager[1194]: <info> [1741998686.6089] manager: NetworkManager stat>
Mar 14 17:31:26 no-pc.home NetworkManager[1194]: <info> [1741998686.6085] manager: sleep: sleep reques>
Mar 14 17:31:26 no-pc.home ModemManager[1178]: <msg> [sleep-monitor-systemd] system is about to suspend
Mar 14 17:31:26 no-pc.home systemd-logind[1077]: The system will suspend now!
Mar 14 17:31:23 no-pc.home systemd[1]: Started PackageKit Daemon.
Mar 14 17:31:23 no-pc.home systemd[1]: Reached target Network is Online.
Mar 14 17:31:23 no-pc.home systemd[1]: Finished Network Manager Wait Online.
Mar 14 17:31:23 no-pc.home PackageKit[8692]: daemon start
Mar 14 17:31:23 no-pc.home systemd[1]: Starting PackageKit Daemon...
Mar 14 17:31:23 no-pc.home systemd[1]: Starting Network Manager Wait Online...
Mar 14 17:31:23 no-pc.home systemd[1911]: Started Xfce configuration service.
Mar 14 17:31:23 no-pc.home systemd[1911]: Starting Xfce configuration service...
Mar 14 17:28:29 no-pc.home rtkit-daemon[2048]: Successfully made thread 8370 of process 8027 owned by '>
Mar 14 17:27:34 no-pc.home smartd[1070]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature>
Mar 14 17:27:34 no-pc.home smartd[1070]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Tem>
Mar 14 17:27:34 no-pc.home smartd[1070]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read>
Mar 14 17:20:58 no-pc.home rtkit-daemon[2048]: Successfully made thread 7954 of process 7575 owned by '>
Mar 14 17:20:17 no-pc.home kernel: perf: interrupt took too long (4367 > 4288), lowering kernel.perf_ev>
Mar 14 17:14:20 no-pc.home kernel: perf: interrupt took too long (3431 > 3288), lowering kernel.perf_ev>
Mar 14 17:14:18 no-pc.home systemd[1911]: Started Xfce configuration service.
Mar 14 17:14:18 no-pc.home systemd[1911]: Starting Xfce configuration service...
Mar 14 17:12:05 no-pc.home kernel: perf: interrupt took too long (2631 > 2500), lowering kernel.perf_ev>
Mar 14 17:11:50 no-pc.home systemd[1]: Finished Cleanup of Temporary Directories.
cat: /proc/driver/nvidia/params: No such file or directory
There was no question in the installer for âhow would you like to handle video for your nvidia card?â
lsmod shows ânouveauâ all over the place.
Ran both commands in the Older TW and same outcome on the ânvidiaâ question.
For comparisonâs sake I tried to run the âjournalctlâ command in the OLDer TW install, but it keeps going back to the last shut down, even though I rebooted several times in and out of kernel 6.12.6 and into the newer 6.13.5 and suspended the machine . . . it still shows âshutting downâ whereas in the NEW TW install it showed the âsuspendâ data posted above.
Of interest is that 6.13.5 revived from brief suspends more than one time, I didnât remove it, but I donât recall that it âworkedâ like that previously. There were some zypper upgrades recentlly and now I see again likely >2K packages are waiting in zypper to be run through . . . I hesitated before, but in the world of rolling distros the only way to roll is âforward.â Dang the torpedoes and so forth . . . maybe the âfixâ will be in there?? TBD.
After the latest 2048± package ugrade, there was a new kernel, 6.13.6 installed. On reboot I selected the newest kernel and did a few moves, then suspended the machine for a couple hours. When I got back, it did revive the display, not quickly, but it did it. Then I suspended/revived two more times, same, albeit slowly. The fourth time I suspended and tried to revive, it did not. That puts it in the âgrey areaâ as sometimes I suspend more often than that and sometimes not.
Had to shut down with the power button. When I rebooted I went to the 6.13.5 kernel and I ran the suggested âjournalctl xxxxâ command, and in this version of TW I have âunlimited linesâ pref and it came back with 2122 lines within a few minutes of the total data showing. Iâm guessing that the âbottomâ lines are the actual âstartâ point, it shows selecting the 6.13.6 kernel and then runs thru the dmesg stuff and then gets up into various repeated data . . . which might be the three or four âsuspendsâ ???
There were a few issues reported, but nothing that showed âkernel panicâ or anything âdefinitiveâ . . . . Itâs â63 pagesâ of data for the 2122 lines, I copy/pasted it into an LO .txt file and a Featherpad plain txt file . . . . None of the red lines in the console showed up in those docs.
Here are the top or possibly last lines of the report, which had been repeated with black space between them for numerous times. Just showing that the system is âsuspendingâ but then did not âstart time serviceâ as it did not then revive the display and I shut down with the power button.
Mar 15 15:53:50 no.home kernel: PM: suspend entry (deep)
Mar 15 15:53:50 no.home systemd-sleep[3091]: Performing sleep opera>
Mar 15 15:53:50 no.home systemd-sleep[3093]: INFO: Skip running /us>
Mar 15 15:53:50 no.home systemd-sleep[3091]: Successfully froze uni>
Mar 15 15:53:50 no.home systemd[1]: user.slice: Unit now frozen.
Mar 15 15:53:50 no.home systemd[1]: user-1000.slice: Unit now froze>
Mar 15 15:53:50 no.home systemd[1]: session-3.scope: Unit now froze>
Mar 15 15:53:50 no.home systemd[1]: user@1000.service: Unit now fro>
Mar 15 15:53:50 no.home systemd[1]: Starting System Suspend...
Mar 15 15:53:50 no.home systemd[1]: Reached target Sleep.
Mar 15 15:53:50 no.home NetworkManager[1238]: <info> [1742079230.3>
Mar 15 15:53:50 no.home kernel: b43-phy0: Loading firmware version >
Mar 15 15:53:50 no.home NetworkManager[1238]: <info> [1742079230.0>
Mar 15 15:53:50 no.home NetworkManager[1238]: <info> [1742079230.0>
Mar 15 15:53:50 no.home NetworkManager[1238]: <info> [1742079230.0>
Mar 15 15:53:50 no.home ModemManager[1228]: <msg> [sleep-monitor-sy>
Mar 15 15:53:50 no.home systemd-logind[1122]: The system will suspe>
Mar 15 15:53:47 no.home mate-session-save[3064]: Authorization requ>
Mar 15 15:53:47 no.home mate-session-save[3064]: Authorization requ>
Mar 15 15:53:37 no.home sudo[2936]: pam_unix(sudo:session): session>
Mar 15 15:51:36 no.home deja-dup[2944]: Authorization required, but>
Mar 15 15:51:35 no.home systemd[1894]: Started dbus-:1.2-org.gnome.>
Mar 15 15:51:35 no.home systemd[1894]: Created slice Slice /app/dbu>
@non_space You need to show the output from an openSUSE working kernel and the output from an openSUSE non-working kernel from cat /proc/driver/nvidia/params | sort
Alrighty, well, the 6.13xxx options seem to be intermittent . . . sometimes they work to revive the display and sometimes not.
Iâm now booted in the old TW install running the consistent 6.12.6 kernel and it brings the same results as posted above . . . .
cat: /proc/driver/nvidia/params: No such file or directory
None of them seem to be showing anything from that command.
So the nvidia driver isnât running?
It never has been, it has always been ânouveauâ as the driver, but seems like nouveau uses âG05â?? There was a point a few months back where ânvidiaâ blacklisted nouveau and tried to install G06 resulting in the same problem, had to unblacklist nouveau and lock the G05 . . . as nouveau needs something in the nvidia package?
Actually, in checking for âG05â in my older TW install, that package doesnât show up in YaST, only the âG06â package does, which has been locked out.
There is a âkernel-firmware-nvidiaâ and a âlibdrm_nouveauâ . . . so I guess the G05 package was removed by zypper or by me back when nvidia had blacklisted nouveau, causing this same non-revival from suspend problem??
G05 is showing in the new TW installs YaST as an option to install, but is not installed there.
@non_space So change nvidia for nouveau /proc/driver/nouveau/params | sort
or systool -vm nouveau
need to see what is set especially runpm
and NVreg_RegistryDwords
parameters.
Those commands didnât seem to pan out? I am booted in the older TW partition this AM, I first ran the command as sudo, then I ran it w/o, then as root. The systool option wanted sysutils to be installed, ran that, ânothing foundâ:
~> /proc/driver/nouveau/params | sort
bash: /proc/driver/nouveau/params: No such file or directory
-pc:~> su
Password:
# /proc/driver/nouveau/params | sort
bash: /proc/driver/nouveau/params: No such file or directory
no # systool -vm nouveau
The program 'systool' can be found in the following package:
* sysfsutils [ path: /usr/bin/systool, repository: download.opensuse.org-oss ]
Try installing with:
sudo zypper install sysfsutils
Reading installed packages...
'sysfutils' not found in package names. Trying capabilities.
No provider of 'sysfutils' found.
Resolving package dependencies...
Nothing to do.
You spelled the package name wrong. That is why it is not found by zypper.
O jeez . . . I had the previous command in the clipboard so indeed I did type that out, as I thought it was spelled. Error piling onto error . . . . : - 0
# systool -vm nouveau
Module = "nouveau"
Attributes:
coresize = "3612672"
initsize = "0"
initstate = "live"
refcnt = "6"
srcversion = "15E2E81EE8FC767FC92B122"
taint = ""
uevent = <store method only>
Parameters:
NVreg_RegistryDwords= "(null)"
atomic = "0"
config = 28 6e 75 6c 6c 29 0a
debug = "(null)"
duallink = "1"
hdmimhz = "0"
ignorelid = "0"
kms_vram_pushbuf = "-1"
modeset = "-1"
mst = "1"
noaccel = "0"
runpm = "-1"
tv_disable = "0"
tv_norm = "(null)"
vram_pushbuf = "0"
Sections:
.altinstr_replacement= "0xffffffffc093819c"
.altinstructions = "0xffffffffc0a22000"
.bss = "0xffffffffc0963d80"
.call_sites = "0xffffffffc0af8c88"
.data..once = "0xffffffffc0963650"
.data..read_mostly = "0xffffffffc0963698"
.data = "0xffffffffc0944ae0"
.exit.data = "0xffffffffc0963658"
.exit.text = "0xffffffffc09381e0"
.gnu.linkonce.this_module= "0xffffffffc0963840"
.ibt_endbr_seal = "0xffffffffc0b0e9f8"
.init.data = "0xffffffffc0b74000"
.init.text = "0xffffffffc062e000"
.note.Linux = "0xffffffffc0b72c34"
.note.gnu.build-id = "0xffffffffc0b72c10"
.note.gnu.property = "0xffffffffc0b72bd0"
.orc_header = "0xffffffffc0b72c64"
.orc_unwind = "0xffffffffc0b0fb08"
.orc_unwind_ip = "0xffffffffc0b4b1e4"
.printk_index = "0xffffffffc095d628"
.retpoline_sites = "0xffffffffc0af2030"
.return_sites = "0xffffffffc0af5268"
.rodata = "0xffffffffc0a220c0"
.rodata.cst2 = "0xffffffffc0ada8f4"
.rodata.str1.1 = "0xffffffffc0acbf00"
.rodata.str1.8 = "0xffffffffc0ada908"
.smp_locks = "0xffffffffc0af1c08"
.static_call_sites = "0xffffffffc0963710"
.strtab = "0xffffffffc0be5e40"
.symtab = "0xffffffffc0b74008"
.text = "0xffffffffc0800000"
.text.unlikely = "0xffffffffc0923b20"
__bug_table = "0xffffffffc093a000"
__dyndbg = "0xffffffffc09636a0"
__dyndbg_classes = "0xffffffffc0963660"
__jump_table = "0xffffffffc062c000"
__mcount_loc = "0xffffffffc0ac3bd0"
__param = "0xffffffffc0af1dd8"
__patchable_function_entries= "0xffffffffc093c758"