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

English Open Chat
41

I have a nvidia card and multi-display setup. I already had the occasional issue of displays not reviving from sleep, but after the dup it’s 100% of the time.

Waiting around doesn’t seem to help, but pressing Esc can nudge the displays to wakeup after the computer is already up. It’s still not usable without rebooting because plasmashell will have crashed and restarted, and everything is glitchy and lagging, so that’s more like a desperate measure to save whatever you were doing and reboot properly.

1 Like
42

Hmm . . . seems like there is a “bug” going around. Same question to you, using the proprietary drivers or nouveau or possibly “default” drivers??

There is a bug report, in which it was suggested to “try booting with nomodeset” . . . but I haven’t done that in many years, so I have yet to try it.

Seems like since I posted this thread I have perhaps 4 new kernel upgrades, as the working kernel has again been pushed off the grub list . . . none of them seemed to have fixed the problem . . . maybe pushed it around a bit.

It’s an"old" problem that keeps showing up in new variation . . . .

43

@non_space old hardware, intel support dropped, nvidia support dropped etc… Times move on…

44

Indeed they do. But, largely only in my openSUSE installs . . . . So does that mean that openSUSE is decidedly “not supporting” hardware older than what, ten years . . . & intel cpus are dropped?? I know from experience that nvidia does not keep pace with bleeding edge upgrades like TW in their proprietary drivers . . . nor do they support “old cards,” . . . but now nouveau is also dropping out on “the old”??

There has been more support provided in the forum on this issue in the not too distant past . . . seems like now “washing the hands on it”??

The question asked and not answered is, "why doesn’t zypper recognize that upgrading the system will break basic function, of itself, and just provide an error message saying, “This upgrade will break basic function, we suggest you lock the kernel where it is?”

Based upon a previous discussion with you in the previous iteration of this problem you suggested locking the system at G05??? which I did and then that problem was resolved . . . why isn’t zypper doing a better job at seeing the “dependency” problem and just blithely upgrading into dysfunction?

Of note, this problem did occur in another rolling distro that I am running on this ancient machine, Manjaro, also running similar range of kernels . . . so far resolved by rolling back in kernel. I also have Manjaro in newer version on another new to me but ancient '12 mac Mini . . . which is running the latest 6.13 spec kernel . . . it doesn’t have an nvidia card and it revives fine. Seemingly pointing to a problem in TW with nouveau?? So, “support” is extant for an Intel cpu from '12, but not on my same year, Mac Pro?

I have 5 other linux systems running various new and older kernels, reviving from suspend just fine . . . just the openSUSE installs coming up lame.

Takashi, on the bug report says, “reviving from suspend is complicated,” and yet, other systems on the same machine seem to get it done. Forum answer, “Old hardware, move along, plz.”??? 13 year old machines, it’s not like 20 . . . .

45

Well it’s not openSUSE, it’s upstream… for Nvidia anything less that Turing is now considered legacy, for Intel anything less that 12th Gen is now considered legacy, for Leap 16.0 only CPU v2+ support. There is a legacy opencl for intel being worked on.

I have older Intel hardware (HP 11 Stream) running MicroOS and Hyprland, it works fine with suspend/hibernation etc.

I’m in the process of replacing my monitors here for ones that have DP ports as they work better with Wayland…

Optimus systems have always been an issue for folks…

46

OK . . . that is the problem with “technology,” the pace is fast . . . leaving the old to their own devices.

I believe at one point I had to check my cpu for “v” and I think it is “v2” . . . so when you say “v2+” doesn’t that mean “v2” is supported?

I tried a few commands I found online, didn’t seem to bring up anything except one pplace where it had a “v1” and some data and next line, “v2” and some data. ??? model name : Intel(R) Xeon(R) CPU W3565 @ 3.20GHz

This machine does what I need it to do, I would consider moving up the cpu to something “newer” or again upgrading the GPU . . . perhaps to something other than the finicky but visually tidy, nvidia brand . . . .

A box is a box . . . basic stuff . . . posting questions on linux forums about how to keep ancient hardware working . . . etc.

47

@non_space the command to run is /lib64/ld-linux-x86-64.so.2 --help

1 Like
48

So run as “user” w/o sudo is what I did run, and a bunch of instructional “man” data with this at the bottom:

