* kexec regression since 4.9 caused by efi
@ 2017-03-08 20:16 Omar Sandoval
2017-03-09 2:21 ` Dave Young
2017-03-09 6:38 ` Dave Young
0 siblings, 2 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-03-08 20:16 UTC (permalink / raw)
To: Matt Fleming, Dave Young, Ingo Molnar; +Cc: linux-kernel, kernel-team
Hi, everyone,
Since 4.9, kexec results in the following panic on some of our servers:
[ 0.001000] general protection fault: 0000 [#1] SMP
[ 0.001000] Modules linked in:
[ 0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
[ 0.001000] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
[ 0.001000] task: ffffffff81e0e4c0 task.stack: ffffffff81e00000
[ 0.001000] RIP: 0010:virt_efi_set_variable+0x85/0x1a0
[ 0.001000] RSP: 0000:ffffffff81e03e18 EFLAGS: 00010202
[ 0.001000] RAX: afafafafafafafaf RBX: ffffffff81e3a4e0 RCX: 0000000000000007
[ 0.001000] RDX: ffffffff81e03e70 RSI: ffffffff81e3a4e0 RDI: ffff88407f8c2de0
[ 0.001000] RBP: ffffffff81e03e60 R08: 0000000000000000 R09: 0000000000000000
[ 0.001000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81e03e70
[ 0.001000] R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
[ 0.001000] FS: 0000000000000000(0000) GS:ffff881fff600000(0000) knlGS:0000000000000000
[ 0.001000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.001000] CR2: ffff88407f30f000 CR3: 0000001fff102000 CR4: 00000000000406b0
[ 0.001000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.001000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.001000] Call Trace:
[ 0.001000] efi_delete_dummy_variable+0x7a/0x80
[ 0.001000] efi_enter_virtual_mode+0x3e2/0x494
[ 0.001000] start_kernel+0x392/0x418
[ 0.001000] ? set_init_arg+0x55/0x55
[ 0.001000] x86_64_start_reservations+0x2a/0x2c
[ 0.001000] x86_64_start_kernel+0xea/0xed
[ 0.001000] start_cpu+0x14/0x14
[ 0.001000] Code: 42 25 8d ff 80 3d 43 77 95 00 00 75 68 9c 8f 04 24 48 8b 05 3e 7d 7e 00 48 89 de 4d 89 f9 4d 89 f0 44 89 e9 4c 89 e2 48 8b 40 58 <48> 8b 78 58 31 c0 e8 90 e4 92 ff 48 8b 3c 24 48 c7 c6 2b 0a ca
[ 0.001000] RIP: virt_efi_set_variable+0x85/0x1a0 RSP: ffffffff81e03e18
[ 0.001000] ---[ end trace 0bd213e540e9b19f ]---
[ 0.001000] Kernel panic - not syncing: Fatal exception
[ 0.001000] ---[ end Kernel panic - not syncing: Fatal exception
Booting normally (i.e., not kexec) still works.
The decoded code is:
0: 42 25 8d ff 80 3d rex.X and $0x3d80ff8d,%eax
6: 43 77 95 rex.XB ja 0xffffffffffffff9e
9: 00 00 add %al,(%rax)
b: 75 68 jne 0x75
d: 9c pushfq
e: 8f 04 24 popq (%rsp)
11: 48 8b 05 3e 7d 7e 00 mov 0x7e7d3e(%rip),%rax # 0x7e7d56
18: 48 89 de mov %rbx,%rsi
1b: 4d 89 f9 mov %r15,%r9
1e: 4d 89 f0 mov %r14,%r8
21: 44 89 e9 mov %r13d,%ecx
24: 4c 89 e2 mov %r12,%rdx
27: 48 8b 40 58 mov 0x58(%rax),%rax
2b:* 48 8b 78 58 mov 0x58(%rax),%rdi <-- trapping instruction
2f: 31 c0 xor %eax,%eax
31: e8 90 e4 92 ff callq 0xffffffffff92e4c6
36: 48 8b 3c 24 mov (%rsp),%rdi
3a: 48 rex.W
3b: c7 .byte 0xc7
3c: c6 (bad)
3d: 2b 0a sub (%rdx),%ecx
3f: ca .byte 0xca
If I'm reading this correctly, efi.systab->runtime == 0xafafafafafafafaf,
and we're crashing when we try to dereference that.
Here is the output of efi=debug from before the crash:
[ 0.000000] Linux version 4.11.0-rc1 (osandov@devbig561.prn1.facebook.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #53 SMP Wed Mar 8 12:07:16 PST 2017
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.6.7-34_fbk7_2504_g8275185 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 co
nsole=ttyS1,57600 efi=debug
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] extended physical RAM map:
[ 0.000000] reserve setup_data: [mem 0x0000000000000100-0x000000000009ffff] usable
[ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000010006f] usable
[ 0.000000] reserve setup_data: [mem 0x0000000000100070-0x00000000750bdfff] usable
[ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] efi: EFI v2.40 by American Megatrends
[ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
[ 0.000000] efi: mem00: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
[ 0.000000] efi: mem01: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
[ 0.000000] efi: mem02: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
[ 0.000000] efi: mem03: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
[ 0.000000] efi: mem04: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
[ 0.000000] efi: mem05: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
[ 0.000000] SMBIOS 3.0.0 present.
[ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
[ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
[ 0.000000] x2apic: enabled by BIOS, switching to x2apic ops
[ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
[ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
Reverting commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and
avoid a kmalloc()") on top of v4.11-rc1 fixes the problem. Bisecting
this was interesting:
- Up until 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a
kmalloc()"), kexec worked.
- From 8e80632fb23f to 9d80448ac92b ("efi/arm64: Add debugfs node to
dump UEFI runtime page tables"), kexec just hung after the
"kexec_core: Starting new kernel" message.
- From 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init until after
memblock_x86_fill") to 0a637ee61247 ("x86/efi: Allow invocation of
arbitrary boot services"), kexec hit the BUG_ON(!efi.systab) in
kexec_enter_virtual_mode().
- Finally, after 92dc33501bfb ("x86/efi: Round EFI memmap reservations
to EFI_PAGE_SIZE"), I get the panic described above.
Let me know if there is any more information I can provide.
Thanks!
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-08 20:16 kexec regression since 4.9 caused by efi Omar Sandoval
@ 2017-03-09 2:21 ` Dave Young
2017-03-09 3:36 ` Omar Sandoval
2017-03-09 6:38 ` Dave Young
1 sibling, 1 reply; 55+ messages in thread
From: Dave Young @ 2017-03-09 2:21 UTC (permalink / raw)
To: Omar Sandoval; +Cc: Matt Fleming, Ingo Molnar, linux-kernel, kernel-team
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [ 0.001000] general protection fault: 0000 [#1] SMP
> [ 0.001000] Modules linked in:
> [ 0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
> [ 0.001000] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.001000] task: ffffffff81e0e4c0 task.stack: ffffffff81e00000
> [ 0.001000] RIP: 0010:virt_efi_set_variable+0x85/0x1a0
> [ 0.001000] RSP: 0000:ffffffff81e03e18 EFLAGS: 00010202
> [ 0.001000] RAX: afafafafafafafaf RBX: ffffffff81e3a4e0 RCX: 0000000000000007
> [ 0.001000] RDX: ffffffff81e03e70 RSI: ffffffff81e3a4e0 RDI: ffff88407f8c2de0
> [ 0.001000] RBP: ffffffff81e03e60 R08: 0000000000000000 R09: 0000000000000000
> [ 0.001000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81e03e70
> [ 0.001000] R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
> [ 0.001000] FS: 0000000000000000(0000) GS:ffff881fff600000(0000) knlGS:0000000000000000
> [ 0.001000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.001000] CR2: ffff88407f30f000 CR3: 0000001fff102000 CR4: 00000000000406b0
> [ 0.001000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 0.001000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 0.001000] Call Trace:
> [ 0.001000] efi_delete_dummy_variable+0x7a/0x80
> [ 0.001000] efi_enter_virtual_mode+0x3e2/0x494
> [ 0.001000] start_kernel+0x392/0x418
> [ 0.001000] ? set_init_arg+0x55/0x55
> [ 0.001000] x86_64_start_reservations+0x2a/0x2c
> [ 0.001000] x86_64_start_kernel+0xea/0xed
> [ 0.001000] start_cpu+0x14/0x14
> [ 0.001000] Code: 42 25 8d ff 80 3d 43 77 95 00 00 75 68 9c 8f 04 24 48 8b 05 3e 7d 7e 00 48 89 de 4d 89 f9 4d 89 f0 44 89 e9 4c 89 e2 48 8b 40 58 <48> 8b 78 58 31 c0 e8 90 e4 92 ff 48 8b 3c 24 48 c7 c6 2b 0a ca
> [ 0.001000] RIP: virt_efi_set_variable+0x85/0x1a0 RSP: ffffffff81e03e18
> [ 0.001000] ---[ end trace 0bd213e540e9b19f ]---
> [ 0.001000] Kernel panic - not syncing: Fatal exception
> [ 0.001000] ---[ end Kernel panic - not syncing: Fatal exception
>
> Booting normally (i.e., not kexec) still works.
>
> The decoded code is:
>
>
> 0: 42 25 8d ff 80 3d rex.X and $0x3d80ff8d,%eax
> 6: 43 77 95 rex.XB ja 0xffffffffffffff9e
> 9: 00 00 add %al,(%rax)
> b: 75 68 jne 0x75
> d: 9c pushfq
> e: 8f 04 24 popq (%rsp)
> 11: 48 8b 05 3e 7d 7e 00 mov 0x7e7d3e(%rip),%rax # 0x7e7d56
> 18: 48 89 de mov %rbx,%rsi
> 1b: 4d 89 f9 mov %r15,%r9
> 1e: 4d 89 f0 mov %r14,%r8
> 21: 44 89 e9 mov %r13d,%ecx
> 24: 4c 89 e2 mov %r12,%rdx
> 27: 48 8b 40 58 mov 0x58(%rax),%rax
> 2b:* 48 8b 78 58 mov 0x58(%rax),%rdi <-- trapping instruction
> 2f: 31 c0 xor %eax,%eax
> 31: e8 90 e4 92 ff callq 0xffffffffff92e4c6
> 36: 48 8b 3c 24 mov (%rsp),%rdi
> 3a: 48 rex.W
> 3b: c7 .byte 0xc7
> 3c: c6 (bad)
> 3d: 2b 0a sub (%rdx),%ecx
> 3f: ca .byte 0xca
>
> If I'm reading this correctly, efi.systab->runtime == 0xafafafafafafafaf,
> and we're crashing when we try to dereference that.
>
> Here is the output of efi=debug from before the crash:
>
> [ 0.000000] Linux version 4.11.0-rc1 (osandov@devbig561.prn1.facebook.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #53 SMP Wed Mar 8 12:07:16 PST 2017
> [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.6.7-34_fbk7_2504_g8275185 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 co
> nsole=ttyS1,57600 efi=debug
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> [ 0.000000] e820: BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
> [ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] extended physical RAM map:
> [ 0.000000] reserve setup_data: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000010006f] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100070-0x00000000750bdfff] usable
> [ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] efi: EFI v2.40 by American Megatrends
> [ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
> [ 0.000000] efi: mem00: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
> [ 0.000000] efi: mem01: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
> [ 0.000000] efi: mem02: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
> [ 0.000000] efi: mem03: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
> [ 0.000000] efi: mem04: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
> [ 0.000000] efi: mem05: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
> [ 0.000000] SMBIOS 3.0.0 present.
> [ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
> [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
> [ 0.000000] x2apic: enabled by BIOS, switching to x2apic ops
> [ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
> [ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
>
> Reverting commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and
> avoid a kmalloc()") on top of v4.11-rc1 fixes the problem. Bisecting
> this was interesting:
I have no esrt machine to test, can you share the full kernel log with
efi=debug in kernel cmdline?
*) normal boot kernel log without the reverting
*) kexec boot log with and without the reverting
>
> - Up until 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a
> kmalloc()"), kexec worked.
>
> - From 8e80632fb23f to 9d80448ac92b ("efi/arm64: Add debugfs node to
> dump UEFI runtime page tables"), kexec just hung after the
> "kexec_core: Starting new kernel" message.
>
> - From 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init until after
> memblock_x86_fill") to 0a637ee61247 ("x86/efi: Allow invocation of
> arbitrary boot services"), kexec hit the BUG_ON(!efi.systab) in
> kexec_enter_virtual_mode().
>
> - Finally, after 92dc33501bfb ("x86/efi: Round EFI memmap reservations
> to EFI_PAGE_SIZE"), I get the panic described above.
>
> Let me know if there is any more information I can provide.
>
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-09 2:21 ` Dave Young
@ 2017-03-09 3:36 ` Omar Sandoval
0 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-03-09 3:36 UTC (permalink / raw)
To: Dave Young; +Cc: Matt Fleming, Ingo Molnar, linux-kernel, kernel-team
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
On Thu, Mar 09, 2017 at 10:21:36AM +0800, Dave Young wrote:
> I have no esrt machine to test, can you share the full kernel log with
> efi=debug in kernel cmdline?
>
> *) normal boot kernel log without the reverting
> *) kexec boot log with and without the reverting
Attached.
[-- Attachment #2: normal_boot.txt --]
[-- Type: text/plain, Size: 44731 bytes --]
[ 0.000000] Linux version 4.11.0-rc1 (osandov@devbig561.prn1.facebook.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #53 SMP Wed Mar 8 12:07:16 PST 2017
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-rc1 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 console=ttyS1,57600 efi=debug
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] extended physical RAM map:
[ 0.000000] reserve setup_data: [mem 0x0000000000000000-0x000000000009ffff] usable
[ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x00000000709fb017] usable
[ 0.000000] reserve setup_data: [mem 0x00000000709fb018-0x0000000070a4b857] usable
[ 0.000000] reserve setup_data: [mem 0x0000000070a4b858-0x0000000070a4c017] usable
[ 0.000000] reserve setup_data: [mem 0x0000000070a4c018-0x0000000070a53c57] usable
[ 0.000000] reserve setup_data: [mem 0x0000000070a53c58-0x00000000750bdfff] usable
[ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] efi: EFI v2.40 by American Megatrends
[ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
[ 0.000000] efi: mem00: [Boot Code | | | | | | | | |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000007fff] (0MB)
[ 0.000000] efi: mem01: [Loader Data | | | | | | | | |WB|WT|WC|UC] range=[0x0000000000008000-0x0000000000008fff] (0MB)
[ 0.000000] efi: mem02: [Conventional Memory| | | | | | | | |WB|WT|WC|UC] range=[0x0000000000009000-0x000000000003ffff] (0MB)
[ 0.000000] efi: mem03: [Boot Code | | | | | | | | |WB|WT|WC|UC] range=[0x0000000000040000-0x000000000009ffff] (0MB)
[ 0.000000] efi: mem04: [Conventional Memory| | | | | | | | |WB|WT|WC|UC] range=[0x0000000000100000-0x0000000000ffffff] (15MB)
[ 0.000000] efi: mem05: [Loader Data | | | | | | | | |WB|WT|WC|UC] range=[0x0000000001000000-0x00000000024cdfff] (20MB)
[ 0.000000] efi: mem06: [Conventional Memory| | | | | | | | |WB|WT|WC|UC] range=[0x00000000024ce000-0x000000003f14afff] (972MB)
[ 0.000000] efi: mem07: [Loader Data | | | | | | | | |WB|WT|WC|UC] range=[0x000000003f14b000-0x000000003fffffff] (14MB)
[ 0.000000] efi: mem08: [Conventional Memory| | | | | | | | |WB|WT|WC|UC] range=[0x0000000040000000-0x0000000045ed1fff] (94MB)
[ 0.000000] efi: mem09: [Loader Data | | | | | | | | |WB|WT|WC|UC] range=[0x0000000045ed2000-0x0000000062158fff] (450MB)
[ 0.000000] efi: mem10: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x0000000062159000-0x00000000621d8fff] (0MB)
[ 0.000000] efi: mem11: [Conventional Memory| | | | | | | | |WB|WT|WC|UC] range=[0x00000000621d9000-0x00000000709fafff] (232MB)
[ 0.000000] efi: mem12: [Loader Data | | | | | | | | |WB|WT|WC|UC] range=[0x00000000709fb000-0x0000000070c4cfff] (2MB)
[ 0.000000] efi: mem13: [Loader Code | | | | | | | | |WB|WT|WC|UC] range=[0x0000000070c4d000-0x0000000070d73fff] (1MB)
[ 0.000000] efi: mem14: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x0000000070d74000-0x0000000074a32fff] (60MB)
[ 0.000000] efi: mem15: [Conventional Memory| | | | | | | | |WB|WT|WC|UC] range=[0x0000000074a33000-0x0000000074b81fff] (1MB)
[ 0.000000] efi: mem16: [Boot Code | | | | | | | | |WB|WT|WC|UC] range=[0x0000000074b82000-0x00000000750bdfff] (5MB)
[ 0.000000] efi: mem17: [Reserved | | | | | | | | |WB|WT|WC|UC] range=[0x00000000750be000-0x0000000075ddbfff] (13MB)
[ 0.000000] efi: mem18: [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC] range=[0x0000000075ddc000-0x0000000075e32fff] (0MB)
[ 0.000000] efi: mem19: [ACPI Memory NVS | | | | | | | | |WB|WT|WC|UC] range=[0x0000000075e33000-0x000000007642dfff] (5MB)
[ 0.000000] efi: mem20: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
[ 0.000000] efi: mem21: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
[ 0.000000] efi: mem22: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x000000007bcda000-0x000000007bcdafff] (0MB)
[ 0.000000] efi: mem23: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
[ 0.000000] efi: mem24: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x000000007bd61000-0x000000007bffffff] (2MB)
[ 0.000000] efi: mem25: [Conventional Memory| | | | | | | | |WB|WT|WC|UC] range=[0x0000000100000000-0x000000407fffffff] (260096MB)
[ 0.000000] efi: mem26: [Reserved | | | | | | | | | | | | ] range=[0x000000007c000000-0x000000007fffffff] (64MB)
[ 0.000000] efi: mem27: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
[ 0.000000] efi: mem28: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
[ 0.000000] efi: mem29: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
[ 0.000000] SMBIOS 3.0.0 present.
[ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
[ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
[ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
[ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
[ 0.000000] Using GB pages for direct mapping
[ 0.000000] Secure boot could not be determined
[ 0.000000] RAMDISK: [mem 0x3f14b000-0x3fffafff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x0000000075F5C000 000024 (v02 ALASKA)
[ 0.000000] ACPI: XSDT 0x0000000075F5C0A0 0000C4 (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FACP 0x0000000075F904B0 00010C (v05 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: DSDT 0x0000000075F5C200 0342AB (v02 ALASKA A M I 01072009 INTL 20091013)
[ 0.000000] ACPI: FACS 0x000000007642CF80 000040
[ 0.000000] ACPI: APIC 0x0000000075F905C0 000374 (v03 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FPDT 0x0000000075F90938 000044 (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FIDT 0x0000000075F90980 00009C (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: TCPA 0x0000000075F90A20 000032 (v02 ALASKA NAPAASF 00000001 MSFT 01000013)
[ 0.000000] ACPI: SPMI 0x0000000075F90A58 000041 (v05 ALASKA A M I 00000000 AMI. 00000000)
[ 0.000000] ACPI: MCFG 0x0000000075F90AA0 00003C (v01 ALASKA A M I 01072009 MSFT 00000097)
[ 0.000000] ACPI: UEFI 0x0000000075F90AE0 000042 (v01 ALASKA A M I 01072009 00000000)
[ 0.000000] ACPI: HPET 0x0000000075F90B28 000038 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: MSCT 0x0000000075F90B60 000090 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SLIT 0x0000000075F90BF0 000030 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SRAT 0x0000000075F90C20 001158 (v03 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: WDDT 0x0000000075F91D78 000040 (v01 ALASKA A M I 00000000 INTL 20091013)
[ 0.000000] ACPI: SSDT 0x0000000075F91DB8 0170C7 (v02 ALASKA PmMgt 00000001 INTL 20120913)
[ 0.000000] ACPI: NITR 0x0000000075FA8E80 000071 (v02 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SPCR 0x0000000075FA8EF8 000050 (v01 A M I APTIO V 01072009 AMI. 0005000B)
[ 0.000000] ACPI: SSDT 0x0000000075FA8F48 002652 (v02 ALASKA SpsNm 00000002 INTL 20120913)
[ 0.000000] ACPI: SSDT 0x0000000075FAB5A0 000064 (v02 ALASKA SpsNvs 00000002 INTL 20120913)
[ 0.000000] ACPI: PRAD 0x0000000075FAB608 000102 (v02 ALASKA A M I 00000002 INTL 20120913)
[ 0.000000] ACPI: DMAR 0x0000000075FAB710 0000E0 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x02 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x04 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x06 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x08 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0a -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0c -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x10 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x12 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x14 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x16 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x18 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1a -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1c -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x20 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x22 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x24 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x26 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x28 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2c -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x30 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x32 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x34 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x36 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x38 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3c -> Node 1
[ 0.000000] SRAT: PXM 0 -> APIC 0x01 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x03 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x05 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x07 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x09 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0b -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0d -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x11 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x13 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x15 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x17 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x19 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1b -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1d -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x21 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x23 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x25 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x27 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x29 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2b -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2d -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x31 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x33 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x35 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x37 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x39 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3b -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3d -> Node 1
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x207fffffff]
[ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x2080000000-0x407fffffff]
[ 0.000000] NUMA: Node 0 [mem 0x00000000-0x7fffffff] + [mem 0x100000000-0x207fffffff] -> [mem 0x00000000-0x207fffffff]
[ 0.000000] NODE_DATA(0) allocated [mem 0x207fffe000-0x207fffffff]
[ 0.000000] NODE_DATA(1) allocated [mem 0x407fffb000-0x407fffcfff]
[ 0.000000] Reserving 128MB of memory at 768MB for crashkernel (System RAM: 261970MB)
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x000000407fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009ffff]
[ 0.000000] node 0: [mem 0x0000000000100000-0x00000000750bdfff]
[ 0.000000] node 0: [mem 0x000000007bcda000-0x000000007bcdafff]
[ 0.000000] node 0: [mem 0x000000007bd61000-0x000000007bffffff]
[ 0.000000] node 0: [mem 0x0000000100000000-0x000000207fffffff]
[ 0.000000] node 1: [mem 0x0000002080000000-0x000000407fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000207fffffff]
[ 0.000000] Initmem setup node 1 [mem 0x0000002080000000-0x000000407fffffff]
[ 0.000000] tboot: non-0 tboot_addr but it is not of type E820_RESERVED
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x18] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x20] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x22] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x24] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x26] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x28] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x30] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x32] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x34] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x36] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x38] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x19] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x21] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x23] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x25] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x27] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x29] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x31] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x33] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x35] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x37] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x39] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3d] high edge lint[0x1])
[ 0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] IOAPIC[1]: apic_id 2, version 32, address 0xfec01000, GSI 24-47
[ 0.000000] IOAPIC[2]: apic_id 3, version 32, address 0xfec40000, GSI 48-71
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] smpboot: Allowing 56 CPUs, 0 hotplug CPUs
[ 0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[ 0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:56 nr_node_ids:2
[ 0.000000] percpu: Embedded 36 pages/cpu @ffff881fff600000 s108568 r8192 d30696 u262144
[ 0.000000] Built 2 zonelists in Node order, mobility grouping on. Total pages: 66016663
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.11.0-rc1 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 console=ttyS1,57600 efi=debug
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Memory: 263752904K/268258292K available (8783K kernel code, 1280K rwdata, 3152K rodata, 1336K init, 2520K bss, 4505388K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=56, Nodes=2
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 64.
[ 0.000000] RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=56.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=56
[ 0.000000] NR_IRQS:8448 nr_irqs:1688 16
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] console [ttyS1] enabled
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.001000] tsc: Detected 2394.241 MHz processor
[ 0.002000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4788.48 BogoMIPS (lpj=2394241)
[ 0.003002] pid_max: default: 57344 minimum: 448
[ 0.004026] ACPI: Core revision 20170119
[ 0.049942] ACPI: 4 ACPI AML tables successfully acquired and loaded
[ 0.050048] efi: EFI runtime memory map:
[ 0.051005] efi: mem00: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
[ 0.052003] efi: mem01: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
[ 0.053003] efi: mem02: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
[ 0.054003] efi: mem03: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x000000007bd61000-0x000000007bffffff] (2MB)
[ 0.055002] efi: mem04: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
[ 0.056003] efi: mem05: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x000000007bcda000-0x000000007bcdafff] (0MB)
[ 0.057002] efi: mem06: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
[ 0.058002] efi: mem07: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
[ 0.059002] efi: mem08: [Boot Code | | | | | | | | |WB|WT|WC|UC] range=[0x0000000074b82000-0x00000000750bdfff] (5MB)
[ 0.060002] efi: mem09: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x0000000070d74000-0x0000000074a32fff] (60MB)
[ 0.061002] efi: mem10: [Boot Data | | | | | | | | |WB|WT|WC|UC] range=[0x0000000062159000-0x00000000621d8fff] (0MB)
[ 0.062002] efi: mem11: [Boot Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x0000000000040000-0x000000000009ffff] (0MB)
[ 0.063003] efi: mem12: [Boot Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000007fff] (0MB)
[ 0.065072] Security Framework initialized
[ 0.066002] SELinux: Disabled at boot.
[ 0.077614] Dentry cache hash table entries: 33554432 (order: 16, 268435456 bytes)
[ 0.125933] Inode-cache hash table entries: 16777216 (order: 15, 134217728 bytes)
[ 0.148016] Mount-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.149177] Mountpoint-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.152119] CPU: Physical Processor ID: 0
[ 0.153002] CPU: Processor Core ID: 0
[ 0.154005] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.155001] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.156004] mce: CPU supports 22 MCE banks
[ 0.157016] CPU0: Thermal monitoring enabled (TM1)
[ 0.158048] process: using mwait in idle threads
[ 0.159003] Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
[ 0.160002] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
[ 0.161134] Freeing SMP alternatives memory: 32K
[ 0.164751] ftrace: allocating 32009 entries in 126 pages
[ 0.173081] smpboot: Max logical packages: 4
[ 0.174009] DMAR: Host address width 46
[ 0.175003] DMAR: DRHD base: 0x000000fbffc000 flags: 0x0
[ 0.176010] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap 8d2078c106f0466 ecap f020df
[ 0.177002] DMAR: DRHD base: 0x000000c7ffc000 flags: 0x1
[ 0.178006] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap 8d2078c106f0466 ecap f020df
[ 0.179002] DMAR: RMRR base: 0x0000007bb46000 end: 0x0000007bb55fff
[ 0.180002] DMAR: ATSR flags: 0x0
[ 0.181002] DMAR: RHSA base: 0x000000c7ffc000 proximity domain: 0x0
[ 0.182002] DMAR: RHSA base: 0x000000fbffc000 proximity domain: 0x1
[ 0.183003] DMAR-IR: IOAPIC id 3 under DRHD base 0xfbffc000 IOMMU 0
[ 0.184002] DMAR-IR: IOAPIC id 1 under DRHD base 0xc7ffc000 IOMMU 1
[ 0.185002] DMAR-IR: IOAPIC id 2 under DRHD base 0xc7ffc000 IOMMU 1
[ 0.186002] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
[ 0.187002] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[ 0.187003] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[ 0.190746] DMAR-IR: Enabled IRQ remapping in xapic mode
[ 0.191000] x2apic: IRQ remapping doesn't support X2APIC mode
[ 0.191002] Switched APIC routing to physical flat.
[ 0.193241] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.203244] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (family: 0x6, model: 0x4f, stepping: 0x1)
[ 0.204067] Performance Events: PEBS fmt2+, Broadwell events, 16-deep LBR, full-width counters, Intel PMU driver.
[ 0.205002] ... version: 3
[ 0.206000] ... bit width: 48
[ 0.207000] ... generic registers: 4
[ 0.208001] ... value mask: 0000ffffffffffff
[ 0.209001] ... max period: 00007fffffffffff
[ 0.210000] ... fixed-purpose events: 3
[ 0.211001] ... event mask: 000000070000000f
[ 0.214388] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[ 0.215013] smp: Bringing up secondary CPUs ...
[ 0.216068] x86: Booting SMP configuration:
[ 0.217001] .... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13
[ 1.011001] .... node #1, CPUs: #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 #24 #25 #26 #27
[ 1.867001] .... node #0, CPUs: #28 #29 #30 #31 #32 #33 #34 #35 #36 #37 #38 #39 #40 #41
[ 2.722001] .... node #1, CPUs: #42 #43 #44 #45 #46 #47 #48 #49 #50 #51 #52 #53 #54 #55
[ 3.576048] smp: Brought up 2 nodes, 56 CPUs
[ 3.578002] smpboot: Total of 56 processors activated (268499.98 BogoMIPS)
[ 3.581068] sched_clock: Marking stable (3581000000, 0)->(4716222369, -1135222369)
[ 3.602542] devtmpfs: initialized
[ 3.609378] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 3.628903] futex hash table entries: 16384 (order: 8, 1048576 bytes)
[ 3.642151] xor: automatically using best checksumming function avx
[ 3.657118] NET: Registered protocol family 16
[ 3.666194] cpuidle: using governor menu
[ 3.674031] PCCT header not found.
[ 3.681020] ACPI: bus type PCI registered
[ 3.689099] dca service started, version 1.12.1
[ 3.698160] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
[ 3.716744] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820
[ 3.730311] PCI: Using configuration type 1 for base access
[ 3.743695] HugeTLB registered 1 GB page size, pre-allocated 0 pages
[ 3.756392] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 3.786216] raid6: sse2x1 gen() 7929 MB/s
[ 3.811278] raid6: sse2x1 xor() 5925 MB/s
[ 3.836338] raid6: sse2x2 gen() 9546 MB/s
[ 3.861394] raid6: sse2x2 xor() 6476 MB/s
[ 3.886454] raid6: sse2x4 gen() 11281 MB/s
[ 3.911509] raid6: sse2x4 xor() 7982 MB/s
[ 3.936566] raid6: avx2x1 gen() 15308 MB/s
[ 3.961622] raid6: avx2x1 xor() 11341 MB/s
[ 3.986680] raid6: avx2x2 gen() 17585 MB/s
[ 4.011738] raid6: avx2x2 xor() 12017 MB/s
[ 4.036813] raid6: avx2x4 gen() 20578 MB/s
[ 4.061872] raid6: avx2x4 xor() 14667 MB/s
[ 4.070400] raid6: using algorithm avx2x4 gen() 20578 MB/s
[ 4.081357] raid6: .... xor() 14667 MB/s, rmw enabled
[ 4.091446] raid6: using avx2x2 recovery algorithm
[ 4.101179] ACPI: Added _OSI(Module Device)
[ 4.109525] ACPI: Added _OSI(Processor Device)
[ 4.118383] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 4.127780] ACPI: Added _OSI(Processor Aggregator Device)
[ 4.149314] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 4.168777] ACPI: Dynamic OEM Table Load:
[ 4.199842] ACPI: Interpreter enabled
[ 4.207163] ACPI: (supports S0 S5)
[ 4.213951] ACPI: Using IOAPIC for interrupt routing
[ 4.223903] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 4.270646] ACPI: PCI Root Bridge [UNC1] (domain 0000 [bus ff])
[ 4.282467] acpi PNP0A03:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.301066] acpi PNP0A03:02: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.317077] PCI host bridge to bus 0000:ff
[ 4.325263] pci_bus 0000:ff: root bus resource [bus ff]
[ 4.338709] ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus 7f])
[ 4.350539] acpi PNP0A03:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.367650] acpi PNP0A03:03: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.383656] PCI host bridge to bus 0000:7f
[ 4.391831] pci_bus 0000:7f: root bus resource [bus 7f]
[ 4.416003] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e])
[ 4.428340] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.445232] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.461241] PCI host bridge to bus 0000:00
[ 4.469425] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 4.482980] pci_bus 0000:00: root bus resource [io 0x1000-0x7fff window]
[ 4.496537] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 4.511480] pci_bus 0000:00: root bus resource [mem 0x90000000-0xc7ffbfff window]
[ 4.526423] pci_bus 0000:00: root bus resource [mem 0x380000000000-0x383fffffffff window]
[ 4.542753] pci_bus 0000:00: root bus resource [bus 00-7e]
[ 4.556214] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 4.569162] pci 0000:00:02.0: PCI bridge to [bus 02]
[ 4.579101] pci 0000:00:03.0: PCI bridge to [bus 03]
[ 4.590084] pci 0000:04:00.0: VF(n) BAR0 space: [mem 0x00000000-0x007fffff 64bit pref] (contains BAR0 for 8 VFs)
[ 4.611010] pci 0000:00:03.2: PCI bridge to [bus 04]
[ 4.621623] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-fe])
[ 4.633973] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.650844] acpi PNP0A08:01: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.666865] PCI host bridge to bus 0000:80
[ 4.675038] pci_bus 0000:80: root bus resource [io 0x8000-0xffff window]
[ 4.688594] pci_bus 0000:80: root bus resource [mem 0xc8000000-0xfbffbfff window]
[ 4.703540] pci_bus 0000:80: root bus resource [mem 0x384000000000-0x387fffffffff window]
[ 4.719869] pci_bus 0000:80: root bus resource [bus 80-fe]
[ 4.731392] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 4.745544] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 4.759682] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 *11 12 14 15)
[ 4.773474] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15)
[ 4.787265] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.803669] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.820060] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.836468] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.852895] ACPI: Enabled 3 GPEs in block 00 to 3F
[ 4.862655] SCSI subsystem initialized
[ 4.870163] ACPI: bus type USB registered
[ 4.878189] usbcore: registered new interface driver usbfs
[ 4.889152] usbcore: registered new interface driver hub
[ 4.899909] usbcore: registered new device driver usb
[ 4.910015] pps_core: LinuxPPS API ver. 1 registered
[ 4.919933] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 4.938177] PTP clock support registered
[ 4.946217] Registered efivars operations
[ 4.986105] PCI: Using ACPI for IRQ routing
[ 4.999147] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[ 5.011482] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 5.025241] clocksource: Switched to clocksource hpet
[ 5.049659] VFS: Disk quotas dquot_6.6.0
[ 5.057535] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 5.071371] pnp: PnP ACPI init
[ 5.077874] system 00:01: [io 0x0500-0x057f] has been reserved
[ 5.089705] system 00:01: [io 0x0400-0x0427] has been reserved
[ 5.101528] system 00:01: [io 0x0430-0x047f] has been reserved
[ 5.113350] system 00:01: [io 0x0580-0x059f] has been reserved
[ 5.125172] system 00:01: [io 0x0600-0x061f] has been reserved
[ 5.136995] system 00:01: [io 0x0880-0x0883] has been reserved
[ 5.148818] system 00:01: [io 0x0800-0x081f] has been reserved
[ 5.160642] system 00:01: [mem 0xfed1c000-0xfed3ffff] has been reserved
[ 5.173850] system 00:01: [mem 0xfed45000-0xfed8bfff] has been reserved
[ 5.187060] system 00:01: [mem 0xff000000-0xffffffff] has been reserved
[ 5.200269] system 00:01: [mem 0xfee00000-0xfeefffff] has been reserved
[ 5.213481] system 00:01: [mem 0xfed12000-0xfed1200f] has been reserved
[ 5.226686] system 00:01: [mem 0xfed12010-0xfed1201f] has been reserved
[ 5.239897] system 00:01: [mem 0xfed1b000-0xfed1bfff] has been reserved
[ 5.253341] system 00:02: [io 0x0a00-0x0a0f] has been reserved
[ 5.265171] system 00:02: [io 0x0a10-0x0a1f] has been reserved
[ 5.276994] system 00:02: [io 0x0a20-0x0a2f] has been reserved
[ 5.288817] system 00:02: [io 0x0a30-0x0a3f] has been reserved
[ 5.300640] system 00:02: [io 0x0a40-0x0a4f] has been reserved
[ 5.313543] pnp: PnP ACPI: found 6 devices
[ 5.328175] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 5.345946] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 5.355858] pci 0000:00:02.0: PCI bridge to [bus 02]
[ 5.365770] pci 0000:00:02.0: bridge window [mem 0xc7e00000-0xc7efffff]
[ 5.379326] pci 0000:00:03.0: PCI bridge to [bus 03]
[ 5.389245] pci 0000:04:00.0: BAR 7: no space for [mem size 0x00800000 64bit pref]
[ 5.404374] pci 0000:04:00.0: BAR 7: failed to assign [mem size 0x00800000 64bit pref]
[ 5.420185] pci 0000:00:03.2: PCI bridge to [bus 04]
[ 5.430098] pci 0000:00:03.2: bridge window [mem 0xc7d00000-0xc7dfffff]
[ 5.443656] pci 0000:00:03.2: bridge window [mem 0x383ffc000000-0x383ffdffffff 64bit pref]
[ 5.460510] pci_bus 0000:00: Some PCI device resources are unassigned, try booting with pci=realloc
[ 5.478818] NET: Registered protocol family 2
[ 5.487961] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
[ 5.503580] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 5.517127] TCP: Hash tables configured (established 524288 bind 65536)
[ 5.530501] UDP hash table entries: 65536 (order: 9, 2097152 bytes)
[ 5.543404] UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes)
[ 5.557292] NET: Registered protocol family 1
[ 5.588678] Trying to unpack rootfs image as initramfs...
[ 5.840634] Freeing initrd memory: 15040K
[ 5.848750] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 5.861613] software IO TLB [mem 0x6c9fb000-0x709fb000] (64MB) mapped at [ffff88006c9fb000-ffff8800709fafff]
[ 5.881309] Intel CQM monitoring enabled
[ 5.889140] Intel MBM enabled
[ 5.896248] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer
[ 5.912069] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[ 5.923531] RAPL PMU: hw unit of domain package 2^-14 Joules
[ 5.934833] RAPL PMU: hw unit of domain dram 2^-14 Joules
[ 5.945615] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[ 5.968638] audit: initializing netlink subsys (disabled)
[ 5.979509] audit: type=2000 audit(1489028958.885:1): state=initialized audit_enabled=0 res=1
[ 5.980198] workingset: timestamp_bits=44 max_order=26 bucket_order=0
[ 5.981564] SGI XFS with ACLs, security attributes, no debug enabled
[ 5.983327] NET: Registered protocol family 38
[ 5.983335] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 5.983445] io scheduler noop registered
[ 5.983446] io scheduler deadline registered
[ 5.983475] io scheduler cfq registered (default)
[ 5.983475] io scheduler mq-deadline registered
[ 6.081716] pcieport 0000:00:01.0: AER enabled with IRQ 26
[ 6.092689] pcieport 0000:00:02.0: AER enabled with IRQ 28
[ 6.103659] pcieport 0000:00:03.0: AER enabled with IRQ 29
[ 6.114632] pcieport 0000:00:03.2: AER enabled with IRQ 30
[ 6.134864] ERST: Error Record Serialization Table (ERST) support is disabled.
[ 6.149302] GHES: HEST is not enabled!
[ 6.156780] EINJ: EINJ table not found.
[ 6.164448] ioatdma: Intel(R) QuickData Technology Driver 4.00
[ 6.176193] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 6.209374] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 6.244648] 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 6.294376] tpm_tis 00:05: 1.2 TPM (device-id 0x1A, rev-id 16)
[ 6.529681] brd: module loaded
[ 6.536171] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x20 impl SATA mode
[ 6.552511] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst
[ 6.568035] scsi host0: ahci
[ 6.573921] scsi host1: ahci
[ 6.579874] scsi host2: ahci
[ 6.585771] scsi host3: ahci
[ 6.591680] scsi host4: ahci
[ 6.597612] scsi host5: ahci
[ 6.603379] ata1: DUMMY
[ 6.608262] ata2: DUMMY
[ 6.613153] ata3: DUMMY
[ 6.618039] ata4: DUMMY
[ 6.622927] ata5: DUMMY
[ 6.627819] ata6: SATA max UDMA/133 abar m2048@0xc7f00000 port 0xc7f00380 irq 31
[ 6.642703] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[ 6.656619] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 6.667770] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 5.0.0-k
[ 6.683067] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
[ 6.695041] mlx5_core 0000:04:00.0: firmware version: 14.16.2012
[ 6.953777] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 6.972436] tsc: Refined TSC clocksource calibration: 2394.473 MHz
[ 6.984812] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2283d2806c9, max_idle_ns: 440795281091 ns
[ 7.112383] ata6.00: ATA-8: TOSHIBA MG04ACA200A, FP2A, max UDMA/100
[ 7.124922] ata6.00: 488378646 sectors, multi 2: LBA48 NCQ (depth 31/32), AA
[ 7.139972] ata6.00: configured for UDMA/100
[ 7.148793] scsi 5:0:0:0: Direct-Access ATA TOSHIBA MG04ACA2 FP2A PQ: 0 ANSI: 5
[ 7.165655] sd 5:0:0:0: [sda] 488378646 4096-byte logical blocks: (2.00 TB/1.82 TiB)
[ 7.181198] sd 5:0:0:0: [sda] Write Protect is off
[ 7.190889] sd 5:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 7.310874] (0000:04:00.0): E-Switch: Total vports 9, l2 table size(65536), per vport: max uc(1024) max mc(16384)
[ 7.353291] mlx5_core 0000:04:00.0: Port module event: module 0, Cable plugged
[ 7.375483] random: fast init done
[ 7.388820] mlx5_core 0000:04:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(64) RxCqeCmprss(0)
[ 7.440347] sda: sda1 sda2 sda3 sda4
[ 7.448699] sd 5:0:0:0: [sda] Attached SCSI disk
[ 7.597831] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 7.610882] ehci-pci: EHCI PCI platform driver
[ 7.619991] ehci-pci 0000:00:1d.0: EHCI Host Controller
[ 7.630431] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 1
[ 7.645230] ehci-pci 0000:00:1d.0: debug port 2
[ 7.658188] ehci-pci 0000:00:1d.0: irq 18, io mem 0xc7f01000
[ 7.676526] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[ 7.688591] hub 1-0:1.0: USB hub found
[ 7.696141] hub 1-0:1.0: 2 ports detected
[ 7.704475] uhci_hcd: USB Universal Host Controller Interface driver
[ 7.717209] usbcore: registered new interface driver usbserial
[ 7.728864] usbcore: registered new interface driver ark3116
[ 7.740179] usbserial: USB Serial support registered for ark3116
[ 7.752177] usbcore: registered new interface driver pl2303
[ 7.763319] usbserial: USB Serial support registered for pl2303
[ 7.775158] i8042: PNP: No PS/2 controller found.
[ 7.784583] rtc_cmos 00:00: RTC can wake from S4
[ 7.793945] rtc_cmos 00:00: rtc core: registered rtc_cmos as rtc0
[ 7.806160] rtc_cmos 00:00: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 7.821573] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-devel@redhat.com
[ 7.838443] intel_pstate: Intel P-state driver initializing
[ 7.856084] usbcore: registered new interface driver usbhid
[ 7.867208] usbhid: USB HID core driver
[ 7.874983] Netfilter messages via NETLINK v0.30.
[ 7.884413] ip_set: protocol 6
[ 7.890558] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 7.901168] Initializing XFRM netlink socket
[ 7.909776] NET: Registered protocol family 10
[ 7.919143] Segment Routing with IPv6
[ 7.926487] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 7.937261] NET: Registered protocol family 17
[ 7.946143] Key type dns_resolver registered
[ 7.963630] intel_rdt: Intel RDT L3 allocation detected
[ 7.974078] intel_rdt: Intel RDT L3DATA allocation detected
[ 7.985208] intel_rdt: Intel RDT L3CODE allocation detected
[ 7.996390] microcode: sig=0x406f1, pf=0x1, revision=0xb00001d
[ 8.010165] microcode: Microcode Update Driver: v2.2.
[ 8.010170] AVX2 version of gcm_enc/dec engaged.
[ 8.029482] AES CTR mode by8 optimization enabled
[ 8.040420] registered taskstats version 1
[ 8.048945] Btrfs loaded, crc32c=crc32c-intel
[ 8.058539] usb 1-1: new high-speed USB device number 2 using ehci-pci
[ 8.071632] clocksource: Switched to clocksource tsc
[ 8.190561] hub 1-1:1.0: USB hub found
[ 8.198119] hub 1-1:1.0: 8 ports detected
[ 8.436253] netpoll: netconsole: local port 6666
[ 8.445485] netpoll: netconsole: local IPv6 address 2401:db00:11:b03e:face:0:9:0
[ 8.460248] netpoll: netconsole: interface 'eth0'
[ 8.469640] netpoll: netconsole: remote port 1514
[ 8.479036] netpoll: netconsole: remote IPv6 address 2401:db00:eef0:a59::
[ 8.492592] netpoll: netconsole: remote ethernet address 02:90:fb:5b:b7:1e
[ 8.506326] netpoll: netconsole: device eth0 not up yet, forcing it
[ 8.854283] mlx5_core 0000:04:00.0 eth0: Link up
[ 8.863799] netpoll: netconsole: carrier detect appears untrustworthy, waiting 4 seconds
[ 11.877651] random: crng init done
[ 12.926613] console [netcon_ext0] enabled
[ 12.934621] console [netcon0] enabled
[ 12.941935] netconsole: network logging started
[ 12.951057] rtc_cmos 00:00: setting system clock to 2017-03-09 03:09:31 UTC (1489028971)
[ 12.967215] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 12.979205] EDD information not available.
[ 12.988521] Freeing unused kernel memory: 1336K
[ 12.997591] Write protecting the kernel read-only data: 14336k
[ 13.009970] Freeing unused kernel memory: 1436K
[ 13.020819] Freeing unused kernel memory: 944K
[ 13.098717] systemd[1]: systemd 231 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[ 13.135396] systemd[1]: Detected architecture x86-64.
[ 13.145493] systemd[1]: Running in initial RAM disk.
[-- Attachment #3: kexec_no_revert.txt --]
[-- Type: text/plain, Size: 20240 bytes --]
[ 0.000000] Linux version 4.11.0-rc1 (osandov@devbig561.prn1.facebook.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #53 SMP Wed Mar 8 12:07:16 PST 2017
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-rc1 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 console=ttyS1,57600 efi=debug
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] extended physical RAM map:
[ 0.000000] reserve setup_data: [mem 0x0000000000000100-0x000000000009ffff] usable
[ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000010006f] usable
[ 0.000000] reserve setup_data: [mem 0x0000000000100070-0x00000000750bdfff] usable
[ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] efi: EFI v2.40 by American Megatrends
[ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
[ 0.000000] efi: mem00: [Boot Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000007fff] (0MB)
[ 0.000000] efi: mem01: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
[ 0.000000] efi: mem02: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
[ 0.000000] efi: mem03: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
[ 0.000000] efi: mem04: [Boot Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x0000000000040000-0x000000000009ffff] (0MB)
[ 0.000000] efi: mem05: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
[ 0.000000] efi: mem06: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
[ 0.000000] efi: mem07: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
[ 0.000000] SMBIOS 3.0.0 present.
[ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
[ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
[ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
[ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
[ 0.000000] Using GB pages for direct mapping
[ 0.000000] Secure boot could not be determined
[ 0.000000] RAMDISK: [mem 0x407d150000-0x407dffffff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x0000000075F5C000 000024 (v02 ALASKA)
[ 0.000000] ACPI: XSDT 0x0000000075F5C0A0 0000C4 (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FACP 0x0000000075F904B0 00010C (v05 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: DSDT 0x0000000075F5C200 0342AB (v02 ALASKA A M I 01072009 INTL 20091013)
[ 0.000000] ACPI: FACS 0x000000007642CF80 000040
[ 0.000000] ACPI: APIC 0x0000000075F905C0 000374 (v03 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FPDT 0x0000000075F90938 000044 (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FIDT 0x0000000075F90980 00009C (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: TCPA 0x0000000075F90A20 000032 (v02 ALASKA NAPAASF 00000001 MSFT 01000013)
[ 0.000000] ACPI: SPMI 0x0000000075F90A58 000041 (v05 ALASKA A M I 00000000 AMI. 00000000)
[ 0.000000] ACPI: MCFG 0x0000000075F90AA0 00003C (v01 ALASKA A M I 01072009 MSFT 00000097)
[ 0.000000] ACPI: UEFI 0x0000000075F90AE0 000042 (v01 ALASKA A M I 01072009 00000000)
[ 0.000000] ACPI: HPET 0x0000000075F90B28 000038 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: MSCT 0x0000000075F90B60 000090 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SLIT 0x0000000075F90BF0 000030 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SRAT 0x0000000075F90C20 001158 (v03 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: WDDT 0x0000000075F91D78 000040 (v01 ALASKA A M I 00000000 INTL 20091013)
[ 0.000000] ACPI: SSDT 0x0000000075F91DB8 0170C7 (v02 ALASKA PmMgt 00000001 INTL 20120913)
[ 0.000000] ACPI: NITR 0x0000000075FA8E80 000071 (v02 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SPCR 0x0000000075FA8EF8 000050 (v01 A M I APTIO V 01072009 AMI. 0005000B)
[ 0.000000] ACPI: SSDT 0x0000000075FA8F48 002652 (v02 ALASKA SpsNm 00000002 INTL 20120913)
[ 0.000000] ACPI: SSDT 0x0000000075FAB5A0 000064 (v02 ALASKA SpsNvs 00000002 INTL 20120913)
[ 0.000000] ACPI: PRAD 0x0000000075FAB608 000102 (v02 ALASKA A M I 00000002 INTL 20120913)
[ 0.000000] ACPI: DMAR 0x0000000075FAB710 0000E0 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x02 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x04 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x06 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x08 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0a -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0c -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x10 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x12 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x14 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x16 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x18 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1a -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1c -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x20 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x22 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x24 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x26 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x28 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2c -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x30 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x32 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x34 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x36 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x38 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3c -> Node 1
[ 0.000000] SRAT: PXM 0 -> APIC 0x01 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x03 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x05 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x07 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x09 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0b -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0d -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x11 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x13 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x15 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x17 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x19 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1b -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1d -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x21 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x23 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x25 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x27 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x29 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2b -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2d -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x31 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x33 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x35 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x37 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x39 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3b -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3d -> Node 1
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x207fffffff]
[ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x2080000000-0x407fffffff]
[ 0.000000] NUMA: Node 0 [mem 0x00000000-0x7fffffff] + [mem 0x100000000-0x207fffffff] -> [mem 0x00000000-0x207fffffff]
[ 0.000000] NODE_DATA(0) allocated [mem 0x207fffe000-0x207fffffff]
[ 0.000000] NODE_DATA(1) allocated [mem 0x407fffd000-0x407fffefff]
[ 0.000000] Reserving 128MB of memory at 768MB for crashkernel (System RAM: 261970MB)
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x000000407fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009ffff]
[ 0.000000] node 0: [mem 0x0000000000100000-0x00000000750bdfff]
[ 0.000000] node 0: [mem 0x000000007bcda000-0x000000007bcdafff]
[ 0.000000] node 0: [mem 0x000000007bd61000-0x000000007bffffff]
[ 0.000000] node 0: [mem 0x0000000100000000-0x000000207fffffff]
[ 0.000000] node 1: [mem 0x0000002080000000-0x000000407fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000207fffffff]
[ 0.000000] Initmem setup node 1 [mem 0x0000002080000000-0x000000407fffffff]
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x18] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x20] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x22] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x24] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x26] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x28] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x30] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x32] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x34] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x36] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x38] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x19] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x21] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x23] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x25] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x27] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x29] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x31] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x33] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x35] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x37] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x39] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3d] high edge lint[0x1])
[ 0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] IOAPIC[1]: apic_id 2, version 32, address 0xfec01000, GSI 24-47
[ 0.000000] IOAPIC[2]: apic_id 3, version 32, address 0xfec40000, GSI 48-71
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] smpboot: Allowing 56 CPUs, 0 hotplug CPUs
[ 0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[ 0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:56 nr_node_ids:2
[ 0.000000] percpu: Embedded 36 pages/cpu @ffff881fff600000 s108568 r8192 d30696 u262144
[ 0.000000] Built 2 zonelists in Node order, mobility grouping on. Total pages: 66016661
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.11.0-rc1 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 console=ttyS1,57600 efi=debug
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Memory: 263824028K/268258292K available (8783K kernel code, 1280K rwdata, 3152K rodata, 1336K init, 2520K bss, 4434264K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=56, Nodes=2
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 64.
[ 0.000000] RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=56.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=56
[ 0.000000] NR_IRQS:8448 nr_irqs:1688 16
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] console [ttyS1] enabled
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2394.475 MHz processor
[ 0.000020] Calibrating delay loop (skipped), value calculated using timer frequency.. 4788.95 BogoMIPS (lpj=2394475)
[ 0.001000] pid_max: default: 57344 minimum: 448
[ 0.001000] ACPI: Core revision 20170119
[ 0.001000] ACPI: 4 ACPI AML tables successfully acquired and loaded
[ 0.001000] general protection fault: 0000 [#1] SMP
[ 0.001000] Modules linked in:
[ 0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
[ 0.001000] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
[ 0.001000] task: ffffffff81e0e4c0 task.stack: ffffffff81e00000
[ 0.001000] RIP: 0010:virt_efi_set_variable+0x85/0x1a0
[ 0.001000] RSP: 0000:ffffffff81e03e18 EFLAGS: 00010202
[ 0.001000] RAX: afafafafafafafaf RBX: ffffffff81e3a4e0 RCX: 0000000000000007
[ 0.001000] RDX: ffffffff81e03e70 RSI: ffffffff81e3a4e0 RDI: ffff881fff145de0
[ 0.001000] RBP: ffffffff81e03e60 R08: 0000000000000000 R09: 0000000000000000
[ 0.001000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81e03e70
[ 0.001000] R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
[ 0.001000] FS: 0000000000000000(0000) GS:ffff881fff600000(0000) knlGS:0000000000000000
[ 0.001000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.001000] CR2: ffff88407f30f000 CR3: 000000407f87f000 CR4: 00000000000406b0
[ 0.001000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.001000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.001000] Call Trace:
[ 0.001000] efi_delete_dummy_variable+0x7a/0x80
[ 0.001000] efi_enter_virtual_mode+0x3e2/0x494
[ 0.001000] start_kernel+0x392/0x418
[ 0.001000] ? set_init_arg+0x55/0x55
[ 0.001000] x86_64_start_reservations+0x2a/0x2c
[ 0.001000] x86_64_start_kernel+0xea/0xed
[ 0.001000] start_cpu+0x14/0x14
[ 0.001000] Code: 42 25 8d ff 80 3d 43 77 95 00 00 75 68 9c 8f 04 24 48 8b 05 3e 7d 7e 00 48 89 de 4d 89 f9 4d 89 f0 44 89 e9 4c 89 e2 48 8b 40 58 <48> 8b 78 58 31 c0 e8 90 e4 92 ff 48 8b 3c 24 48 c7 c6 2b 0a ca
[ 0.001000] RIP: virt_efi_set_variable+0x85/0x1a0 RSP: ffffffff81e03e18
[ 0.001000] ---[ end trace 577c5dc2f51daaaf ]---
[ 0.001000] Kernel panic - not syncing: Fatal exception
[ 0.001000] ---[ end Kernel panic - not syncing: Fatal exception
[-- Attachment #4: kexec_revert.txt --]
[-- Type: text/plain, Size: 39857 bytes --]
[ 0.000000] Linux version 4.11.0-rc1-00001-gc4ded36 (osandov@devbig561.prn1.facebook.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #54 SMP Wed Mar 8 19:17:46 PST 2017
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-rc1 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 console=ttyS1,57600 efi=debug
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] extended physical RAM map:
[ 0.000000] reserve setup_data: [mem 0x0000000000000100-0x000000000009ffff] usable
[ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000010006f] usable
[ 0.000000] reserve setup_data: [mem 0x0000000000100070-0x00000000750bdfff] usable
[ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
[ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
[ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
[ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
[ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
[ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] efi: EFI v2.40 by American Megatrends
[ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
[ 0.000000] efi: mem00: [Boot Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000007fff] (0MB)
[ 0.000000] efi: mem01: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
[ 0.000000] efi: mem02: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
[ 0.000000] efi: mem03: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
[ 0.000000] efi: mem04: [Boot Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x0000000000040000-0x000000000009ffff] (0MB)
[ 0.000000] efi: mem05: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
[ 0.000000] efi: mem06: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
[ 0.000000] efi: mem07: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
[ 0.000000] SMBIOS 3.0.0 present.
[ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
[ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
[ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
[ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
[ 0.000000] Using GB pages for direct mapping
[ 0.000000] Secure boot could not be determined
[ 0.000000] RAMDISK: [mem 0x407d150000-0x407dffffff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x0000000075F5C000 000024 (v02 ALASKA)
[ 0.000000] ACPI: XSDT 0x0000000075F5C0A0 0000C4 (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FACP 0x0000000075F904B0 00010C (v05 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: DSDT 0x0000000075F5C200 0342AB (v02 ALASKA A M I 01072009 INTL 20091013)
[ 0.000000] ACPI: FACS 0x000000007642CF80 000040
[ 0.000000] ACPI: APIC 0x0000000075F905C0 000374 (v03 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FPDT 0x0000000075F90938 000044 (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FIDT 0x0000000075F90980 00009C (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: TCPA 0x0000000075F90A20 000032 (v02 ALASKA NAPAASF 00000001 MSFT 01000013)
[ 0.000000] ACPI: SPMI 0x0000000075F90A58 000041 (v05 ALASKA A M I 00000000 AMI. 00000000)
[ 0.000000] ACPI: MCFG 0x0000000075F90AA0 00003C (v01 ALASKA A M I 01072009 MSFT 00000097)
[ 0.000000] ACPI: UEFI 0x0000000075F90AE0 000042 (v01 ALASKA A M I 01072009 00000000)
[ 0.000000] ACPI: HPET 0x0000000075F90B28 000038 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: MSCT 0x0000000075F90B60 000090 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SLIT 0x0000000075F90BF0 000030 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SRAT 0x0000000075F90C20 001158 (v03 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: WDDT 0x0000000075F91D78 000040 (v01 ALASKA A M I 00000000 INTL 20091013)
[ 0.000000] ACPI: SSDT 0x0000000075F91DB8 0170C7 (v02 ALASKA PmMgt 00000001 INTL 20120913)
[ 0.000000] ACPI: NITR 0x0000000075FA8E80 000071 (v02 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] ACPI: SPCR 0x0000000075FA8EF8 000050 (v01 A M I APTIO V 01072009 AMI. 0005000B)
[ 0.000000] ACPI: SSDT 0x0000000075FA8F48 002652 (v02 ALASKA SpsNm 00000002 INTL 20120913)
[ 0.000000] ACPI: SSDT 0x0000000075FAB5A0 000064 (v02 ALASKA SpsNvs 00000002 INTL 20120913)
[ 0.000000] ACPI: PRAD 0x0000000075FAB608 000102 (v02 ALASKA A M I 00000002 INTL 20120913)
[ 0.000000] ACPI: DMAR 0x0000000075FAB710 0000E0 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x02 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x04 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x06 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x08 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0a -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0c -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x10 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x12 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x14 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x16 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x18 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1a -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1c -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x20 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x22 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x24 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x26 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x28 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2c -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x30 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x32 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x34 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x36 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x38 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3c -> Node 1
[ 0.000000] SRAT: PXM 0 -> APIC 0x01 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x03 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x05 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x07 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x09 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0b -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0d -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x11 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x13 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x15 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x17 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x19 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1b -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x1d -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x21 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x23 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x25 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x27 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x29 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2b -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2d -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x31 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x33 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x35 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x37 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x39 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3b -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x3d -> Node 1
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x207fffffff]
[ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x2080000000-0x407fffffff]
[ 0.000000] NUMA: Node 0 [mem 0x00000000-0x7fffffff] + [mem 0x100000000-0x207fffffff] -> [mem 0x00000000-0x207fffffff]
[ 0.000000] NODE_DATA(0) allocated [mem 0x207fffe000-0x207fffffff]
[ 0.000000] NODE_DATA(1) allocated [mem 0x407fffd000-0x407fffefff]
[ 0.000000] Reserving 128MB of memory at 768MB for crashkernel (System RAM: 261970MB)
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x000000407fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009ffff]
[ 0.000000] node 0: [mem 0x0000000000100000-0x00000000750bdfff]
[ 0.000000] node 0: [mem 0x000000007bcda000-0x000000007bcdafff]
[ 0.000000] node 0: [mem 0x000000007bd61000-0x000000007bffffff]
[ 0.000000] node 0: [mem 0x0000000100000000-0x000000207fffffff]
[ 0.000000] node 1: [mem 0x0000002080000000-0x000000407fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000207fffffff]
[ 0.000000] Initmem setup node 1 [mem 0x0000002080000000-0x000000407fffffff]
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x18] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x20] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x22] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x24] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x26] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x28] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x30] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x32] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x34] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x36] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x38] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x19] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x1d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x21] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x23] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x25] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x27] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x29] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x2d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x31] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x33] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x35] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x37] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x39] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x3d] high edge lint[0x1])
[ 0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] IOAPIC[1]: apic_id 2, version 32, address 0xfec01000, GSI 24-47
[ 0.000000] IOAPIC[2]: apic_id 3, version 32, address 0xfec40000, GSI 48-71
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] smpboot: Allowing 56 CPUs, 0 hotplug CPUs
[ 0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[ 0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:56 nr_node_ids:2
[ 0.000000] percpu: Embedded 36 pages/cpu @ffff881fff600000 s108568 r8192 d30696 u262144
[ 0.000000] Built 2 zonelists in Node order, mobility grouping on. Total pages: 66016661
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.11.0-rc1 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 console=ttyS1,57600 efi=debug
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Memory: 263824028K/268258292K available (8783K kernel code, 1280K rwdata, 3152K rodata, 1336K init, 2520K bss, 4434264K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=56, Nodes=2
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 64.
[ 0.000000] RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=56.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=56
[ 0.000000] NR_IRQS:8448 nr_irqs:1688 16
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] console [ttyS1] enabled
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2394.502 MHz processor
[ 0.000021] Calibrating delay loop (skipped), value calculated using timer frequency.. 4789.00 BogoMIPS (lpj=2394502)
[ 0.001000] pid_max: default: 57344 minimum: 448
[ 0.001000] ACPI: Core revision 20170119
[ 0.001000] ACPI: 4 ACPI AML tables successfully acquired and loaded
[ 0.001000] Security Framework initialized
[ 0.001000] SELinux: Disabled at boot.
[ 0.001000] Dentry cache hash table entries: 33554432 (order: 16, 268435456 bytes)
[ 0.001000] Inode-cache hash table entries: 16777216 (order: 15, 134217728 bytes)
[ 0.001000] Mount-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.001000] Mountpoint-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.001000] CPU: Physical Processor ID: 0
[ 0.001000] CPU: Processor Core ID: 0
[ 0.001000] mce: CPU supports 22 MCE banks
[ 0.001000] CPU0: Thermal monitoring enabled (TM1)
[ 0.001000] process: using mwait in idle threads
[ 0.001000] Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
[ 0.001000] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
[ 0.001000] Freeing SMP alternatives memory: 32K
[ 0.001000] ftrace: allocating 32009 entries in 126 pages
[ 0.001000] smpboot: Max logical packages: 4
[ 0.001000] DMAR: Host address width 46
[ 0.001000] DMAR: DRHD base: 0x000000fbffc000 flags: 0x0
[ 0.001000] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap 8d2078c106f0466 ecap f020df
[ 0.001000] DMAR: DRHD base: 0x000000c7ffc000 flags: 0x1
[ 0.001000] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap 8d2078c106f0466 ecap f020df
[ 0.001000] DMAR: RMRR base: 0x0000007bb46000 end: 0x0000007bb55fff
[ 0.001000] DMAR: ATSR flags: 0x0
[ 0.001000] DMAR: RHSA base: 0x000000c7ffc000 proximity domain: 0x0
[ 0.001000] DMAR: RHSA base: 0x000000fbffc000 proximity domain: 0x1
[ 0.001000] DMAR-IR: IOAPIC id 3 under DRHD base 0xfbffc000 IOMMU 0
[ 0.001000] DMAR-IR: IOAPIC id 1 under DRHD base 0xc7ffc000 IOMMU 1
[ 0.001000] DMAR-IR: IOAPIC id 2 under DRHD base 0xc7ffc000 IOMMU 1
[ 0.001000] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
[ 0.001000] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[ 0.001000] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[ 0.001000] DMAR-IR: IRQ remapping was enabled on dmar0 but we are not in kdump mode
[ 0.001000] DMAR-IR: Failed to copy IR table for dmar0 from previous kernel
[ 0.001000] DMAR-IR: IRQ remapping was enabled on dmar1 but we are not in kdump mode
[ 0.001000] DMAR-IR: Failed to copy IR table for dmar1 from previous kernel
[ 0.001000] DMAR-IR: Enabled IRQ remapping in xapic mode
[ 0.001000] x2apic: IRQ remapping doesn't support X2APIC mode
[ 0.001000] Switched APIC routing to physical flat.
[ 0.001000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.010867] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (family: 0x6, model: 0x4f, stepping: 0x1)
[ 0.011065] Performance Events: PEBS fmt2+, Broadwell events, 16-deep LBR, full-width counters, Broken BIOS detected, complain to your hardware vendor.
[ 0.012001] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is b00)
[ 0.013000] Intel PMU driver.
[ 0.014004] ... version: 3
[ 0.015000] ... bit width: 48
[ 0.016000] ... generic registers: 4
[ 0.017001] ... value mask: 0000ffffffffffff
[ 0.018000] ... max period: 00007fffffffffff
[ 0.019000] ... fixed-purpose events: 3
[ 0.020000] ... event mask: 000000070000000f
[ 0.023338] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[ 0.024015] smp: Bringing up secondary CPUs ...
[ 0.025066] x86: Booting SMP configuration:
[ 0.026002] .... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13
[ 0.820001] .... node #1, CPUs: #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 #24 #25 #26 #27
[ 1.676001] .... node #0, CPUs: #28 #29 #30 #31 #32 #33 #34 #35 #36 #37 #38 #39 #40 #41
[ 2.531001] .... node #1, CPUs: #42 #43 #44 #45 #46 #47 #48 #49 #50 #51 #52 #53 #54 #55
[ 3.385042] smp: Brought up 2 nodes, 56 CPUs
[ 3.387003] smpboot: Total of 56 processors activated (268518.81 BogoMIPS)
[ 3.389956] sched_clock: Marking stable (3389000000, 0)->(4420843236, -1031843236)
[ 3.411286] devtmpfs: initialized
[ 3.418124] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 3.437631] futex hash table entries: 16384 (order: 8, 1048576 bytes)
[ 3.450875] xor: automatically using best checksumming function avx
[ 3.465895] NET: Registered protocol family 16
[ 3.474950] cpuidle: using governor menu
[ 3.482795] PCCT header not found.
[ 3.489740] ACPI: bus type PCI registered
[ 3.497821] dca service started, version 1.12.1
[ 3.506891] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
[ 3.525469] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820
[ 3.539035] PCI: Using configuration type 1 for base access
[ 3.552066] HugeTLB registered 1 GB page size, pre-allocated 0 pages
[ 3.564764] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 3.594933] raid6: sse2x1 gen() 9570 MB/s
[ 3.619965] raid6: sse2x1 xor() 7158 MB/s
[ 3.645004] raid6: sse2x2 gen() 11484 MB/s
[ 3.670039] raid6: sse2x2 xor() 7826 MB/s
[ 3.695077] raid6: sse2x4 gen() 13546 MB/s
[ 3.720112] raid6: sse2x4 xor() 9544 MB/s
[ 3.745149] raid6: avx2x1 gen() 18328 MB/s
[ 3.770187] raid6: avx2x1 xor() 13714 MB/s
[ 3.795223] raid6: avx2x2 gen() 21523 MB/s
[ 3.820261] raid6: avx2x2 xor() 14535 MB/s
[ 3.845299] raid6: avx2x4 gen() 24953 MB/s
[ 3.870340] raid6: avx2x4 xor() 16843 MB/s
[ 3.878858] raid6: using algorithm avx2x4 gen() 24953 MB/s
[ 3.889797] raid6: .... xor() 16843 MB/s, rmw enabled
[ 3.899868] raid6: using avx2x2 recovery algorithm
[ 3.909589] ACPI: Added _OSI(Module Device)
[ 3.917948] ACPI: Added _OSI(Processor Device)
[ 3.926820] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 3.936199] ACPI: Added _OSI(Processor Aggregator Device)
[ 3.956012] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 3.974257] ACPI: Dynamic OEM Table Load:
[ 4.001346] ACPI: Interpreter enabled
[ 4.008657] ACPI: (supports S0 S5)
[ 4.015449] ACPI: Using IOAPIC for interrupt routing
[ 4.025375] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 4.067617] ACPI: PCI Root Bridge [UNC1] (domain 0000 [bus ff])
[ 4.079446] acpi PNP0A03:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.097673] acpi PNP0A03:02: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.113685] PCI host bridge to bus 0000:ff
[ 4.121857] pci_bus 0000:ff: root bus resource [bus ff]
[ 4.134744] ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus 7f])
[ 4.146561] acpi PNP0A03:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.163546] acpi PNP0A03:03: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.179547] PCI host bridge to bus 0000:7f
[ 4.187725] pci_bus 0000:7f: root bus resource [bus 7f]
[ 4.209416] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e])
[ 4.221753] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.238550] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.254560] PCI host bridge to bus 0000:00
[ 4.262747] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 4.276298] pci_bus 0000:00: root bus resource [io 0x1000-0x7fff window]
[ 4.289854] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 4.304778] pci_bus 0000:00: root bus resource [mem 0x90000000-0xc7ffbfff window]
[ 4.319719] pci_bus 0000:00: root bus resource [mem 0x380000000000-0x383fffffffff window]
[ 4.336049] pci_bus 0000:00: root bus resource [bus 00-7e]
[ 4.349196] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 4.362120] pci 0000:00:02.0: PCI bridge to [bus 02]
[ 4.372059] pci 0000:00:03.0: PCI bridge to [bus 03]
[ 4.383010] pci 0000:04:00.0: VF(n) BAR0 space: [mem 0x00000000-0x007fffff 64bit pref] (contains BAR0 for 8 VFs)
[ 4.403919] pci 0000:00:03.2: PCI bridge to [bus 04]
[ 4.414462] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-fe])
[ 4.426806] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 4.443596] acpi PNP0A08:01: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 4.459618] PCI host bridge to bus 0000:80
[ 4.467799] pci_bus 0000:80: root bus resource [io 0x8000-0xffff window]
[ 4.481354] pci_bus 0000:80: root bus resource [mem 0xc8000000-0xfbffbfff window]
[ 4.496295] pci_bus 0000:80: root bus resource [mem 0x384000000000-0x387fffffffff window]
[ 4.512623] pci_bus 0000:80: root bus resource [bus 80-fe]
[ 4.524054] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15), disabled.
[ 4.540105] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15), disabled.
[ 4.556156] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 *11 12 14 15), disabled.
[ 4.571852] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15), disabled.
[ 4.587546] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.603934] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.620321] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.636707] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 4.653131] ACPI: Enabled 3 GPEs in block 00 to 3F
[ 4.662851] SCSI subsystem initialized
[ 4.670351] ACPI: bus type USB registered
[ 4.678358] usbcore: registered new interface driver usbfs
[ 4.689309] usbcore: registered new interface driver hub
[ 4.700035] usbcore: registered new device driver usb
[ 4.710131] pps_core: LinuxPPS API ver. 1 registered
[ 4.720035] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 4.738257] PTP clock support registered
[ 4.746293] Registered efivars operations
[ 4.784312] PCI: Using ACPI for IRQ routing
[ 4.796939] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[ 4.809287] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 4.823032] clocksource: Switched to clocksource hpet
[ 4.845585] VFS: Disk quotas dquot_6.6.0
[ 4.853456] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 4.867261] pnp: PnP ACPI init
[ 4.873681] system 00:01: [io 0x0500-0x057f] has been reserved
[ 4.885507] system 00:01: [io 0x0400-0x0427] has been reserved
[ 4.897326] system 00:01: [io 0x0430-0x047f] has been reserved
[ 4.909147] system 00:01: [io 0x0580-0x059f] has been reserved
[ 4.920970] system 00:01: [io 0x0600-0x061f] has been reserved
[ 4.932790] system 00:01: [io 0x0880-0x0883] has been reserved
[ 4.944612] system 00:01: [io 0x0800-0x081f] has been reserved
[ 4.956437] system 00:01: [mem 0xfed1c000-0xfed3ffff] has been reserved
[ 4.969640] system 00:01: [mem 0xfed45000-0xfed8bfff] has been reserved
[ 4.982851] system 00:01: [mem 0xff000000-0xffffffff] has been reserved
[ 4.996058] system 00:01: [mem 0xfee00000-0xfeefffff] has been reserved
[ 5.009267] system 00:01: [mem 0xfed12000-0xfed1200f] has been reserved
[ 5.022474] system 00:01: [mem 0xfed12010-0xfed1201f] has been reserved
[ 5.035681] system 00:01: [mem 0xfed1b000-0xfed1bfff] has been reserved
[ 5.049095] system 00:02: [io 0x0a00-0x0a0f] has been reserved
[ 5.060919] system 00:02: [io 0x0a10-0x0a1f] has been reserved
[ 5.072742] system 00:02: [io 0x0a20-0x0a2f] has been reserved
[ 5.084565] system 00:02: [io 0x0a30-0x0a3f] has been reserved
[ 5.096385] system 00:02: [io 0x0a40-0x0a4f] has been reserved
[ 5.109137] pnp: PnP ACPI: found 6 devices
[ 5.123399] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 5.141201] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 5.151126] pci 0000:00:02.0: PCI bridge to [bus 02]
[ 5.161036] pci 0000:00:02.0: bridge window [mem 0xc7e00000-0xc7efffff]
[ 5.174592] pci 0000:00:03.0: PCI bridge to [bus 03]
[ 5.184512] pci 0000:04:00.0: BAR 7: no space for [mem size 0x00800000 64bit pref]
[ 5.199622] pci 0000:04:00.0: BAR 7: failed to assign [mem size 0x00800000 64bit pref]
[ 5.215430] pci 0000:00:03.2: PCI bridge to [bus 04]
[ 5.225344] pci 0000:00:03.2: bridge window [mem 0xc7d00000-0xc7dfffff]
[ 5.238897] pci 0000:00:03.2: bridge window [mem 0x383ffc000000-0x383ffdffffff 64bit pref]
[ 5.255748] pci_bus 0000:00: Some PCI device resources are unassigned, try booting with pci=realloc
[ 5.274043] NET: Registered protocol family 2
[ 5.283186] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
[ 5.298762] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 5.312304] TCP: Hash tables configured (established 524288 bind 65536)
[ 5.325663] UDP hash table entries: 65536 (order: 9, 2097152 bytes)
[ 5.338531] UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes)
[ 5.352399] NET: Registered protocol family 1
[ 5.361667] Trying to unpack rootfs image as initramfs...
[ 5.574263] Freeing initrd memory: 15040K
[ 5.582402] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 5.595259] software IO TLB [mem 0x710be000-0x750be000] (64MB) mapped at [ffff8800710be000-ffff8800750bdfff]
[ 5.614944] Intel CQM monitoring enabled
[ 5.622779] Intel MBM enabled
[ 5.629497] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer
[ 5.645318] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[ 5.656790] RAPL PMU: hw unit of domain package 2^-14 Joules
[ 5.668089] RAPL PMU: hw unit of domain dram 2^-14 Joules
[ 5.678853] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[ 5.699329] audit: initializing netlink subsys (disabled)
[ 5.710176] audit: type=2000 audit(1489029608.626:1): state=initialized audit_enabled=0 res=1
[ 5.710754] workingset: timestamp_bits=44 max_order=26 bucket_order=0
[ 5.711919] SGI XFS with ACLs, security attributes, no debug enabled
[ 5.713461] NET: Registered protocol family 38
[ 5.713467] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 5.713562] io scheduler noop registered
[ 5.713564] io scheduler deadline registered
[ 5.713588] io scheduler cfq registered (default)
[ 5.713588] io scheduler mq-deadline registered
[ 5.811952] pcieport 0000:00:01.0: AER enabled with IRQ 26
[ 5.822927] pcieport 0000:00:02.0: AER enabled with IRQ 28
[ 5.833896] pcieport 0000:00:03.0: AER enabled with IRQ 29
[ 5.844868] pcieport 0000:00:03.2: AER enabled with IRQ 30
[ 5.863719] ERST: Error Record Serialization Table (ERST) support is disabled.
[ 5.878142] GHES: HEST is not enabled!
[ 5.885624] EINJ: EINJ table not found.
[ 5.893292] ioatdma: Intel(R) QuickData Technology Driver 4.00
[ 5.905026] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 5.938196] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 5.973469] 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 6.023049] tpm_tis 00:05: 1.2 TPM (device-id 0x1A, rev-id 16)
[ 6.194773] brd: module loaded
[ 6.201207] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x20 impl SATA mode
[ 6.217541] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst
[ 6.233000] scsi host0: ahci
[ 6.238937] scsi host1: ahci
[ 6.244856] scsi host2: ahci
[ 6.250774] scsi host3: ahci
[ 6.256665] scsi host4: ahci
[ 6.262542] scsi host5: ahci
[ 6.268312] ata1: DUMMY
[ 6.273202] ata2: DUMMY
[ 6.278072] ata3: DUMMY
[ 6.282962] ata4: DUMMY
[ 6.287849] ata5: DUMMY
[ 6.292738] ata6: SATA max UDMA/133 abar m2048@0xc7f00000 port 0xc7f00380 irq 31
[ 6.307647] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[ 6.321551] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 6.332700] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 5.0.0-k
[ 6.347999] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
[ 6.359889] mlx5_core 0000:04:00.0: firmware version: 14.16.2012
[ 6.616158] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 6.706073] tsc: Refined TSC clocksource calibration: 2394.472 MHz
[ 6.718433] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2283d1a10f2, max_idle_ns: 440795323121 ns
[ 6.775043] ata6.00: ATA-8: TOSHIBA MG04ACA200A, FP2A, max UDMA/100
[ 6.787562] ata6.00: 488378646 sLBA48 NCQ (depth 31/32), AA
[ 6.802622] ata6.00: configured for UDMA/100
[ 6.811437] scsi 5:0:0:0: Direct-Access ATA TOSHIBA MG04ACA2 FP2A PQ: 0 ANSI: 5
[ 6.828457] sd 5:0:0:0: [sda] 488378646 4096-byte logical blocks: (2.00 TB/1.82 TiB)
[ 6.843978] sd 5:0:0:0: [sda] Write Protect is off
[ 6.853643] sd 5:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 6.973458] (0000:04:00.0): E-Switch: Total vports 9, l2 table size(65536), per vport: max uc(1024) max mc(16384)
[ 7.015790] mlx5_core 0000:04:00.0: Port module event: module 0, Cable plugged
[ 7.044506] mlx5_core 0000:04:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(64) RxCqeCmprss(0)
[ 7.103087] sda: sda1 sda2 sda3 sda4
[ 7.111431] sd 5:0:0:0: [sda] Attached SCSI disk
[ 7.177092] random: fast init done
[ 7.259733] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 7.272774] ehci-pci: EHCI PCI platform driver
[ 7.281844] ehci-pci 0000:00:1d.0: EHCI Host Controller
[ 7.292279] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 1
[ 7.307050] ehci-pci 0000:00:1d.0: debug port 2
[ 7.319995] ehci-pci 0000:00:1d.0: irq 18, io mem 0xc7f01000
[ 7.338040] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[ 7.350133] hub 1-0:1.0: USB hub found
[ 7.357664] hub 1-0:1.0: 2 ports detected
[ 7.366079] uhci_hcd: USB Universal Host Controller Interface driver
[ 7.378794] usbcore: registered new interface driver usbserial
[ 7.390455] usbcore: registered new interface driver ark3116
[ 7.401755] usbserial: USB Serial support registered for ark3116
[ 7.413750] usbcore: registered new interface driver pl2303
[ 7.424874] usbserial: USB Serial support registered for pl2303
[ 7.436706] i8042: PNP: No PS/2 controller found.
[ 7.446133] rtc_cmos 00:00: RTC can wake from S4
[ 7.455486] rtc_cmos 00:00: rtc core: registered rtc_cmos as rtc0
[ 7.467692] rtc_cmos 00:00: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 7.483088] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-devel@redhat.com
[ 7.499935] intel_pstate: Intel P-state driver initializing
[ 7.517598] usbcore: registered new interface driver usbhid
[ 7.528734] usbhid: USB HID core driver
[ 7.536523] Netfilter messages via NETLINK v0.30.
[ 7.545927] ip_set: protocol 6
[ 7.552065] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 7.562674] Initializing XFRM netlink socket
[ 7.571278] NET: Registered protocol family 10
[ 7.580584] Segment Routing with IPv6
[ 7.587908] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 7.598693] NET: Registered protocol family 17
[ 7.607575] Key type dns_resolver registered
[ 7.625168] intel_rdt: Intel RDT L3 allocation detected
[ 7.635619] intel_rdt: Intel RDT L3DATA allocation detected
[ 7.646741] intel_rdt: Intel RDT L3CODE allocation detected
[ 7.657916] microcode: sig=0x406f1, pf=0x1, revision=0xb00001d
[ 7.671697] microcode: Microcode Update Driver: v2.2.
[ 7.671714] AVX2 version of gcm_enc/dec engaged.
[ 7.691014] AES CTR mode by8 optimization enabled
[ 7.701823] registered taskstats version 1
[ 7.710345] Btrfs loaded, crc32c=crc32c-intel
[ 7.720012] usb 1-1: new high-speed USB device number 2 using ehci-pci
[ 7.794392] clocksource: Switched to clocksource tsc
[ 7.851688] hub 1-1:1.0: USB hub found
[ 7.859379] hub 1-1:1.0: 8 ports detected
[ 8.098584] netpoll: netconsole: local port 6666
[ 8.107813] netpoll: netconsole: local IPv6 address 2401:db00:11:b03e:face:0:9:0
[ 8.122583] netpoll: netconsole: interface 'eth0'
[ 8.131969] netpoll: netconsole: remote port 1514
[ 8.141346] netpoll: netconsole: remote IPv6 address 2401:db00:eef0:a59::
[ 8.154885] netpoll: netconsole: remote ethernet address 02:90:fb:5b:b7:1e
[ 8.168597] netpoll: netconsole: device eth0 not up yet, forcing it
[ 8.513889] mlx5_core 0000:04:00.0 eth0: Link up
[ 8.523379] netpoll: netconsole: carrier detect appears untrustworthy, waiting 4 seconds
[ 11.394656] random: crng init done
[ 12.595479] console [netcon_ext0] enabled
[ 12.603486] console [netcon0] enabled
[ 12.610796] netconsole: network logging started
[ 12.619927] rtc_cmos 00:00: setting system clock to 2017-03-09 03:20:20 UTC (1489029620)
[ 12.636088] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 12.648081] EDD information not available.
[ 12.657270] Freeing unused kernel memory: 1336K
[ 12.666324] Write protecting the kernel read-only data: 14336k
[ 12.678607] Freeing unused kernel memory: 1436K
[ 12.689360] Freeing unused kernel memory: 944K
[ 12.766189] systemd[1]: systemd 231 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[ 12.802909] systemd[1]: Detected architecture x86-64.
[ 12.812995] systemd[1]: Running in initial RAM disk.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-08 20:16 kexec regression since 4.9 caused by efi Omar Sandoval
2017-03-09 2:21 ` Dave Young
@ 2017-03-09 6:38 ` Dave Young
1 sibling, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-09 6:38 UTC (permalink / raw)
To: Omar Sandoval
Cc: Matt Fleming, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
Add efi/kexec list.
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [ 0.001000] general protection fault: 0000 [#1] SMP
> [ 0.001000] Modules linked in:
> [ 0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
> [ 0.001000] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.001000] task: ffffffff81e0e4c0 task.stack: ffffffff81e00000
> [ 0.001000] RIP: 0010:virt_efi_set_variable+0x85/0x1a0
> [ 0.001000] RSP: 0000:ffffffff81e03e18 EFLAGS: 00010202
> [ 0.001000] RAX: afafafafafafafaf RBX: ffffffff81e3a4e0 RCX: 0000000000000007
> [ 0.001000] RDX: ffffffff81e03e70 RSI: ffffffff81e3a4e0 RDI: ffff88407f8c2de0
> [ 0.001000] RBP: ffffffff81e03e60 R08: 0000000000000000 R09: 0000000000000000
> [ 0.001000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81e03e70
> [ 0.001000] R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
> [ 0.001000] FS: 0000000000000000(0000) GS:ffff881fff600000(0000) knlGS:0000000000000000
> [ 0.001000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.001000] CR2: ffff88407f30f000 CR3: 0000001fff102000 CR4: 00000000000406b0
> [ 0.001000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 0.001000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 0.001000] Call Trace:
> [ 0.001000] efi_delete_dummy_variable+0x7a/0x80
> [ 0.001000] efi_enter_virtual_mode+0x3e2/0x494
> [ 0.001000] start_kernel+0x392/0x418
> [ 0.001000] ? set_init_arg+0x55/0x55
> [ 0.001000] x86_64_start_reservations+0x2a/0x2c
> [ 0.001000] x86_64_start_kernel+0xea/0xed
> [ 0.001000] start_cpu+0x14/0x14
> [ 0.001000] Code: 42 25 8d ff 80 3d 43 77 95 00 00 75 68 9c 8f 04 24 48 8b 05 3e 7d 7e 00 48 89 de 4d 89 f9 4d 89 f0 44 89 e9 4c 89 e2 48 8b 40 58 <48> 8b 78 58 31 c0 e8 90 e4 92 ff 48 8b 3c 24 48 c7 c6 2b 0a ca
> [ 0.001000] RIP: virt_efi_set_variable+0x85/0x1a0 RSP: ffffffff81e03e18
> [ 0.001000] ---[ end trace 0bd213e540e9b19f ]---
> [ 0.001000] Kernel panic - not syncing: Fatal exception
> [ 0.001000] ---[ end Kernel panic - not syncing: Fatal exception
>
> Booting normally (i.e., not kexec) still works.
>
> The decoded code is:
>
>
> 0: 42 25 8d ff 80 3d rex.X and $0x3d80ff8d,%eax
> 6: 43 77 95 rex.XB ja 0xffffffffffffff9e
> 9: 00 00 add %al,(%rax)
> b: 75 68 jne 0x75
> d: 9c pushfq
> e: 8f 04 24 popq (%rsp)
> 11: 48 8b 05 3e 7d 7e 00 mov 0x7e7d3e(%rip),%rax # 0x7e7d56
> 18: 48 89 de mov %rbx,%rsi
> 1b: 4d 89 f9 mov %r15,%r9
> 1e: 4d 89 f0 mov %r14,%r8
> 21: 44 89 e9 mov %r13d,%ecx
> 24: 4c 89 e2 mov %r12,%rdx
> 27: 48 8b 40 58 mov 0x58(%rax),%rax
> 2b:* 48 8b 78 58 mov 0x58(%rax),%rdi <-- trapping instruction
> 2f: 31 c0 xor %eax,%eax
> 31: e8 90 e4 92 ff callq 0xffffffffff92e4c6
> 36: 48 8b 3c 24 mov (%rsp),%rdi
> 3a: 48 rex.W
> 3b: c7 .byte 0xc7
> 3c: c6 (bad)
> 3d: 2b 0a sub (%rdx),%ecx
> 3f: ca .byte 0xca
>
> If I'm reading this correctly, efi.systab->runtime == 0xafafafafafafafaf,
I have no more clue yet from your provided log, but the runtime value is
odd to me. It is set in below code:
arch/x86/platform/efi/efi.c: efi_systab_init()
efi_systab.runtime = data ?
(void *)(unsigned long)data->runtime :
(void *)(unsigne long)systab64->runtime;
Here data is the setup_data passed by kexec-tools from normal kernel to
kexec kernel, efi_setup_data structure is like below:
struct efi_setup_data {
u64 fw_vendor;
u64 runtime;
u64 tables;
u64 smbios;
u64 reserved[8];
};
kexec-tools get the runtime address from /sys/firmware/efi/runtime
So can you do some debuggin on your side, eg. see the sysfs runtime
value is correct or not. And add some printk in efi init path etc.
> and we're crashing when we try to dereference that.
>
> Here is the output of efi=debug from before the crash:
>
> [ 0.000000] Linux version 4.11.0-rc1 (osandov@devbig561.prn1.facebook.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #53 SMP Wed Mar 8 12:07:16 PST 2017
> [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.6.7-34_fbk7_2504_g8275185 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 co
> nsole=ttyS1,57600 efi=debug
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> [ 0.000000] e820: BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
> [ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] extended physical RAM map:
> [ 0.000000] reserve setup_data: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000010006f] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100070-0x00000000750bdfff] usable
> [ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] efi: EFI v2.40 by American Megatrends
> [ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
> [ 0.000000] efi: mem00: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
> [ 0.000000] efi: mem01: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
> [ 0.000000] efi: mem02: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
> [ 0.000000] efi: mem03: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
> [ 0.000000] efi: mem04: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
> [ 0.000000] efi: mem05: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
> [ 0.000000] SMBIOS 3.0.0 present.
> [ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
> [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
> [ 0.000000] x2apic: enabled by BIOS, switching to x2apic ops
> [ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
> [ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
>
> Reverting commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and
> avoid a kmalloc()") on top of v4.11-rc1 fixes the problem. Bisecting
> this was interesting:
>
> - Up until 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a
> kmalloc()"), kexec worked.
>
> - From 8e80632fb23f to 9d80448ac92b ("efi/arm64: Add debugfs node to
> dump UEFI runtime page tables"), kexec just hung after the
> "kexec_core: Starting new kernel" message.
>
> - From 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init until after
> memblock_x86_fill") to 0a637ee61247 ("x86/efi: Allow invocation of
> arbitrary boot services"), kexec hit the BUG_ON(!efi.systab) in
> kexec_enter_virtual_mode().
>
> - Finally, after 92dc33501bfb ("x86/efi: Round EFI memmap reservations
> to EFI_PAGE_SIZE"), I get the panic described above.
>
> Let me know if there is any more information I can provide.
>
> Thanks!
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-09 6:38 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-09 6:38 UTC (permalink / raw)
To: Omar Sandoval
Cc: Matt Fleming, Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-team-b10kYP2dOMg, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-efi-u79uwXL29TY76Z2rM5mHXA
Add efi/kexec list.
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [ 0.001000] general protection fault: 0000 [#1] SMP
> [ 0.001000] Modules linked in:
> [ 0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
> [ 0.001000] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.001000] task: ffffffff81e0e4c0 task.stack: ffffffff81e00000
> [ 0.001000] RIP: 0010:virt_efi_set_variable+0x85/0x1a0
> [ 0.001000] RSP: 0000:ffffffff81e03e18 EFLAGS: 00010202
> [ 0.001000] RAX: afafafafafafafaf RBX: ffffffff81e3a4e0 RCX: 0000000000000007
> [ 0.001000] RDX: ffffffff81e03e70 RSI: ffffffff81e3a4e0 RDI: ffff88407f8c2de0
> [ 0.001000] RBP: ffffffff81e03e60 R08: 0000000000000000 R09: 0000000000000000
> [ 0.001000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81e03e70
> [ 0.001000] R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
> [ 0.001000] FS: 0000000000000000(0000) GS:ffff881fff600000(0000) knlGS:0000000000000000
> [ 0.001000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.001000] CR2: ffff88407f30f000 CR3: 0000001fff102000 CR4: 00000000000406b0
> [ 0.001000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 0.001000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 0.001000] Call Trace:
> [ 0.001000] efi_delete_dummy_variable+0x7a/0x80
> [ 0.001000] efi_enter_virtual_mode+0x3e2/0x494
> [ 0.001000] start_kernel+0x392/0x418
> [ 0.001000] ? set_init_arg+0x55/0x55
> [ 0.001000] x86_64_start_reservations+0x2a/0x2c
> [ 0.001000] x86_64_start_kernel+0xea/0xed
> [ 0.001000] start_cpu+0x14/0x14
> [ 0.001000] Code: 42 25 8d ff 80 3d 43 77 95 00 00 75 68 9c 8f 04 24 48 8b 05 3e 7d 7e 00 48 89 de 4d 89 f9 4d 89 f0 44 89 e9 4c 89 e2 48 8b 40 58 <48> 8b 78 58 31 c0 e8 90 e4 92 ff 48 8b 3c 24 48 c7 c6 2b 0a ca
> [ 0.001000] RIP: virt_efi_set_variable+0x85/0x1a0 RSP: ffffffff81e03e18
> [ 0.001000] ---[ end trace 0bd213e540e9b19f ]---
> [ 0.001000] Kernel panic - not syncing: Fatal exception
> [ 0.001000] ---[ end Kernel panic - not syncing: Fatal exception
>
> Booting normally (i.e., not kexec) still works.
>
> The decoded code is:
>
>
> 0: 42 25 8d ff 80 3d rex.X and $0x3d80ff8d,%eax
> 6: 43 77 95 rex.XB ja 0xffffffffffffff9e
> 9: 00 00 add %al,(%rax)
> b: 75 68 jne 0x75
> d: 9c pushfq
> e: 8f 04 24 popq (%rsp)
> 11: 48 8b 05 3e 7d 7e 00 mov 0x7e7d3e(%rip),%rax # 0x7e7d56
> 18: 48 89 de mov %rbx,%rsi
> 1b: 4d 89 f9 mov %r15,%r9
> 1e: 4d 89 f0 mov %r14,%r8
> 21: 44 89 e9 mov %r13d,%ecx
> 24: 4c 89 e2 mov %r12,%rdx
> 27: 48 8b 40 58 mov 0x58(%rax),%rax
> 2b:* 48 8b 78 58 mov 0x58(%rax),%rdi <-- trapping instruction
> 2f: 31 c0 xor %eax,%eax
> 31: e8 90 e4 92 ff callq 0xffffffffff92e4c6
> 36: 48 8b 3c 24 mov (%rsp),%rdi
> 3a: 48 rex.W
> 3b: c7 .byte 0xc7
> 3c: c6 (bad)
> 3d: 2b 0a sub (%rdx),%ecx
> 3f: ca .byte 0xca
>
> If I'm reading this correctly, efi.systab->runtime == 0xafafafafafafafaf,
I have no more clue yet from your provided log, but the runtime value is
odd to me. It is set in below code:
arch/x86/platform/efi/efi.c: efi_systab_init()
efi_systab.runtime = data ?
(void *)(unsigned long)data->runtime :
(void *)(unsigne long)systab64->runtime;
Here data is the setup_data passed by kexec-tools from normal kernel to
kexec kernel, efi_setup_data structure is like below:
struct efi_setup_data {
u64 fw_vendor;
u64 runtime;
u64 tables;
u64 smbios;
u64 reserved[8];
};
kexec-tools get the runtime address from /sys/firmware/efi/runtime
So can you do some debuggin on your side, eg. see the sysfs runtime
value is correct or not. And add some printk in efi init path etc.
> and we're crashing when we try to dereference that.
>
> Here is the output of efi=debug from before the crash:
>
> [ 0.000000] Linux version 4.11.0-rc1 (osandov-LNiRsUx2DMbOmZU/NTPFeQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #53 SMP Wed Mar 8 12:07:16 PST 2017
> [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.6.7-34_fbk7_2504_g8275185 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 co
> nsole=ttyS1,57600 efi=debug
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> [ 0.000000] e820: BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
> [ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] extended physical RAM map:
> [ 0.000000] reserve setup_data: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000010006f] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100070-0x00000000750bdfff] usable
> [ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] efi: EFI v2.40 by American Megatrends
> [ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
> [ 0.000000] efi: mem00: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
> [ 0.000000] efi: mem01: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
> [ 0.000000] efi: mem02: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
> [ 0.000000] efi: mem03: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
> [ 0.000000] efi: mem04: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
> [ 0.000000] efi: mem05: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
> [ 0.000000] SMBIOS 3.0.0 present.
> [ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
> [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
> [ 0.000000] x2apic: enabled by BIOS, switching to x2apic ops
> [ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
> [ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
>
> Reverting commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and
> avoid a kmalloc()") on top of v4.11-rc1 fixes the problem. Bisecting
> this was interesting:
>
> - Up until 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a
> kmalloc()"), kexec worked.
>
> - From 8e80632fb23f to 9d80448ac92b ("efi/arm64: Add debugfs node to
> dump UEFI runtime page tables"), kexec just hung after the
> "kexec_core: Starting new kernel" message.
>
> - From 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init until after
> memblock_x86_fill") to 0a637ee61247 ("x86/efi: Allow invocation of
> arbitrary boot services"), kexec hit the BUG_ON(!efi.systab) in
> kexec_enter_virtual_mode().
>
> - Finally, after 92dc33501bfb ("x86/efi: Round EFI memmap reservations
> to EFI_PAGE_SIZE"), I get the panic described above.
>
> Let me know if there is any more information I can provide.
>
> Thanks!
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-09 6:38 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-09 6:38 UTC (permalink / raw)
To: Omar Sandoval
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, kernel-team, Ingo Molnar
Add efi/kexec list.
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [ 0.001000] general protection fault: 0000 [#1] SMP
> [ 0.001000] Modules linked in:
> [ 0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
> [ 0.001000] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.001000] task: ffffffff81e0e4c0 task.stack: ffffffff81e00000
> [ 0.001000] RIP: 0010:virt_efi_set_variable+0x85/0x1a0
> [ 0.001000] RSP: 0000:ffffffff81e03e18 EFLAGS: 00010202
> [ 0.001000] RAX: afafafafafafafaf RBX: ffffffff81e3a4e0 RCX: 0000000000000007
> [ 0.001000] RDX: ffffffff81e03e70 RSI: ffffffff81e3a4e0 RDI: ffff88407f8c2de0
> [ 0.001000] RBP: ffffffff81e03e60 R08: 0000000000000000 R09: 0000000000000000
> [ 0.001000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81e03e70
> [ 0.001000] R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
> [ 0.001000] FS: 0000000000000000(0000) GS:ffff881fff600000(0000) knlGS:0000000000000000
> [ 0.001000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.001000] CR2: ffff88407f30f000 CR3: 0000001fff102000 CR4: 00000000000406b0
> [ 0.001000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 0.001000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 0.001000] Call Trace:
> [ 0.001000] efi_delete_dummy_variable+0x7a/0x80
> [ 0.001000] efi_enter_virtual_mode+0x3e2/0x494
> [ 0.001000] start_kernel+0x392/0x418
> [ 0.001000] ? set_init_arg+0x55/0x55
> [ 0.001000] x86_64_start_reservations+0x2a/0x2c
> [ 0.001000] x86_64_start_kernel+0xea/0xed
> [ 0.001000] start_cpu+0x14/0x14
> [ 0.001000] Code: 42 25 8d ff 80 3d 43 77 95 00 00 75 68 9c 8f 04 24 48 8b 05 3e 7d 7e 00 48 89 de 4d 89 f9 4d 89 f0 44 89 e9 4c 89 e2 48 8b 40 58 <48> 8b 78 58 31 c0 e8 90 e4 92 ff 48 8b 3c 24 48 c7 c6 2b 0a ca
> [ 0.001000] RIP: virt_efi_set_variable+0x85/0x1a0 RSP: ffffffff81e03e18
> [ 0.001000] ---[ end trace 0bd213e540e9b19f ]---
> [ 0.001000] Kernel panic - not syncing: Fatal exception
> [ 0.001000] ---[ end Kernel panic - not syncing: Fatal exception
>
> Booting normally (i.e., not kexec) still works.
>
> The decoded code is:
>
>
> 0: 42 25 8d ff 80 3d rex.X and $0x3d80ff8d,%eax
> 6: 43 77 95 rex.XB ja 0xffffffffffffff9e
> 9: 00 00 add %al,(%rax)
> b: 75 68 jne 0x75
> d: 9c pushfq
> e: 8f 04 24 popq (%rsp)
> 11: 48 8b 05 3e 7d 7e 00 mov 0x7e7d3e(%rip),%rax # 0x7e7d56
> 18: 48 89 de mov %rbx,%rsi
> 1b: 4d 89 f9 mov %r15,%r9
> 1e: 4d 89 f0 mov %r14,%r8
> 21: 44 89 e9 mov %r13d,%ecx
> 24: 4c 89 e2 mov %r12,%rdx
> 27: 48 8b 40 58 mov 0x58(%rax),%rax
> 2b:* 48 8b 78 58 mov 0x58(%rax),%rdi <-- trapping instruction
> 2f: 31 c0 xor %eax,%eax
> 31: e8 90 e4 92 ff callq 0xffffffffff92e4c6
> 36: 48 8b 3c 24 mov (%rsp),%rdi
> 3a: 48 rex.W
> 3b: c7 .byte 0xc7
> 3c: c6 (bad)
> 3d: 2b 0a sub (%rdx),%ecx
> 3f: ca .byte 0xca
>
> If I'm reading this correctly, efi.systab->runtime == 0xafafafafafafafaf,
I have no more clue yet from your provided log, but the runtime value is
odd to me. It is set in below code:
arch/x86/platform/efi/efi.c: efi_systab_init()
efi_systab.runtime = data ?
(void *)(unsigned long)data->runtime :
(void *)(unsigne long)systab64->runtime;
Here data is the setup_data passed by kexec-tools from normal kernel to
kexec kernel, efi_setup_data structure is like below:
struct efi_setup_data {
u64 fw_vendor;
u64 runtime;
u64 tables;
u64 smbios;
u64 reserved[8];
};
kexec-tools get the runtime address from /sys/firmware/efi/runtime
So can you do some debuggin on your side, eg. see the sysfs runtime
value is correct or not. And add some printk in efi init path etc.
> and we're crashing when we try to dereference that.
>
> Here is the output of efi=debug from before the crash:
>
> [ 0.000000] Linux version 4.11.0-rc1 (osandov@devbig561.prn1.facebook.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #53 SMP Wed Mar 8 12:07:16 PST 2017
> [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.6.7-34_fbk7_2504_g8275185 ro root=LABEL=/ ipv6.autoconf=0 erst_disable biosdevname=0 net.ifnames=0 fsck.repair=yes pcie_pme=nomsi netconsole=+6666@2401:db00:0011:b03e:face:0000:0009:0000/eth0,1514@2401:db00:eef0:a59::/02:90:fb:5b:b7:1e crashkernel=128M console=tty0 co
> nsole=ttyS1,57600 efi=debug
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> [ 0.000000] e820: BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000750bdfff] usable
> [ 0.000000] BIOS-e820: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] BIOS-e820: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] BIOS-e820: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] extended physical RAM map:
> [ 0.000000] reserve setup_data: [mem 0x0000000000000100-0x000000000009ffff] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000010006f] usable
> [ 0.000000] reserve setup_data: [mem 0x0000000000100070-0x00000000750bdfff] usable
> [ 0.000000] reserve setup_data: [mem 0x00000000750be000-0x0000000075ddbfff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000075ddc000-0x0000000075e32fff] ACPI data
> [ 0.000000] reserve setup_data: [mem 0x0000000075e33000-0x000000007642dfff] ACPI NVS
> [ 0.000000] reserve setup_data: [mem 0x000000007642e000-0x000000007bcd9fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bcda000-0x000000007bcdafff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007bcdb000-0x000000007bd60fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x000000007bd61000-0x000000007bffffff] usable
> [ 0.000000] reserve setup_data: [mem 0x000000007c000000-0x000000008fffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved
> [ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x000000407fffffff] usable
> [ 0.000000] efi: EFI v2.40 by American Megatrends
> [ 0.000000] efi: ACPI=0x75f5c000 ACPI 2.0=0x75f5c000 ESRT=0x7bc4d018 SMBIOS=0xf05e0 SMBIOS 3.0=0x7bb2f000 MPS=0xfc9e0
> [ 0.000000] efi: mem00: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007642e000-0x000000007bc50fff] (88MB)
> [ 0.000000] efi: mem01: [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bc51000-0x000000007bcd9fff] (0MB)
> [ 0.000000] efi: mem02: [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x000000007bcdb000-0x000000007bd60fff] (0MB)
> [ 0.000000] efi: mem03: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x0000000080000000-0x000000008fffffff] (256MB)
> [ 0.000000] efi: mem04: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000fed1c000-0x00000000fed44fff] (0MB)
> [ 0.000000] efi: mem05: [Memory Mapped I/O |RUN| | | | | | | | | | |UC] range=[0x00000000ff000000-0x00000000ffffffff] (16MB)
> [ 0.000000] SMBIOS 3.0.0 present.
> [ 0.000000] DMI: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
> [ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
> [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
> [ 0.000000] x2apic: enabled by BIOS, switching to x2apic ops
> [ 0.000000] e820: last_pfn = 0x7c000 max_arch_pfn = 0x400000000
> [ 0.000000] esrt: Reserving ESRT space from 0x000000007bc4d018 to 0x000000007bc4d050.
>
> Reverting commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and
> avoid a kmalloc()") on top of v4.11-rc1 fixes the problem. Bisecting
> this was interesting:
>
> - Up until 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a
> kmalloc()"), kexec worked.
>
> - From 8e80632fb23f to 9d80448ac92b ("efi/arm64: Add debugfs node to
> dump UEFI runtime page tables"), kexec just hung after the
> "kexec_core: Starting new kernel" message.
>
> - From 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init until after
> memblock_x86_fill") to 0a637ee61247 ("x86/efi: Allow invocation of
> arbitrary boot services"), kexec hit the BUG_ON(!efi.systab) in
> kexec_enter_virtual_mode().
>
> - Finally, after 92dc33501bfb ("x86/efi: Round EFI memmap reservations
> to EFI_PAGE_SIZE"), I get the panic described above.
>
> Let me know if there is any more information I can provide.
>
> Thanks!
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-09 6:38 ` Dave Young
@ 2017-03-09 9:54 ` Omar Sandoval
-1 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-03-09 9:54 UTC (permalink / raw)
To: Dave Young
Cc: Matt Fleming, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> Add efi/kexec list.
>
> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
[snip]
> I have no more clue yet from your provided log, but the runtime value is
> odd to me. It is set in below code:
>
> arch/x86/platform/efi/efi.c: efi_systab_init()
> efi_systab.runtime = data ?
> (void *)(unsigned long)data->runtime :
> (void *)(unsigne long)systab64->runtime;
>
> Here data is the setup_data passed by kexec-tools from normal kernel to
> kexec kernel, efi_setup_data structure is like below:
> struct efi_setup_data {
> u64 fw_vendor;
> u64 runtime;
> u64 tables;
> u64 smbios;
> u64 reserved[8];
> };
>
> kexec-tools get the runtime address from /sys/firmware/efi/runtime
>
> So can you do some debuggin on your side, eg. see the sysfs runtime
> value is correct or not. And add some printk in efi init path etc.
The attached patch fixes this for me.
[-- Attachment #2: 0001-efi-adjust-virt_addr-when-splitting-descriptors-in-e.patch --]
[-- Type: text/x-diff, Size: 2223 bytes --]
>From 4b343f0b0b408469f28c973ea52877797a166313 Mon Sep 17 00:00:00 2001
Message-Id: <4b343f0b0b408469f28c973ea52877797a166313.1489053164.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
Date: Thu, 9 Mar 2017 01:46:19 -0800
Subject: [PATCH] efi: adjust virt_addr when splitting descriptors in
efi_memmap_insert()
When we split efi memory descriptors, we adjust the physical address but
not the virtual address it maps to. This leads to bogus memory mappings
later when these virtual addresses are used.
This fixes a kexec boot regression since 8e80632fb23f ("efi/esrt: Use
efi_mem_reserve() and avoid a kmalloc()"), although the bug was only
exposed by that commit.
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
drivers/firmware/efi/memmap.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index 78686443cb37..ca614db76faf 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -298,6 +298,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
memcpy(new, old, old_memmap->desc_size);
md = new;
md->phys_addr = m_end + 1;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (end - md->phys_addr + 1) >>
EFI_PAGE_SHIFT;
}
@@ -312,6 +313,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
md = new;
md->attribute |= m_attr;
md->phys_addr = m_start;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (m_end - m_start + 1) >>
EFI_PAGE_SHIFT;
/* last part */
@@ -319,6 +321,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
memcpy(new, old, old_memmap->desc_size);
md = new;
md->phys_addr = m_end + 1;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (end - m_end) >>
EFI_PAGE_SHIFT;
}
@@ -333,6 +336,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
memcpy(new, old, old_memmap->desc_size);
md = new;
md->phys_addr = m_start;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (end - md->phys_addr + 1) >>
EFI_PAGE_SHIFT;
md->attribute |= m_attr;
--
2.12.0
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-09 9:54 ` Omar Sandoval
0 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-03-09 9:54 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, kernel-team, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> Add efi/kexec list.
>
> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
[snip]
> I have no more clue yet from your provided log, but the runtime value is
> odd to me. It is set in below code:
>
> arch/x86/platform/efi/efi.c: efi_systab_init()
> efi_systab.runtime = data ?
> (void *)(unsigned long)data->runtime :
> (void *)(unsigne long)systab64->runtime;
>
> Here data is the setup_data passed by kexec-tools from normal kernel to
> kexec kernel, efi_setup_data structure is like below:
> struct efi_setup_data {
> u64 fw_vendor;
> u64 runtime;
> u64 tables;
> u64 smbios;
> u64 reserved[8];
> };
>
> kexec-tools get the runtime address from /sys/firmware/efi/runtime
>
> So can you do some debuggin on your side, eg. see the sysfs runtime
> value is correct or not. And add some printk in efi init path etc.
The attached patch fixes this for me.
[-- Attachment #2: 0001-efi-adjust-virt_addr-when-splitting-descriptors-in-e.patch --]
[-- Type: text/x-diff, Size: 2222 bytes --]
From 4b343f0b0b408469f28c973ea52877797a166313 Mon Sep 17 00:00:00 2001
Message-Id: <4b343f0b0b408469f28c973ea52877797a166313.1489053164.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
Date: Thu, 9 Mar 2017 01:46:19 -0800
Subject: [PATCH] efi: adjust virt_addr when splitting descriptors in
efi_memmap_insert()
When we split efi memory descriptors, we adjust the physical address but
not the virtual address it maps to. This leads to bogus memory mappings
later when these virtual addresses are used.
This fixes a kexec boot regression since 8e80632fb23f ("efi/esrt: Use
efi_mem_reserve() and avoid a kmalloc()"), although the bug was only
exposed by that commit.
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
drivers/firmware/efi/memmap.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index 78686443cb37..ca614db76faf 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -298,6 +298,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
memcpy(new, old, old_memmap->desc_size);
md = new;
md->phys_addr = m_end + 1;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (end - md->phys_addr + 1) >>
EFI_PAGE_SHIFT;
}
@@ -312,6 +313,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
md = new;
md->attribute |= m_attr;
md->phys_addr = m_start;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (m_end - m_start + 1) >>
EFI_PAGE_SHIFT;
/* last part */
@@ -319,6 +321,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
memcpy(new, old, old_memmap->desc_size);
md = new;
md->phys_addr = m_end + 1;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (end - m_end) >>
EFI_PAGE_SHIFT;
}
@@ -333,6 +336,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
memcpy(new, old, old_memmap->desc_size);
md = new;
md->phys_addr = m_start;
+ md->virt_addr += md->phys_addr - start;
md->num_pages = (end - md->phys_addr + 1) >>
EFI_PAGE_SHIFT;
md->attribute |= m_attr;
--
2.12.0
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-09 9:54 ` Omar Sandoval
(?)
@ 2017-03-09 11:53 ` Ard Biesheuvel
-1 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-09 11:53 UTC (permalink / raw)
To: Omar Sandoval, Matt Fleming
Cc: Dave Young, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On 9 March 2017 at 10:54, Omar Sandoval <osandov@osandov.com> wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
>> Add efi/kexec list.
>>
>> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
>> I have no more clue yet from your provided log, but the runtime value is
>> odd to me. It is set in below code:
>>
>> arch/x86/platform/efi/efi.c: efi_systab_init()
>> efi_systab.runtime = data ?
>> (void *)(unsigned long)data->runtime :
>> (void *)(unsigne long)systab64->runtime;
>>
>> Here data is the setup_data passed by kexec-tools from normal kernel to
>> kexec kernel, efi_setup_data structure is like below:
>> struct efi_setup_data {
>> u64 fw_vendor;
>> u64 runtime;
>> u64 tables;
>> u64 smbios;
>> u64 reserved[8];
>> };
>>
>> kexec-tools get the runtime address from /sys/firmware/efi/runtime
>>
>> So can you do some debuggin on your side, eg. see the sysfs runtime
>> value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
Hi Omar,
Thanks for tracking this down.
I wonder if this is an unintended side effect of the way we repurpose
the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
splitting memory map entries should only be necessary for regions that
are not runtime memory regions to begin with, and so whether their
virtual mapping address makes sense or not should be irrelevant.
Perhaps this only illustrates my lack of understanding of the x86 way
of doing this, so perhaps Matt can shed some light on this?
Thanks,
Ard.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-09 11:53 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-09 11:53 UTC (permalink / raw)
To: Omar Sandoval, Matt Fleming
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-team-b10kYP2dOMg,
Dave Young, Ingo Molnar
On 9 March 2017 at 10:54, Omar Sandoval <osandov-nWWhXC5lh1RBDgjK7y7TUQ@public.gmane.org> wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
>> Add efi/kexec list.
>>
>> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
>> I have no more clue yet from your provided log, but the runtime value is
>> odd to me. It is set in below code:
>>
>> arch/x86/platform/efi/efi.c: efi_systab_init()
>> efi_systab.runtime = data ?
>> (void *)(unsigned long)data->runtime :
>> (void *)(unsigne long)systab64->runtime;
>>
>> Here data is the setup_data passed by kexec-tools from normal kernel to
>> kexec kernel, efi_setup_data structure is like below:
>> struct efi_setup_data {
>> u64 fw_vendor;
>> u64 runtime;
>> u64 tables;
>> u64 smbios;
>> u64 reserved[8];
>> };
>>
>> kexec-tools get the runtime address from /sys/firmware/efi/runtime
>>
>> So can you do some debuggin on your side, eg. see the sysfs runtime
>> value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
Hi Omar,
Thanks for tracking this down.
I wonder if this is an unintended side effect of the way we repurpose
the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
splitting memory map entries should only be necessary for regions that
are not runtime memory regions to begin with, and so whether their
virtual mapping address makes sense or not should be irrelevant.
Perhaps this only illustrates my lack of understanding of the x86 way
of doing this, so perhaps Matt can shed some light on this?
Thanks,
Ard.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-09 11:53 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-09 11:53 UTC (permalink / raw)
To: Omar Sandoval, Matt Fleming
Cc: linux-efi, kexec, linux-kernel, kernel-team, Dave Young, Ingo Molnar
On 9 March 2017 at 10:54, Omar Sandoval <osandov@osandov.com> wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
>> Add efi/kexec list.
>>
>> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
>> I have no more clue yet from your provided log, but the runtime value is
>> odd to me. It is set in below code:
>>
>> arch/x86/platform/efi/efi.c: efi_systab_init()
>> efi_systab.runtime = data ?
>> (void *)(unsigned long)data->runtime :
>> (void *)(unsigne long)systab64->runtime;
>>
>> Here data is the setup_data passed by kexec-tools from normal kernel to
>> kexec kernel, efi_setup_data structure is like below:
>> struct efi_setup_data {
>> u64 fw_vendor;
>> u64 runtime;
>> u64 tables;
>> u64 smbios;
>> u64 reserved[8];
>> };
>>
>> kexec-tools get the runtime address from /sys/firmware/efi/runtime
>>
>> So can you do some debuggin on your side, eg. see the sysfs runtime
>> value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
Hi Omar,
Thanks for tracking this down.
I wonder if this is an unintended side effect of the way we repurpose
the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
splitting memory map entries should only be necessary for regions that
are not runtime memory regions to begin with, and so whether their
virtual mapping address makes sense or not should be irrelevant.
Perhaps this only illustrates my lack of understanding of the x86 way
of doing this, so perhaps Matt can shed some light on this?
Thanks,
Ard.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-09 11:53 ` Ard Biesheuvel
@ 2017-03-10 1:39 ` Dave Young
-1 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-10 1:39 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Omar Sandoval, Matt Fleming, Ingo Molnar, linux-kernel,
kernel-team, kexec, linux-efi
On 03/09/17 at 12:53pm, Ard Biesheuvel wrote:
> On 9 March 2017 at 10:54, Omar Sandoval <osandov@osandov.com> wrote:
> > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> >> Add efi/kexec list.
> >>
> >> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> >
> > [snip]
> >
> >> I have no more clue yet from your provided log, but the runtime value is
> >> odd to me. It is set in below code:
> >>
> >> arch/x86/platform/efi/efi.c: efi_systab_init()
> >> efi_systab.runtime = data ?
> >> (void *)(unsigned long)data->runtime :
> >> (void *)(unsigne long)systab64->runtime;
> >>
> >> Here data is the setup_data passed by kexec-tools from normal kernel to
> >> kexec kernel, efi_setup_data structure is like below:
> >> struct efi_setup_data {
> >> u64 fw_vendor;
> >> u64 runtime;
> >> u64 tables;
> >> u64 smbios;
> >> u64 reserved[8];
> >> };
> >>
> >> kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >>
> >> So can you do some debuggin on your side, eg. see the sysfs runtime
> >> value is correct or not. And add some printk in efi init path etc.
> >
> > The attached patch fixes this for me.
>
> Hi Omar,
>
> Thanks for tracking this down.
>
> I wonder if this is an unintended side effect of the way we repurpose
> the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
> splitting memory map entries should only be necessary for regions that
> are not runtime memory regions to begin with, and so whether their
> virtual mapping address makes sense or not should be irrelevant.
In this case the esrt chunk are Runtime Data which is not necessary to
be reserved explicitly. I think efi_arch_mem_reserve are for boot areas.
Probably there could be esrt data which belongs to boot data? If we are
sure they are all runtime, the better fix may be just dropping the
efi_mem_reserve in esrt.c
>
> Perhaps this only illustrates my lack of understanding of the x86 way
> of doing this, so perhaps Matt can shed some light on this?
>
> Thanks,
> Ard.
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-10 1:39 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-10 1:39 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, Ingo Molnar,
Omar Sandoval, kernel-team
On 03/09/17 at 12:53pm, Ard Biesheuvel wrote:
> On 9 March 2017 at 10:54, Omar Sandoval <osandov@osandov.com> wrote:
> > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> >> Add efi/kexec list.
> >>
> >> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> >
> > [snip]
> >
> >> I have no more clue yet from your provided log, but the runtime value is
> >> odd to me. It is set in below code:
> >>
> >> arch/x86/platform/efi/efi.c: efi_systab_init()
> >> efi_systab.runtime = data ?
> >> (void *)(unsigned long)data->runtime :
> >> (void *)(unsigne long)systab64->runtime;
> >>
> >> Here data is the setup_data passed by kexec-tools from normal kernel to
> >> kexec kernel, efi_setup_data structure is like below:
> >> struct efi_setup_data {
> >> u64 fw_vendor;
> >> u64 runtime;
> >> u64 tables;
> >> u64 smbios;
> >> u64 reserved[8];
> >> };
> >>
> >> kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >>
> >> So can you do some debuggin on your side, eg. see the sysfs runtime
> >> value is correct or not. And add some printk in efi init path etc.
> >
> > The attached patch fixes this for me.
>
> Hi Omar,
>
> Thanks for tracking this down.
>
> I wonder if this is an unintended side effect of the way we repurpose
> the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
> splitting memory map entries should only be necessary for regions that
> are not runtime memory regions to begin with, and so whether their
> virtual mapping address makes sense or not should be irrelevant.
In this case the esrt chunk are Runtime Data which is not necessary to
be reserved explicitly. I think efi_arch_mem_reserve are for boot areas.
Probably there could be esrt data which belongs to boot data? If we are
sure they are all runtime, the better fix may be just dropping the
efi_mem_reserve in esrt.c
>
> Perhaps this only illustrates my lack of understanding of the x86 way
> of doing this, so perhaps Matt can shed some light on this?
>
> Thanks,
> Ard.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-09 9:54 ` Omar Sandoval
(?)
@ 2017-03-10 1:42 ` Dave Young
-1 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-10 1:42 UTC (permalink / raw)
To: Omar Sandoval
Cc: Matt Fleming, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the runtime value is
> > odd to me. It is set in below code:
> >
> > arch/x86/platform/efi/efi.c: efi_systab_init()
> > efi_systab.runtime = data ?
> > (void *)(unsigned long)data->runtime :
> > (void *)(unsigne long)systab64->runtime;
> >
> > Here data is the setup_data passed by kexec-tools from normal kernel to
> > kexec kernel, efi_setup_data structure is like below:
> > struct efi_setup_data {
> > u64 fw_vendor;
> > u64 runtime;
> > u64 tables;
> > u64 smbios;
> > u64 reserved[8];
> > };
> >
> > kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >
> > So can you do some debuggin on your side, eg. see the sysfs runtime
> > value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
> From 4b343f0b0b408469f28c973ea52877797a166313 Mon Sep 17 00:00:00 2001
> Message-Id: <4b343f0b0b408469f28c973ea52877797a166313.1489053164.git.osandov@fb.com>
> From: Omar Sandoval <osandov@fb.com>
> Date: Thu, 9 Mar 2017 01:46:19 -0800
> Subject: [PATCH] efi: adjust virt_addr when splitting descriptors in
> efi_memmap_insert()
>
> When we split efi memory descriptors, we adjust the physical address but
> not the virtual address it maps to. This leads to bogus memory mappings
> later when these virtual addresses are used.
>
> This fixes a kexec boot regression since 8e80632fb23f ("efi/esrt: Use
> efi_mem_reserve() and avoid a kmalloc()"), although the bug was only
> exposed by that commit.
>
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
> drivers/firmware/efi/memmap.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> index 78686443cb37..ca614db76faf 100644
> --- a/drivers/firmware/efi/memmap.c
> +++ b/drivers/firmware/efi/memmap.c
> @@ -298,6 +298,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_end + 1;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> }
> @@ -312,6 +313,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> md = new;
> md->attribute |= m_attr;
> md->phys_addr = m_start;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (m_end - m_start + 1) >>
> EFI_PAGE_SHIFT;
> /* last part */
> @@ -319,6 +321,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_end + 1;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - m_end) >>
> EFI_PAGE_SHIFT;
> }
> @@ -333,6 +336,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_start;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> md->attribute |= m_attr;
> --
> 2.12.0
>
Nice, thanks for the debugging, so the problem is clear now.
Just Runtime areas are not necessarily to be reserved, for boot areas no
need to update the virt address. But I'm not sure about the fakemem
usage of this.
So need comments from Matt..
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-10 1:42 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-10 1:42 UTC (permalink / raw)
To: Omar Sandoval
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, Matt Fleming,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-team-b10kYP2dOMg,
Ingo Molnar
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the runtime value is
> > odd to me. It is set in below code:
> >
> > arch/x86/platform/efi/efi.c: efi_systab_init()
> > efi_systab.runtime = data ?
> > (void *)(unsigned long)data->runtime :
> > (void *)(unsigne long)systab64->runtime;
> >
> > Here data is the setup_data passed by kexec-tools from normal kernel to
> > kexec kernel, efi_setup_data structure is like below:
> > struct efi_setup_data {
> > u64 fw_vendor;
> > u64 runtime;
> > u64 tables;
> > u64 smbios;
> > u64 reserved[8];
> > };
> >
> > kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >
> > So can you do some debuggin on your side, eg. see the sysfs runtime
> > value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
> From 4b343f0b0b408469f28c973ea52877797a166313 Mon Sep 17 00:00:00 2001
> Message-Id: <4b343f0b0b408469f28c973ea52877797a166313.1489053164.git.osandov-b10kYP2dOMg@public.gmane.org>
> From: Omar Sandoval <osandov-b10kYP2dOMg@public.gmane.org>
> Date: Thu, 9 Mar 2017 01:46:19 -0800
> Subject: [PATCH] efi: adjust virt_addr when splitting descriptors in
> efi_memmap_insert()
>
> When we split efi memory descriptors, we adjust the physical address but
> not the virtual address it maps to. This leads to bogus memory mappings
> later when these virtual addresses are used.
>
> This fixes a kexec boot regression since 8e80632fb23f ("efi/esrt: Use
> efi_mem_reserve() and avoid a kmalloc()"), although the bug was only
> exposed by that commit.
>
> Signed-off-by: Omar Sandoval <osandov-b10kYP2dOMg@public.gmane.org>
> ---
> drivers/firmware/efi/memmap.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> index 78686443cb37..ca614db76faf 100644
> --- a/drivers/firmware/efi/memmap.c
> +++ b/drivers/firmware/efi/memmap.c
> @@ -298,6 +298,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_end + 1;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> }
> @@ -312,6 +313,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> md = new;
> md->attribute |= m_attr;
> md->phys_addr = m_start;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (m_end - m_start + 1) >>
> EFI_PAGE_SHIFT;
> /* last part */
> @@ -319,6 +321,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_end + 1;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - m_end) >>
> EFI_PAGE_SHIFT;
> }
> @@ -333,6 +336,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_start;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> md->attribute |= m_attr;
> --
> 2.12.0
>
Nice, thanks for the debugging, so the problem is clear now.
Just Runtime areas are not necessarily to be reserved, for boot areas no
need to update the virt address. But I'm not sure about the fakemem
usage of this.
So need comments from Matt..
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-10 1:42 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-10 1:42 UTC (permalink / raw)
To: Omar Sandoval
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, kernel-team, Ingo Molnar
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the runtime value is
> > odd to me. It is set in below code:
> >
> > arch/x86/platform/efi/efi.c: efi_systab_init()
> > efi_systab.runtime = data ?
> > (void *)(unsigned long)data->runtime :
> > (void *)(unsigne long)systab64->runtime;
> >
> > Here data is the setup_data passed by kexec-tools from normal kernel to
> > kexec kernel, efi_setup_data structure is like below:
> > struct efi_setup_data {
> > u64 fw_vendor;
> > u64 runtime;
> > u64 tables;
> > u64 smbios;
> > u64 reserved[8];
> > };
> >
> > kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >
> > So can you do some debuggin on your side, eg. see the sysfs runtime
> > value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
> From 4b343f0b0b408469f28c973ea52877797a166313 Mon Sep 17 00:00:00 2001
> Message-Id: <4b343f0b0b408469f28c973ea52877797a166313.1489053164.git.osandov@fb.com>
> From: Omar Sandoval <osandov@fb.com>
> Date: Thu, 9 Mar 2017 01:46:19 -0800
> Subject: [PATCH] efi: adjust virt_addr when splitting descriptors in
> efi_memmap_insert()
>
> When we split efi memory descriptors, we adjust the physical address but
> not the virtual address it maps to. This leads to bogus memory mappings
> later when these virtual addresses are used.
>
> This fixes a kexec boot regression since 8e80632fb23f ("efi/esrt: Use
> efi_mem_reserve() and avoid a kmalloc()"), although the bug was only
> exposed by that commit.
>
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
> drivers/firmware/efi/memmap.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> index 78686443cb37..ca614db76faf 100644
> --- a/drivers/firmware/efi/memmap.c
> +++ b/drivers/firmware/efi/memmap.c
> @@ -298,6 +298,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_end + 1;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> }
> @@ -312,6 +313,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> md = new;
> md->attribute |= m_attr;
> md->phys_addr = m_start;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (m_end - m_start + 1) >>
> EFI_PAGE_SHIFT;
> /* last part */
> @@ -319,6 +321,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_end + 1;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - m_end) >>
> EFI_PAGE_SHIFT;
> }
> @@ -333,6 +336,7 @@ void __init efi_memmap_insert(struct efi_memory_map *old_memmap, void *buf,
> memcpy(new, old, old_memmap->desc_size);
> md = new;
> md->phys_addr = m_start;
> + md->virt_addr += md->phys_addr - start;
> md->num_pages = (end - md->phys_addr + 1) >>
> EFI_PAGE_SHIFT;
> md->attribute |= m_attr;
> --
> 2.12.0
>
Nice, thanks for the debugging, so the problem is clear now.
Just Runtime areas are not necessarily to be reserved, for boot areas no
need to update the virt address. But I'm not sure about the fakemem
usage of this.
So need comments from Matt..
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-09 9:54 ` Omar Sandoval
(?)
@ 2017-03-13 7:37 ` Dave Young
-1 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-13 7:37 UTC (permalink / raw)
To: Omar Sandoval
Cc: Matt Fleming, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the runtime value is
> > odd to me. It is set in below code:
> >
> > arch/x86/platform/efi/efi.c: efi_systab_init()
> > efi_systab.runtime = data ?
> > (void *)(unsigned long)data->runtime :
> > (void *)(unsigne long)systab64->runtime;
> >
> > Here data is the setup_data passed by kexec-tools from normal kernel to
> > kexec kernel, efi_setup_data structure is like below:
> > struct efi_setup_data {
> > u64 fw_vendor;
> > u64 runtime;
> > u64 tables;
> > u64 smbios;
> > u64 reserved[8];
> > };
> >
> > kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >
> > So can you do some debuggin on your side, eg. see the sysfs runtime
> > value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
correct to be used in efi_arch_mem_reserve, if it passed your test, I
can rewrite patch log with more background and send it out:
for_each_efi_memory_desc(md) {
[snip]
if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
md->type != EFI_BOOT_SERVICES_DATA &&
md->type != EFI_RUNTIME_SERVICES_DATA) {
continue;
}
In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
data or runtime data, this is wrong for efi_mem_reserve, because we are
reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
running time. Just is happened to work and we did not capture the error.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/quirks.c | 4 +++-
drivers/firmware/efi/efi.c | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/efi.h | 1 +
3 files changed, 43 insertions(+), 1 deletion(-)
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -191,7 +191,9 @@ void __init efi_arch_mem_reserve(phys_ad
int num_entries;
void *new;
- if (efi_mem_desc_lookup(addr, &md)) {
+ if (efi_md_lookup_boot_data(addr, &md)) {
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
pr_err("Failed to lookup EFI memory descriptor for %pa\n", &addr);
return;
}
--- linux-x86.orig/drivers/firmware/efi/efi.c
+++ linux-x86/drivers/firmware/efi/efi.c
@@ -353,6 +353,45 @@ err_put:
subsys_initcall(efisubsys_init);
/*
+ * Find the efi memory descriptor for a given physical address.
+ * Given a physical address, if it exists within an EFI memory map
+ * entry of type EFI_BOOT_SERVICES_DATA and the entry has no attribute
+ * EFI_MEMORY_RUNTIME, then populate the supplied memory descriptor
+ * with the appropriate data.
+ */
+int __init efi_md_lookup_boot_data(u64 phys_addr,
+ efi_memory_desc_t *out_md)
+{
+ efi_memory_desc_t *md;
+
+ if (!efi_enabled(EFI_MEMMAP)) {
+ pr_err_once("EFI_MEMMAP is not enabled.\n");
+ return -EINVAL;
+ }
+
+ if (!out_md) {
+ pr_err_once("out_md is null.\n");
+ return -EINVAL;
+ }
+
+ for_each_efi_memory_desc(md) {
+ u64 size;
+ u64 end;
+
+ if (md->type != EFI_BOOT_SERVICES_DATA)
+ continue;
+
+ size = md->num_pages << EFI_PAGE_SHIFT;
+ end = md->phys_addr + size;
+ if (phys_addr >= md->phys_addr && phys_addr < end) {
+ memcpy(out_md, md, sizeof(*out_md));
+ return 0;
+ }
+ }
+ return -ENOENT;
+}
+
+/*
* Find the efi memory descriptor for a given physical address. Given a
* physical address, determine if it exists within an EFI Memory Map entry,
* and if so, populate the supplied memory descriptor with the appropriate
--- linux-x86.orig/include/linux/efi.h
+++ linux-x86/include/linux/efi.h
@@ -979,6 +979,7 @@ extern u64 efi_mem_attribute (unsigned l
extern int __init efi_uart_console_only (void);
extern u64 efi_mem_desc_end(efi_memory_desc_t *md);
extern int efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md);
+extern int efi_md_lookup_boot_data(u64 phys_addr, efi_memory_desc_t *out_md);
extern void efi_mem_reserve(phys_addr_t addr, u64 size);
extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource, struct resource *bss_resource);
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-13 7:37 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-13 7:37 UTC (permalink / raw)
To: Omar Sandoval
Cc: Matt Fleming, Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-team-b10kYP2dOMg, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-efi-u79uwXL29TY76Z2rM5mHXA
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the runtime value is
> > odd to me. It is set in below code:
> >
> > arch/x86/platform/efi/efi.c: efi_systab_init()
> > efi_systab.runtime = data ?
> > (void *)(unsigned long)data->runtime :
> > (void *)(unsigne long)systab64->runtime;
> >
> > Here data is the setup_data passed by kexec-tools from normal kernel to
> > kexec kernel, efi_setup_data structure is like below:
> > struct efi_setup_data {
> > u64 fw_vendor;
> > u64 runtime;
> > u64 tables;
> > u64 smbios;
> > u64 reserved[8];
> > };
> >
> > kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >
> > So can you do some debuggin on your side, eg. see the sysfs runtime
> > value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
correct to be used in efi_arch_mem_reserve, if it passed your test, I
can rewrite patch log with more background and send it out:
for_each_efi_memory_desc(md) {
[snip]
if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
md->type != EFI_BOOT_SERVICES_DATA &&
md->type != EFI_RUNTIME_SERVICES_DATA) {
continue;
}
In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
data or runtime data, this is wrong for efi_mem_reserve, because we are
reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
running time. Just is happened to work and we did not capture the error.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/x86/platform/efi/quirks.c | 4 +++-
drivers/firmware/efi/efi.c | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/efi.h | 1 +
3 files changed, 43 insertions(+), 1 deletion(-)
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -191,7 +191,9 @@ void __init efi_arch_mem_reserve(phys_ad
int num_entries;
void *new;
- if (efi_mem_desc_lookup(addr, &md)) {
+ if (efi_md_lookup_boot_data(addr, &md)) {
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
pr_err("Failed to lookup EFI memory descriptor for %pa\n", &addr);
return;
}
--- linux-x86.orig/drivers/firmware/efi/efi.c
+++ linux-x86/drivers/firmware/efi/efi.c
@@ -353,6 +353,45 @@ err_put:
subsys_initcall(efisubsys_init);
/*
+ * Find the efi memory descriptor for a given physical address.
+ * Given a physical address, if it exists within an EFI memory map
+ * entry of type EFI_BOOT_SERVICES_DATA and the entry has no attribute
+ * EFI_MEMORY_RUNTIME, then populate the supplied memory descriptor
+ * with the appropriate data.
+ */
+int __init efi_md_lookup_boot_data(u64 phys_addr,
+ efi_memory_desc_t *out_md)
+{
+ efi_memory_desc_t *md;
+
+ if (!efi_enabled(EFI_MEMMAP)) {
+ pr_err_once("EFI_MEMMAP is not enabled.\n");
+ return -EINVAL;
+ }
+
+ if (!out_md) {
+ pr_err_once("out_md is null.\n");
+ return -EINVAL;
+ }
+
+ for_each_efi_memory_desc(md) {
+ u64 size;
+ u64 end;
+
+ if (md->type != EFI_BOOT_SERVICES_DATA)
+ continue;
+
+ size = md->num_pages << EFI_PAGE_SHIFT;
+ end = md->phys_addr + size;
+ if (phys_addr >= md->phys_addr && phys_addr < end) {
+ memcpy(out_md, md, sizeof(*out_md));
+ return 0;
+ }
+ }
+ return -ENOENT;
+}
+
+/*
* Find the efi memory descriptor for a given physical address. Given a
* physical address, determine if it exists within an EFI Memory Map entry,
* and if so, populate the supplied memory descriptor with the appropriate
--- linux-x86.orig/include/linux/efi.h
+++ linux-x86/include/linux/efi.h
@@ -979,6 +979,7 @@ extern u64 efi_mem_attribute (unsigned l
extern int __init efi_uart_console_only (void);
extern u64 efi_mem_desc_end(efi_memory_desc_t *md);
extern int efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md);
+extern int efi_md_lookup_boot_data(u64 phys_addr, efi_memory_desc_t *out_md);
extern void efi_mem_reserve(phys_addr_t addr, u64 size);
extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource, struct resource *bss_resource);
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-13 7:37 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-13 7:37 UTC (permalink / raw)
To: Omar Sandoval
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, kernel-team, Ingo Molnar
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the runtime value is
> > odd to me. It is set in below code:
> >
> > arch/x86/platform/efi/efi.c: efi_systab_init()
> > efi_systab.runtime = data ?
> > (void *)(unsigned long)data->runtime :
> > (void *)(unsigne long)systab64->runtime;
> >
> > Here data is the setup_data passed by kexec-tools from normal kernel to
> > kexec kernel, efi_setup_data structure is like below:
> > struct efi_setup_data {
> > u64 fw_vendor;
> > u64 runtime;
> > u64 tables;
> > u64 smbios;
> > u64 reserved[8];
> > };
> >
> > kexec-tools get the runtime address from /sys/firmware/efi/runtime
> >
> > So can you do some debuggin on your side, eg. see the sysfs runtime
> > value is correct or not. And add some printk in efi init path etc.
>
> The attached patch fixes this for me.
Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
correct to be used in efi_arch_mem_reserve, if it passed your test, I
can rewrite patch log with more background and send it out:
for_each_efi_memory_desc(md) {
[snip]
if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
md->type != EFI_BOOT_SERVICES_DATA &&
md->type != EFI_RUNTIME_SERVICES_DATA) {
continue;
}
In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
data or runtime data, this is wrong for efi_mem_reserve, because we are
reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
running time. Just is happened to work and we did not capture the error.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/quirks.c | 4 +++-
drivers/firmware/efi/efi.c | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/efi.h | 1 +
3 files changed, 43 insertions(+), 1 deletion(-)
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -191,7 +191,9 @@ void __init efi_arch_mem_reserve(phys_ad
int num_entries;
void *new;
- if (efi_mem_desc_lookup(addr, &md)) {
+ if (efi_md_lookup_boot_data(addr, &md)) {
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
pr_err("Failed to lookup EFI memory descriptor for %pa\n", &addr);
return;
}
--- linux-x86.orig/drivers/firmware/efi/efi.c
+++ linux-x86/drivers/firmware/efi/efi.c
@@ -353,6 +353,45 @@ err_put:
subsys_initcall(efisubsys_init);
/*
+ * Find the efi memory descriptor for a given physical address.
+ * Given a physical address, if it exists within an EFI memory map
+ * entry of type EFI_BOOT_SERVICES_DATA and the entry has no attribute
+ * EFI_MEMORY_RUNTIME, then populate the supplied memory descriptor
+ * with the appropriate data.
+ */
+int __init efi_md_lookup_boot_data(u64 phys_addr,
+ efi_memory_desc_t *out_md)
+{
+ efi_memory_desc_t *md;
+
+ if (!efi_enabled(EFI_MEMMAP)) {
+ pr_err_once("EFI_MEMMAP is not enabled.\n");
+ return -EINVAL;
+ }
+
+ if (!out_md) {
+ pr_err_once("out_md is null.\n");
+ return -EINVAL;
+ }
+
+ for_each_efi_memory_desc(md) {
+ u64 size;
+ u64 end;
+
+ if (md->type != EFI_BOOT_SERVICES_DATA)
+ continue;
+
+ size = md->num_pages << EFI_PAGE_SHIFT;
+ end = md->phys_addr + size;
+ if (phys_addr >= md->phys_addr && phys_addr < end) {
+ memcpy(out_md, md, sizeof(*out_md));
+ return 0;
+ }
+ }
+ return -ENOENT;
+}
+
+/*
* Find the efi memory descriptor for a given physical address. Given a
* physical address, determine if it exists within an EFI Memory Map entry,
* and if so, populate the supplied memory descriptor with the appropriate
--- linux-x86.orig/include/linux/efi.h
+++ linux-x86/include/linux/efi.h
@@ -979,6 +979,7 @@ extern u64 efi_mem_attribute (unsigned l
extern int __init efi_uart_console_only (void);
extern u64 efi_mem_desc_end(efi_memory_desc_t *md);
extern int efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md);
+extern int efi_md_lookup_boot_data(u64 phys_addr, efi_memory_desc_t *out_md);
extern void efi_mem_reserve(phys_addr_t addr, u64 size);
extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource, struct resource *bss_resource);
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-09 11:53 ` Ard Biesheuvel
@ 2017-03-16 12:15 ` Matt Fleming
-1 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-16 12:15 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Omar Sandoval, Dave Young, Ingo Molnar, linux-kernel,
kernel-team, kexec, linux-efi
On Thu, 09 Mar, at 12:53:36PM, Ard Biesheuvel wrote:
>
> Hi Omar,
>
> Thanks for tracking this down.
>
> I wonder if this is an unintended side effect of the way we repurpose
> the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
> splitting memory map entries should only be necessary for regions that
> are not runtime memory regions to begin with, and so whether their
> virtual mapping address makes sense or not should be irrelevant.
>
> Perhaps this only illustrates my lack of understanding of the x86 way
> of doing this, so perhaps Matt can shed some light on this?
Sorry for the delay.
Yes, Ard is correct. It's not necessary to split/reserve memory
regions that already have the EFI_MEMORY_RUNTIME attribute.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-16 12:15 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-16 12:15 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval,
Dave Young, kernel-team
On Thu, 09 Mar, at 12:53:36PM, Ard Biesheuvel wrote:
>
> Hi Omar,
>
> Thanks for tracking this down.
>
> I wonder if this is an unintended side effect of the way we repurpose
> the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
> splitting memory map entries should only be necessary for regions that
> are not runtime memory regions to begin with, and so whether their
> virtual mapping address makes sense or not should be irrelevant.
>
> Perhaps this only illustrates my lack of understanding of the x86 way
> of doing this, so perhaps Matt can shed some light on this?
Sorry for the delay.
Yes, Ard is correct. It's not necessary to split/reserve memory
regions that already have the EFI_MEMORY_RUNTIME attribute.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-16 12:41 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-16 12:41 UTC (permalink / raw)
To: Dave Young
Cc: Omar Sandoval, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
>
> Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> correct to be used in efi_arch_mem_reserve, if it passed your test, I
> can rewrite patch log with more background and send it out:
>
> for_each_efi_memory_desc(md) {
> [snip]
> if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> md->type != EFI_BOOT_SERVICES_DATA &&
> md->type != EFI_RUNTIME_SERVICES_DATA) {
> continue;
> }
>
> In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> data or runtime data, this is wrong for efi_mem_reserve, because we are
> reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> running time. Just is happened to work and we did not capture the error.
Wouldn't something like this be simpler?
---
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 30031d5293c4..cdfe8c628959 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
return;
}
+ /* No need to reserve regions that will never be freed. */
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-16 12:41 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-16 12:41 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Omar Sandoval,
kernel-team-b10kYP2dOMg
On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
>
> Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> correct to be used in efi_arch_mem_reserve, if it passed your test, I
> can rewrite patch log with more background and send it out:
>
> for_each_efi_memory_desc(md) {
> [snip]
> if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> md->type != EFI_BOOT_SERVICES_DATA &&
> md->type != EFI_RUNTIME_SERVICES_DATA) {
> continue;
> }
>
> In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> data or runtime data, this is wrong for efi_mem_reserve, because we are
> reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> running time. Just is happened to work and we did not capture the error.
Wouldn't something like this be simpler?
---
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 30031d5293c4..cdfe8c628959 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
return;
}
+ /* No need to reserve regions that will never be freed. */
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-16 12:41 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-16 12:41 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval, kernel-team
On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
>
> Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> correct to be used in efi_arch_mem_reserve, if it passed your test, I
> can rewrite patch log with more background and send it out:
>
> for_each_efi_memory_desc(md) {
> [snip]
> if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> md->type != EFI_BOOT_SERVICES_DATA &&
> md->type != EFI_RUNTIME_SERVICES_DATA) {
> continue;
> }
>
> In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> data or runtime data, this is wrong for efi_mem_reserve, because we are
> reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> running time. Just is happened to work and we did not capture the error.
Wouldn't something like this be simpler?
---
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 30031d5293c4..cdfe8c628959 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
return;
}
+ /* No need to reserve regions that will never be freed. */
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-03-16 12:41 ` Matt Fleming
@ 2017-03-16 17:50 ` Omar Sandoval
-1 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-03-16 17:50 UTC (permalink / raw)
To: Matt Fleming
Cc: Dave Young, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On Thu, Mar 16, 2017 at 12:41:32PM +0000, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > can rewrite patch log with more background and send it out:
> >
> > for_each_efi_memory_desc(md) {
> > [snip]
> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > md->type != EFI_BOOT_SERVICES_DATA &&
> > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > continue;
> > }
> >
> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > running time. Just is happened to work and we did not capture the error.
>
> Wouldn't something like this be simpler?
>
> ---
>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 30031d5293c4..cdfe8c628959 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
> size += addr % EFI_PAGE_SIZE;
> size = round_up(size, EFI_PAGE_SIZE);
> addr = round_down(addr, EFI_PAGE_SIZE);
This works for me.
Reported-and-tested-by: Omar Sandoval <osandov@fb.com>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-16 17:50 ` Omar Sandoval
0 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-03-16 17:50 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi, kexec, linux-kernel, kernel-team, Dave Young, Ingo Molnar
On Thu, Mar 16, 2017 at 12:41:32PM +0000, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > can rewrite patch log with more background and send it out:
> >
> > for_each_efi_memory_desc(md) {
> > [snip]
> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > md->type != EFI_BOOT_SERVICES_DATA &&
> > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > continue;
> > }
> >
> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > running time. Just is happened to work and we did not capture the error.
>
> Wouldn't something like this be simpler?
>
> ---
>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 30031d5293c4..cdfe8c628959 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
> size += addr % EFI_PAGE_SIZE;
> size = round_up(size, EFI_PAGE_SIZE);
> addr = round_down(addr, EFI_PAGE_SIZE);
This works for me.
Reported-and-tested-by: Omar Sandoval <osandov@fb.com>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 2:09 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-17 2:09 UTC (permalink / raw)
To: Matt Fleming
Cc: Omar Sandoval, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On 03/16/17 at 12:41pm, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > can rewrite patch log with more background and send it out:
> >
> > for_each_efi_memory_desc(md) {
> > [snip]
> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > md->type != EFI_BOOT_SERVICES_DATA &&
> > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > continue;
> > }
> >
> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > running time. Just is happened to work and we did not capture the error.
>
> Wouldn't something like this be simpler?
>
> ---
>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 30031d5293c4..cdfe8c628959 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
Matt, I think it should be fine although I think the md type checking in
efi_mem_desc_lookup() is causing confusion and not easy to understand..
How about move the if chunk early like below because it seems no need
to sanity check the addr + size any more if the md is still RUNTIME?
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -196,6 +196,10 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
+ /* No need to reserve regions that will never be freed. */
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
+
if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
return;
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 2:09 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-17 2:09 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Omar Sandoval,
kernel-team-b10kYP2dOMg
On 03/16/17 at 12:41pm, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > can rewrite patch log with more background and send it out:
> >
> > for_each_efi_memory_desc(md) {
> > [snip]
> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > md->type != EFI_BOOT_SERVICES_DATA &&
> > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > continue;
> > }
> >
> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > running time. Just is happened to work and we did not capture the error.
>
> Wouldn't something like this be simpler?
>
> ---
>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 30031d5293c4..cdfe8c628959 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
Matt, I think it should be fine although I think the md type checking in
efi_mem_desc_lookup() is causing confusion and not easy to understand..
How about move the if chunk early like below because it seems no need
to sanity check the addr + size any more if the md is still RUNTIME?
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -196,6 +196,10 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
+ /* No need to reserve regions that will never be freed. */
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
+
if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
return;
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 2:09 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-17 2:09 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval, kernel-team
On 03/16/17 at 12:41pm, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > can rewrite patch log with more background and send it out:
> >
> > for_each_efi_memory_desc(md) {
> > [snip]
> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > md->type != EFI_BOOT_SERVICES_DATA &&
> > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > continue;
> > }
> >
> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > running time. Just is happened to work and we did not capture the error.
>
> Wouldn't something like this be simpler?
>
> ---
>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 30031d5293c4..cdfe8c628959 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
Matt, I think it should be fine although I think the md type checking in
efi_mem_desc_lookup() is causing confusion and not easy to understand..
How about move the if chunk early like below because it seems no need
to sanity check the addr + size any more if the md is still RUNTIME?
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -196,6 +196,10 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
+ /* No need to reserve regions that will never be freed. */
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
+
if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
return;
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 13:25 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-17 13:25 UTC (permalink / raw)
To: Dave Young
Cc: Matt Fleming, Omar Sandoval, Ingo Molnar, linux-kernel,
kernel-team, kexec, linux-efi
On 17 March 2017 at 02:09, Dave Young <dyoung@redhat.com> wrote:
> On 03/16/17 at 12:41pm, Matt Fleming wrote:
>> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
>> >
>> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
>> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
>> > can rewrite patch log with more background and send it out:
>> >
>> > for_each_efi_memory_desc(md) {
>> > [snip]
>> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
>> > md->type != EFI_BOOT_SERVICES_DATA &&
>> > md->type != EFI_RUNTIME_SERVICES_DATA) {
>> > continue;
>> > }
>> >
>> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
>> > data or runtime data, this is wrong for efi_mem_reserve, because we are
>> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
>> > running time. Just is happened to work and we did not capture the error.
>>
>> Wouldn't something like this be simpler?
>>
>> ---
>>
>> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
>> index 30031d5293c4..cdfe8c628959 100644
>> --- a/arch/x86/platform/efi/quirks.c
>> +++ b/arch/x86/platform/efi/quirks.c
>> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
>> return;
>> }
>>
>> + /* No need to reserve regions that will never be freed. */
>> + if (md.attribute & EFI_MEMORY_RUNTIME)
>> + return;
>> +
>
> Matt, I think it should be fine although I think the md type checking in
> efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> How about move the if chunk early like below because it seems no need
> to sanity check the addr + size any more if the md is still RUNTIME?
>
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -196,6 +196,10 @@ void __init efi_arch_mem_reserve(phys_ad
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
> if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
> pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
> return;
>
This way, we suppress the error it the region spans multiple
descriptors, and only the first one has the runtime attribute. So the
two patches are not equivalent. I don't have a strong preference
either way, though.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 13:25 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-17 13:25 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, Matt Fleming,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Omar Sandoval,
kernel-team-b10kYP2dOMg
On 17 March 2017 at 02:09, Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 03/16/17 at 12:41pm, Matt Fleming wrote:
>> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
>> >
>> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
>> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
>> > can rewrite patch log with more background and send it out:
>> >
>> > for_each_efi_memory_desc(md) {
>> > [snip]
>> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
>> > md->type != EFI_BOOT_SERVICES_DATA &&
>> > md->type != EFI_RUNTIME_SERVICES_DATA) {
>> > continue;
>> > }
>> >
>> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
>> > data or runtime data, this is wrong for efi_mem_reserve, because we are
>> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
>> > running time. Just is happened to work and we did not capture the error.
>>
>> Wouldn't something like this be simpler?
>>
>> ---
>>
>> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
>> index 30031d5293c4..cdfe8c628959 100644
>> --- a/arch/x86/platform/efi/quirks.c
>> +++ b/arch/x86/platform/efi/quirks.c
>> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
>> return;
>> }
>>
>> + /* No need to reserve regions that will never be freed. */
>> + if (md.attribute & EFI_MEMORY_RUNTIME)
>> + return;
>> +
>
> Matt, I think it should be fine although I think the md type checking in
> efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> How about move the if chunk early like below because it seems no need
> to sanity check the addr + size any more if the md is still RUNTIME?
>
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -196,6 +196,10 @@ void __init efi_arch_mem_reserve(phys_ad
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
> if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
> pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
> return;
>
This way, we suppress the error it the region spans multiple
descriptors, and only the first one has the runtime attribute. So the
two patches are not equivalent. I don't have a strong preference
either way, though.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 13:25 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-17 13:25 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, Ingo Molnar,
Omar Sandoval, kernel-team
On 17 March 2017 at 02:09, Dave Young <dyoung@redhat.com> wrote:
> On 03/16/17 at 12:41pm, Matt Fleming wrote:
>> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
>> >
>> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
>> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
>> > can rewrite patch log with more background and send it out:
>> >
>> > for_each_efi_memory_desc(md) {
>> > [snip]
>> > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
>> > md->type != EFI_BOOT_SERVICES_DATA &&
>> > md->type != EFI_RUNTIME_SERVICES_DATA) {
>> > continue;
>> > }
>> >
>> > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
>> > data or runtime data, this is wrong for efi_mem_reserve, because we are
>> > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
>> > running time. Just is happened to work and we did not capture the error.
>>
>> Wouldn't something like this be simpler?
>>
>> ---
>>
>> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
>> index 30031d5293c4..cdfe8c628959 100644
>> --- a/arch/x86/platform/efi/quirks.c
>> +++ b/arch/x86/platform/efi/quirks.c
>> @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
>> return;
>> }
>>
>> + /* No need to reserve regions that will never be freed. */
>> + if (md.attribute & EFI_MEMORY_RUNTIME)
>> + return;
>> +
>
> Matt, I think it should be fine although I think the md type checking in
> efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> How about move the if chunk early like below because it seems no need
> to sanity check the addr + size any more if the md is still RUNTIME?
>
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -196,6 +196,10 @@ void __init efi_arch_mem_reserve(phys_ad
> return;
> }
>
> + /* No need to reserve regions that will never be freed. */
> + if (md.attribute & EFI_MEMORY_RUNTIME)
> + return;
> +
> if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
> pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
> return;
>
This way, we suppress the error it the region spans multiple
descriptors, and only the first one has the runtime attribute. So the
two patches are not equivalent. I don't have a strong preference
either way, though.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 13:32 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-17 13:32 UTC (permalink / raw)
To: Dave Young
Cc: Omar Sandoval, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
>
> Matt, I think it should be fine although I think the md type checking in
> efi_mem_desc_lookup() is causing confusion and not easy to understand..
Could you make that a separate patch if you think of improvements
there?
> How about move the if chunk early like below because it seems no need
> to sanity check the addr + size any more if the md is still RUNTIME?
My original version did as you suggest, but I changed it because we
*really* want to know if someone tries to reserve a range that spans
regions. That would be totally unexpected and a warning about a
potential bug/issue.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 13:32 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-17 13:32 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Omar Sandoval,
kernel-team-b10kYP2dOMg
On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
>
> Matt, I think it should be fine although I think the md type checking in
> efi_mem_desc_lookup() is causing confusion and not easy to understand..
Could you make that a separate patch if you think of improvements
there?
> How about move the if chunk early like below because it seems no need
> to sanity check the addr + size any more if the md is still RUNTIME?
My original version did as you suggest, but I changed it because we
*really* want to know if someone tries to reserve a range that spans
regions. That would be totally unexpected and a warning about a
potential bug/issue.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-17 13:32 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-03-17 13:32 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval, kernel-team
On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
>
> Matt, I think it should be fine although I think the md type checking in
> efi_mem_desc_lookup() is causing confusion and not easy to understand..
Could you make that a separate patch if you think of improvements
there?
> How about move the if chunk early like below because it seems no need
> to sanity check the addr + size any more if the md is still RUNTIME?
My original version did as you suggest, but I changed it because we
*really* want to know if someone tries to reserve a range that spans
regions. That would be totally unexpected and a warning about a
potential bug/issue.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-20 2:14 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-20 2:14 UTC (permalink / raw)
To: Matt Fleming
Cc: Omar Sandoval, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On 03/17/17 at 01:32pm, Matt Fleming wrote:
> On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >
> > Matt, I think it should be fine although I think the md type checking in
> > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> Could you make that a separate patch if you think of improvements
> there?
Duplicate the lookup function is indeed a little ugly, will do it when I
have a better idea, we can leave it as is since it works.
>
> > How about move the if chunk early like below because it seems no need
> > to sanity check the addr + size any more if the md is still RUNTIME?
>
> My original version did as you suggest, but I changed it because we
> *really* want to know if someone tries to reserve a range that spans
> regions. That would be totally unexpected and a warning about a
> potential bug/issue.
Matt, I'm fine if you prefer to capture the range checking errors.
Would you like me to post it or just you send it out?
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-20 2:14 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-20 2:14 UTC (permalink / raw)
To: Matt Fleming
Cc: Omar Sandoval, Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-team-b10kYP2dOMg, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-efi-u79uwXL29TY76Z2rM5mHXA
On 03/17/17 at 01:32pm, Matt Fleming wrote:
> On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >
> > Matt, I think it should be fine although I think the md type checking in
> > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> Could you make that a separate patch if you think of improvements
> there?
Duplicate the lookup function is indeed a little ugly, will do it when I
have a better idea, we can leave it as is since it works.
>
> > How about move the if chunk early like below because it seems no need
> > to sanity check the addr + size any more if the md is still RUNTIME?
>
> My original version did as you suggest, but I changed it because we
> *really* want to know if someone tries to reserve a range that spans
> regions. That would be totally unexpected and a warning about a
> potential bug/issue.
Matt, I'm fine if you prefer to capture the range checking errors.
Would you like me to post it or just you send it out?
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-20 2:14 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-20 2:14 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval, kernel-team
On 03/17/17 at 01:32pm, Matt Fleming wrote:
> On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >
> > Matt, I think it should be fine although I think the md type checking in
> > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> Could you make that a separate patch if you think of improvements
> there?
Duplicate the lookup function is indeed a little ugly, will do it when I
have a better idea, we can leave it as is since it works.
>
> > How about move the if chunk early like below because it seems no need
> > to sanity check the addr + size any more if the md is still RUNTIME?
>
> My original version did as you suggest, but I changed it because we
> *really* want to know if someone tries to reserve a range that spans
> regions. That would be totally unexpected and a warning about a
> potential bug/issue.
Matt, I'm fine if you prefer to capture the range checking errors.
Would you like me to post it or just you send it out?
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-21 7:48 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-21 7:48 UTC (permalink / raw)
To: Matt Fleming
Cc: Omar Sandoval, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On 03/20/17 at 10:14am, Dave Young wrote:
> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> > >
> > > Matt, I think it should be fine although I think the md type checking in
> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >
> > Could you make that a separate patch if you think of improvements
> > there?
>
> Duplicate the lookup function is indeed a little ugly, will do it when I
> have a better idea, we can leave it as is since it works.
Matt, rethinking about this, how about doint something below, not
tested, just seeking for idea and opinons, in this way no need duplicate
a function, but there is an assumption that no overlapped mem ranges in
efi memmap.
Also the case Omar reported is the esrt memory range type is
RUNTIME_DATA, that is a little different with the mem attribute of
RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
attribute, like bgrt in kexec reboot. Should we distinguish the two
cases and give out some warnings or debug info?
---
arch/x86/platform/efi/quirks.c | 5 +++++
drivers/firmware/efi/efi.c | 6 ------
drivers/firmware/efi/esrt.c | 7 +++++++
3 files changed, 12 insertions(+), 6 deletions(-)
--- linux-x86.orig/drivers/firmware/efi/efi.c
+++ linux-x86/drivers/firmware/efi/efi.c
@@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
u64 size;
u64 end;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_DATA &&
- md->type != EFI_RUNTIME_SERVICES_DATA) {
- continue;
- }
-
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
if (phys_addr >= md->phys_addr && phys_addr < end) {
--- linux-x86.orig/drivers/firmware/efi/esrt.c
+++ linux-x86/drivers/firmware/efi/esrt.c
@@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
return;
}
+ if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
+ md->type != EFI_BOOT_SERVICES_DATA &&
+ md->type != EFI_RUNTIME_SERVICES_DATA) {
+ pr_err("ESRT header memory map type is invalid\n");
+ return;
+ }
+
max = efi_mem_desc_end(&md);
if (max < efi.esrt) {
pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
+ if (md->attribute & EFI_MEMORY_RUNTIME ||
+ md->type != EFI_BOOT_SERVICES_DATA) {
+ return;
+ }
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);
>
> >
> > > How about move the if chunk early like below because it seems no need
> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >
> > My original version did as you suggest, but I changed it because we
> > *really* want to know if someone tries to reserve a range that spans
> > regions. That would be totally unexpected and a warning about a
> > potential bug/issue.
>
> Matt, I'm fine if you prefer to capture the range checking errors.
> Would you like me to post it or just you send it out?
>
> Thanks
> Dave
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-21 7:48 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-21 7:48 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Omar Sandoval,
kernel-team-b10kYP2dOMg
On 03/20/17 at 10:14am, Dave Young wrote:
> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> > >
> > > Matt, I think it should be fine although I think the md type checking in
> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >
> > Could you make that a separate patch if you think of improvements
> > there?
>
> Duplicate the lookup function is indeed a little ugly, will do it when I
> have a better idea, we can leave it as is since it works.
Matt, rethinking about this, how about doint something below, not
tested, just seeking for idea and opinons, in this way no need duplicate
a function, but there is an assumption that no overlapped mem ranges in
efi memmap.
Also the case Omar reported is the esrt memory range type is
RUNTIME_DATA, that is a little different with the mem attribute of
RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
attribute, like bgrt in kexec reboot. Should we distinguish the two
cases and give out some warnings or debug info?
---
arch/x86/platform/efi/quirks.c | 5 +++++
drivers/firmware/efi/efi.c | 6 ------
drivers/firmware/efi/esrt.c | 7 +++++++
3 files changed, 12 insertions(+), 6 deletions(-)
--- linux-x86.orig/drivers/firmware/efi/efi.c
+++ linux-x86/drivers/firmware/efi/efi.c
@@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
u64 size;
u64 end;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_DATA &&
- md->type != EFI_RUNTIME_SERVICES_DATA) {
- continue;
- }
-
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
if (phys_addr >= md->phys_addr && phys_addr < end) {
--- linux-x86.orig/drivers/firmware/efi/esrt.c
+++ linux-x86/drivers/firmware/efi/esrt.c
@@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
return;
}
+ if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
+ md->type != EFI_BOOT_SERVICES_DATA &&
+ md->type != EFI_RUNTIME_SERVICES_DATA) {
+ pr_err("ESRT header memory map type is invalid\n");
+ return;
+ }
+
max = efi_mem_desc_end(&md);
if (max < efi.esrt) {
pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
+ if (md->attribute & EFI_MEMORY_RUNTIME ||
+ md->type != EFI_BOOT_SERVICES_DATA) {
+ return;
+ }
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);
>
> >
> > > How about move the if chunk early like below because it seems no need
> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >
> > My original version did as you suggest, but I changed it because we
> > *really* want to know if someone tries to reserve a range that spans
> > regions. That would be totally unexpected and a warning about a
> > potential bug/issue.
>
> Matt, I'm fine if you prefer to capture the range checking errors.
> Would you like me to post it or just you send it out?
>
> Thanks
> Dave
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-21 7:48 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-21 7:48 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval, kernel-team
On 03/20/17 at 10:14am, Dave Young wrote:
> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> > >
> > > Matt, I think it should be fine although I think the md type checking in
> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >
> > Could you make that a separate patch if you think of improvements
> > there?
>
> Duplicate the lookup function is indeed a little ugly, will do it when I
> have a better idea, we can leave it as is since it works.
Matt, rethinking about this, how about doint something below, not
tested, just seeking for idea and opinons, in this way no need duplicate
a function, but there is an assumption that no overlapped mem ranges in
efi memmap.
Also the case Omar reported is the esrt memory range type is
RUNTIME_DATA, that is a little different with the mem attribute of
RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
attribute, like bgrt in kexec reboot. Should we distinguish the two
cases and give out some warnings or debug info?
---
arch/x86/platform/efi/quirks.c | 5 +++++
drivers/firmware/efi/efi.c | 6 ------
drivers/firmware/efi/esrt.c | 7 +++++++
3 files changed, 12 insertions(+), 6 deletions(-)
--- linux-x86.orig/drivers/firmware/efi/efi.c
+++ linux-x86/drivers/firmware/efi/efi.c
@@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
u64 size;
u64 end;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_DATA &&
- md->type != EFI_RUNTIME_SERVICES_DATA) {
- continue;
- }
-
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
if (phys_addr >= md->phys_addr && phys_addr < end) {
--- linux-x86.orig/drivers/firmware/efi/esrt.c
+++ linux-x86/drivers/firmware/efi/esrt.c
@@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
return;
}
+ if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
+ md->type != EFI_BOOT_SERVICES_DATA &&
+ md->type != EFI_RUNTIME_SERVICES_DATA) {
+ pr_err("ESRT header memory map type is invalid\n");
+ return;
+ }
+
max = efi_mem_desc_end(&md);
if (max < efi.esrt) {
pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
+ if (md->attribute & EFI_MEMORY_RUNTIME ||
+ md->type != EFI_BOOT_SERVICES_DATA) {
+ return;
+ }
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);
>
> >
> > > How about move the if chunk early like below because it seems no need
> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >
> > My original version did as you suggest, but I changed it because we
> > *really* want to know if someone tries to reserve a range that spans
> > regions. That would be totally unexpected and a warning about a
> > potential bug/issue.
>
> Matt, I'm fine if you prefer to capture the range checking errors.
> Would you like me to post it or just you send it out?
>
> Thanks
> Dave
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-22 16:10 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 16:10 UTC (permalink / raw)
To: Dave Young
Cc: Matt Fleming, Omar Sandoval, Ingo Molnar, linux-kernel,
kernel-team, kexec, linux-efi
On 21 March 2017 at 07:48, Dave Young <dyoung@redhat.com> wrote:
> On 03/20/17 at 10:14am, Dave Young wrote:
>> On 03/17/17 at 01:32pm, Matt Fleming wrote:
>> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
>> > >
>> > > Matt, I think it should be fine although I think the md type checking in
>> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>> >
>> > Could you make that a separate patch if you think of improvements
>> > there?
>>
>> Duplicate the lookup function is indeed a little ugly, will do it when I
>> have a better idea, we can leave it as is since it works.
>
> Matt, rethinking about this, how about doint something below, not
> tested, just seeking for idea and opinons, in this way no need duplicate
> a function, but there is an assumption that no overlapped mem ranges in
> efi memmap.
>
> Also the case Omar reported is the esrt memory range type is
> RUNTIME_DATA, that is a little different with the mem attribute of
> RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> attribute, like bgrt in kexec reboot. Should we distinguish the two
> cases and give out some warnings or debug info?
>
>
> ---
> arch/x86/platform/efi/quirks.c | 5 +++++
> drivers/firmware/efi/efi.c | 6 ------
> drivers/firmware/efi/esrt.c | 7 +++++++
> 3 files changed, 12 insertions(+), 6 deletions(-)
>
> --- linux-x86.orig/drivers/firmware/efi/efi.c
> +++ linux-x86/drivers/firmware/efi/efi.c
> @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> u64 size;
> u64 end;
>
> - if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> - md->type != EFI_BOOT_SERVICES_DATA &&
> - md->type != EFI_RUNTIME_SERVICES_DATA) {
> - continue;
> - }
> -
> size = md->num_pages << EFI_PAGE_SHIFT;
> end = md->phys_addr + size;
> if (phys_addr >= md->phys_addr && phys_addr < end) {
> --- linux-x86.orig/drivers/firmware/efi/esrt.c
> +++ linux-x86/drivers/firmware/efi/esrt.c
> @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> return;
> }
>
> + if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> + md->type != EFI_BOOT_SERVICES_DATA &&
> + md->type != EFI_RUNTIME_SERVICES_DATA) {
> + pr_err("ESRT header memory map type is invalid\n");
> + return;
> + }
> +
This looks wrong to me. While the meanings get convoluted in practice,
the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
a virtual mapping for the region. It is perfectly legal for a
EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
attribute, if the region is never accessed by the runtime services
themselves, and this is not entirely unlikely for tables that the
firmware exposes to the OS
> max = efi_mem_desc_end(&md);
> if (max < efi.esrt) {
> pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> return;
> }
>
> + if (md->attribute & EFI_MEMORY_RUNTIME ||
> + md->type != EFI_BOOT_SERVICES_DATA) {
> + return;
> + }
> +
> size += addr % EFI_PAGE_SIZE;
> size = round_up(size, EFI_PAGE_SIZE);
> addr = round_down(addr, EFI_PAGE_SIZE);
>
>>
>> >
>> > > How about move the if chunk early like below because it seems no need
>> > > to sanity check the addr + size any more if the md is still RUNTIME?
>> >
>> > My original version did as you suggest, but I changed it because we
>> > *really* want to know if someone tries to reserve a range that spans
>> > regions. That would be totally unexpected and a warning about a
>> > potential bug/issue.
>>
>> Matt, I'm fine if you prefer to capture the range checking errors.
>> Would you like me to post it or just you send it out?
>>
>> Thanks
>> Dave
>
> Thanks
> Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-22 16:10 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 16:10 UTC (permalink / raw)
To: Dave Young
Cc: Matt Fleming, Omar Sandoval, Ingo Molnar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-team-b10kYP2dOMg,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-efi-u79uwXL29TY76Z2rM5mHXA
On 21 March 2017 at 07:48, Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 03/20/17 at 10:14am, Dave Young wrote:
>> On 03/17/17 at 01:32pm, Matt Fleming wrote:
>> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
>> > >
>> > > Matt, I think it should be fine although I think the md type checking in
>> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>> >
>> > Could you make that a separate patch if you think of improvements
>> > there?
>>
>> Duplicate the lookup function is indeed a little ugly, will do it when I
>> have a better idea, we can leave it as is since it works.
>
> Matt, rethinking about this, how about doint something below, not
> tested, just seeking for idea and opinons, in this way no need duplicate
> a function, but there is an assumption that no overlapped mem ranges in
> efi memmap.
>
> Also the case Omar reported is the esrt memory range type is
> RUNTIME_DATA, that is a little different with the mem attribute of
> RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> attribute, like bgrt in kexec reboot. Should we distinguish the two
> cases and give out some warnings or debug info?
>
>
> ---
> arch/x86/platform/efi/quirks.c | 5 +++++
> drivers/firmware/efi/efi.c | 6 ------
> drivers/firmware/efi/esrt.c | 7 +++++++
> 3 files changed, 12 insertions(+), 6 deletions(-)
>
> --- linux-x86.orig/drivers/firmware/efi/efi.c
> +++ linux-x86/drivers/firmware/efi/efi.c
> @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> u64 size;
> u64 end;
>
> - if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> - md->type != EFI_BOOT_SERVICES_DATA &&
> - md->type != EFI_RUNTIME_SERVICES_DATA) {
> - continue;
> - }
> -
> size = md->num_pages << EFI_PAGE_SHIFT;
> end = md->phys_addr + size;
> if (phys_addr >= md->phys_addr && phys_addr < end) {
> --- linux-x86.orig/drivers/firmware/efi/esrt.c
> +++ linux-x86/drivers/firmware/efi/esrt.c
> @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> return;
> }
>
> + if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> + md->type != EFI_BOOT_SERVICES_DATA &&
> + md->type != EFI_RUNTIME_SERVICES_DATA) {
> + pr_err("ESRT header memory map type is invalid\n");
> + return;
> + }
> +
This looks wrong to me. While the meanings get convoluted in practice,
the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
a virtual mapping for the region. It is perfectly legal for a
EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
attribute, if the region is never accessed by the runtime services
themselves, and this is not entirely unlikely for tables that the
firmware exposes to the OS
> max = efi_mem_desc_end(&md);
> if (max < efi.esrt) {
> pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> return;
> }
>
> + if (md->attribute & EFI_MEMORY_RUNTIME ||
> + md->type != EFI_BOOT_SERVICES_DATA) {
> + return;
> + }
> +
> size += addr % EFI_PAGE_SIZE;
> size = round_up(size, EFI_PAGE_SIZE);
> addr = round_down(addr, EFI_PAGE_SIZE);
>
>>
>> >
>> > > How about move the if chunk early like below because it seems no need
>> > > to sanity check the addr + size any more if the md is still RUNTIME?
>> >
>> > My original version did as you suggest, but I changed it because we
>> > *really* want to know if someone tries to reserve a range that spans
>> > regions. That would be totally unexpected and a warning about a
>> > potential bug/issue.
>>
>> Matt, I'm fine if you prefer to capture the range checking errors.
>> Would you like me to post it or just you send it out?
>>
>> Thanks
>> Dave
>
> Thanks
> Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-22 16:10 ` Ard Biesheuvel
0 siblings, 0 replies; 55+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 16:10 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, Ingo Molnar,
Omar Sandoval, kernel-team
On 21 March 2017 at 07:48, Dave Young <dyoung@redhat.com> wrote:
> On 03/20/17 at 10:14am, Dave Young wrote:
>> On 03/17/17 at 01:32pm, Matt Fleming wrote:
>> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
>> > >
>> > > Matt, I think it should be fine although I think the md type checking in
>> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>> >
>> > Could you make that a separate patch if you think of improvements
>> > there?
>>
>> Duplicate the lookup function is indeed a little ugly, will do it when I
>> have a better idea, we can leave it as is since it works.
>
> Matt, rethinking about this, how about doint something below, not
> tested, just seeking for idea and opinons, in this way no need duplicate
> a function, but there is an assumption that no overlapped mem ranges in
> efi memmap.
>
> Also the case Omar reported is the esrt memory range type is
> RUNTIME_DATA, that is a little different with the mem attribute of
> RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> attribute, like bgrt in kexec reboot. Should we distinguish the two
> cases and give out some warnings or debug info?
>
>
> ---
> arch/x86/platform/efi/quirks.c | 5 +++++
> drivers/firmware/efi/efi.c | 6 ------
> drivers/firmware/efi/esrt.c | 7 +++++++
> 3 files changed, 12 insertions(+), 6 deletions(-)
>
> --- linux-x86.orig/drivers/firmware/efi/efi.c
> +++ linux-x86/drivers/firmware/efi/efi.c
> @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> u64 size;
> u64 end;
>
> - if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> - md->type != EFI_BOOT_SERVICES_DATA &&
> - md->type != EFI_RUNTIME_SERVICES_DATA) {
> - continue;
> - }
> -
> size = md->num_pages << EFI_PAGE_SHIFT;
> end = md->phys_addr + size;
> if (phys_addr >= md->phys_addr && phys_addr < end) {
> --- linux-x86.orig/drivers/firmware/efi/esrt.c
> +++ linux-x86/drivers/firmware/efi/esrt.c
> @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> return;
> }
>
> + if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> + md->type != EFI_BOOT_SERVICES_DATA &&
> + md->type != EFI_RUNTIME_SERVICES_DATA) {
> + pr_err("ESRT header memory map type is invalid\n");
> + return;
> + }
> +
This looks wrong to me. While the meanings get convoluted in practice,
the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
a virtual mapping for the region. It is perfectly legal for a
EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
attribute, if the region is never accessed by the runtime services
themselves, and this is not entirely unlikely for tables that the
firmware exposes to the OS
> max = efi_mem_desc_end(&md);
> if (max < efi.esrt) {
> pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> return;
> }
>
> + if (md->attribute & EFI_MEMORY_RUNTIME ||
> + md->type != EFI_BOOT_SERVICES_DATA) {
> + return;
> + }
> +
> size += addr % EFI_PAGE_SIZE;
> size = round_up(size, EFI_PAGE_SIZE);
> addr = round_down(addr, EFI_PAGE_SIZE);
>
>>
>> >
>> > > How about move the if chunk early like below because it seems no need
>> > > to sanity check the addr + size any more if the md is still RUNTIME?
>> >
>> > My original version did as you suggest, but I changed it because we
>> > *really* want to know if someone tries to reserve a range that spans
>> > regions. That would be totally unexpected and a warning about a
>> > potential bug/issue.
>>
>> Matt, I'm fine if you prefer to capture the range checking errors.
>> Would you like me to post it or just you send it out?
>>
>> Thanks
>> Dave
>
> Thanks
> Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-23 2:43 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-23 2:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Matt Fleming, Omar Sandoval, Ingo Molnar, linux-kernel,
kernel-team, pjones, kexec, linux-efi
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young <dyoung@redhat.com> wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >> > >
> >> > > Matt, I think it should be fine although I think the md type checking in
> >> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >> >
> >> > Could you make that a separate patch if you think of improvements
> >> > there?
> >>
> >> Duplicate the lookup function is indeed a little ugly, will do it when I
> >> have a better idea, we can leave it as is since it works.
> >
> > Matt, rethinking about this, how about doint something below, not
> > tested, just seeking for idea and opinons, in this way no need duplicate
> > a function, but there is an assumption that no overlapped mem ranges in
> > efi memmap.
> >
> > Also the case Omar reported is the esrt memory range type is
> > RUNTIME_DATA, that is a little different with the mem attribute of
> > RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> > attribute, like bgrt in kexec reboot. Should we distinguish the two
> > cases and give out some warnings or debug info?
> >
> >
> > ---
> > arch/x86/platform/efi/quirks.c | 5 +++++
> > drivers/firmware/efi/efi.c | 6 ------
> > drivers/firmware/efi/esrt.c | 7 +++++++
> > 3 files changed, 12 insertions(+), 6 deletions(-)
> >
> > --- linux-x86.orig/drivers/firmware/efi/efi.c
> > +++ linux-x86/drivers/firmware/efi/efi.c
> > @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> > u64 size;
> > u64 end;
> >
> > - if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > - md->type != EFI_BOOT_SERVICES_DATA &&
> > - md->type != EFI_RUNTIME_SERVICES_DATA) {
> > - continue;
> > - }
> > -
> > size = md->num_pages << EFI_PAGE_SHIFT;
> > end = md->phys_addr + size;
> > if (phys_addr >= md->phys_addr && phys_addr < end) {
> > --- linux-x86.orig/drivers/firmware/efi/esrt.c
> > +++ linux-x86/drivers/firmware/efi/esrt.c
> > @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> > return;
> > }
> >
> > + if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > + md->type != EFI_BOOT_SERVICES_DATA &&
> > + md->type != EFI_RUNTIME_SERVICES_DATA) {
> > + pr_err("ESRT header memory map type is invalid\n");
> > + return;
> > + }
> > +
>
> This looks wrong to me. While the meanings get convoluted in practice,
> the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
> a virtual mapping for the region. It is perfectly legal for a
> EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
> attribute, if the region is never accessed by the runtime services
> themselves, and this is not entirely unlikely for tables that the
> firmware exposes to the OS
Thanks for the comment, if so "!(md->attribute & EFI_MEMORY_RUNTIME) &&"
should be dropped.
BTW, md->type should be md.type, bgrt reserving works fine with this
change but I have no esrt machine to test it. I would like to wait for
Matt's opinions about this first before an update.
Also cc Peter about the esrt piece.
>
> > max = efi_mem_desc_end(&md);
> > if (max < efi.esrt) {
> > pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
> > --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> > +++ linux-x86/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> > return;
> > }
> >
> > + if (md->attribute & EFI_MEMORY_RUNTIME ||
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > + return;
> > + }
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
> >
> >>
> >> >
> >> > > How about move the if chunk early like below because it seems no need
> >> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >> >
> >> > My original version did as you suggest, but I changed it because we
> >> > *really* want to know if someone tries to reserve a range that spans
> >> > regions. That would be totally unexpected and a warning about a
> >> > potential bug/issue.
> >>
> >> Matt, I'm fine if you prefer to capture the range checking errors.
> >> Would you like me to post it or just you send it out?
> >>
> >> Thanks
> >> Dave
> >
> > Thanks
> > Dave
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-23 2:43 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-23 2:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Matt Fleming, Omar Sandoval, Ingo Molnar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-team-b10kYP2dOMg,
pjones-H+wXaHxf7aLQT0dZR+AlfA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-efi-u79uwXL29TY76Z2rM5mHXA
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >> > >
> >> > > Matt, I think it should be fine although I think the md type checking in
> >> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >> >
> >> > Could you make that a separate patch if you think of improvements
> >> > there?
> >>
> >> Duplicate the lookup function is indeed a little ugly, will do it when I
> >> have a better idea, we can leave it as is since it works.
> >
> > Matt, rethinking about this, how about doint something below, not
> > tested, just seeking for idea and opinons, in this way no need duplicate
> > a function, but there is an assumption that no overlapped mem ranges in
> > efi memmap.
> >
> > Also the case Omar reported is the esrt memory range type is
> > RUNTIME_DATA, that is a little different with the mem attribute of
> > RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> > attribute, like bgrt in kexec reboot. Should we distinguish the two
> > cases and give out some warnings or debug info?
> >
> >
> > ---
> > arch/x86/platform/efi/quirks.c | 5 +++++
> > drivers/firmware/efi/efi.c | 6 ------
> > drivers/firmware/efi/esrt.c | 7 +++++++
> > 3 files changed, 12 insertions(+), 6 deletions(-)
> >
> > --- linux-x86.orig/drivers/firmware/efi/efi.c
> > +++ linux-x86/drivers/firmware/efi/efi.c
> > @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> > u64 size;
> > u64 end;
> >
> > - if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > - md->type != EFI_BOOT_SERVICES_DATA &&
> > - md->type != EFI_RUNTIME_SERVICES_DATA) {
> > - continue;
> > - }
> > -
> > size = md->num_pages << EFI_PAGE_SHIFT;
> > end = md->phys_addr + size;
> > if (phys_addr >= md->phys_addr && phys_addr < end) {
> > --- linux-x86.orig/drivers/firmware/efi/esrt.c
> > +++ linux-x86/drivers/firmware/efi/esrt.c
> > @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> > return;
> > }
> >
> > + if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > + md->type != EFI_BOOT_SERVICES_DATA &&
> > + md->type != EFI_RUNTIME_SERVICES_DATA) {
> > + pr_err("ESRT header memory map type is invalid\n");
> > + return;
> > + }
> > +
>
> This looks wrong to me. While the meanings get convoluted in practice,
> the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
> a virtual mapping for the region. It is perfectly legal for a
> EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
> attribute, if the region is never accessed by the runtime services
> themselves, and this is not entirely unlikely for tables that the
> firmware exposes to the OS
Thanks for the comment, if so "!(md->attribute & EFI_MEMORY_RUNTIME) &&"
should be dropped.
BTW, md->type should be md.type, bgrt reserving works fine with this
change but I have no esrt machine to test it. I would like to wait for
Matt's opinions about this first before an update.
Also cc Peter about the esrt piece.
>
> > max = efi_mem_desc_end(&md);
> > if (max < efi.esrt) {
> > pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
> > --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> > +++ linux-x86/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> > return;
> > }
> >
> > + if (md->attribute & EFI_MEMORY_RUNTIME ||
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > + return;
> > + }
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
> >
> >>
> >> >
> >> > > How about move the if chunk early like below because it seems no need
> >> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >> >
> >> > My original version did as you suggest, but I changed it because we
> >> > *really* want to know if someone tries to reserve a range that spans
> >> > regions. That would be totally unexpected and a warning about a
> >> > potential bug/issue.
> >>
> >> Matt, I'm fine if you prefer to capture the range checking errors.
> >> Would you like me to post it or just you send it out?
> >>
> >> Thanks
> >> Dave
> >
> > Thanks
> > Dave
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-03-23 2:43 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-03-23 2:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Matt Fleming, kexec, linux-kernel, Ingo Molnar,
pjones, Omar Sandoval, kernel-team
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young <dyoung@redhat.com> wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >> > >
> >> > > Matt, I think it should be fine although I think the md type checking in
> >> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >> >
> >> > Could you make that a separate patch if you think of improvements
> >> > there?
> >>
> >> Duplicate the lookup function is indeed a little ugly, will do it when I
> >> have a better idea, we can leave it as is since it works.
> >
> > Matt, rethinking about this, how about doint something below, not
> > tested, just seeking for idea and opinons, in this way no need duplicate
> > a function, but there is an assumption that no overlapped mem ranges in
> > efi memmap.
> >
> > Also the case Omar reported is the esrt memory range type is
> > RUNTIME_DATA, that is a little different with the mem attribute of
> > RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> > attribute, like bgrt in kexec reboot. Should we distinguish the two
> > cases and give out some warnings or debug info?
> >
> >
> > ---
> > arch/x86/platform/efi/quirks.c | 5 +++++
> > drivers/firmware/efi/efi.c | 6 ------
> > drivers/firmware/efi/esrt.c | 7 +++++++
> > 3 files changed, 12 insertions(+), 6 deletions(-)
> >
> > --- linux-x86.orig/drivers/firmware/efi/efi.c
> > +++ linux-x86/drivers/firmware/efi/efi.c
> > @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> > u64 size;
> > u64 end;
> >
> > - if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > - md->type != EFI_BOOT_SERVICES_DATA &&
> > - md->type != EFI_RUNTIME_SERVICES_DATA) {
> > - continue;
> > - }
> > -
> > size = md->num_pages << EFI_PAGE_SHIFT;
> > end = md->phys_addr + size;
> > if (phys_addr >= md->phys_addr && phys_addr < end) {
> > --- linux-x86.orig/drivers/firmware/efi/esrt.c
> > +++ linux-x86/drivers/firmware/efi/esrt.c
> > @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> > return;
> > }
> >
> > + if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > + md->type != EFI_BOOT_SERVICES_DATA &&
> > + md->type != EFI_RUNTIME_SERVICES_DATA) {
> > + pr_err("ESRT header memory map type is invalid\n");
> > + return;
> > + }
> > +
>
> This looks wrong to me. While the meanings get convoluted in practice,
> the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
> a virtual mapping for the region. It is perfectly legal for a
> EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
> attribute, if the region is never accessed by the runtime services
> themselves, and this is not entirely unlikely for tables that the
> firmware exposes to the OS
Thanks for the comment, if so "!(md->attribute & EFI_MEMORY_RUNTIME) &&"
should be dropped.
BTW, md->type should be md.type, bgrt reserving works fine with this
change but I have no esrt machine to test it. I would like to wait for
Matt's opinions about this first before an update.
Also cc Peter about the esrt piece.
>
> > max = efi_mem_desc_end(&md);
> > if (max < efi.esrt) {
> > pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
> > --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> > +++ linux-x86/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> > return;
> > }
> >
> > + if (md->attribute & EFI_MEMORY_RUNTIME ||
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > + return;
> > + }
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
> >
> >>
> >> >
> >> > > How about move the if chunk early like below because it seems no need
> >> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >> >
> >> > My original version did as you suggest, but I changed it because we
> >> > *really* want to know if someone tries to reserve a range that spans
> >> > regions. That would be totally unexpected and a warning about a
> >> > potential bug/issue.
> >>
> >> Matt, I'm fine if you prefer to capture the range checking errors.
> >> Would you like me to post it or just you send it out?
> >>
> >> Thanks
> >> Dave
> >
> > Thanks
> > Dave
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-04-03 23:54 ` Omar Sandoval
0 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-04-03 23:54 UTC (permalink / raw)
To: Matt Fleming
Cc: Dave Young, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On Thu, Mar 16, 2017 at 10:50:48AM -0700, Omar Sandoval wrote:
> On Thu, Mar 16, 2017 at 12:41:32PM +0000, Matt Fleming wrote:
> > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> > >
> > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > > can rewrite patch log with more background and send it out:
> > >
> > > for_each_efi_memory_desc(md) {
> > > [snip]
> > > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > > md->type != EFI_BOOT_SERVICES_DATA &&
> > > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > > continue;
> > > }
> > >
> > > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > > running time. Just is happened to work and we did not capture the error.
> >
> > Wouldn't something like this be simpler?
> >
> > ---
> >
> > diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> > index 30031d5293c4..cdfe8c628959 100644
> > --- a/arch/x86/platform/efi/quirks.c
> > +++ b/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> > return;
> > }
> >
> > + /* No need to reserve regions that will never be freed. */
> > + if (md.attribute & EFI_MEMORY_RUNTIME)
> > + return;
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
>
> This works for me.
>
> Reported-and-tested-by: Omar Sandoval <osandov@fb.com>
Is this going to go in for 4.11?
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-04-03 23:54 ` Omar Sandoval
0 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-04-03 23:54 UTC (permalink / raw)
To: Matt Fleming
Cc: Dave Young, Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-team-b10kYP2dOMg, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-efi-u79uwXL29TY76Z2rM5mHXA
On Thu, Mar 16, 2017 at 10:50:48AM -0700, Omar Sandoval wrote:
> On Thu, Mar 16, 2017 at 12:41:32PM +0000, Matt Fleming wrote:
> > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> > >
> > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > > can rewrite patch log with more background and send it out:
> > >
> > > for_each_efi_memory_desc(md) {
> > > [snip]
> > > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > > md->type != EFI_BOOT_SERVICES_DATA &&
> > > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > > continue;
> > > }
> > >
> > > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > > running time. Just is happened to work and we did not capture the error.
> >
> > Wouldn't something like this be simpler?
> >
> > ---
> >
> > diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> > index 30031d5293c4..cdfe8c628959 100644
> > --- a/arch/x86/platform/efi/quirks.c
> > +++ b/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> > return;
> > }
> >
> > + /* No need to reserve regions that will never be freed. */
> > + if (md.attribute & EFI_MEMORY_RUNTIME)
> > + return;
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
>
> This works for me.
>
> Reported-and-tested-by: Omar Sandoval <osandov-b10kYP2dOMg@public.gmane.org>
Is this going to go in for 4.11?
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-04-03 23:54 ` Omar Sandoval
0 siblings, 0 replies; 55+ messages in thread
From: Omar Sandoval @ 2017-04-03 23:54 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi, kexec, linux-kernel, kernel-team, Dave Young, Ingo Molnar
On Thu, Mar 16, 2017 at 10:50:48AM -0700, Omar Sandoval wrote:
> On Thu, Mar 16, 2017 at 12:41:32PM +0000, Matt Fleming wrote:
> > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> > >
> > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is not
> > > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> > > can rewrite patch log with more background and send it out:
> > >
> > > for_each_efi_memory_desc(md) {
> > > [snip]
> > > if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > > md->type != EFI_BOOT_SERVICES_DATA &&
> > > md->type != EFI_RUNTIME_SERVICES_DATA) {
> > > continue;
> > > }
> > >
> > > In above code, it meant to get a md of EFI_MEMORY_RUNTIME of either boot
> > > data or runtime data, this is wrong for efi_mem_reserve, because we are
> > > reserving boot data which has no EFI_MEMORY_RUNTIME attribute at the
> > > running time. Just is happened to work and we did not capture the error.
> >
> > Wouldn't something like this be simpler?
> >
> > ---
> >
> > diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> > index 30031d5293c4..cdfe8c628959 100644
> > --- a/arch/x86/platform/efi/quirks.c
> > +++ b/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
> > return;
> > }
> >
> > + /* No need to reserve regions that will never be freed. */
> > + if (md.attribute & EFI_MEMORY_RUNTIME)
> > + return;
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
>
> This works for me.
>
> Reported-and-tested-by: Omar Sandoval <osandov@fb.com>
Is this going to go in for 4.11?
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-04-04 13:37 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-04-04 13:37 UTC (permalink / raw)
To: Dave Young
Cc: Omar Sandoval, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
>
> Matt, I'm fine if you prefer to capture the range checking errors.
> Would you like me to post it or just you send it out?
Can you please send out the patch with the minimal change to
efi_arch_mem_reserve() and we'll get it into urgent ASAP.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-04-04 13:37 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-04-04 13:37 UTC (permalink / raw)
To: Dave Young
Cc: Omar Sandoval, Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-team-b10kYP2dOMg, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-efi-u79uwXL29TY76Z2rM5mHXA
On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
>
> Matt, I'm fine if you prefer to capture the range checking errors.
> Would you like me to post it or just you send it out?
Can you please send out the patch with the minimal change to
efi_arch_mem_reserve() and we'll get it into urgent ASAP.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-04-04 13:37 ` Matt Fleming
0 siblings, 0 replies; 55+ messages in thread
From: Matt Fleming @ 2017-04-04 13:37 UTC (permalink / raw)
To: Dave Young
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval, kernel-team
On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
>
> Matt, I'm fine if you prefer to capture the range checking errors.
> Would you like me to post it or just you send it out?
Can you please send out the patch with the minimal change to
efi_arch_mem_reserve() and we'll get it into urgent ASAP.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
2017-04-04 13:37 ` Matt Fleming
@ 2017-04-05 1:23 ` Dave Young
-1 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-04-05 1:23 UTC (permalink / raw)
To: Matt Fleming
Cc: Omar Sandoval, Ingo Molnar, linux-kernel, kernel-team, kexec, linux-efi
On 04/04/17 at 02:37pm, Matt Fleming wrote:
> On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
> >
> > Matt, I'm fine if you prefer to capture the range checking errors.
> > Would you like me to post it or just you send it out?
>
> Can you please send out the patch with the minimal change to
> efi_arch_mem_reserve() and we'll get it into urgent ASAP.
Omar has sent it out, for the lookup function issue I think I can do it
after this one later.
Thanks
Dave
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: kexec regression since 4.9 caused by efi
@ 2017-04-05 1:23 ` Dave Young
0 siblings, 0 replies; 55+ messages in thread
From: Dave Young @ 2017-04-05 1:23 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-efi, kexec, linux-kernel, Ingo Molnar, Omar Sandoval, kernel-team
On 04/04/17 at 02:37pm, Matt Fleming wrote:
> On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
> >
> > Matt, I'm fine if you prefer to capture the range checking errors.
> > Would you like me to post it or just you send it out?
>
> Can you please send out the patch with the minimal change to
> efi_arch_mem_reserve() and we'll get it into urgent ASAP.
Omar has sent it out, for the lookup function issue I think I can do it
after this one later.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2017-04-05 1:28 UTC | newest]
Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-08 20:16 kexec regression since 4.9 caused by efi Omar Sandoval
2017-03-09 2:21 ` Dave Young
2017-03-09 3:36 ` Omar Sandoval
2017-03-09 6:38 ` Dave Young
2017-03-09 6:38 ` Dave Young
2017-03-09 6:38 ` Dave Young
2017-03-09 9:54 ` Omar Sandoval
2017-03-09 9:54 ` Omar Sandoval
2017-03-09 11:53 ` Ard Biesheuvel
2017-03-09 11:53 ` Ard Biesheuvel
2017-03-09 11:53 ` Ard Biesheuvel
2017-03-10 1:39 ` Dave Young
2017-03-10 1:39 ` Dave Young
2017-03-16 12:15 ` Matt Fleming
2017-03-16 12:15 ` Matt Fleming
2017-03-10 1:42 ` Dave Young
2017-03-10 1:42 ` Dave Young
2017-03-10 1:42 ` Dave Young
2017-03-13 7:37 ` Dave Young
2017-03-13 7:37 ` Dave Young
2017-03-13 7:37 ` Dave Young
2017-03-16 12:41 ` Matt Fleming
2017-03-16 12:41 ` Matt Fleming
2017-03-16 12:41 ` Matt Fleming
2017-03-16 17:50 ` Omar Sandoval
2017-03-16 17:50 ` Omar Sandoval
2017-04-03 23:54 ` Omar Sandoval
2017-04-03 23:54 ` Omar Sandoval
2017-04-03 23:54 ` Omar Sandoval
2017-03-17 2:09 ` Dave Young
2017-03-17 2:09 ` Dave Young
2017-03-17 2:09 ` Dave Young
2017-03-17 13:25 ` Ard Biesheuvel
2017-03-17 13:25 ` Ard Biesheuvel
2017-03-17 13:25 ` Ard Biesheuvel
2017-03-17 13:32 ` Matt Fleming
2017-03-17 13:32 ` Matt Fleming
2017-03-17 13:32 ` Matt Fleming
2017-03-20 2:14 ` Dave Young
2017-03-20 2:14 ` Dave Young
2017-03-20 2:14 ` Dave Young
2017-03-21 7:48 ` Dave Young
2017-03-21 7:48 ` Dave Young
2017-03-21 7:48 ` Dave Young
2017-03-22 16:10 ` Ard Biesheuvel
2017-03-22 16:10 ` Ard Biesheuvel
2017-03-22 16:10 ` Ard Biesheuvel
2017-03-23 2:43 ` Dave Young
2017-03-23 2:43 ` Dave Young
2017-03-23 2:43 ` Dave Young
2017-04-04 13:37 ` Matt Fleming
2017-04-04 13:37 ` Matt Fleming
2017-04-04 13:37 ` Matt Fleming
2017-04-05 1:23 ` Dave Young
2017-04-05 1:23 ` Dave Young
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.