[Bug 1220088] New: Hibernate completes shuts machine off *then* machine automatically turns back on.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 Bug ID: 1220088 Summary: Hibernate completes shuts machine off *then* machine automatically turns back on. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: pj.opensuse@gmx.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Hi, when hibernate is envoked from the Tumbleweed menu the hibernate feature seems to complete and shutoff the machine for 2 seconds...... Then the machine automatically powers back on. I enter the LUKS password and the machine continues to boot. I enter the user password at SDDM screen. After loading KDE I can then see that Hibernate has indeed worked. Largest issue is machine is cycling, (powering back on) after hibernation has been envoked. I have shut off all wake-on power options in the bios settings. The machine is kept very current with the latest updates. What are your thoughts on this? -Best Regards -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c6 --- Comment #6 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Stefan Hundhammer from comment #3)
This sounds very much like that machine's BIOS not handling those power states correctly. Did you check if there is a BIOS update available? Are there similar complaints in user forums that are dedicated to this hardware?
This machine in question has the latest Bios update as per HP website which is v: 2RKT64BUS date: 01/08/2014 Many users consider this hardware obsolete and will not use it. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c7 --- Comment #7 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878427 --> https://bugzilla.suse.com/attachment.cgi?id=878427&action=edit Lenovo m57p hwinfo result. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c8 --- Comment #8 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878428 --> https://bugzilla.suse.com/attachment.cgi?id=878428&action=edit dmesg output after waking from hibernation This is the dmesg output after a hibernation attempt was made. The machine exhibits same behaviour as before. # echo -n XHC1 > /proc/acpi/wakeup had been passed prior to dmesg result taken after wake from hibernation. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c9 Paul Graff <pj.opensuse@gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(pj.opensuse@gmx.c | |om) | --- Comment #9 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #5)
Is this a regression by the updates, e.g. by the recent kernels? I do not believe that the hibernate feature has worked on this machine before. I can not say this for absolute certain to you though. This Tumbleweeds life began in 2020. I did not attempt to work with Hibernation on this machine until near time of this bug report.
You can try to check /proc/acpi/wakeup contents and disable the wake up sources by writing to it. e.g. echo -n XHC1 > /proc/acpi/wakeup cat /proc/acpi/wakeup Device S-state Status Sysfs node LAN S5 *enabled pci:0000:00:19.0 USB4 S3 *enabled pci:0000:00:1a.0 USB5 S3 *enabled pci:0000:00:1a.1 USB7 S3 *enabled pci:0000:00:1a.2 ESB2 S3 *enabled pci:0000:00:1a.7 EXP1 S4 *disabled EXP2 S4 *disabled EXP3 S4 *disabled EXP4 S4 *disabled EXP5 S4 *disabled EXP6 S4 *disabled USB1 S3 *enabled pci:0000:00:1d.0 USB2 S3 *enabled pci:0000:00:1d.1 USB3 S3 *enabled pci:0000:00:1d.2 USB6 S3 *disabled ESB1 S3 *enabled pci:0000:00:1d.7 PCIB S5 *disabled pci:0000:00:1e.0 COM1 S4 *disabled pnp:00:02 COM2 S4 *disabled pnp:00:03 KBC0 S4 *disabled pnp:00:06 *disabled serio:serio0 MSE0 S4 *disabled PWRB S3 *enabled platform:PNP0C0C:00
I disabled all the above then attempted to hibernate machine. I do not see XHC1 in the output above, is this a concern then? Had machine attempt to logout out of KDE to SDDM multiple times after envoking hibernation to take (perhaps recent updates). Auto power on behavior persists shortly after shutoff.
will toggle the enable/disable of the wakeup from XHC1. ok After disabling all wake up sources, go to hibernate and check whether the wake up happens.
When Hibernate is envoked from start menu, machine is logging out of KDE to SDDM then shutting off for split second then powering back on to SDDM screen. Multiple hibernation attempts from start menu to hibernate machine (will try clean poweroff and reattempt hibernate again with wakeup sources all again disabled). Same power on behavior at POST as before it appears thus far.
Last but not least, please give the hwinfo output and the dmesg output. I have attached the requested output.
Thank you all for your help. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c10 --- Comment #10 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878429 --> https://bugzilla.suse.com/attachment.cgi?id=878429&action=edit acpi wake sources on m57p disabled before hibernation attempt is made. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c11 --- Comment #11 from Paul Graff <pj.opensuse@gmx.com> --- Some journal entries relating to ACPI in current boot. journalctl -b | grep "Fail\|Warn\|Ignore" [sudo] password for root: Nov 06 23:34:40 paul-Thinkcentre-M57p kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0._OSC.CAPB], AE_ALREADY_EXISTS (20240322/dsfield-184) Nov 06 23:34:58 paul-Thinkcentre-M57p kernel: ACPI Warning: SystemIO range 0x0000000000001028-0x000000000000102F conflicts with OpRegion 0x0000000000001028-0x0000000000001047 (\_SB.PCI0.IEIT.EITR) (20240322/utaddress-204) Nov 06 23:34:58 paul-Thinkcentre-M57p kernel: ACPI Warning: SystemIO range 0x0000000000001028-0x000000000000102F conflicts with OpRegion 0x0000000000001000-0x000000000000102F (\_SB.PCI0.LPC0.PMIO) (20240322/utaddress-204) Nov 06 23:34:58 paul-Thinkcentre-M57p kernel: ACPI Warning: SystemIO range 0x0000000000001180-0x00000000000011AF conflicts with OpRegion 0x0000000000001180-0x00000000000011AF (\_SB.PCI0.LPC0.GPOX) (20240322/utaddress-204) Is this irrelevant? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c12 --- Comment #12 from Paul Graff <pj.opensuse@gmx.com> --- Also to tell you that I have switched the Nvidia Quadro K600 with a Radeon RX 550 in machine 2 week ago. Seeing > amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.3.1 test failed (-110) in dmesg output. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c14 --- Comment #14 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878520 --> https://bugzilla.suse.com/attachment.cgi?id=878520&action=edit inside BIOS wol disabled -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c15 --- Comment #15 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878521 --> https://bugzilla.suse.com/attachment.cgi?id=878521&action=edit Verified once again all acpi wakeup devices disabled before attempt hibernation -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c16 --- Comment #16 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #13)
(In reply to Paul Graff from comment #9)
(In reply to Takashi Iwai from comment #5)
Is this a regression by the updates, e.g. by the recent kernels? I do not believe that the hibernate feature has worked on this machine before. I can not say this for absolute certain to you though. This Tumbleweeds life began in 2020. I did not attempt to work with Hibernation on this machine until near time of this bug report.
You can try to check /proc/acpi/wakeup contents and disable the wake up sources by writing to it. e.g. echo -n XHC1 > /proc/acpi/wakeup cat /proc/acpi/wakeup Device S-state Status Sysfs node LAN S5 *enabled pci:0000:00:19.0 USB4 S3 *enabled pci:0000:00:1a.0 USB5 S3 *enabled pci:0000:00:1a.1 USB7 S3 *enabled pci:0000:00:1a.2 ESB2 S3 *enabled pci:0000:00:1a.7 EXP1 S4 *disabled EXP2 S4 *disabled EXP3 S4 *disabled EXP4 S4 *disabled EXP5 S4 *disabled EXP6 S4 *disabled USB1 S3 *enabled pci:0000:00:1d.0 USB2 S3 *enabled pci:0000:00:1d.1 USB3 S3 *enabled pci:0000:00:1d.2 USB6 S3 *disabled ESB1 S3 *enabled pci:0000:00:1d.7 PCIB S5 *disabled pci:0000:00:1e.0 COM1 S4 *disabled pnp:00:02 COM2 S4 *disabled pnp:00:03 KBC0 S4 *disabled pnp:00:06 *disabled serio:serio0 MSE0 S4 *disabled PWRB S3 *enabled platform:PNP0C0C:00
I disabled all the above then attempted to hibernate machine. I do not see XHC1 in the output above, is this a concern then?
No, I showed XHCI1 just as an example that could be applied on my machine. The entries utterly vary, depending on the system.
I understand.
Had machine attempt to logout out of KDE to SDDM multiple times after envoking hibernation to take (perhaps recent updates). Auto power on behavior persists shortly after shutoff.
Hm, please verify that all entries are indeed disabled by checking /proc/acpi/wakeup before testing.
I have verified the entires are disabled. Have added another attachment above.
Also, try to disable WoL, too. See examples at: https://unix.stackexchange.com/questions/288717/how-to-disable-wake-on-lan
Excellent, but this does not seem to help. :~> sudo ethtool enp0s25 | grep Wake Supports Wake-on: pumbg Wake-on: g *now* :~> sudo ethtool enp0s25 | grep Wake [sudo] password for root: Supports Wake-on: pumbg Wake-on: d Attempting to hibernate once again exhibits similar if not the very same behavior as before. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c19 --- Comment #19 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #18)
BTW, I didn't get an answer to the first question in the comment 5, which is rather more important than others.
Apologies, I do not know if this is a regression and if it ever worked with this CPU or model machine. I am using 6.6.11-1-default and testing hibernation now. I have previously edited zypp.conf to have kept that oldest kernel as well as past kernels.
If it's a kernel regression, we need to narrow down the changes. You can find older kernel packages in my OBS repos, e.g. home:tiwai:kernel:6.10, home:tiwai:kernel:6.9, etc.
I have now tried values: bios acpi kbd triple efi pci with the 6.6.11-1-default #1 SMP PREEMPT_DYNAMIC kernel and the same behavior. 1. attempt to hibernate...goes to sddm 2. enter user password at sddm then attempt hibernate again. 3. hibernate usually succeeds 8but* resulting in a machine powerup after 2 seconds.
https://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.10/ standard/
https://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.9/standard...
Note that those kernel packages are unofficial builds, hence you'd need to disable Secure Boot if it was turned on. Thank you, this machine does not have secure boot capabilitie either way. Good to know. What would my next steps possibly be? Is it possible that something on the mainboard is triggering the powersupply? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c21 --- Comment #21 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #20)
(In reply to Paul Graff from comment #19)
(In reply to Takashi Iwai from comment #18)
BTW, I didn't get an answer to the first question in the comment 5, which is rather more important than others.
Apologies, I do not know if this is a regression and if it ever worked with this CPU or model machine. I am using 6.6.11-1-default and testing hibernation now. I have previously edited zypp.conf to have kept that oldest kernel as well as past kernels.
And 6.6.x still showed the same behavior, right? You can try much older kernels from my OBS repos to figure out whether it's a kernel regression or not.
If it's a kernel regression, we need to narrow down the changes. You can find older kernel packages in my OBS repos, e.g. home:tiwai:kernel:6.10, home:tiwai:kernel:6.9, etc.
I have now tried values: bios acpi kbd triple efi pci with the 6.6.11-1-default #1 SMP PREEMPT_DYNAMIC kernel and the same behavior. 1. attempt to hibernate...goes to sddm 2. enter user password at sddm then attempt hibernate again. 3. hibernate usually succeeds 8but* resulting in a machine powerup after 2 seconds.
Just to be sure: you tested each one, and all 6 tests showed the same behavior? I'm rather surprise that all those methods worked more or less. You can check the content of /sys/kernel/reboot/type and verify whether it's really set correctly.
https://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.10/ standard/
https://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.9/standard...
Note that those kernel packages are unofficial builds, hence you'd need to disable Secure Boot if it was turned on. Thank you, this machine does not have secure boot capabilitie either way. Good to know. What would my next steps possibly be? Is it possible that something on the mainboard is triggering the powersupply?
I don't think it's a hardware defect, but the wake-up is certainly a BIOS thing. Let's check with the older kernels (e.g. 5.x). Ok, I added the http://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.0/standard/ After marking for installation, package 5.0.13-1.1.....x64 using YaST Software Manager am receiving error message as follows: Nothing provides 'mkinitrd >= 2.7.1' needed by the to be installed kernel-default.
Conflict Resolution: 1: do not install kernel-default-5.0.13-1.1gb11e2d7.x86-64 2: break kernel-default-5.0.13-1.1gb11e2d7.x86-64 by ignoring some of it's dependencies. How do you suggest proceeding? Is this a matter of regenerating dracut? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c22 --- Comment #22 from Paul Graff <pj.opensuse@gmx.com> ---
I have now tried values: bios acpi kbd triple efi pci with the 6.6.11-1-default #1 SMP PREEMPT_DYNAMIC kernel and the same behavior. 1. attempt to hibernate...goes to sddm 2. enter user password at sddm then attempt hibernate again. 3. hibernate usually succeeds *but* resulting in a machine powerup after 2 seconds.
Just to be sure: you tested each one, and all 6 tests showed the same behavior? I'm rather surprise that all those methods worked more or less. I did switch and verify each of the 6 options above. You can check the content of /sys/kernel/reboot/type and verify whether it's really set correctly. I understand: cat /sys/kernel/reboot/type and have done so. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c24 --- Comment #24 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #23)
You can proceed the installation by breaking the dependency, and build initrd manually after installing the package by invoking dracut: dracut --kver 5.x... where 5.x... is the kernel version you installed (found in /lib/modules/*). Note that this version number might be slightly different from the rpm version number.
Trying also now by downloading the rpm file here: https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.0/standard... Then cd to ~/Downloads and sudo zypper in -f kernel-default-5.0.13-1.1.gb11e2d7.x86_64.rpm Receiving a very long list of packages to remove. Shown in attachment. Asking again about proceeding with this again. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c25 --- Comment #25 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878527 --> https://bugzilla.suse.com/attachment.cgi?id=878527&action=edit Proceed with deinstallation of many packages? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c27 --- Comment #27 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #26)
Likely because of the usrmerge change on TW. The package was built before that.
You can install the package via rpm directly, e.g. rpm -ivh kernel-default-5.0.13-1.1.gb11e2d7.x86_64.rpm --nodeps --oldpackage
And pass --test in addition for checking the installation, too.
sudo rpm -ivh kernel-default-5.0.13-1.1.gb11e2d7.x86_64.rpm --nodeps --oldpackage --test [sudo] password for root: Verifying... ################################# [100%] Preparing... ################################# [100%]
But, maybe you can start from other later 5.x kernel packages which is after usrmerge, too.
sudo rpm -ivh kernel-default-5.0.13-1.1.gb11e2d7.x86_64.rpm --nodeps --oldpackage Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:kernel-default-5.0.13-1.1.gb11e2d################################# [100%] depmod: ERROR: fstatat(5, nvidia-drm.ko): No such file or directory depmod: ERROR: fstatat(5, nvidia-modeset.ko): No such file or directory depmod: ERROR: fstatat(5, nvidia-uvm.ko): No such file or directory depmod: ERROR: fstatat(5, nvidia.ko): No such file or directory depmod: WARNING: could not open modules.builtin.modinfo at /usr/lib/modules/5.0.13-1.gb11e2d7-default: No such file or directory EFI variables are not supported on this system Failed to import /etc/uefi/certs/03454412.crt Now sudo dracut --kver 5.0.13-1.gb11e2d7-default dracut[I]: Executing: /usr/bin/dracut --kver 5.0.13-1.gb11e2d7-default dracut[I]: Module 'systemd-networkd' will not be installed, because command 'networkctl' could not be found! dracut[I]: Module 'systemd-networkd' will not be installed, because command '/usr/lib/systemd/systemd-networkd' could not be found! dracut[I]: Module 'systemd-networkd' will not be installed, because command '/usr/lib/systemd/systemd-networkd-wait-online' could not be found! dracut[I]: Module 'systemd-pcrphase' will not be installed, because command '/usr/lib/systemd/systemd-pcrextend' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command 'resolvectl' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command '/usr/lib/systemd/systemd-resolved' could not be found! dracut[I]: Module 'rngd' will not be installed, because command 'rngd' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut[I]: Module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut[I]: Module 'nvmf' will not be installed, because command 'jq' could not be found! dracut[I]: Module 'biosdevname' will not be installed, because command 'biosdevname' could not be found! dracut[I]: Module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut[I]: memstrack is not available dracut[I]: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut[I]: Module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut[I]: Module 'squash' will not be installed, because command 'unsquashfs' could not be found! dracut[I]: Module 'systemd-pcrphase' will not be installed, because command '/usr/lib/systemd/systemd-pcrextend' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command 'resolvectl' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command '/usr/lib/systemd/systemd-resolved' could not be found! dracut[I]: Module 'rngd' will not be installed, because command 'rngd' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut[I]: Module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut[I]: Module 'nvmf' will not be installed, because command 'jq' could not be found! dracut[I]: Module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut[I]: memstrack is not available dracut[I]: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut[I]: Module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut[I]: Module 'squash' will not be installed, because command 'unsquashfs' could not be found! dracut[I]: *** Including module: systemd *** dracut[I]: *** Including module: systemd-initrd *** dracut[I]: *** Including module: i18n *** dracut[I]: *** Including module: drm *** dracut[I]: *** Including module: plymouth *** dracut[I]: *** Including module: btrfs *** dracut[I]: *** Including module: crypt *** dracut[I]: *** Including module: dm *** dracut[I]: *** Including module: kernel-modules *** dracut[I]: *** Including module: kernel-modules-extra *** dracut[I]: *** Including module: lvm *** dracut[I]: *** Including module: resume *** dracut[I]: *** Including module: rootfs-block *** dracut[I]: *** Including module: suse-btrfs *** dracut[I]: *** Including module: suse-xfs *** dracut[I]: *** Including module: terminfo *** dracut[I]: *** Including module: udev-rules *** dracut[I]: *** Including module: dracut-systemd *** dracut[I]: *** Including module: haveged *** dracut[I]: *** Including module: ostree *** dracut[I]: *** Including module: selinux-microos *** dracut[I]: *** Including module: usrmount *** dracut[I]: *** Including module: base *** dracut[I]: *** Including module: fs-lib *** dracut[I]: *** Including module: shutdown *** dracut[I]: *** Including module: suse *** dracut[I]: *** Including module: suse-initrd *** dracut[I]: *** Including modules done *** dracut[I]: *** Installing kernel module dependencies *** depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/dracut.piEmK0/initramfs/usr/lib/modules/5.0.13-1.gb11e2d7-default: No such file or directory dracut[I]: *** Installing kernel module dependencies done *** dracut[I]: *** Resolving executable dependencies *** dracut[I]: *** Resolving executable dependencies done *** dracut[I]: *** Hardlinking files *** dracut[I]: *** Hardlinking files done *** dracut[I]: *** Generating early-microcode cpio image *** dracut[I]: *** Constructing GenuineIntel.bin *** dracut[I]: *** Store current command line parameters *** dracut[I]: Stored kernel commandline: dracut[I]: rd.driver.pre=btrfs dracut[I]: rd.luks.uuid=luks-d095bece-13e0-47ca-b2a9-f6119d3989fc dracut[I]: rd.lvm.lv=system/swap rd.lvm.lv=system/root dracut[I]: resume=UUID=e736498b-60e5-4f99-99c2-8a6850a78ca9 dracut[I]: root=UUID=605560ad-fe93-4d09-8760-df0725b43ee1 rootfstype=btrfs rootflags=rw,relatime,seclabel,ssd,space_cache,subvolid=2328,subvol=/@/.snapshots/1727/snapshot,subvol=@/.snapshots/1727/snapshot dracut[I]: *** Stripping files *** dracut[I]: *** Stripping files done *** dracut[I]: *** Creating image file '/boot/initrd-5.0.13-1.gb11e2d7-default' *** dracut[W]: Kernel has no zstd support compiled in. dracut[I]: Using auto-determined compression method 'pigz' dracut[I]: *** Creating initramfs image file '/boot/initrd-5.0.13-1.gb11e2d7-default' done *** Now /lib/modules contains 5.0.13-1.gb11e2d7-default I will powercycle and select the 5.0.13-1.gb11e2d7-default series kernel. If the machine fails to boot into sddm and then kde desktop environment I assume I can try the suspend states and reboot type in TTY1? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c28 --- Comment #28 from Paul Graff <pj.opensuse@gmx.com> --- After powercycleing there is no additional entry listed for the 5.0.13-1.gb11e2d7-default kernel. I have tried: sudo grub2-mkconfig -o /boot/grub2/grub.cfg [sudo] password for root: Generating grub configuration file ... Found theme: /boot/grub2/themes/openSUSE/theme.txt Found linux image: /boot/vmlinuz-6.11.6-2-default Found initrd image: /boot/initrd-6.11.6-2-default Found linux image: /boot/vmlinuz-6.11.5-2-default Found initrd image: /boot/initrd-6.11.5-2-default Found linux image: /boot/vmlinuz-6.11.3-1-default Found initrd image: /boot/initrd-6.11.3-1-default Found linux image: /boot/vmlinuz-6.11.2-1-default Found initrd image: /boot/initrd-6.11.2-1-default Found linux image: /boot/vmlinuz-6.11.0-1-default Found initrd image: /boot/initrd-6.11.0-1-default Found linux image: /boot/vmlinuz-6.10.5-1-default Found initrd image: /boot/initrd-6.10.5-1-default Found linux image: /boot/vmlinuz-6.10.3-1-default Found initrd image: /boot/initrd-6.10.3-1-default Found linux image: /boot/vmlinuz-6.10.2-1-default Found initrd image: /boot/initrd-6.10.2-1-default Found linux image: /boot/vmlinuz-6.9.9-1-default Found initrd image: /boot/initrd-6.9.9-1-default Found linux image: /boot/vmlinuz-6.9.7-1-default Found initrd image: /boot/initrd-6.9.7-1-default Found linux image: /boot/vmlinuz-6.6.11-1-default Found initrd image: /boot/initrd-6.6.11-1-default Found memtest image: /usr/lib/memtest86/memtest.bin Warning: os-prober will be executed to detect other bootable partitions. Its output will be used to detect bootable binaries on them and create new boot entries. 336.704778 | sdb: broken device without vendor ID 336.704828 | sdb: broken device without product ID 336.709854 | DM multipath kernel driver not loaded Adding boot menu entry for UEFI Firmware Settings ... done What am I missing here? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c30 --- Comment #30 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #29)
Hmm, not sure what went wrong. If this doesn't look easy, skip this kernel but try a newer one. Have not tried the https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.1/standard... kernel yet. But, before testing other kernels, please check the content of /sys/power/disk. On my system, it shows like: % cat /sys/power/disk [platform] shutdown reboot suspend test_resume
Try to choose shutdown: % echo -n shutdown > /sys/power/disk
Tried, # sudo echo -n shutdown > /sys/power/disk # cat /sys/power/disk platform [shutdown] reboot suspend test_resume
and retest. Hibernation retest results in same behavior as previous. Should this be used in conjunction with disabling all /proc/acpi/wakeup devices , changing /sys/kernel/reboot/type (1 of 6 options), as well as using ethtool to disable WoL? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c31 --- Comment #31 from Paul Graff <pj.opensuse@gmx.com> --- I was looking at the xorg log file and this is an excerpt from it. [ 32.998] (II) config/udev: Adding input device Power Button (/dev/input/event3) [ 32.998] (**) Power Button: Applying InputClass "evdev keyboard catchall" [ 32.998] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 32.998] (**) Power Button: Applying InputClass "system-keyboard" [ 32.998] (II) LoadModule: "libinput" [ 32.999] (II) Loading /usr/lib64/xorg/modules/input/libinput_drv.so [ 33.011] (II) Module libinput: vendor="X.Org Foundation" [ 33.011] compiled for 1.21.1.12, module version = 1.5.0 [ 33.011] Module class: X.Org XInput Driver [ 33.011] ABI class: X.Org XInput driver, version 24.4 [ 33.011] (II) Using input driver 'libinput' for 'Power Button' [ 33.011] (**) Power Button: always reports core events [ 33.011] (**) Option "Device" "/dev/input/event3" [ 33.022] (II) event3 - Power Button: is tagged by udev as: Keyboard [ 33.023] (II) event3 - Power Button: device is a keyboard [ 33.023] (II) event3 - Power Button: device removed [ 33.056] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3" [ 33.056] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6) [ 33.056] (**) Option "xkb_model" "pc105+inet" [ 33.056] (**) Option "xkb_layout" "us" [ 33.056] (**) Option "xkb_options" "terminate:ctrl_alt_bksp" [ 33.090] (II) event3 - Power Button: is tagged by udev as: Keyboard [ 33.090] (II) event3 - Power Button: device is a keyboard [ 33.091] (II) config/udev: Adding input device Power Button (/dev/input/event2) [ 33.091] (**) Power Button: Applying InputClass "evdev keyboard catchall" [ 33.091] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 33.091] (**) Power Button: Applying InputClass "system-keyboard" [ 33.091] (II) Using input driver 'libinput' for 'Power Button' [ 33.091] (**) Power Button: always reports core events [ 33.091] (**) Option "Device" "/dev/input/event2" [ 33.093] (II) event2 - Power Button: is tagged by udev as: Keyboard [ 33.093] (II) event2 - Power Button: device is a keyboard [ 33.093] (II) event2 - Power Button: device removed [ 33.116] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0C:00/input/input2/event2" [ 33.116] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 7) [ 33.116] (**) Option "xkb_model" "pc105+inet" [ 33.116] (**) Option "xkb_layout" "us" [ 33.116] (**) Option "xkb_options" "terminate:ctrl_alt_bksp" [ 33.118] (II) event2 - Power Button: is tagged by udev as: Keyboard [ 33.118] (II) event2 - Power Button: device is a keyboard Would any of this udev event3 - Power Button: is tagged by udev as: Keyboard [ 33.023] (II) event3 - Power Button: device is a keyboard Have anything to do with this perhaps? Regardless I have attached an xorg log file. -Thanks -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c32 --- Comment #32 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878620 --> https://bugzilla.suse.com/attachment.cgi?id=878620&action=edit xorg log file, udev, keyboard as pwrb -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c34 --- Comment #34 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #33)
Basically it's BIOS who wakes up, so whatever you see in the X log indicates the result of an action by BIOS, unlikely the cause.
Ok that's good to know.
And this doesn't happen you shutdown normally, right? Correct, when shutdown is attempted the machine does shutdown (turn off).
That would make things puzzling, because the problem happens even if you switch the hibernation to shutdown via /sys/power/disk change... I have just attempted what we are discussing with the 6.6.11-1-default kernel and there is no difference in behavior when envoking hibernation.
I am having no success with kernel 5.0.13-1.gb11e2d7-default and 5.1.16-1.g2af8a22-default appearing in boot menus kernel selections. They both appear in /lib/modules . -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c35 --- Comment #35 from Paul Graff <pj.opensuse@gmx.com> --- Created attachment 878656 --> https://bugzilla.suse.com/attachment.cgi?id=878656&action=edit lib modules two 5.xx series kernels displayed -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c37 --- Comment #37 from Paul Graff <pj.opensuse@gmx.com> --- Hi, I just attempted the following as root: # echo -n disk > /sys/power/state -bash: echo: write error: Cannot allocate memory I will attempt again after typing. It seems that after passing the above command network manager lost wired connection. Can you tell anymore from this message? -Thanks -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c38 --- Comment #38 from Paul Graff <pj.opensuse@gmx.com> --- The second attempt of passing: # echo -n disk > /sys/power/state succeeded with hibernation then the machine powered on and then and after entering LUKS passphrase booted directly into KDE DE with no SDDM login window. Have not tried /sys/power/disk *or* /sys/kernel/reboot/type variances as of yet with this. Suggestion on this please. -Thanks -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220088 https://bugzilla.suse.com/show_bug.cgi?id=1220088#c40 --- Comment #40 from Paul Graff <pj.opensuse@gmx.com> --- (In reply to Takashi Iwai from comment #39)
OK, the automatic power-up behavior itself doesn't change even if you do the direct write to /sys/power/state, right? If so, it concludes that systemd hooks are irrelevant with that behavior.
Takashi Iwai, thank you for all of your help with the Lenovo m57P type 9088 . I have migrated the machine to a distribution of Unix at this time. Is this report able to be labeled as pending perhaps? -Thank you -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com