After zypper dup in TW for 2082 packages today, machine does not revive from suspend?

@hui It does as it has the same comment I quoted in the latest release :wink:

@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.

1 Like

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


1 Like

@non_space also show output from cat /proc/driver/nvidia/params | sort

1 Like

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

1 Like

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.

1 Like

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"