Attempting to Hibernate, powercycles machine instead::
Hello, A question for you is that currently attempting to 'Hibernate' (tried twice), the machine goes through the process...halts/poweroff *completely* for about a second. All signs of PSU and display features turn off.... then suddenly powers up at bios menu. After entering the LUKS passphrase some boot information is displayed. pertaining to the prior "Hibernate" attempt (I believe). Here is some journalctl output on this: Thinkcentre-M57p:/> journalctl -b -1 | grep "hibernate" Feb 17 13:15:48 Thinkcentre-M57p systemd[1]: systemd-hibernate-resume.service: Deactivated successfully. - I recently created a PS2.Keyboard.service to try allow for 'suspend' to work with my PS/2 connector style keyboard in an attempt to mitigate the i8042 controller bug. The machine seems to work well now when suspend is envoked. - I have increased the swap partition and swap on the system to 15.5G . # swapon NAME TYPE SIZE USED PRIO /dev/dm-1 partition 15.5G 2.3G -2 Thinkcentre-M57p:/> lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS fd0 2:0 1 4K 0 disk sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 8M 0 part └─sda2 8:2 0 931.5G 0 part └─Lenovo_M57p-openSUSE_Tumbleweed 254:0 0 931.5G 0 crypt ├─system-swap 254:1 0 15.5G 0 lvm [SWAP] └─system-root 254:2 0 916G 0 lvm /var /usr/local /srv /root /opt /home /boot/grub2/x86_64-efi /boot/grub2/i386-pc /.snapshots / sdb 8:16 1 1.9G 0 disk └─luks-fd28e551-c765-461e-aab0-a2c49bb786b9 254:3 0 1.9G 0 crypt /run/media/paul/WORLDWIDE1 sr0 11:0 1 1024M 0 rom - Do you know what is going on here by preventing "hibernate' feature from functioning completely? -Regards
Hello, In the Message; Subject : Attempting to Hibernate, powercycles machine instead:: Message-ID : <5fad169b-c2e2-4bbf-a0ec-73f9a1dc85ff@gmx.com> Date & Time: Sat, 17 Feb 2024 20:26:05 -0600 [pj] == -pj via openSUSE Users <users@lists.opensuse.org> has written: [...] pj> I have increased the swap partition and swap on the system to 15.5G . pj> # swapon NAME TYPE SIZE USED PRIO pj> /dev/dm-1 partition 15.5G 2.3G -2 [..] What is -2? I have never seen a negative value.... (_ _? In my case, # swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 94.1G 2.4G 100 I'm going out now, so I'll leave the rest to the other members. Best Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "As Google fights for positioning in a new AI boom and an era where some consumers are turning to TikTok or ChatGPT instead of Google Search, some employees now worry product development could become dangerously hasty. The restructuring of RESIN has increased those concerns, the sources say." -- Google Splits Up a Key AI Ethics Watchdog --
On 2024-02-18 04:07, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : Attempting to Hibernate, powercycles machine instead:: Message-ID : <5fad169b-c2e2-4bbf-a0ec-73f9a1dc85ff@gmx.com> Date & Time: Sat, 17 Feb 2024 20:26:05 -0600
[pj] == -pj via openSUSE Users <users@lists.opensuse.org> has written:
[...] pj> I have increased the swap partition and swap on the system to 15.5G . pj> # swapon NAME TYPE SIZE USED PRIO pj> /dev/dm-1 partition 15.5G 2.3G -2 [..]
What is -2? I have never seen a negative value.... (_ _?
I have. Not a problem: Telcontar:~ # swapon NAME TYPE SIZE USED PRIO /dev/nvme0n1p2 partition 100G 696.5M -2 Telcontar:~ # Not my doing: Telcontar:~ # grep swap /etc/fstab LABEL=nvme-swap swap swap defaults 0 0 Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Hello, In the Message; Subject : Re: Attempting to Hibernate, powercycles machine instead:: Message-ID : <c7607ee0-9d91-4aed-967b-e9821ea76a57@telefonica.net> Date & Time: Sun, 18 Feb 2024 12:30:56 +0100 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: [...] MN> > What is -2? MN> > I have never seen a negative value.... (_ _? CER> I have. Not a problem: CER> Telcontar:~ # swapon CER> NAME TYPE SIZE USED PRIO CER> /dev/nvme0n1p2 partition 100G 696.5M -2 CER> Telcontar:~ # [...] Have you ever seen the man of swapon? [...] It is written in the man of swapon; Priority Each swap area has a priority, either high or low. The default prior‐ ity is low. Within the low‐priority areas, newer areas are even lower priority than older areas. All priorities set with swapflags are high‐priority, higher than de‐ fault. They may have any nonnegative value chosen by the caller. Higher numbers mean higher priority. Swap pages are allocated from areas in priority order, highest priority first. For areas with different priorities, a higher‐priority area is exhausted before using a lower‐priority area. If two or more areas have the same priority, and it is the highest priority available, pages are allocated on a round‐robin basis between them. [...] Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "As Google fights for positioning in a new AI boom and an era where some consumers are turning to TikTok or ChatGPT instead of Google Search, some employees now worry product development could become dangerously hasty. The restructuring of RESIN has increased those concerns, the sources say." -- Google Splits Up a Key AI Ethics Watchdog --
On 2024-02-18 22:16, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : Re: Attempting to Hibernate, powercycles machine instead:: Message-ID : <c7607ee0-9d91-4aed-967b-e9821ea76a57@telefonica.net> Date & Time: Sun, 18 Feb 2024 12:30:56 +0100
[CER] == "Carlos E. R." <robin.listas@telefonica.net> has written:
[...] MN> > What is -2? MN> > I have never seen a negative value.... (_ _?
CER> I have. Not a problem:
CER> Telcontar:~ # swapon CER> NAME TYPE SIZE USED PRIO CER> /dev/nvme0n1p2 partition 100G 696.5M -2 CER> Telcontar:~ # [...]
Have you ever seen the man of swapon?
Over two decades ago :-) I did not write a negative priority myself. What I wrote was this: Telcontar:~ # grep swap /etc/fstab LABEL=nvme-swap swap swap defaults 0 0 Telcontar:~ # Each field means: fs_spec = swap fs_file = swap fs_mntops = defaults fs_freq = 0 fs_passno = 0 That means "priority is set to default". "man 8 swapon" says: -p, --priority priority Specify the priority of the swap device. priority is a value between -1 and 32767. Higher numbers indicate higher priority. See swapon(2) for a full description of swap priorities. Add pri=value to the option field of /etc/fstab for use with swapon -a. When no priority is defined, it defaults to -1. So you see, as I did not specify any priority, the system, not me, sets a negative priority. Why -2 and not -1, I have no idea. This machine has 3 rotating disks and one nvme. All of them have swap partitions, but only one is declared in fstab, and that's the only one that is used. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-02-18 03:26, -pj via openSUSE Users wrote:
Hello,
A question for you is that currently attempting to 'Hibernate' (tried twice), the machine goes through the process...halts/poweroff *completely* for about a second. All signs of PSU and display features turn off.... then suddenly powers up at bios menu.
After entering the LUKS passphrase some boot information is displayed. pertaining to the prior "Hibernate" attempt (I believe).
Then, does it continue booting, or does it restore from hibernation?
Here is some journalctl output on this: Thinkcentre-M57p:/> journalctl -b -1 | grep "hibernate"
Feb 17 13:15:48 Thinkcentre-M57p systemd[1]: systemd-hibernate-resume.service: Deactivated successfully.
Nothing.
- I recently created a PS2.Keyboard.service to try allow for 'suspend' to work with my PS/2 connector style keyboard in an attempt to mitigate the i8042 controller bug. The machine seems to work well now when suspend is envoked. -
You could try removing temporarily the changes to the boot line, and see if that way you can hibernate. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 02-18-2024 05:34AM, Carlos E. R. wrote:
On 2024-02-18 03:26, -pj via openSUSE Users wrote:
Hello,
A question for you is that currently attempting to 'Hibernate' (tried twice), the machine goes through the process...halts/poweroff *completely* for about a second. All signs of PSU and display features turn off.... then suddenly powers up at bios menu.
After entering the LUKS passphrase some boot information is displayed. pertaining to the prior "Hibernate" attempt (I believe).
Then, does it continue booting, or does it restore from hibernation?
How can I perform a proper test to find out if the machine is in fact possibly restoring from a "hibernation" state? What to look for (read below)? To me (what I see) is, when the current hibernation is envoked and (automaticly at this time) reboot completes, and desktop GUI loads completely. Everything appears as before. For example, this email I am writing now appears. Konversation appears and channels are displayed. After more testing I can confirm that *yes* i believe the hibernation in itself is functioning. Please do note that I see a very fast *error* displayed after the LUKS passphrase has been given (only after the current automatic hibernation powercycle *not* normal powercycle) and the 'enter key' has been depressed. Would this possibly show up in a log perhaps? I believe this message may be unable to be photographed because it is so briefly displayed. I can try to take a photo though maybe.
Here is some journalctl output on this: Thinkcentre-M57p:/> journalctl -b -1 | grep "hibernate"
Feb 17 13:15:48 Thinkcentre-M57p systemd[1]: systemd-hibernate-resume.service: Deactivated successfully.
Nothing.
- I recently created a PS2.Keyboard.service to try allow for 'suspend' to work with my PS/2 connector style keyboard in an attempt to mitigate the i8042 controller bug. The machine seems to work well now when suspend is envoked. -
You could try removing temporarily the changes to the boot line, and see if that way you can hibernate.
Ok. To reaffirm, I removed the following from /etc/default/grub previously: # Removed the following from above (maybe causing lockups): i8042.nomux=1 i8042.reset i8042.noloop=1 Current kernel options in /etc/default/grub are: :~> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.7.4-1-default root=/dev/mapper/system-root resume=/dev/system/swap nosimplefb=1 splash=0 plymouth.enable=0 mitigations=auto Please do see if there may be a current kernel boot option shown above that may be an issue with hibernation. I have disabled the 'PS2-Keyboard.service' then powercycled, relogged into machine. Then attempted a hibernate and no change (in machine staying off when hibernate is envoked). -Great Regards
On 2024-02-18 18:58, -pj via openSUSE Users wrote:
On 02-18-2024 05:34AM, Carlos E. R. wrote:
On 2024-02-18 03:26, -pj via openSUSE Users wrote:
Hello,
A question for you is that currently attempting to 'Hibernate' (tried twice), the machine goes through the process...halts/poweroff *completely* for about a second. All signs of PSU and display features turn off.... then suddenly powers up at bios menu.
After entering the LUKS passphrase some boot information is displayed. pertaining to the prior "Hibernate" attempt (I believe).
Then, does it continue booting, or does it restore from hibernation?
How can I perform a proper test to find out if the machine is in fact possibly restoring from a "hibernation" state? What to look for (read below)?
Leave something open. An email half written, say. A file half edited (and not saved the last comma).
To me (what I see) is, when the current hibernation is envoked and (automaticly at this time) reboot completes, and desktop GUI loads completely. Everything appears as before. For example, this email I am writing now appears. Konversation appears and channels are displayed.
After more testing I can confirm that *yes* i believe the hibernation in itself is functioning.
Please do note that I see a very fast *error* displayed after the LUKS passphrase has been given (only after the current automatic hibernation powercycle *not* normal powercycle) and the 'enter key' has been depressed. Would this possibly show up in a log perhaps? I believe this message may be unable to be photographed because it is so briefly displayed. I can try to take a photo though maybe.
A video, perhaps. If the machine does in fact hibernate and restore, you will have the complete journal of the event. With the caveat that the timestamps will not all be correct, some entries from hibernation are in fact written to disk after restoring. There will be a part, when the tasks are frozen, that nothing can be logged. ...
You could try removing temporarily the changes to the boot line, and see if that way you can hibernate.
Ok. To reaffirm, I removed the following from /etc/default/grub previously: # Removed the following from above (maybe causing lockups): i8042.nomux=1 i8042.reset i8042.noloop=1
Current kernel options in /etc/default/grub are: :~> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.7.4-1-default root=/dev/mapper/system-root resume=/dev/system/swap nosimplefb=1 splash=0 plymouth.enable=0 mitigations=auto
Please do see if there may be a current kernel boot option shown above that may be an issue with hibernation.
I do not know. Just remove (and save in comments) everything you added to that line during the ps2 problem investigation
I have disabled the 'PS2-Keyboard.service'
That one you can leave, I think.
then powercycled, relogged into machine. Then attempted a hibernate and no change (in machine staying off when hibernate is envoked).
Machine continues and powers itself on and restores? Well, then you can put back the options, they don't have an effect. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 02-18-2024 01:58PM, Carlos E. R. wrote:
On 2024-02-18 18:58, -pj via openSUSE Users wrote:
On 02-18-2024 05:34AM, Carlos E. R. wrote:
On 2024-02-18 03:26, -pj via openSUSE Users wrote:
Hello,
A question for you is that currently attempting to 'Hibernate' (tried twice), the machine goes through the process...halts/poweroff *completely* for about a second. All signs of PSU and display features turn off.... then suddenly powers up at bios menu.
After entering the LUKS passphrase some boot information is displayed. pertaining to the prior "Hibernate" attempt (I believe).
Then, does it continue booting, or does it restore from hibernation?
How can I perform a proper test to find out if the machine is in fact possibly restoring from a "hibernation" state? What to look for (read below)?
Leave something open. An email half written, say. A file half edited (and not saved the last comma).
To me (what I see) is, when the current hibernation is envoked and (automaticly at this time) reboot completes, and desktop GUI loads completely. Everything appears as before. For example, this email I am writing now appears. Konversation appears and channels are displayed.
After more testing I can confirm that *yes* i believe the hibernation in itself is functioning.
Please do note that I see a very fast *error* displayed after the LUKS passphrase has been given (only after the current automatic hibernation powercycle *not* normal powercycle) and the 'enter key' has been depressed. Would this possibly show up in a log perhaps? I believe this message may be unable to be photographed because it is so briefly displayed. I can try to take a photo though maybe.
A video, perhaps.
Yes, I have taken a video of the error. I then took a snapshot of the error message out of the video and posted it here: https://paste.opensuse.org/pastes/f6af9e38c1ac
If the machine does in fact hibernate and restore, you will have the complete journal of the event. With the caveat that the timestamps will not all be correct, some entries from hibernation are in fact written to disk after restoring.
There will be a part, when the tasks are frozen, that nothing can be logged.
...
You could try removing temporarily the changes to the boot line, and see if that way you can hibernate.
Ok. To reaffirm, I removed the following from /etc/default/grub previously: # Removed the following from above (maybe causing lockups): i8042.nomux=1 i8042.reset i8042.noloop=1
Current kernel options in /etc/default/grub are: :~> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.7.4-1-default root=/dev/mapper/system-root resume=/dev/system/swap nosimplefb=1 splash=0 plymouth.enable=0 mitigations=auto
Please do see if there may be a current kernel boot option shown above that may be an issue with hibernation.
I do not know. Just remove (and save in comments) everything you added to that line during the ps2 problem investigation
Yes, I have done that now and powercycled. Also I have tested hibernate with the usbcore.autosuspend=-1 option in /etc/default/grub see below: Thinkcentre-M57p:/> cat /sys/module/usbcore/parameters/autosuspend -1 Thinkcentre-M57p:/> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.7.4-1-default root=/dev/mapper/system-root resume=/dev/system/swap nosimplefb=1 splash=0 plymouth.enable=0 mitigations=auto quiet splash usbcore.autosuspend=-1 Thinkcentre-M57p:/> Please do note: after this modification I used '# grub2-mkconfig -o /boot/grub2/grub.cfg' then powercycled, it did not take. Then I '# update-bootloader --refresh' then powercycled. It did take. It does seem to me that, '# update-bootloader --refresh' is better for updating grub. The usbcore.autosuspend=_1 option does not appear to help with basically anything from what I can tell for this situation.
I have disabled the 'PS2-Keyboard.service'
Yes, I have enabled the PS2.Keyboard.service once again.
That one you can leave, I think.
then powercycled, relogged into machine. Then attempted a hibernate and no change (in machine staying off when hibernate is envoked).
Machine continues and powers itself on and restores? Well, then you can put back the options, they don't have an effect.
I have also looked at the bios power setting and have them currently set to these in the following image located here: https://paste.opensuse.org/pastes/cbbc7060867b
Do note that once hibernate is envoked, I am able to *hold down* the power button *after* bios logo is displayed for a complete machine shutdown. Then I am able to hold power button to commence with machine boot from hibernation. Could the hibernate script itself need to possibly be adjusted for this particular machines needs? -Thanks
On 2024-02-18 22:45, -pj via openSUSE Users wrote:
On 02-18-2024 01:58PM, Carlos E. R. wrote:
On 2024-02-18 18:58, -pj via openSUSE Users wrote:
...
Please do note that I see a very fast *error* displayed after the LUKS passphrase has been given (only after the current automatic hibernation powercycle *not* normal powercycle) and the 'enter key' has been depressed. Would this possibly show up in a log perhaps? I believe this message may be unable to be photographed because it is so briefly displayed. I can try to take a photo though maybe.
A video, perhaps.
Yes, I have taken a video of the error. I then took a snapshot of the error message out of the video and posted it here: https://paste.opensuse.org/pastes/f6af9e38c1ac
Ah, you have been hunting with success :-) The message doesn't seem relevant to me, though. ...
Please do see if there may be a current kernel boot option shown above that may be an issue with hibernation.
I do not know. Just remove (and save in comments) everything you added to that line during the ps2 problem investigation
Yes, I have done that now and powercycled. Also I have tested hibernate with the usbcore.autosuspend=-1 option in /etc/default/grub see below:
Thinkcentre-M57p:/> cat /sys/module/usbcore/parameters/autosuspend -1
Thinkcentre-M57p:/> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.7.4-1-default root=/dev/mapper/system-root resume=/dev/system/swap nosimplefb=1 splash=0 plymouth.enable=0 mitigations=auto quiet splash usbcore.autosuspend=-1 Thinkcentre-M57p:/>
Please do note: after this modification I used '# grub2-mkconfig -o /boot/grub2/grub.cfg' then powercycled, it did not take.
Then I '# update-bootloader --refresh' then powercycled. It did take.
It does seem to me that, '# update-bootloader --refresh' is better for updating grub.
Different things. When you modify "/etc/default/grub" the command to use is solely 'grub2-mkconfig -o /boot/grub2/grub.cfg', because that is what the file itself documents.
The usbcore.autosuspend=_1 option does not appear to help with basically anything from what I can tell for this situation.
Ok, so that's out of the equation. Methinks, that if the machine does poweroff, there is something in the hardware that tells the machine to boot again. It thinks a button was pressed or something. A hardware defect. You could try with a "normal" usb keyboard.
I have disabled the 'PS2-Keyboard.service'
Yes, I have enabled the PS2.Keyboard.service once again.
That one you can leave, I think.
then powercycled, relogged into machine. Then attempted a hibernate and no change (in machine staying off when hibernate is envoked).
Machine continues and powers itself on and restores? Well, then you can put back the options, they don't have an effect.
I have also looked at the bios power setting and have them currently set to these in the following image located here: https://paste.opensuse.org/pastes/cbbc7060867b
Do note that once hibernate is envoked, I am able to *hold down* the power button *after* bios logo is displayed for a complete machine shutdown.
Right.
Then I am able to hold power button to commence with machine boot from hibernation. Could the hibernate script itself need to possibly be adjusted for this particular machines needs?
I'm not a true expert on this area, but I can not suspect of anything in the script that triggers the machine to boot again after it has pwoered off. Except a firmware bug or hardware defect. And you already have all wake on events disabled. Check whether there are BIOS/UEFI updates for your machine. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 02-18-2024 05:27PM, Carlos E. R. wrote:
On 2024-02-18 22:45, -pj via openSUSE Users wrote:
On 02-18-2024 01:58PM, Carlos E. R. wrote:
On 2024-02-18 18:58, -pj via openSUSE Users wrote:
...
Please do note that I see a very fast *error* displayed after the LUKS passphrase has been given (only after the current automatic hibernation powercycle *not* normal powercycle) and the 'enter key' has been depressed. Would this possibly show up in a log perhaps? I believe this message may be unable to be photographed because it is so briefly displayed. I can try to take a photo though maybe.
A video, perhaps.
Yes, I have taken a video of the error. I then took a snapshot of the error message out of the video and posted it here: https://paste.opensuse.org/pastes/f6af9e38c1ac
Ah, you have been hunting with success :-)
Yes, I thought about a video and didn't try to capture it before your response.
The message doesn't seem relevant to me, though.
Ok.
...
Please do see if there may be a current kernel boot option shown above that may be an issue with hibernation.
I do not know. Just remove (and save in comments) everything you added to that line during the ps2 problem investigation
Yes, I have done that now and powercycled. Also I have tested hibernate with the usbcore.autosuspend=-1 option in /etc/default/grub see below:
Thinkcentre-M57p:/> cat /sys/module/usbcore/parameters/autosuspend -1
Thinkcentre-M57p:/> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.7.4-1-default root=/dev/mapper/system-root resume=/dev/system/swap nosimplefb=1 splash=0 plymouth.enable=0 mitigations=auto quiet splash usbcore.autosuspend=-1 Thinkcentre-M57p:/>
Please do note: after this modification I used '# grub2-mkconfig -o /boot/grub2/grub.cfg' then powercycled, it did not take.
Then I '# update-bootloader --refresh' then powercycled. It did take.
It does seem to me that, '# update-bootloader --refresh' is better for updating grub.
Different things.
When you modify "/etc/default/grub" the command to use is solely 'grub2-mkconfig -o /boot/grub2/grub.cfg', because that is what the file itself documents.
[:|] Ok.
The usbcore.autosuspend=_1 option does not appear to help with basically anything from what I can tell for this situation.
Ok, so that's out of the equation.
I do notice that if "usbcore.autosuspend=_1" is used in /etc/default/grub the machine is able to be unsuspended by the pressing of a single key (on the PS/2 keyboard). There is no jamming or lockups either yet I can report.
Methinks, that if the machine does poweroff, there is something in the hardware that tells the machine to boot again. It thinks a button was pressed or something. A hardware defect.
:[ I have been using a wired ethernet connection (Cat 5) lately. Some time ago I installed a Ralink rt61p pci wireless card. I tried removing the card earlier. Going through the complete cycle. Turn machine on then load OS then hibernate after wireless card and ethernet cable had been removed. No success. It does seem like it thinks the button was pressed. It stays off for about 2 seconds maybe instead of only 1 second.
You could try with a "normal" usb keyboard.
I unplugged the PS/2 keyboard and then shutdown the machine. I connected the wireless usb keyboard and turned the machine on. I attempted to hibernate with only the usb keyboard dongle attached and no joy. Currently I have both the usb and the PS/2 keyboards attached and can use either. Do you think something in here can be the cause? Thinkcentre-M57p:~ # 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 *disabled platform:PNP0C0C:00 I tried toggling PWRB with: # echo PWRB > /proc/acpi/wakeup Then hibernating and no gain either.
I have disabled the 'PS2-Keyboard.service'
Yes, I have enabled the PS2.Keyboard.service once again.
That one you can leave, I think.
then powercycled, relogged into machine. Then attempted a hibernate and no change (in machine staying off when hibernate is envoked).
Machine continues and powers itself on and restores? Well, then you can put back the options, they don't have an effect.
I have also looked at the bios power setting and have them currently set to these in the following image located here: https://paste.opensuse.org/pastes/cbbc7060867b
Do note that once hibernate is envoked, I am able to *hold down* the power button *after* bios logo is displayed for a complete machine shutdown.
Right.
Then I am able to hold power button to commence with machine boot from hibernation. Could the hibernate script itself need to possibly be adjusted for this particular machines needs?
I'm not a true expert on this area, but I can not suspect of anything in the script that triggers the machine to boot again after it has pwoered off. Except a firmware bug or hardware defect.
Yes. Please see this error that was displayed in journalctl output from Feb 18 17:44:08 paul-Thinkcentre-M57p kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug If you are interested please review the following output from: Thinkcentre-M57p:/> journalctl -b -1 -r | grep "bug\|hibernate\|ACPI" Please see the short listing located here: https://paste.opensuse.org/pastes/d88e173b7bd6 Do you think this pci=nocrs above could be the culprit of sorts?
And you already have all wake on events disabled.
Yes. :|
Check whether there are BIOS/UEFI updates for your machine.
I have done so and there are not any. I will check again.
-Thanks
These are some new findings (for me) for the hibernation situation: https://en.opensuse.org/SDB:Suspend_to_disk - I think if I can implement this maybe here: https://en.opensuse.org/SDB:Suspend_to_disk#Shutdown_method Shutdown method After the image is written to disk, there are two methods to shut down the machine: going through the ACPI BIOS (called "platform mode") plain shutdown (as in a system shutdown) Usually the recommended mode is to go through the ACPI BIOS (on some machines this is necessary, otherwise various parts of the system might malfunction after resume, e.g. thermal management). *There are machines, which have problems with that and e.g. wake up immediately after shutting down this way.* The mode can be selected with *shutdown method = shutdown* *There are three methods to choose from: "platform", "shutdown" and "reboot", which is only useful for debugging: the machine reboots and resumes immediately.* - I am wondering if I should do the following: call pm-hibernate as root from a shell to invoke s2disk? - Then maybe edit /etc/suspend.conf (there is not currently an /etc/suspend.conf file). I believe this is because pm-hibernate has never been called? - Do you really think this could possibly be a hard - hardware bug of sorts? It seems debugging is possible, but my knowledge is limited. :[ - I do not want to give up on it yet. Do you believe I may be onto something with the above findings perhaps? - -Good Day
On 02-18-2024 09:38PM, -pj via openSUSE Users wrote:
These are some new findings (for me) for the hibernation situation: https://en.opensuse.org/SDB:Suspend_to_disk - I think if I can implement this maybe here: https://en.opensuse.org/SDB:Suspend_to_disk#Shutdown_method
I was incorrect with '# pm-hibernate' as it does not do anything. Also I neglected to see this statement at the top of the article: This article or section refers to the version '11.3' and it is now obsolete!
Shutdown method
After the image is written to disk, there are two methods to shut down the machine:
going through the ACPI BIOS (called "platform mode") plain shutdown (as in a system shutdown)
Usually the recommended mode is to go through the ACPI BIOS (on some machines this is necessary, otherwise various parts of the system might malfunction after resume, e.g. thermal management). *There are machines, which have problems with that and e.g. wake up immediately after shutting down this way.* The mode can be selected with
*shutdown method = shutdown*
*There are three methods to choose from: "platform", "shutdown" and "reboot", which is only useful for debugging: the machine reboots and resumes immediately.* - I am wondering if I should do the following: call pm-hibernate as root from a shell to invoke s2disk? - Then maybe edit /etc/suspend.conf (there is not currently an /etc/suspend.conf file). I believe this is because pm-hibernate has never been called? - Do you really think this could possibly be a hard - hardware bug of sorts? It seems debugging is possible, but my knowledge is limited. :[ - I do not want to give up on it yet. Do you believe I may be onto something with the above findings perhaps? -
-Good Day
On 2024-02-19 05:32, -pj via openSUSE Users wrote:
On 02-18-2024 09:38PM, -pj via openSUSE Users wrote:
These are some new findings (for me) for the hibernation situation: https://en.opensuse.org/SDB:Suspend_to_disk - I think if I can implement this maybe here: https://en.opensuse.org/SDB:Suspend_to_disk#Shutdown_method
I was incorrect with '# pm-hibernate' as it does not do anything. Also I neglected to see this statement at the top of the article: This article or section refers to the version '11.3' and it is now obsolete!
None the less, the three modes of shutdown do still exist. What I don't remember now is how to select one. The current method calls "systemctl hibernate", which in the end calls the kernel. echo a number to a variable in /proc/somewhere. I must have it in some bugzilla. [...] Can't locate it... Ah. There is a lot of information here: https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 02-19-2024 05:58AM, Carlos E. R. wrote:
On 2024-02-19 05:32, -pj via openSUSE Users wrote:
On 02-18-2024 09:38PM, -pj via openSUSE Users wrote:
These are some new findings (for me) for the hibernation situation: https://en.opensuse.org/SDB:Suspend_to_disk - I think if I can implement this maybe here: https://en.opensuse.org/SDB:Suspend_to_disk#Shutdown_method
I was incorrect with '# pm-hibernate' as it does not do anything. Also I neglected to see this statement at the top of the article: This article or section refers to the version '11.3' and it is now obsolete!
None the less, the three modes of shutdown do still exist. What I don't remember now is how to select one.
The current method calls "systemctl hibernate", which in the end calls the kernel. echo a number to a variable in /proc/somewhere. I must have it in some bugzilla.
[...]
Can't locate it...
Ah. There is a lot of information here:
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate
Thank you for this information. I will start working with it again. I have been trying to learn why machinhes btrfs filesystem became corrupted and full balance fails. It appears as if the use of partclone had something to do with it.
participants (3)
-
-pj -
Carlos E. R. -
Masaru Nomiya