Hello! Please, someone tell me, why SeaBIOS changing e820 memory map for 0x100000 - 0x7ff2dfff region? For example:
Jun 4 21:41:31 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2dfff] usable Jun 4 21:49:24 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2efff] usable Jun 4 21:50:36 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2efff] usable Jun 6 23:09:46 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2ffff] usable Jun 8 20:46:35 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2efff] usable Jun 8 21:04:49 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2dfff] usable Jun 8 21:05:30 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2efff] usable Jun 9 17:25:25 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2efff] usable Jun 9 22:15:33 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2dfff] usable Jun 10 20:42:33 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2efff] usable Jun 10 20:43:12 tp0 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ff2efff] usable
This interrupts the boot from hibernation:
tp0 kernel: [ 6.241612] Hibernate inconsistent memory map detected! tp0 kernel: [ 6.243876] PM: Image mismatch: architecture specific data tp0 kernel: [ 6.246132] PM: Read 3253276 kbytes in 0.01 seconds (325327.60 MB/s) tp0 kernel: [ 6.248816] PM: Error -1 resuming tp0 kernel: [ 6.248852] PM: Failed to load hibernation image, recovering.
OS Debian testing Linux tp0 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 Thinkpad T420 with IvyBridge i5-3380M coreboot-4.9-1980-g66bcc3101e SeaBIOS (version rel-1.12.1-0-ga5cab58)
Thanks!
On Mon, Jun 10, 2019 at 9:15 PM Andrew A. I. aidron@yandex.ru wrote:
Hello! Please, someone tell me, why SeaBIOS changing e820 memory map for 0x100000 - 0x7ff2dfff region? For example:
Could you collect and share the coreboot logs with 'util/cbmem -1'. I've seen similar hibernate/resume failure before, it was then related to the changed memory layout of coreboot tables (which is reflected in the e820 table SeaBIOS creates). In short, hibernate (ACPI S4) does not work on the first boot after flashing firmware or change of DIMMs. It's about MRC CACHE being allocated in CBMEM for the initial boot, but not the following resume boots.
If this is your case too, there should be an easy fix by adding a dummy reserve, but sounds like nobody has taken the initiative to submit such change. As an alternative solution, I would like to see runtime code to mask of ACPI S4 and S3 features from SSDT/DSDT.
Kyösti
Hello, Kyösti! cbmem log in attachment. I am rebooting and/or powering off after upgrading corboot firmware for verify. It doesn't help, as I remember.
Andrew.
10.06.2019, 22:59, "Kyösti Mälkki" kyosti.malkki@gmail.com:
On Mon, Jun 10, 2019 at 9:15 PM Andrew A. I. aidron@yandex.ru wrote:
Hello! Please, someone tell me, why SeaBIOS changing e820 memory map for 0x100000 - 0x7ff2dfff region? For example:
Could you collect and share the coreboot logs with 'util/cbmem -1'. I've seen similar hibernate/resume failure before, it was then related to the changed memory layout of coreboot tables (which is reflected in the e820 table SeaBIOS creates). In short, hibernate (ACPI S4) does not work on the first boot after flashing firmware or change of DIMMs. It's about MRC CACHE being allocated in CBMEM for the initial boot, but not the following resume boots.
If this is your case too, there should be an easy fix by adding a dummy reserve, but sounds like nobody has taken the initiative to submit such change. As an alternative solution, I would like to see runtime code to mask of ACPI S4 and S3 features from SSDT/DSDT.
Kyösti
On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I. aidron@yandex.ru wrote:
Hello, Kyösti! cbmem log in attachment. I am rebooting and/or powering off after upgrading corboot firmware for verify. It doesn't help, as I remember.
Logs from both a cold boot and hibernation resume would be needed for comparison.
But this pretty much sounds like the case of entering ACPI S4 from a boot that did memory training and wrote MRC CACHE in SPI. This is the known failing case described earlier.
Kyösti
In case it would have any meaning:
https://mail.coreboot.org/pipermail/seabios/2018-November/012553.html
My colleague discovered some inconsistence between coreboot tables and e820 in SeaBIOS. However the patch has been forgotten on the mailing list.
Best regards, Michał
On 11.06.2019 07:28, Kyösti Mälkki wrote:
On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I. aidron@yandex.ru wrote:
Hello, Kyösti! cbmem log in attachment. I am rebooting and/or powering off after upgrading corboot firmware for verify. It doesn't help, as I remember.
Logs from both a cold boot and hibernation resume would be needed for comparison.
But this pretty much sounds like the case of entering ACPI S4 from a boot that did memory training and wrote MRC CACHE in SPI. This is the known failing case described earlier.
Kyösti _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
cbmem log after cold boot (power off) and hibernate (success resume). Did MRC cache present (and used) in case of IvyBridge CPU and native memory init without FSP?
11.06.2019, 08:29, "Kyösti Mälkki" kyosti.malkki@gmail.com:
On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I. aidron@yandex.ru wrote:
Hello, Kyösti! cbmem log in attachment. I am rebooting and/or powering off after upgrading corboot firmware for verify. It doesn't help, as I remember.
Logs from both a cold boot and hibernation resume would be needed for comparison.
But this pretty much sounds like the case of entering ACPI S4 from a boot that did memory training and wrote MRC CACHE in SPI. This is the known failing case described earlier.
Kyösti _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
And cbmem logs after updating coreboot firmware. After power-off and resume from hibernate (fail)
11.06.2019, 08:29, "Kyösti Mälkki" kyosti.malkki@gmail.com:
On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I. aidron@yandex.ru wrote:
Hello, Kyösti! cbmem log in attachment. I am rebooting and/or powering off after upgrading corboot firmware for verify. It doesn't help, as I remember.
Logs from both a cold boot and hibernation resume would be needed for comparison.
But this pretty much sounds like the case of entering ACPI S4 from a boot that did memory training and wrote MRC CACHE in SPI. This is the known failing case described earlier.
Kyösti _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Andrew A. I. -
Kyösti Mälkki -
Michal Zygowski