This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib/x86_64-linux-gnu (system search path)
  /usr/lib/x86_64-linux-gnu (system search path)
  /lib (system search path)
  /usr/lib (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3
  x86-64-v2 (supported, searched)

Does that indicate “v2” only? Or, “v3 & v4” are also possible??

[edit] Realizing that I am running Sid today, so that data is from Sid iteration . . . should be the same cpu, right? [/edit]

49

@non_space just v2 is supported…

1 Like
50

Running on stems and seeds here today . . . so v2 is eligible for Leap 16, correct? I am considering that with Leap 15.6 seemingly degenerating worse than TW is, that upgrading to 16 might be more amusing than luffing along with 15.6 . . . which is offering less “support” than the newer version . . . . Have to figure out how to edit the repos to get that done.

I have yet to try MicroOS out, which I was thinking is more for VM than for bare metal installs???

51

@non_space Yes, you will be fine with Leap 16.0 as best it can be…

1 Like
52

So this brings up the “display” side of things . . . which I am running a fairly “old” ViewSonic display that has VGA ports . . . connected via cable that is VGA to HDMI port on the two '12 machines . . . . For some reason I had to switch the cable connected to the older to me '12 Mac Pro, in order for the new to me '12 Mac Mini display to work . . . . And that resulted in a re-sizing of the desktop . . . but both machines are plugged into the display, the one Mini seems fine with 6.13 kernel in Manjaro, the Mac Pro has problems with openSUSE installs . . . .

Would it make any difference to openSUSE if the display was a newer item that would be HDMI to HDMI?? Not sure if the Mac Pro has “DP” or either of them . . . but I do know that VGA isn’t state of the art and might be “legacy” and that might be an easy upgrade to bring a little more life to the ancient hardware??

53

@non_space I have found it’s better to match port type to port type. If HDMI and only have a VGA monitor I use HDMI to VGA converters…

54

So that may be an answer, seemingly you prefer matching port types, but if they don’t match then you go with that?

But the question about whether upgrading the display to HDMI would make a difference to the revival from suspend question . . . was seemingly not touched.

So far after numerous kernel upgrades the non-revival problem in TW & Leap is still happening . . . and the Leap advanced options listing in openSUSE’s osprober grub, show all of the same data . . . some of them booting to kernel panic . . . . Is this a ancient “hardware” problem that could be adjusted via a newer display, or a “software” problem where certain packages are not coordinating to provide video after suspending?? The “software” side of things has been where this problem has been created and then resolved, looking at numerous forums threads that have been posted here on the forum . . . .

55

@non_space if you can always match the outputs gpus/monitors then should have a better experience… But Desktop Environments are checking the likes of EDID info to set things up, that’s why these days even with Nvidia and on X11, there should be no need for any configuration files…

1 Like
56

Alrighty, back in TW today, ran the zypper dup, saw that 6.13.2 kernel was listed for installation, which did sort of work in Leap . . . ran it through.

First suspend of the day it did revive the display, not quickly, but it worked. Suspended the machine again and second time was NOT the charm. Machine starts up, display stays black.

Shut down via power button, back in 6.13.2 to type this out. Everything else seems to be working fine . . . only the display gets “lost” after suspending.

57

Hi, I have had a similar with intermittent problems with suspend from sleep with Nvidia, although I have a fairly newish PC (2 years old) & a modern LG widescreen + older monitor. Having got fed up / frustrated with it I tried two things.

  1. The best solution f or me was to switch my cables to the on board AMD chip with built in graphics & cut out the Nvidia card all together. This means a switch from Display port + hdmi to hdmi + VGA but solves the problem & works really well with the power button mapped to suspend on a single press. SO suggesting the problem lies with Nvidia / drivers, although perhaps I didn’t have the right ones of enough of those installed? This is fine for me as I don’t do gaming & don’t really need the high powered graphics. It sound like you have older hardware including VGA, although maybe your onboard graphics might not be up to your needs or have enough ports perhaps?
  2. The other thing I tied was rolling back the 570 driver to the stable 550 drivers which worked before. However I did this via YAST by ticking a box in the Nvidia repo & this gave me some problems afterwards so I reverted to 570 and am back on my onboard card again. However someone else in another thread who had problems with an external monitor being black managed the roll back successfully via zypper and it solved their problem, so maybe that could work for you? I’ve not had the courage to try it again given the problems I had the first time. See the last few posts on this thread for the commands & how to lock it in etc. https://forums.opensuse.org/t/how-can-i-get-my-second-monitor-to-work-with-proprietary-nvidia-drivers/182602
  3. Hope this might help you to get it resolved.
1 Like
58

Thanks for posting over here. So, usually the proprietary nvidia drivers are involved in generic problems that show up, so if, as you mention, you don’t do gaming, then likely “nouveau” driver would likely be better over the long haul . . . .

For my nvidia card the drivers are “G05” and maybe “G06” but the 6 iteration created problems, and possibly “blacklisted nouveau” . . . took some messing to get that straight.

I, in my personal mind, see the problem connected to “the kernel” . . . as in TW the system was running and reviving the display properly in 6.12.6 . . . but in ensuing kernels offered, appeared and wasn’t fixed in the kernels after that . . . now somewhere around 6.13.2. Bit of a pain, because I had edited the /etc/zypp/zypp.conf??? file, I think mentioned above, to allow 4 kernels, and did not lock the 6.12.6 kernel . . . and it is again gone.

Later today I will try to get that kernel back, and that should give me a working revival on the display. I would look at the actual display connections if it happened in all 7 of my linux installs, but it is exclusive to the openSUSE iterations. Each of my installs are running variations of kernel, so a bit hard to nail it down . . . but does seem like from the Factory list-serve that the 6.13 xxx range has some . . . um . . . “bugs”???

59

Back in TW, trying to get back to the 6.12.6 kernel, while trying to get a retro 6.12.10 kernel installed . . . which didn’t go through due to dependency problems, I ran a zypper dup and then showed a new 6.13.3 kernel option . . . ran it through, updated grub and cold booted into the newest kernel . . . ran OK, suspended, and on the third day . . . it did not rise again.

Machine spins up, display remains black. Now trying to add capacity for another kernel and trying to get the 6.12.6 kernel installed and have it be “running” . . . see if I can retro time travel to again have a functioning TW system . . . . Finger’s crossed, etc.

60

OK . . . thanks to an assist from @mrmazda I used the Slow Roll kernel resources to get the 6.12.6 kernel and zypper it in . . . and it seems to be working to revive the display . . . .

Where so far the entire 6.13xxx series does not.

1 Like