Ran the large 2082 package upgrade today . . . shut down after that and cold booted back to TW . . . all seemed fine. I logged out and back in and then suspended the '12 Mac Pro. When I came back to revive the machine started up but the display remains black.
Used the power button to shut down and rebooted to TW. This has been a recurring problem over the years, lately having to do with some nvidia package that blacklists nouveau. I checked lsmod and “nouveau” is showing all over the place. I ran zypper up again and it brought in another 164 packages ran that through, did the same procedure, shut down, rebooted, logged out/in and suspended it. The first time I clicked a key it came back right away . . . did some stuff. Then suspended from the GUI and did some other stuff. Again, no revival from suspend. Had to use the power button to get back to TW GUI.
Other problem that caused this issue was something in sddm . . . I did see “sddm” listed iin the several thousand package upgrade list . . . but can’t recall if it was “we had to add ‘sddm-qt6’” to get revival back . . . so, not exactly sure if it was a “sddm-qt7” package in todays upgrades that might not be jiving with my machine . . . has non-OEM Nvidia 780 graphics card. All was running well in TW before this latest upgrade . . . also have 6 other linux installs on the same machine . . . suspend revival working fine, etc.
sudo update-alternatives --config default-displaymanager
There are 4 choices for the alternative default-displaymanager (providing /usr/lib/X11/displaymanagers/default-displaymanager).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/lib/X11/displaymanagers/sddm 25 auto mode
1 /usr/lib/X11/displaymanagers/console 5 manual mode
2 /usr/lib/X11/displaymanagers/lightdm 15 manual mode
3 /usr/lib/X11/displaymanagers/sddm 25 manual mode
4 /usr/lib/X11/displaymanagers/xdm 10 manual mode
Press <enter> to keep the current choice[*], or type selection number:
Sorry for the repeat, trying to add it to my first post errored out, then said, “time expired” but then seems to have added it??
Hmm . . . ??? Had to go to work, so I’m away from that machine now. Which driver is that for?? How would I search that?? Just type “470.256.02” in the console??
OK . . . well, I’m not using proprietary drivers . . . I’m using nouveau. But there have been times when the zypper upgrade has switched me over to Nvidia, without asking me. But, as mentioned, checking lsmod shows “nouveau” all over the place . . . . ???
I have tried to use Nvidia drivers way back, but that causes problems more often with upgrades, so I switched to nouveau. Don’t know enough to know if that still uses nvidia drivers or not??
Back atcha with the requested data when I get back to that machine . . . . Be awhile.
Hi, if you are using openSUSE Tumbleweed (which your post title states), the preferred method to pull in packages to upgrade TW is zypper dup not zypper up. This may have caused some issues. I am unsure of which issues though exactly.
you may be able to track down some clues to the suspend problem by viewing dmesg and journal output.
Ran a zypper up in Leap 15.6 this morning, a number of “firmware” packages, while that was running through there was some “nvidia error” reported with a “no such file” mentioned while it was speeding through . . . .
Logged out and in, suspended, revived OK. Suspended it again for several hours, and it revived . . . quickly with key stroke. I have had these non-revival issues in both of my openSUSE installs over the recent years. In this case, Leap seems to have dodged the bullet but TW bit it.
OK, looks like I “misspoke” in post #10. When I posted that I had not refreshed the grub bootloader, so Leap was running the previous kernel.
I went back to TW, which handles grub, checked for the problem then updated the bootloader. After doing that, booting to Leap in the newer “lp” kernel, now Leap also is not reviving from suspend.
I went back to grub and selected “advanced options” for TW and selected the older of the two kernel options, 6.12.6-1 . . . after a brief suspend, it does revive. I’ll test it for a longer period of suspending to see if that “fixes” the problem. For now it seems like kernel 6.12.8-2 is involved in this failure to revive problem.
I did take a look at dmesg data and there were some red errors, some involving “b-43” PCI, but TW is on a desktop so I don’t need wifi . . . and there was a “systemd” error about the system having something with “Killall=none” as being a “not good” choice. But I didn’t change anything previously . . . . There was nothing found on “journal” . . . but “journalctl” brings an endless document, going back to “May 22”???
I am now looking at the potential issue being wrapped in the 6.12.8-2 kernel upgrade?
Hi, you could try something like # journalctl -b -1 to see prior boot journal entries and # journalctl -b -2 for second prior and so on. Maybe try something like # journalctl -b | grep -i "error\|warn\|fail" will show you some more.
Might be something to consider a bug report on then. I am not very experienced with troubleshooting in general.
Alrighty, after suspending TW in the old kernel, a couple hours later the machine literally sprang to life, almost before I touched the keyboard . . . it was that “lively.”
Pretty sure that is “kernel” related . . . and perhaps if Malcolm has no follow ups on his original line of questioning, then perhaps Takashi will be the receiver of this data over on the Bugzilla??
I did check your journalctl -b | grep -i "error\|warn\|fail" suggestion and that did cut the data down significantly, there were a few items, but not germane . . . stuff about “ping” on Firefox . . . .
For the troubleshooting process to me it is more germane that in one kernel, the new kernel, there is a problem . . . in the previous kernel, there is not . . . is “diagnostic” . . . .
For the kicks I’ll try rebooting out of TW and over to Leap and repeat the test . . . even though Leap is running different kernels, somehow, something recent has lost some capacity for revival . . . .
Hi, I’ve never used a Mac before, perhaps check BIOS power management settings too. Also for info, I believe it’s fine to have the kernel-firmware-nvidia package as installed. Even if using Nouveau. With Kepler -2 GPU can you use Nvidia (G06) if desired? Either way check the power settings for the desktop environment again too. Is machine booting to graphical target for you now?
Also not certain if there is a sddm-qt7 package available. You must be using KDE desktop from what I can tell.
Here am using kernel:stable standard and
zypper se -si sddm
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+-----------------------------+---------+---------------------------------------+--------+-----------
i | plasma6-sddm-theme-openSUSE | package | 84.87~git20240313T170730~9c664b7-17.1 | noarch | repo-oss
i | sddm | package | 0.21.0-4.2 | x86_64 | repo-oss
i | sddm-branding-openSUSE | package | 0.21.0-4.2 | noarch | repo-oss
i | sddm-greeter-qt5 | package | 0.21.0-4.2 | x86_64 | repo-oss
i | sddm-greeter-qt6 | package | 0.21.0-4.2 | x86_64 | repo-oss
i | sddm-kcm6 | package | 6.2.5-1.1 | x86_64 | repo-oss
i | sddm-qt6-branding-openSUSE | package | 6.2.5-1.1 | x86_64 | repo-
I tried “advanced options” in Leap 15.6 to try to get to an older kernel . . . but it got complicated. I have the “lp” line of kernels going from a time in the past where we had this same problem, and then the “regular” kernel line. In advanced options in TW there are only two kernels, clearly labeled.
In Leap there are showing ten or so lines, all labeled the same. Lines #3, #4 did not boot. Scrolling down to line #6 it did . . . I tested the suspend revival and it did not. I checked uname -r and it showed uname -r 6.12.9-lp155.2.g0ae2136-default
I then cold booted back to the regular Leap grub listing and it booted to . . . checking uname -r uname -r 6.12.9-lp155.2.g0ae2136-default
The same kernel. If it suspends and I try to revive within a few seconds it seems to work, but if I suspend for over a minute, again it does not. So, perhaps this is “educational” in that moving forward past the TW 6.12.8 kernel does not seem to fix the issue.
Alrighty, back over in TW in the offending newest kernel 6.12.8-2 and running yr suggestion brings:
The following 2 items are locked and will not be changed by any action:
Available:
kernel-firmware-nvidia-gsp-G06 nvidia-open-driver-G06-signed-kmp-default
Nothing to do.
macpro02:~> zypper se -si sddm
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------+---------+------------+--------+----------------------
i+ | sddm-conf | package | 0.3.0-1.1 | x86_64 | Main Repository (OSS)
i | sddm-greeter-qt5 | package | 0.21.0-4.2 | x86_64 | Main Repository (OSS)
i | sddm-greeter-qt6 | package | 0.21.0-4.2 | x86_64 | Main Repository (OSS)
i+ | sddm-qt6 | package | 0.21.0-4.2 | x86_64 | Main Repository (OSS)
To answer the G06 question, no, this machine is a '12 and going to G06 some time back brought other issues, if not the same, nonrevival from suspend issues I see that TW has sddm-qt5 & qt6 . . . .
Are you able to switch to a different visible/legible TTY after the suspend/wakeup failure? Then perhaps you can view on the spot journal and/or dmesg information.