S3 breaks system memory about skulls

[JeffreyAbbinante]

@notthebee is this happening on the latest version? I didn't notice any sleep issues personally.

[JeffreyAbbinante]

I am having this issue too. If I put the laptop to sleep it sometimes won't wake up. I switched back to the stock BIOS for now.

[merge]

I have this issue too and switched to hibernating. Would you mind searching https://ticket.coreboot.org/projects/coreboot/issues if there's a ticket about this?

[merge]

nevertheless, during the last 2 months there have been some changes in coreboot related to all lenovo boards, so I did a Skulls release that is basically a coreboot-bump.

Please report if this issue persists with the new version. thanks.

[khseal]

I confirm the problem with sleep on the latest version.

[notthebee]

I can confirm the problem too, for now pm-suspend-hybrid is a good backup option

[merge]

me neither...

[notthebee]

@JeffreyAbbinante @merge I installed the latest version and so far there are no issues with suspending. Will let you know if the issue comes back. Thank you!

[merge]

The S3 resume problem has occured quite often IRC. Let's wait a week or so before we (hopefully) close this issue.

[gazny]

My s3 issue is no longer present since release skulls-x230 0.0.11.

[JeffreyAbbinante]

This issue no longer exists on the latest skulls or any coreboot or heads rom that has been compiled since the previous 0.0.10 release. There were several changes made with regards to how sleep was handled on the newer coreboot versions. I've tested both skulls 0.0.11 and my own self compiled images on my own x230 and sleep works fine.

[varac]

I use skulls 0.1.0 and its released non-free images. Everything works so but but not resuming from hibernate. These are the regarding boot msgs trying to resume:

Jan 03 11:42:16 rocinante kernel: PM: Image signature found, resuming
Jan 03 11:42:16 rocinante kernel: PM: resume from hibernation
Jan 03 11:42:16 rocinante kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Jan 03 11:42:16 rocinante kernel: OOM killer disabled.
Jan 03 11:42:16 rocinante kernel: PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
Jan 03 11:42:16 rocinante kernel: PM: Marking nosave pages: [mem 0x0009f000-0x000fffff]
Jan 03 11:42:16 rocinante kernel: PM: Marking nosave pages: [mem 0xbff0d000-0xffffffff]
Jan 03 11:42:16 rocinante kernel: PM: Basic memory bitmaps created
Jan 03 11:42:16 rocinante kernel: PM: Using 3 thread(s) for decompression
Jan 03 11:42:16 rocinante kernel: PM: Loading and decompressing image data (702020 pages)...
Jan 03 11:42:16 rocinante kernel: Hibernate inconsistent memory map detected!
Jan 03 11:42:16 rocinante kernel: PM: Image mismatch: architecture specific data
Jan 03 11:42:16 rocinante kernel: PM: Read 2808080 kbytes in 0.01 seconds (280808.00 MB/s)
Jan 03 11:42:16 rocinante kernel: PM: Error -1 resuming
Jan 03 11:42:16 rocinante kernel: PM: Failed to load hibernation image, recovering.
Jan 03 11:42:16 rocinante kernel: PM: Basic memory bitmaps freed
Jan 03 11:42:16 rocinante kernel: OOM killer enabled.
Jan 03 11:42:16 rocinante kernel: Restarting tasks ... done.
Jan 03 11:42:16 rocinante kernel: video LNXVIDEO:00: Restoring backlight state
Jan 03 11:42:16 rocinante kernel: PM: resume from hibernation failed (-1)

My dmidecode details:

# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: coreboot
	Version: CBET4000 4.8-2601-g2ca2acc51f-dirty
	Release Date: 12/19/2018
	ROM Size: 12288 kB
	Characteristics:
		PCI is supported
		PC Card (PCMCIA) is supported
		BIOS is upgradeable
		Selectable boot is supported
		ACPI is supported
		Targeted content distribution is supported
	BIOS Revision: 4.0
	Firmware Revision: 0.0

Should I open a dedicated issues for this, to not mix sleep/hibernate modes in this issue ?

[varac]

Btw, I'm confused about the git commit reference in the skulls 0.1.0 release announcment:

This release includes the following changes:

based on coreboot commit 2ca2acc51f
(parent in master branch 47d6663bba)

I couldn't find 2ca2acc51f in any of upstream coreboot branches, and 47d6663bba is quite old (from Mon May 2 23:16:57 2016).

@merge: Can you please check those commit references ?

[paulmenzel]

Am 03.01.19 um 12:02 schrieb Varac:

Btw, I'm confused about the git commit reference in the [skulls 0.1.0 release announcment](https://github.com/merge/skulls/releases/tag/0.1.0): ``` This release includes the following changes: based on coreboot commit 2ca2acc51f (parent in master branch 47d6663bba) ``` I couldn't find `2ca2acc51f` in any of upstream coreboot branches, and `47d6663bba` is quite old (from `Mon May 2 23:16:57 2016`).

No idea, where commit 2ca2acc51f is, but the other one was indeed only committed this December 2018 despite being authored over two years ago. `git show --format=fuller 47d6663bba` shows the commit date. commit 47d6663bba233014dc6d418b94ad6161751f2176 Author: Stefan Tauner <[email protected]> AuthorDate: Mon May 2 23:16:57 2016 +0200 Commit: Patrick Georgi <[email protected]> CommitDate: Wed Dec 19 10:21:32 2018 +0000 utils: introduce find_usbdebug.sh to help find USB debug ports

[varac]

@paulmenzel Oh, thanks for noticing. What a huge QA period where a commit reaches master after 2,5 years 😨

[merge]

I'm on vacation until next week, but so much: 2ca2acc51f should be found using skulls git log, i.e. the changes we pull in out-of-tree. But that's only a blobs repo bump as of now.

[varac]

@merge: I don't understand - I also couldn't find 2ca2acc51 in the skulls git log. It's not urgent - if you have time please paste a command that can be used to find this commit.

[merge]

what's going on is this: A "upstream bump" change like this pulls in out of tree changes that are up at review.coreboot.org. That's then the git HEAD we build; the git commit in question.

How should we improve our docs?

[varac]

@merge Ok, now I got it.

How should we improve our docs?

Well you know best what gets pulled in - at least please reference those commits that can't be found from a simple git log, like pointing to the non-merged merge request https://review.coreboot.org/c/coreboot/+/30308 i.e.

[varac]

Regarding the original issue here - resuming from hibernate still doesn't work for, should I open an issue for this ?

[merge]

yes, please