Bugzilla – Bug 1217613
Leap 15.6 not reviving from suspend on '12 MacPro w/nvidia card
Last modified: 2024-04-29 13:16:24 UTC
For several weeks now Slow Roll does not revive from suspend . . . continuing after the recent package upgrades . . . . Had similar issues in Leap 15.6 that seemed to be fixed by kernel upgrade, but the same kernel now in Slow Roll is not able to "wake up" . . . . Actually the machine itself revives with keyboard clicking, but the display stays black. I usually pick "nouveau" or "default" for my video driver, but I don't recall in the installer that there was an option to do that, or a question about video driver. In Slo Roll lsmod there is no mention of "video" nor anything showing "nouveau" . . . but, now in TW I have multiple line items showing nouveau. No problems with TW at the moment as far as revival from suspending goes.
(In reply to Fritz Hudnut from comment #0) > For several weeks now Slow Roll does not revive from suspend . . . > continuing after the recent package upgrades . . . . Had similar issues in > Leap 15.6 that seemed to be fixed by kernel upgrade, but the same kernel now > in Slow Roll is not able to "wake up" . . . . What does this exactly mean? You've installed Leap 15.6 and upgraded the Leap 15.6 kernel, and the suspend/resume worked there? And now you switched to Slow Roll, and the problem (re-)appeared? Leap 15.6 is 6.4-based plus tons of backports, while Slow Roll takes TW 6.6.x kernel. There are clear differences between them. > Actually the machine itself > revives with keyboard clicking, but the display stays black. And the machine actually reacts with the keyboard / mouse input? That is, if you type blindly, does it operate? It's the question whether it's just the missing video output, or it's a complete hang up. > I usually pick "nouveau" or "default" for my video driver, but I don't > recall in the installer that there was an option to do that, or a question > about video driver. In Slo Roll lsmod there is no mention of "video" nor > anything showing "nouveau" . . . but, now in TW I have multiple line items > showing nouveau. No problems with TW at the moment as far as revival from > suspending goes. If you install TW kernel onto Slow Roll, does it work again?
(In reply to Takashi Iwai from comment #1) > (In reply to Fritz Hudnut from comment #0) > > For several weeks now Slow Roll does not revive from suspend . . . > > continuing after the recent package upgrades . . . . Had similar issues in > > Leap 15.6 that seemed to be fixed by kernel upgrade, but the same kernel now > > in Slow Roll is not able to "wake up" . . . . > > What does this exactly mean? You've installed Leap 15.6 and upgraded the > Leap 15.6 kernel, and the suspend/resume worked there? > And now you switched to Slow Roll, and the problem (re-)appeared? > > Leap 15.6 is 6.4-based plus tons of backports, while Slow Roll takes TW > 6.6.x kernel. There are clear differences between them. I have multi-boot machine, so I have in SUSE a TW, a Leap 15.6, and a Slow Roll install in bare metal partitions. The problem seems to have rotated through my various SUSE installs and is now hitting the Slow Roll, but not the TW. I'm in Leap right now, I think the problem is fixed here, but not sure. > > > Actually the machine itself > > revives with keyboard clicking, but the display stays black. > > And the machine actually reacts with the keyboard / mouse input? > That is, if you type blindly, does it operate? It's the question whether > it's just the missing video output, or it's a complete hang up. I have tried to get to a TTY from the blackness, but, since the display is black I can't tell if there is a cursor there to type after, etc. I have to use the power button to shut down out of the blackness. > > > I usually pick "nouveau" or "default" for my video driver, but I don't > > recall in the installer that there was an option to do that, or a question > > about video driver. In Slo Roll lsmod there is no mention of "video" nor > > anything showing "nouveau" . . . but, now in TW I have multiple line items > > showing nouveau. No problems with TW at the moment as far as revival from > > suspending goes. > > If you install TW kernel onto Slow Roll, does it work again? Did not try that out, as Slow Roll is a different variation . . . won't have time to check that for a few days.
@Takashi: Obviously not a lot going on with this bug, didn't have time to mess with the kernel in Slow Roll . . . and now the system only boots to "dracut emergency shell" which is itself "unresponsive" to attempts to log in and try to run some commands, etc. System appears to have imploded into itself . . . in just a few zypper dup runs . . . . So, the non-revival from suspend is now moot in my Slow Roll install. But, that problem continues in my Leap 15.6 install . . . .
Well, the bug description is still confusing, and I don't get what your system is and what actually doesn't work. Basically for Slow Roll, take the latest Tumbleweed kernel and check the behavior. That is, only upgrade the kernel on your Slow Roll system to Tumbleweed kernel, and retest. OTOH, for Leap 15.6, you should check the very latest kernel from OBS Kernel:SLE15-SP6 repo at first. The released kernel for Leap 15.6 is fairly outdated. In either way, please specify your hardware information more precisely. Give the hwinfo output taken from the running system, and attach the dmesg output as well.
[QUOTE] OTOH, for Leap 15.6, you should check the very latest kernel from OBS Kernel:SLE15-SP6 repo at first. The released kernel for Leap 15.6 is fairly outdated. In either way, please specify your hardware information more precisely. Give the hwinfo output taken from the running system, and attach the dmesg output as well. [/QUOTE] @Takashi: Thanks for the reply, in the present case Slow Roll "blew itself up" and is nuked. So the problem is only happening with Leap 15.6 on a '12 Mac Pro with Nvidia 780 card, and TW is working properly at this moment. I had the latest SLE/OBS kernel running on the system when the problem showed up, as for a previous problem you made the same suggestion. So I believe I have options for two kernel streams in the repos, but over on the forum when I posted about Leap not reviving, the admin suggestion was to "move it to main kernel for Leap 15.6 for faster response to the problem," so I did that . . . but that didn't repair the problem. Couple other things going on, I'll try to get the requested data to you, after switching back over to OBS kernel and see if that gets it.
@Takashi: It looks like we had this almost same conversation back in Leap 15.5, where you asked for hwinfo & dmesg . . . in that thread you said to "run hwinfo > hwinfo.txt as root" . . . trying that today several ways does not create the .txt document, or dmesg.txt . . . . I obviously don't know what I am doing in Suse: [CODE]# hwinfo > hwinfo.txt MacPro:~ # cp hwinfo hwinfo.txt cp: cannot stat 'hwinfo': No such file or directory MacPro:~ # "hwinfo > hwinfo.txt" If 'hwinfo > hwinfo.txt' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf hwinfo > hwinfo.txt [/CODE] The hwinfo data would be the same as it was in that prior bug report: https://bugzilla.suse.com/show_bug.cgi?id=1208069 The dmesg might be different, but it isn't showing up as requested. I looked at the SLE OBS kernels and today's kernel showed something like 5.14?? but right now in Leap I'm running # uname -r 6.4.0-150600.1-default The stable/backport seems to show "6.7"?? But, I'm out of time for this today. You can see the hwinfo in the other bug report.
Please don't type double-quote ("). Instead, run just like the following on a terminal after the boot: su hwinfo > hwinfo.txt dmesg > dmesg.txt exit Then upload hwinfo.txt and dmesg.txt as Bugzilla attachments. Having the hwinfo output is important because it becomes different on each OS, depending on kernel or whatever environment. Leap 15.6 is based on 6.4 kernel. The latest stable is 6.7.x.
[CODE]# hwinfo > hwinfo.txt MacPro:~ # cp hwinfo hwinfo.txt cp: cannot stat 'hwinfo': No such file or directory MacPro:~ # "hwinfo > hwinfo.txt" If 'hwinfo > hwinfo.txt' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf hwinfo > hwinfo.txt [/CODE] @Takashi: I was showing you that I ran it a number of times, including exactly as you showed again at the top of the [CODE] data. I have done this procedure a fair number of times, the command drops or should drop the .txt file in the /home file, but did not. I searched the file system for it, catfish found nothing. Something seems to be amiss?? I believe I found the site for the 6.7 kernel, when I get a free moment I'll try to install that and see if that fixes the issue.
(In reply to Fritz Hudnut from comment #8) > [CODE]# hwinfo > hwinfo.txt What is this [CODE]# ?? Is it a prompt? If not, omit that word. Other than that, it looks fine. But... > MacPro:~ # cp hwinfo hwinfo.txt > cp: cannot stat 'hwinfo': No such file or directory This is nonsense. You're copying a non-existing file hwinfo to another file. > MacPro:~ # "hwinfo > hwinfo.txt" Ditto. Don't put quotations. The first invocation is basically correct (if you didn't type prompt by yourself). After that, you must have a file hwinfo.txt there. Just upload this file to Bugzilla as an attachment.
For 6.7.x kernel: don't try to get the kernel package from OBS Kernel:stable (or Kernel:HEAD) repo, but use OBS Kernel:stable:Backport (or Kernel:HEAD:Backport) repo instead. The former is only for Tumbleweed while the latter (*:Backport) is only for Leap.
I downloaded 1/20 6.7 kernel-default from http://download.opensuse.org/repositories/Kernel:/stable:/Backport/standard/x86_64/ [CODE] ~> uname -r 6.7.1-lp155.2.g4959dd8-default [/CODE] I suspended the machine for a couple of minutes, however the non-revival problem continues. Click keyboard, the machine revives, but the display does not. Previously I was showing you that I ran your exact requested command, but no .txt file was created. So I tried other commands from possibly ubuntu, which also did not work. With the new kernel I again ran your request for #hwinfo > hwinfo.txt and again, no text file. Is there some other step that isn't mentioned to try? I also tried to run just #hwinfo first . . . which did bring data to the console and then I ran the #hwinfo > hwinfo.txt . . . . So far the console is not complying with the prescribed commands to creat a .txt file . . . and it is not reviving the display from suspend. On cold boot I am back in Leap 15.6 to type this post.
It's not #hwinfo but hwinfo. Don't put "#" letter. It's typically meant as a command line prompt.
(In reply to Takashi Iwai from comment #12) > It's not #hwinfo but hwinfo. Don't put "#" letter. It's typically meant as > a command line prompt. LOL, you are killing me here. I understand the large possibility of pilot error being involved in the whole presentation, but I was again just showing you that I was running as root, the command hwinfo . . . . Still fiddling in Leap I ran a zypper, and now with new kernel 18 packages were upgraded . . . there were some errors in the zypper ref: [CODE] Warning: Repository 'update-backports (15.6)' metadata expired since 2023-09-29 02:08:32 PDT. Warning: Repository 'update-non-oss (15.6)' metadata expired since 2023-09-21 05:47:58 PDT. Warning: Repository 'Update repository of openSUSE Backports' metadata expired since 2023-09-29 02:08:32 PDT. [/CODE] But, in looking at them in YaST they all showed "15.6" and I refreshed them again in YaSt and no error came back. In those repos is a line showing an "NVIDIA," but I ran lsmod and in there no line for "video" and nothing mentioned showing either "nvidia" or "nouveau" . . . it's supposed to be "nouveau" or possibly "default" which is what "i95"??? (I don't know) . . . [CODE] # lsmod Module Size Used by st 73728 0 lp 24576 0 parport_pc 77824 0 ppdev 24576 0 parport 86016 3 parport_pc,lp,ppdev rfcomm 102400 4 af_packet 65536 4 b43legacy 172032 0 nft_fib_inet 12288 1 nft_fib_ipv4 12288 1 nft_fib_inet nft_fib_ipv6 12288 1 nft_fib_inet nft_fib 12288 3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inet b43 524288 0 cordic 12288 1 b43 bcma 90112 1 b43 mac80211 1404928 2 b43,b43legacy nft_reject_inet 12288 12 nf_reject_ipv4 16384 1 nft_reject_inet nf_reject_ipv6 24576 1 nft_reject_inet nft_reject 12288 1 nft_reject_inet libarc4 12288 1 mac80211 cfg80211 1323008 3 b43,b43legacy,mac80211 nft_ct 24576 7 nft_chain_nat 12288 3 ssb 131072 2 b43,b43legacy nf_tables 364544 399 nft_ct,nft_reject_inet,nft_fib_ipv6,nft_fib_ipv4,nft_chain_nat,nft_reject,nft_fib,nft_fib_inet mmc_core 274432 2 b43,ssb pcmcia 94208 1 ssb ebtable_nat 12288 0 pcmcia_core 40960 1 pcmcia ebtable_broute 12288 0 ip6table_nat 12288 0 ip6table_mangle 12288 0 ip6table_raw 12288 0 ip6table_security 12288 0 iptable_nat 12288 0 nf_nat 65536 3 ip6table_nat,nft_chain_nat,iptable_nat nf_conntrack 217088 2 nf_nat,nft_ct nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 12288 1 nf_conntrack libcrc32c 12288 3 nf_conntrack,nf_nat,nf_tables iptable_mangle 12288 0 iptable_raw 12288 0 iptable_security 12288 0 ip_set 65536 0 nfnetlink 20480 3 nf_tables,ip_set ebtable_filter 12288 0 ebtables 49152 3 ebtable_nat,ebtable_filter,ebtable_broute ip6table_filter 12288 0 ip6_tables 36864 5 ip6table_filter,ip6table_raw,ip6table_nat,ip6table_mangle,ip6table_security iptable_filter 12288 0 bpfilter 12288 0 qrtr 53248 4 bnep 36864 2 msr 12288 0 nls_iso8859_1 12288 1 nls_cp437 16384 1 vfat 20480 1 fat 106496 1 vfat intel_powerclamp 20480 0 coretemp 16384 0 iTCO_wdt 16384 0 kvm_intel 425984 0 intel_pmc_bxt 16384 1 iTCO_wdt iTCO_vendor_support 12288 1 iTCO_wdt applesmc 32768 0 btusb 86016 0 btrtl 32768 1 btusb kvm 1368064 1 kvm_intel btintel 57344 1 btusb btbcm 24576 1 btusb irqbypass 12288 1 kvm i2c_i801 40960 0 btmtk 16384 1 btusb acpi_cpufreq 32768 0 pcspkr 12288 0 efi_pstore 12288 0 i2c_smbus 20480 1 i2c_i801 snd_hda_codec_realtek 196608 1 snd_hda_codec_hdmi 94208 1 snd_hda_codec_generic 110592 1 snd_hda_codec_realtek lpc_ich 28672 0 ledtrig_audio 12288 1 snd_hda_codec_generic bluetooth 1101824 28 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm snd_hda_intel 65536 4 snd_intel_dspcfg 40960 1 snd_hda_intel snd_intel_sdw_acpi 16384 1 snd_intel_dspcfg snd_hda_codec 233472 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek ecdh_generic 16384 1 bluetooth rfkill 40960 6 bluetooth,cfg80211 snd_hda_core 155648 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek snd_hwdep 20480 1 snd_hda_codec snd_pcm 233472 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core e1000e 372736 0 joydev 24576 0 snd_timer 53248 1 snd_pcm snd 159744 16 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm ioatdma 77824 0 i5500_temp 12288 0 i7core_edac 45056 0 dca 16384 1 ioatdma apple_mfi_fastcharge 16384 0 soundcore 16384 1 snd tiny_power_button 12288 0 fuse 212992 7 configfs 65536 1 dmi_sysfs 24576 0 ip_tables 36864 5 iptable_filter,iptable_security,iptable_raw,iptable_nat,iptable_mangle x_tables 69632 13 ebtables,ip6table_filter,ip6table_raw,iptable_filter,iptable_security,ip6table_nat,ip6_tables,iptable_raw,ip_tables,iptable_nat,ip6table_mangle,ip6table_security,iptable_mangle ext4 1163264 2 mbcache 16384 1 ext4 jbd2 225280 1 ext4 hid_apple 24576 0 hid_generic 12288 0 usbhid 77824 0 sr_mod 28672 0 cdrom 81920 1 sr_mod ahci 57344 5 libahci 69632 1 ahci libata 507904 2 libahci,ahci sd_mod 86016 5 firewire_ohci 61440 0 t10_pi 20480 1 sd_mod crc32c_intel 16384 5 sha512_ssse3 53248 1 sg 49152 0 uhci_hcd 61440 0 ehci_pci 20480 0 firewire_core 110592 1 firewire_ohci ehci_hcd 110592 1 ehci_pci sha256_ssse3 32768 0 crc_itu_t 12288 1 firewire_core sha1_ssse3 32768 0 scsi_mod 348160 5 st,sd_mod,libata,sg,sr_mod usbcore 446464 6 ehci_pci,usbhid,apple_mfi_fastcharge,ehci_hcd,btusb,uhci_hcd scsi_common 16384 6 st,scsi_mod,sd_mod,libata,sg,sr_mod button 24576 0 efivarfs 24576 1 [/CODE]
Created attachment 872045 [details] hwinfo.text from tumbleweed on same machine
Tried to post this comment, but seems to be lost?? Had the idea to run your command in my TW install and this time it worked as it should. Problem persists in Leap 15.6 as far as non-revival from suspend with new packages and the 6.7 kernel. TW hwinfo.txt file is attached, request for info not unchecked because Leap is failing to provide the requested command, but TW gets it done.
If hwinfo command doesn't exist, it means either that hwinfo package is not installed or that you did something wrong. Try to install hwinfo package via zypper. And, if the suspend fails with 6.7 kernel, basically it's an upstream problem. At best report to the upstream and resolve there. But, it's better to narrow down what is failing. I suspect it's a nouveau driver problem; it'd be rather surprising if nouveau driver works without problems on Mac. Most Mac users that need Nvidia graphics use Nvidia binary stuff, I guess. Check whether your machine reacts against the network after suspend/resume, e.g. try to remote access via ssh after resume. If it's still alive and you have a control, try to get the kernel log (dmesg output) at that point. You might have a more interesting kernel log when you boot with drm.debug=0x1e boot option. This will give lots of debug messages from the kernel, and try to suspend / resume immediately after boot, and get the kernel log at resume if possible -- or get the previous kernel log if you can't get access to the resumed system and reboot. It might show something about nouveau bugs. Also, try to suspend-to-disk, not only suspend-to-RAM. The behavior might be different.
(In reply to Takashi Iwai from comment #16) > If hwinfo command doesn't exist, it means either that hwinfo package is not > installed or that you did something wrong. Try to install hwinfo package > via zypper. > OK, well, I can get the hwinfo data to show up in the console, so I believe it is installed, it just isn't transferring to .txt. And then there is the dmesg data, which also isn't going to .txt . . . . I'll check it again, but not holding my breath on it . . . . > And, if the suspend fails with 6.7 kernel, basically it's an upstream > problem. > At best report to the upstream and resolve there. OK, I think of the bugzilla site as semi-upstream, where would upstream be located in this case? > > But, it's better to narrow down what is failing. I suspect it's a nouveau > driver problem; it'd be rather surprising if nouveau driver works without > problems on Mac. Most Mac users that need Nvidia graphics use Nvidia binary > stuff, I guess. I got away from proprietary in a number of my Macs, because Nvidia doesn't keep pace with linux devel editions . . . we used to pray for nouveau to get to PPC editions back when, when nv was our only option. Nouveau has been more or less OK. I'm running it in most of my now 6 other linux installs . . . there have been problems with reviving from suspend on occasion. > > Check whether your machine reacts against the network after suspend/resume, > e.g. try to remote access via ssh after resume. If it's still alive and you > have a control, try to get the kernel log (dmesg output) at that point. > > You might have a more interesting kernel log when you boot with > drm.debug=0x1e boot option. This will give lots of debug messages from the > kernel, and try to suspend / resume immediately after boot, and get the > kernel log at resume if possible -- or get the previous kernel log if you > can't get access to the resumed system and reboot. It might show something > about nouveau bugs. > > Also, try to suspend-to-disk, not only suspend-to-RAM. The behavior might > be different. Thanks for these suggestions, most of them are "beyond my skillset," only recently having to learn about ssh to try to diagnose problems I was having in my TW install a few months back . . . wouldn't really have a clue how to run the "debug boot option" or suspend to disk for that matter, but appreciate the thoughts on it. I believe that I could copy/paste the hwinfo data out of the console, but I recall that to do that for the dmesg data would be "cumbersome" as it has so many lines of data . . . it seemed like the hwinfo was a little less cumbersome. I'll check that later on . . . .
Just a head's up to say that I did get the hwinfo data copied and pasted out of the console this morning and into a .txt document . . . took a fair bit of time to highlight that much data, manually. : - 0 I ran out of time on it before I could upload it here . . . "629 pages" or 1.3MB of data, similar to the TW item. I'll upload it when I get back to Leap 15.6. I watched the dmesg data spin by this morning . . . all "OK," no "errors" showing on it. If it is quick n dirty to copy paste the dmesg I will try that, but if it's another literally 15 mins of holding the mouse button to get the hwinfo copied, that I think will be "too much" . . . ???? I again tried the # hwinfo > hwinfo.txt move and it took a few seconds for the cursor to return, as though something was "happening," but once again, nothing did . . . whereas it did in TW . . . .
Created attachment 872104 [details] hwinfo from Leap 15.6
Created attachment 872105 [details] dmesg from Leap 15.6 The machine is a desktop and does not need b43 wifi
Today, my Manjaro 23.1.3 system running their 5.15.146-1-MANJARO kernel failed to revive from suspend . . . using grub "advanced options" that rolled the kernel back to 5.4.266-1-MANJARO . . . and the problem went away, system revives the display as per request.
Well, the logs in comment 19 and comment 20 indicate that nouveau driver isn't used at all, and your graphics is driven by BIOS EFI framebuffer by some reason. And EFI framebuffer won't work after suspend/resume in most cases. So that's no surprise if the graphics is dead afterwards. But, it might be another stuff that gets broken after suspend/resume, too. For example, b43 is known to be often buggy. You can try to blacklist such drivers and verify whether it changes the behavior, for example.
@Takashi: Well, the question is "why is nouveau not in use?" . . . in the case of B43, in one of those logs it shows a B43 error, as mentioned, it wasn't installed because it's plugged into ethernet, there is no b43?? This problem suddenly hit my Manjaro install, after running well for at least a year . . . posted on their forum, other Nvidia HW users seemed to have hit the problem. One of the helpers said they believe it has to do with "Dbus" and they are waiting for a patch for it . . . ??? In the case of Manjaro I had their 5.4 kernel installed, and booting to that kernel fixed the problem that showed up in their 5.15 kernel. I then installed their 5.10 kernel and that also works, but according to another person with the problem, moving forward to newer kernels so far does not fix it, so e.g., 6.7 did not fix their issue. 5.10 xxx works OK, so in other words rolling back in the kernels rather than forward. I don't have any idea how to check "Dbus" or how to patch it . . . would that possibly be relevant to the Leap situation?? The non-revival of display problem is consistent in those two platforms, but my other 5 linux installs are now working properly.
I have no idea. The hwinfo could identify nouveau module, as it seems, but the actual boot didn't show the driver in use. You need to verify by yourself, e.g. by loading it manually. About b43: the problem is the lack of firmware. It's loaded but not used due to the missing files. They can be fetched by installing b43-firmware package or such, I suppose. They aren't officially distributed. But again, b43 is quite hackish, and I recommend to blacklist at first for testing the stability.
So the problem most likely relevant to the bug report is this "no video" module showing. I'm in TW right now and I see "nouveau" all over the place in lsmod. How am I to manually load nouveau or what is default "i915"??? "sudo modprobe nouveau"??? How would I check to see if nouveau or i915 is even there, if they aren't showing in lsmod? Then I would run "zypper in i915"??? The question remains, why was or does Leap boot up and run OK, until suspend, and then doesn't revive? I would have no idea why some "framebuffer" got in to the Leap system . . . nor do I understand how something that relates to the "internet" like b43 have anything to do with a system that runs fine, until it suspends, and then suddenly "the b43 internet bug reaches over" and makes the screen black?? Please advise.
Based upon your previous data about nouveau not being used, and that thread on forum with a similar problem, today I ran "sudo modprobe nouveau" . . . and entered password and then . . . nothing for several minutes?? Figuring that it was taking too long I tried to cntrl C out of it and the console did not respond. I tried to mouse around in the GUI and there was no mouse . . . GUI was frozen . . . !!! Kernel panic????? Now rebooted in Leap and there are "936 packages being upgraded" . . . we shall see if any of them gets to the problem of loss of nouveau???
Created attachment 872421 [details] data showing nouveau is blacklisted Found a thread in the forum discussing nouveau was blacklisted in Leap 15.5 and I found similar data, but not what was their solution.
https://forums.opensuse.org/t/nouveau-does-not-load-during-boot-up-after-leap-15-5-upgrade/167273/8 Found a thread on the forum discussing nouveau being blacklisted by the system, I ran through some of the suggested commands and found: [code]n01 # modprobe -c | grep nouveau blacklist nouveau alias pci:v000010DEd*sv*sd*bc03sc*i* nouveau alias pci:v000012D2d*sv*sd*bc03sc*i* nouveau n01 # grep -r nouveau /usr/lib/modprobe.d /etc/modprobe.d /etc/modprobe.d/nvidia-default.conf:blacklist nouveau [code] [quote]KittyKatty Student Penguin Jun 2023 Thank you so much! I have checked /lib/modprobe.d and found that in 09-nvidia-modprobe-bbswitch-G04.conf there was line that blacklisted nouveau. After commented it out, it seems to be working now! I hope one day I will be able to use the actual nVidea drivers. [quote] I had to navi to /lib/modprobe.d and in that directory there was no "09-nvidia-modprobe-bbswitch-G04.conf file. I believe that data is listed at the top of the new attachment. I could not replicate the fix, but it appears that at some point, nouveau was blacklisted in my system . . . possibly resulting in this "non-revival from suspend" problem??
The blacklist must be a part of (or a leftover of) Nvidia binary driver. The driver blacklisting of nouveau itself must not hit for yours; we disabled nouveau only for the recent chips, and yours isn't on the list.
[CODE] just delete or move /etc/modprobe.d/nvidia-default.conf and reboot. Also rebuild initrd dracut -f --regenerate-all [CODE] [QUOTE] Alrighty, that does seem to have restored “revival from suspend” function in my machine. I’ll have to monitor it for longevity. Thanks kindly for the data . . . problem has been following numerous iterations of Leap, now maybe a semblance of an idea as to the “why” of it . . . . [QUOTE] [CODE] > uname -r 6.7.3-lp155.3.gce5575e-default [CODE]
Good to hear! So this was about some leftover setup of the nvidia driver installation that prevented nouveau driver. I close this bug for now. Feel free to reopen if you still hit the same problem after the fix of your configuration data.
@Takashi: The "non-revival" from suspend issue in my Leap 15.6 system is back, ran a "28 package" zypper today and then logged out and suspended. Did not revive when trying different mouse and keyboard clicks. Restarted and tried again, same problem. Then restarted and went to "advanced options" and picked line "three" from the top, which I was hoping would get back to the previous kernel . . . but that went to TTY error . . . . Now back in top grub line with [CODE] ~> uname -r 6.8.2-lp155.4.g2eb0f0f-default [/CODE] Reading through the posts in this bug report I saw the issue with nouveau being blcklisted, ran lsmod and again, no "nouveau" showing in the data. Reading the comment about "moving or deleting /etc/modprobe.d/nvidia-default.conf" . . . I tried doing that via sudo and as root #zypper rm /etc/modprobe.d/nvidia-default.conf [CODE] # zypper rm /etc/modprobe.d/nvidia-default.conf Reading installed packages... '/etc/modprobe.d/nvidia-default.conf' not found in package names. Trying capabilities. No provider of '/etc/modprobe.d/nvidia-default.conf' found. Resolving package dependencies... Nothing to do. [/CODE] I can "see" the file when I navi there, but unlike last time it isn't leaving. Short on time this AM, just posting that the problem is back.
You're using 6.8.x kernel and that's again a completely different story. Have you tried to resume via power key?
I'd have to say, "No" . . . sometimes I think of that, but today, did not. I just used it to shut down. After I posted this I did manage to open that "nvidia-default.conf" file, and in it were two words, "blacklist nouveau" . . . . Couldn't get that file to delete or move, jammed for time, so I didn't try to edit those two words out of the file . . . .
Check "rpm -qf /etc/modprobe.d/nvidia-default.conf" I guess you (re-)installed the Nvidia binary driver stuff or such.
(In reply to Takashi Iwai from comment #35) > Check "rpm -qf /etc/modprobe.d/nvidia-default.conf" > I guess you (re-)installed the Nvidia binary driver stuff or such. Zypper re-installed it??? But now it isn't letting me remove that two word script?? Ran yr command: "# rpm -qf /etc/modprobe.d/nvidia-default.conf nvidia-gfxG05-kmp-default-470.239.06_k6.4.0_150600.10-lp156.59.6.x86_64 " I don't know what to do with that info.
I'm seeing a "5 package upgrade" that includes the regular kernel and the "lp" kernel . . . running them through now, but more or less out of time for exploration on it today. Might be a fix?? Or, the nvidia.conf will still be there??? Back when I get a minute on it.
[CODE] just delete or move /etc/modprobe.d/nvidia-default.conf and reboot. Also rebuild initrd dracut -f --regenerate-all [CODE] The problem is the "intermittency" of either the console or the operator . . . today running [CODE] # zypper rm /etc/modprobe.d/nvidia-default.conf [/CODE] did remove the .conf file . . . or this time did I run simply w/o the "zypper," [CODE] # rm /etc/modprobe.d/nvidia-default.conf [/CODE] and that did remove the file, but did not restore "nouveau" into lsmod . . . . I had run the dracut, also not restoring nouveau to lsmod. I then tried to run "modprobe nouveau" and that **instantly** froze the mouse and GUI . . . after a few seconds I shut it down with the power button. On cold boot, that does seem to have restored "nouveau" back into lsmod and the “revival from suspend” function in my machine. I’ll have to monitor it for longevity.
I guess that you tried to run "zypper dup" or such for updating, and this will bring the stuff like nvidia KMP automatically, as it's a "hardware supplement". And of course this package will try to disable nouveau driver as it's conflicting. If you do *not* want Nvidia binary driver stuff, you'd need to remove the repository from zypper, and/or add the package lock for prohibiting the further installation.