Intel: After suspend/resume `cbmem -l` fails with `Program cbmem tried to access /dev/mem between f0000->1f0000.`
Dear coreboot folks,
first of all I wish everyone a happy new year!
On the i945 based Lenovo X60, running `cbmem -l` (or any other option) works fine. Suspending and resuming the system, running any `cbmem` commands does *not* work anymore.
$ sudo pm-suspend $ sudo cbmem -l Failed to mmap /dev/mem: Operation not permitted $ dmesg | tail -1 [ 2834.560179] Program cbmem tried to access /dev/mem between f0000->1f0000.
I think in Prague, it could also be reproduced on Vladimir’s Lenovo X230(?).
Do you have any idea, why this happens? Is that a Linux error?
It’d be great if you Intel device owners, could try to reproduce it.
Thanks,
Paul
$ sudo cbmem -l CBMEM table of contents: ID START LENGTH 0. CBMEM ROOT 7f7ff000 00001000 1. CAR GLOBALS 7f7fe000 00001000 2. CONSOLE 7f7de000 00020000 3. TIME STAMP 7f7dd000 00001000 4. ROMSTAGE 7f7dc000 00001000 5. GDT 7f7db000 00001000 6. IRQ TABLE 7f7da000 00001000 7. SMP TABLE 7f7d9000 00001000 8. ACPI 7f7cd000 0000c000 9. SMBIOS 7f7cc000 00001000 10. ACPI RESUME 7f6cc000 00100000 11. COREBOOT 7f6c4000 00008000 $ more /proc/iomem 00000000-00000fff : reserved 00001000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : PCI Bus 0000:00 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000c0000-000c3fff : PCI Bus 0000:00 000c4000-000c7fff : PCI Bus 0000:00 000c8000-000cbfff : PCI Bus 0000:00 000cc000-000cffff : PCI Bus 0000:00 000d0000-000d3fff : PCI Bus 0000:00 000d4000-000d7fff : PCI Bus 0000:00 000d8000-000dbfff : PCI Bus 0000:00 000dc000-000dffff : PCI Bus 0000:00 000e0000-000e3fff : PCI Bus 0000:00 000e4000-000e7fff : PCI Bus 0000:00 000e8000-000ebfff : PCI Bus 0000:00 000ec000-000effff : PCI Bus 0000:00 000f0000-000fffff : PCI Bus 0000:00 000f0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-7f6c2fff : System RAM 01000000-01490f89 : Kernel code 01490f8a-0167c73f : Kernel data 0172d000-017a1fff : Kernel bss 7f6c3000-7fffffff : reserved 7f800000-7ffbffff : Graphics Stolen Memory 80000000-febfffff : PCI Bus 0000:00 80000000-801fffff : PCI Bus 0000:01 84000000-87ffffff : PCI CardBus 0000:06 88000000-8bffffff : PCI CardBus 0000:06 d0000000-dfffffff : 0000:00:02.0 e0000000-e20fffff : PCI Bus 0000:05 e2000000-e2000fff : 0000:05:00.0 e2000000-e2000fff : yenta_socket e2001000-e20017ff : 0000:05:00.1 e2001000-e20017ff : firewire_ohci e2001800-e20018ff : 0000:05:00.2 e2001800-e20018ff : mmc0 e2100000-e40fffff : PCI Bus 0000:05 e4100000-e41fffff : PCI Bus 0000:01 e4100000-e411ffff : 0000:01:00.0 e4100000-e411ffff : e1000e e4200000-e42fffff : PCI Bus 0000:02 e4200000-e4200fff : 0000:02:00.0 e4200000-e4200fff : iwl3945 e4300000-e437ffff : 0000:00:02.0 e4380000-e43fffff : 0000:00:02.1 e4400000-e443ffff : 0000:00:02.0 e4440000-e4443fff : 0000:00:1b.0 e4440000-e4443fff : ICH HD audio e4444000-e44443ff : 0000:00:1d.7 e4444000-e44443ff : ehci_hcd e4444400-e44447ff : 0000:00:1f.2 e4444400-e44447ff : ahci f0000000-f3ffffff : PCI MMCONFIG 0000 [bus 00-3f] f0000000-f3ffffff : reserved f0000000-f3ffffff : pnp 00:00 fec00000-fec003ff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed00000-fed003ff : pnp 00:01 fed14000-fed17fff : pnp 00:00 fed18000-fed18fff : pnp 00:00 fed19000-fed19fff : pnp 00:00 fed1c000-fed1ffff : pnp 00:00 fed1f410-fed1f414 : iTCO_wdt fed1f410-fed1f414 : iTCO_wdt fed20000-fed3ffff : pnp 00:00 fed40000-fed44fff : PCI Bus 0000:00 fed40000-fed44fff : pnp 00:00 fed45000-fed8ffff : pnp 00:00 fee00000-fee00fff : Local APIC ff000000-ffffffff : INT0800:00 $ sudo pm-suspend $ sudo cbmem -l Failed to mmap /dev/mem: Operation not permitted $ dmesg | tail -1 [ 2834.560179] Program cbmem tried to access /dev/mem between f0000->1f0000. $ sudo strace cbmem -l […] open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\233\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1742588, ...}) = 0 mmap2(NULL, 1747580, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb756e000 mmap2(0xb7713000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a5000) = 0xb7713000 mmap2(0xb7716000, 10876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7716000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb756d000 set_thread_area({entry_number:-1, base_addr:0xb756d940, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6) mprotect(0xb7713000, 8192, PROT_READ) = 0 mprotect(0xb775e000, 4096, PROT_READ) = 0 munmap(0xb7719000, 130429) = 0 open("/dev/mem", O_RDONLY) = 3 mmap2(NULL, 1048576, PROT_READ, MAP_SHARED, 3, 0) = 0xb746d000 munmap(0xb746d000, 1048576) = 0 mmap2(NULL, 1048576, PROT_READ, MAP_SHARED, 3, 0xf0000) = -1 EPERM (Operation not permitted) write(2, "Failed to mmap /dev/mem: Operati"..., 49Failed to mmap /dev/mem: Operation not permitted ) = 49 exit_group(1) = ? +++ exited with 1 +++
On the i945 based Lenovo X60, running `cbmem -l` (or any other option) works fine. Suspending and resuming the system, running any `cbmem` commands does *not* work anymore.
Running cbmem -Vl on my X60t shows that the first run finds the table in the first 1 MiB of memory, after suspend it doesn't and fails to mmap memory containing RAM after the first 1 MiB.
[ 2834.560179] Program cbmem tried to access /dev/mem between f0000->1f0000.
Kernel code prevents accesses to RAM, allowing only access to the first 1 MiB and MMIO.
Do you have any idea, why this happens? Is that a Linux error?
Using dd, grep and hexdump shows that the coreboot table entry at memory address 0x500 gets zeroed. /proc/iomem considers that address "reserved".
Am Sonntag, den 04.01.2015, 12:44 +0100 schrieb Michał Masłowski:
On the i945 based Lenovo X60, running `cbmem -l` (or any other option) works fine. Suspending and resuming the system, running any `cbmem` commands does *not* work anymore.
Running cbmem -Vl on my X60t shows that the first run finds the table in the first 1 MiB of memory, after suspend it doesn't and fails to mmap memory containing RAM after the first 1 MiB.
Does somebody have a coreboot log from serial or USB for cold boot and resume, please? I am unable to get one right now, because the docking station is not here.
[ 2834.560179] Program cbmem tried to access /dev/mem between f0000->1f0000.Kernel code prevents accesses to RAM, allowing only access to the first 1 MiB and MMIO.
Do you have any idea, why this happens? Is that a Linux error?
Using dd, grep and hexdump shows that the coreboot table entry at memory address 0x500 gets zeroed. /proc/iomem considers that address "reserved".
Thank you for the analysis.
Thanks,
Paul
Does somebody have a coreboot log from serial or USB for cold boot and resume, please? I am unable to get one right now, because the docking station is not here.
I have logs from EHCI debug: normal boot and resume from suspend to RAM.
Using dd, grep and hexdump shows that the coreboot table entry at memory address 0x500 gets zeroed. /proc/iomem considers that address "reserved".
Guessing from searching the code: smm_setup_structures from src/southbridge/intel/i82801gx/smi.c overwrote it, called by acpi_resume in src/arch/x86/boot/acpi.c. I haven't checked how the (mentioned in the comment) GNVS relocation or coreboot table writing are done, nor how it's different when resuming.
Am Dienstag, den 06.01.2015, 12:30 +0100 schrieb Michał Masłowski:
Does somebody have a coreboot log from serial or USB for cold boot and resume, please? I am unable to get one right now, because the docking station is not here.
I have logs from EHCI debug: normal boot and resume from suspend to RAM.
Thanks a lot!
Using dd, grep and hexdump shows that the coreboot table entry at memory address 0x500 gets zeroed. /proc/iomem considers that address "reserved".
Guessing from searching the code: smm_setup_structures from src/southbridge/intel/i82801gx/smi.c overwrote it, called by acpi_resume in src/arch/x86/boot/acpi.c. I haven't checked how the (mentioned in the comment) GNVS relocation or coreboot table writing are done, nor how it's different when resuming.
Yes, that looks correct. Thank you for the analysis. Looking through the code, the function is implemented differently for Intel BD82x6x and later models. I tried to quickly backport this to Intel 82801Gx, but failed [1]. Stefan gave some good hints already:
I think on core / core2 SMM is not using TSEG (in our implementation), so you'll have to look at the ASEG.
Since you might be running on either a core cpu (32bit) or core2 (64bit) you might need to determine what CPU you're running on (at runtime) and use the according XXX_state_save_area_t. If the offsets for the registers you are looking at are the same for both CPU types, you can probably avoid that..
Look at src/cpu/x86/smm/smihandler.c for how stuff was set up there.
and
rbx doesn't exist on 32bit CPUs, so you'll have switch at runtime here depending on the CPU type.
Kyösti also replied:
FYI: I have an incompleted patchset to convert from SMM TSEG relocator to SMM_MODULES, and I do not see what would prevent from converting ASEG SMI handlers to SMM_MODULE too.
So, I guess I’ll wait until that work is done. If somebody else has another idea how to solve that for the Intel 82801Gx, please share.
Thanks,
Paul
-
mtjm＠mtjm.eu -
Paul Menzel