Hi Juergen,
Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
discovered instead that my box had turned into a complete slug, not due
to incredible RETPOLINE overhead, rather because box had forgotten that
it had more than one CPU. ?I was going to leave it for the weekend, but
firing up gitk over morning java, I noticed the commits below, and sure
enough, that's what broke my box. ?Given other people's boxen work,
seems likely that the authors of the AMI BIOS in this box were a bit
more creative than usual.
commit 9ede5d5e672586e016eadd5c0aedb6f12e660029 (HEAD -> x86-tip)
Author: Mike Galbraith <[email protected]>
Date: Fri Jan 12 04:17:52 2018 +0100
Revert "x86/boot: Add the ACPI RSDP address to struct setup_header::acpi_rdsp_addr"
This reverts commit 2f74cbf947f45fa082dda8eac1a1f1299a372f49.
commit 0d0b6a9a0d452eaf635580fce8319d49be8b45ed
Author: Mike Galbraith <[email protected]>
Date: Fri Jan 12 04:17:30 2018 +0100
Revert "x86/acpi: Take the RSDP address for boot parameters if available"
This reverts commit 0c89cf36424f7c1177de8a5712514d7cc2eb369f.
commit 2e9b091da44e75f16b8bad776f40de83abb637ff (origin/x86-tip)
Merge: 41c34211458c 1ccb8feda747
Author: Ingo Molnar <[email protected]>
Date: Thu Jan 11 06:54:18 2018 +0100
Merge branch 'perf/core'
On 12/01/18 05:25, Mike Galbraith wrote:
> Hi Juergen,
>
> Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
> discovered instead that my box had turned into a complete slug, not due
> to incredible RETPOLINE overhead, rather because box had forgotten that
> it had more than one CPU. ?I was going to leave it for the weekend, but
> firing up gitk over morning java, I noticed the commits below, and sure
> enough, that's what broke my box. ?Given other people's boxen work,
> seems likely that the authors of the AMI BIOS in this box were a bit
> more creative than usual.
So I'm curious how this should be possible.
Some questions:
- which bootloader are you using?
- what does /sys/kernel/boot_params/version contain?
- can you print the returned value of acpi_arch_get_root_pointer()
in acpi_os_get_root_pointer() with the patches applied and report
it, please?
Juergen
On Fri, 2018-01-12 at 07:40 +0100, Juergen Gross wrote:
> On 12/01/18 05:25, Mike Galbraith wrote:
> > Hi Juergen,
> >
> > Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
> > discovered instead that my box had turned into a complete slug, not due
> > to incredible RETPOLINE overhead, rather because box had forgotten that
> > it had more than one CPU. ?I was going to leave it for the weekend, but
> > firing up gitk over morning java, I noticed the commits below, and sure
> > enough, that's what broke my box. ?Given other people's boxen work,
> > seems likely that the authors of the AMI BIOS in this box were a bit
> > more creative than usual.
>
> So I'm curious how this should be possible.
Box is absolutely certain that it is.
> Some questions:
>
> - which bootloader are you using?
grub2, box is bog standard opensuse-42.3
> - what does /sys/kernel/boot_params/version contain?
0x020e
> - can you print the returned value of acpi_arch_get_root_pointer()
> in acpi_os_get_root_pointer() with the patches applied and report
> it, please?
0x115, which doesn't look all that useful to ACPI.
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: MIKE pa = 0x115
[ 0.000000] ACPI: 0x0000000000000115 000000 (v00 00000000 00000000)
[ 0.000000] Reserving 132MB of low memory at 3392MB for crashkernel (System low RAM: 3556MB)
[ 0.000000] Reserving 256MB of memory at 16608MB for crashkernel (System RAM: 16340MB)
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x000000041effffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000001000-0x0000000000057fff]
[ 0.000000] node 0: [mem 0x0000000000059000-0x000000000009dfff]
[ 0.000000] node 0: [mem 0x0000000000100000-0x00000000d0443fff]
[ 0.000000] node 0: [mem 0x00000000d044b000-0x00000000d0889fff]
[ 0.000000] node 0: [mem 0x00000000d0b4b000-0x00000000de787fff]
[ 0.000000] node 0: [mem 0x00000000defff000-0x00000000deffffff]
[ 0.000000] node 0: [mem 0x0000000100000000-0x000000041effffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000041effffff]
[ 0.000000] On node 0 totalpages: 4183133
[ 0.000000] DMA zone: 64 pages used for memmap
[ 0.000000] DMA zone: 21 pages reserved
[ 0.000000] DMA zone: 3996 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 14164 pages used for memmap
[ 0.000000] DMA32 zone: 906433 pages, LIFO batch:31
[ 0.000000] Normal zone: 51136 pages used for memmap
[ 0.000000] Normal zone: 3272704 pages, LIFO batch:31
[ 0.000000] Reserved but unavailable: 99 pages
[ 0.000000] tboot: non-0 tboot_addr but it is not of type E820_TYPE_RESERVED
[ 0.000000] smpboot: Boot CPU (id 0) not listed by BIOS
[ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.000000] e820: [mem 0xdf000000-0xf7ffffff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on bare hardware
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1
[ 0.000000] percpu: Embedded 43 pages/cpu @ (ptrval) s135896 r8192 d32040 u2097152
[ 0.000000] pcpu-alloc: s135896 r8192 d32040 u2097152 alloc=1*2097152
[ 0.000000] pcpu-alloc: [0] 0
On 12/01/18 09:01, Mike Galbraith wrote:
> On Fri, 2018-01-12 at 07:40 +0100, Juergen Gross wrote:
>> On 12/01/18 05:25, Mike Galbraith wrote:
>>> Hi Juergen,
>>>
>>> Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
>>> discovered instead that my box had turned into a complete slug, not due
>>> to incredible RETPOLINE overhead, rather because box had forgotten that
>>> it had more than one CPU. ?I was going to leave it for the weekend, but
>>> firing up gitk over morning java, I noticed the commits below, and sure
>>> enough, that's what broke my box. ?Given other people's boxen work,
>>> seems likely that the authors of the AMI BIOS in this box were a bit
>>> more creative than usual.
>>
>> So I'm curious how this should be possible.
>
> Box is absolutely certain that it is.
>
>> Some questions:
>>
>> - which bootloader are you using?
>
> grub2, box is bog standard opensuse-42.3
>
>> - what does /sys/kernel/boot_params/version contain?
>
> 0x020e
Hmm, what does:
cat /sys/kernel/boot_params/data | od -t x1 -A x | grep -e ^0002
report? Please do that with 0c89cf36424f7c1177de8a5712514d7cc2eb369f
reverted and with 2f74cbf947f45fa082dda8eac1a1f1299a372f49 applied.
Juergen
On Fri, Jan 12, 2018 at 05:25:28AM +0100, Mike Galbraith wrote:
> Hi Juergen,
>
> Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
> discovered instead that my box had turned into a complete slug, not due
> to incredible RETPOLINE overhead, rather because box had forgotten that
> it had more than one CPU. I was going to leave it for the weekend, but
> firing up gitk over morning java, I noticed the commits below, and sure
> enough, that's what broke my box. Given other people's boxen work,
> seems likely that the authors of the AMI BIOS in this box were a bit
> more creative than usual.
>
> commit 9ede5d5e672586e016eadd5c0aedb6f12e660029 (HEAD -> x86-tip)
> Author: Mike Galbraith <[email protected]>
> Date: Fri Jan 12 04:17:52 2018 +0100
>
> Revert "x86/boot: Add the ACPI RSDP address to struct setup_header::acpi_rdsp_addr"
>
> This reverts commit 2f74cbf947f45fa082dda8eac1a1f1299a372f49.
>
> commit 0d0b6a9a0d452eaf635580fce8319d49be8b45ed
> Author: Mike Galbraith <[email protected]>
> Date: Fri Jan 12 04:17:30 2018 +0100
>
> Revert "x86/acpi: Take the RSDP address for boot parameters if available"
I'm seeing a similar irregularity caused by this one above. I did bisect tip
merges and here's my tree state:
e07fcf1e8c1c (HEAD -> refs/heads/rc7+pti) x86/acpi: Take the RSDP address for boot parameters if available
a7d88e8f7b73 x86/boot: Add the ACPI RSDP address to struct setup_header::acpi_rdsp_addr
372349a5e806 Merge remote-tracking branch 'tip/x86/apic' into rc7+pti
8cf749efdb78 Merge remote-tracking branch 'tip/sched/core' into rc7+pti
4720f8a1ddb0 Merge remote-tracking branch 'tip/ras/core' into rc7+pti
...
So tip commit:
0c89cf36424f x86/acpi: Take the RSDP address for boot parameters if available
ontop of rc7 + a bunch of tip branches is the first one which causes
this (maybe it'll help debugging the issue):
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: \xffffffee 0x0000000000000115 F3F000EE (v238 \xfffffff0\xfffffff3\xffffffee \xffffffee F3F000EE \xffffffee 38F000EE)
[ 0.000000] ACPI: \xffffffff\xffffffff\xffffffff\xffffffff 0xF3F000EEF3F000EE FFFFFFFF (v255 \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff FFFFFFFF \xffffffff\xffffffff\xffffffff\xffffffff FFFFFFFF)
[ 0.000000] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:145 __early_ioremap+0xd0/0x19e
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-rc7+ #16
[ 0.000000] RIP: 0010:__early_ioremap+0xd0/0x19e
[ 0.000000] RSP: 0000:ffffffffa4003ce8 EFLAGS: 00010002 ORIG_RAX: 0000000000000000
[ 0.000000] RAX: 0000000000000000 RBX: 0000000000100001 RCX: 0000000000100001
[ 0.000000] RDX: f3f000eff3f000ec RSI: 00000000000000ee RDI: f3f000eef3f00000
[ 0.000000] RBP: ffffffffa4003d40 R08: 0000000000000001 R09: 00000000000000af
[ 0.000000] R10: 206e6f6974616369 R11: 4530303046334678 R12: 8000000000000163
[ 0.000000] R13: 0000000000000001 R14: f3f000eff3f000ed R15: 0000000000000008
[ 0.000000] FS: 0000000000000000(0000) GS:ffffffffa416b000(0000) knlGS:0000000000000000
[ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.000000] CR2: ffff94efffdff000 CR3: 000000251700a000 CR4: 00000000000406b0
[ 0.000000] Call Trace:
[ 0.000000] early_memremap+0x36/0x3b
[ 0.000000] __acpi_map_table+0x18/0x1d
[ 0.000000] acpi_os_map_iomem+0x135/0x1b0
[ 0.000000] acpi_os_map_memory+0xe/0x10
[ 0.000000] acpi_tb_parse_root_table+0x172/0x29a
[ 0.000000] acpi_initialize_tables+0xd0/0xfb
[ 0.000000] acpi_table_init+0x59/0x1be
[ 0.000000] acpi_boot_table_init+0x23/0x8a
[ 0.000000] setup_arch+0x91e/0xc6d
[ 0.000000] start_kernel+0x5c/0x495
[ 0.000000] x86_64_start_reservations+0x24/0x26
[ 0.000000] x86_64_start_kernel+0x74/0x77
[ 0.000000] secondary_startup_64+0xa5/0xb0
[ 0.000000] Code: 65 d0 00 f0 ff ff 81 e6 ff 0f 00 00 48 29 7d d0 48 89 75 c0 48 8b 4d d0 48 89 7d c8 48 c1 e9 0c 83 f9 40 48 89 4d b0 89 cb 76 07 <0f> ff e9 aa 00 00 00 41 6b d0 c0 4c 8b 7d c8 81 eb ff 05 00 00
[ 0.000000] ---[ end trace 84de100369bbea16 ]---
[ 0.000000] No NUMA configuration found
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, 2018-01-12 at 12:17 +0100, Juergen Gross wrote:
>
> Hmm, what does:
>
> cat /sys/kernel/boot_params/data | od -t x1 -A x | grep -e ^0002
000200 eb 6e 48 64 72 53 0e 02 00 00 00 00 00 10 80 32
000210 21 01 00 80 00 00 00 01 00 a0 63 3f 38 0e 9c 00
000220 00 00 00 00 20 54 00 00 00 b0 ff 3f ff ff ff 7f
000230 00 00 00 01 01 15 1f 00 ff 07 00 00 00 00 00 00
000240 00 00 00 00 00 00 00 00 b4 03 00 00 d9 6e 4f 00
000250 18 30 14 d0 00 00 00 00 00 00 00 01 00 00 00 00
000260 00 80 71 01 90 01 00 00 15 01 00 00 00 00 00 00
000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000290 f2 e9 16 d0 00 00 00 00 10 00 00 00 00 00 00 00
0002a0 c6 2f b0 cc 00 00 00 00 40 37 da cb 00 00 00 00
0002b0 48 4d de cb 00 00 00 00 98 66 c6 cc 00 00 00 00
0002c0 84 38 b0 cc 00 00 00 00 98 66 c6 cc 00 00 00 00
0002d0 00 00 00 00 00 00 00 00 00 80 05 00 00 00 00 00
0002e0 01 00 00 00 00 80 05 00 00 00 00 00 00 10 00 00
0002f0 00 00 00 00 02 00 00 00 00 90 05 00 00 00 00 00
* Mike Galbraith <[email protected]> wrote:
> Hi Juergen,
>
> Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
> discovered instead that my box had turned into a complete slug, not due
> to incredible RETPOLINE overhead, rather because box had forgotten that
> it had more than one CPU. ?I was going to leave it for the weekend, but
> firing up gitk over morning java, I noticed the commits below, and sure
> enough, that's what broke my box. ?Given other people's boxen work,
> seems likely that the authors of the AMI BIOS in this box were a bit
> more creative than usual.
>
> commit 9ede5d5e672586e016eadd5c0aedb6f12e660029 (HEAD -> x86-tip)
> Author: Mike Galbraith <[email protected]>
> Date: Fri Jan 12 04:17:52 2018 +0100
>
> Revert "x86/boot: Add the ACPI RSDP address to struct setup_header::acpi_rdsp_addr"
>
> This reverts commit 2f74cbf947f45fa082dda8eac1a1f1299a372f49.
>
> commit 0d0b6a9a0d452eaf635580fce8319d49be8b45ed
> Author: Mike Galbraith <[email protected]>
> Date: Fri Jan 12 04:17:30 2018 +0100
>
> Revert "x86/acpi: Take the RSDP address for boot parameters if available"
>
> This reverts commit 0c89cf36424f7c1177de8a5712514d7cc2eb369f.
>
Ok, I've excluded tip:x86/boot from tip:master for the time being - these commits
are not v4.16 ready apparently.
Thanks,
Ingo
On 12/01/18 09:01, Mike Galbraith wrote:
> On Fri, 2018-01-12 at 07:40 +0100, Juergen Gross wrote:
>> On 12/01/18 05:25, Mike Galbraith wrote:
>>> Hi Juergen,
>>>
>>> Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
>>> discovered instead that my box had turned into a complete slug, not due
>>> to incredible RETPOLINE overhead, rather because box had forgotten that
>>> it had more than one CPU. ?I was going to leave it for the weekend, but
>>> firing up gitk over morning java, I noticed the commits below, and sure
>>> enough, that's what broke my box. ?Given other people's boxen work,
>>> seems likely that the authors of the AMI BIOS in this box were a bit
>>> more creative than usual.
>>
>> So I'm curious how this should be possible.
>
> Box is absolutely certain that it is.
>
>> Some questions:
>>
>> - which bootloader are you using?
>
> grub2, box is bog standard opensuse-42.3
And this is the problem.
grub2 of opensuse 42.3 is _wrong_.
It copies the setup_header in the size it knows of (last fiels is
handover_offset), fills in some stuff, and then copies back 1024 bytes.
So grub2 of openSUSE 42.3 is _not_ ready to accept extensions of
bootparams.
This is a major breakage of the protocol, I think.
Juergen
>
>> - what does /sys/kernel/boot_params/version contain?
>
> 0x020e
>
>> - can you print the returned value of acpi_arch_get_root_pointer()
>> in acpi_os_get_root_pointer() with the patches applied and report
>> it, please?
>
> 0x115, which doesn't look all that useful to ACPI.
>
> [ 0.000000] ACPI: Early table checksum verification disabled
> [ 0.000000] ACPI: MIKE pa = 0x115
> [ 0.000000] ACPI: 0x0000000000000115 000000 (v00 00000000 00000000)
> [ 0.000000] Reserving 132MB of low memory at 3392MB for crashkernel (System low RAM: 3556MB)
> [ 0.000000] Reserving 256MB of memory at 16608MB for crashkernel (System RAM: 16340MB)
> [ 0.000000] tsc: Fast TSC calibration using PIT
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
> [ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
> [ 0.000000] Normal [mem 0x0000000100000000-0x000000041effffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000001000-0x0000000000057fff]
> [ 0.000000] node 0: [mem 0x0000000000059000-0x000000000009dfff]
> [ 0.000000] node 0: [mem 0x0000000000100000-0x00000000d0443fff]
> [ 0.000000] node 0: [mem 0x00000000d044b000-0x00000000d0889fff]
> [ 0.000000] node 0: [mem 0x00000000d0b4b000-0x00000000de787fff]
> [ 0.000000] node 0: [mem 0x00000000defff000-0x00000000deffffff]
> [ 0.000000] node 0: [mem 0x0000000100000000-0x000000041effffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000041effffff]
> [ 0.000000] On node 0 totalpages: 4183133
> [ 0.000000] DMA zone: 64 pages used for memmap
> [ 0.000000] DMA zone: 21 pages reserved
> [ 0.000000] DMA zone: 3996 pages, LIFO batch:0
> [ 0.000000] DMA32 zone: 14164 pages used for memmap
> [ 0.000000] DMA32 zone: 906433 pages, LIFO batch:31
> [ 0.000000] Normal zone: 51136 pages used for memmap
> [ 0.000000] Normal zone: 3272704 pages, LIFO batch:31
> [ 0.000000] Reserved but unavailable: 99 pages
> [ 0.000000] tboot: non-0 tboot_addr but it is not of type E820_TYPE_RESERVED
> [ 0.000000] smpboot: Boot CPU (id 0) not listed by BIOS
> [ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
> [ 0.000000] e820: [mem 0xdf000000-0xf7ffffff] available for PCI devices
> [ 0.000000] Booting paravirtualized kernel on bare hardware
> [ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
> [ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1
> [ 0.000000] percpu: Embedded 43 pages/cpu @ (ptrval) s135896 r8192 d32040 u2097152
> [ 0.000000] pcpu-alloc: s135896 r8192 d32040 u2097152 alloc=1*2097152
> [ 0.000000] pcpu-alloc: [0] 0
>
On 12/01/18 14:11, Ingo Molnar wrote:
>
> * Mike Galbraith <[email protected]> wrote:
>
>> Hi Juergen,
>>
>> Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
>> discovered instead that my box had turned into a complete slug, not due
>> to incredible RETPOLINE overhead, rather because box had forgotten that
>> it had more than one CPU. I was going to leave it for the weekend, but
>> firing up gitk over morning java, I noticed the commits below, and sure
>> enough, that's what broke my box. Given other people's boxen work,
>> seems likely that the authors of the AMI BIOS in this box were a bit
>> more creative than usual.
>>
>> commit 9ede5d5e672586e016eadd5c0aedb6f12e660029 (HEAD -> x86-tip)
>> Author: Mike Galbraith <[email protected]>
>> Date: Fri Jan 12 04:17:52 2018 +0100
>>
>> Revert "x86/boot: Add the ACPI RSDP address to struct setup_header::acpi_rdsp_addr"
>>
>> This reverts commit 2f74cbf947f45fa082dda8eac1a1f1299a372f49.
>>
>> commit 0d0b6a9a0d452eaf635580fce8319d49be8b45ed
>> Author: Mike Galbraith <[email protected]>
>> Date: Fri Jan 12 04:17:30 2018 +0100
>>
>> Revert "x86/acpi: Take the RSDP address for boot parameters if available"
>>
>> This reverts commit 0c89cf36424f7c1177de8a5712514d7cc2eb369f.
>>
>
> Ok, I've excluded tip:x86/boot from tip:master for the time being - these commits
> are not v4.16 ready apparently.
Ingo, with my finding that above boot failure is related to a bug in
openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
I think my patches are fine for 4.16.
I've filed a bugzilla for SUSE's grub2.
Juergen
On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
> Ingo, with my finding that above boot failure is related to a bug in
> openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
The box I'm seeing this on has SLES12-SP2 grub:
Version : 2.02~beta2-115.9.1
Does it have the same bug?
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, 2018-01-15 at 15:41 +0100, Juergen Gross wrote:
> On 12/01/18 09:01, Mike Galbraith wrote:
> > On Fri, 2018-01-12 at 07:40 +0100, Juergen Gross wrote:
> >> On 12/01/18 05:25, Mike Galbraith wrote:
> >>> Hi Juergen,
> >>>
> >>> Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but
> >>> discovered instead that my box had turned into a complete slug, not due
> >>> to incredible RETPOLINE overhead, rather because box had forgotten that
> >>> it had more than one CPU. ?I was going to leave it for the weekend, but
> >>> firing up gitk over morning java, I noticed the commits below, and sure
> >>> enough, that's what broke my box. ?Given other people's boxen work,
> >>> seems likely that the authors of the AMI BIOS in this box were a bit
> >>> more creative than usual.
> >>
> >> So I'm curious how this should be possible.
> >
> > Box is absolutely certain that it is.
> >
> >> Some questions:
> >>
> >> - which bootloader are you using?
> >
> > grub2, box is bog standard opensuse-42.3
>
> And this is the problem.
>
> grub2 of opensuse 42.3 is _wrong_.
>
> It copies the setup_header in the size it knows of (last fiels is
> handover_offset), fills in some stuff, and then copies back 1024 bytes.
> So grub2 of openSUSE 42.3 is _not_ ready to accept extensions of
> bootparams.
>
> This is a major breakage of the protocol, I think.
Oh joy, userspace b0rkage. ?Kernel b0rkage is a lot less annoying.?
Hohum, I have zero problem with carrying a revert until grub2 gets
fixed up, but lord knows how many others out there may bisect, and
bless your mailbox with the fruit of their labors :)
-Mike
On 15/01/18 15:56, Borislav Petkov wrote:
> On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
>> Ingo, with my finding that above boot failure is related to a bug in
>> openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
>
> The box I'm seeing this on has SLES12-SP2 grub:
>
> Version : 2.02~beta2-115.9.1
>
> Does it have the same bug?
The patch introducing this problem is from 2012. So I guess: yes.
Juergen
* Juergen Gross <[email protected]> wrote:
> On 15/01/18 15:56, Borislav Petkov wrote:
> > On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
> >> Ingo, with my finding that above boot failure is related to a bug in
> >> openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
> >
> > The box I'm seeing this on has SLES12-SP2 grub:
> >
> > Version : 2.02~beta2-115.9.1
> >
> > Does it have the same bug?
>
> The patch introducing this problem is from 2012. So I guess: yes.
I suspect this makes it a widespread, unintended ABI. Can we detect and somehow avoid it?
The boot protocol ABI sucks if it's fragile against such mistakes.
Thanks,
Ingo
On 15/01/18 16:32, Ingo Molnar wrote:
>
> * Juergen Gross <[email protected]> wrote:
>
>> On 15/01/18 15:56, Borislav Petkov wrote:
>>> On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
>>>> Ingo, with my finding that above boot failure is related to a bug in
>>>> openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
>>>
>>> The box I'm seeing this on has SLES12-SP2 grub:
>>>
>>> Version : 2.02~beta2-115.9.1
>>>
>>> Does it have the same bug?
>>
>> The patch introducing this problem is from 2012. So I guess: yes.
>
> I suspect this makes it a widespread, unintended ABI. Can we detect and somehow avoid it?
>
> The boot protocol ABI sucks if it's fragile against such mistakes.
Well, copying sizeof(setup_header) into grub2 and then coyping back just
1024 bytes is plain wrong. It is a miracle nothing broke up to now.
Juergen
On 15.01.2018 16:40, Juergen Gross wrote:
> On 15/01/18 16:32, Ingo Molnar wrote:
>>
Hi Juergen,
>> * Juergen Gross <[email protected]> wrote:
>>
>>> On 15/01/18 15:56, Borislav Petkov wrote:
>>>> On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
>>>>> Ingo, with my finding that above boot failure is related to a bug in
>>>>> openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
>>>>
>>>> The box I'm seeing this on has SLES12-SP2 grub:
>>>>
>>>> Version : 2.02~beta2-115.9.1
>>>>
>>>> Does it have the same bug?
>>>
>>> The patch introducing this problem is from 2012. So I guess: yes.
>>
>> I suspect this makes it a widespread, unintended ABI. Can we detect and somehow avoid it?
>>
>> The boot protocol ABI sucks if it's fragile against such mistakes.
>
> Well, copying sizeof(setup_header) into grub2 and then coyping back just
> 1024 bytes is plain wrong. It is a miracle nothing broke up to now.
>
I'm not on SUSE and hit that too on an H11DSi-NT.
See: https://marc.info/?l=linux-kernel&m=151579540320553&w=2
Regards,
Gabriel C
On 15/01/18 17:29, Gabriel C wrote:
> On 15.01.2018 16:40, Juergen Gross wrote:
>> On 15/01/18 16:32, Ingo Molnar wrote:
>>>
>
> Hi Juergen,
>
>>> * Juergen Gross <[email protected]> wrote:
>>>
>>>> On 15/01/18 15:56, Borislav Petkov wrote:
>>>>> On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
>>>>>> Ingo, with my finding that above boot failure is related to a bug in
>>>>>> openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
>>>>>
>>>>> The box I'm seeing this on has SLES12-SP2 grub:
>>>>>
>>>>> Version : 2.02~beta2-115.9.1
>>>>>
>>>>> Does it have the same bug?
>>>>
>>>> The patch introducing this problem is from 2012. So I guess: yes.
>>>
>>> I suspect this makes it a widespread, unintended ABI. Can we detect
>>> and somehow avoid it?
>>>
>>> The boot protocol ABI sucks if it's fragile against such mistakes.
>>
>> Well, copying sizeof(setup_header) into grub2 and then coyping back just
>> 1024 bytes is plain wrong. It is a miracle nothing broke up to now.
>>
>
> I'm not on SUSE and hit that too on an H11DSi-NT.
> See: https://marc.info/?l=linux-kernel&m=151579540320553&w=2
Where does your grub come from?
Juergen
On 15.01.2018 17:42, Juergen Gross wrote:
> On 15/01/18 17:29, Gabriel C wrote:
>> On 15.01.2018 16:40, Juergen Gross wrote:
>>> On 15/01/18 16:32, Ingo Molnar wrote:
>>>>
>>
>> Hi Juergen,
>>
>>>> * Juergen Gross <[email protected]> wrote:
>>>>
>>>>> On 15/01/18 15:56, Borislav Petkov wrote:
>>>>>> On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
>>>>>>> Ingo, with my finding that above boot failure is related to a bug in
>>>>>>> openSUSE's grub2 (I've verified it soesn't exist in upstream grub2),
>>>>>>
>>>>>> The box I'm seeing this on has SLES12-SP2 grub:
>>>>>>
>>>>>> Version : 2.02~beta2-115.9.1
>>>>>>
>>>>>> Does it have the same bug?
>>>>>
>>>>> The patch introducing this problem is from 2012. So I guess: yes.
>>>>
>>>> I suspect this makes it a widespread, unintended ABI. Can we detect
>>>> and somehow avoid it?
>>>>
>>>> The boot protocol ABI sucks if it's fragile against such mistakes.
>>>
>>> Well, copying sizeof(setup_header) into grub2 and then coyping back just
>>> 1024 bytes is plain wrong. It is a miracle nothing broke up to now.
>>>
>>
>> I'm not on SUSE and hit that too on an H11DSi-NT.
>> See: https://marc.info/?l=linux-kernel&m=151579540320553&w=2
>
> Where does your grub come from?
https://github.com/frugalware/frugalware-current/tree/master/source/base/grub2
On 15/01/18 17:56, Gabriel C wrote:
> On 15.01.2018 17:42, Juergen Gross wrote:
>> On 15/01/18 17:29, Gabriel C wrote:
>>> On 15.01.2018 16:40, Juergen Gross wrote:
>>>> On 15/01/18 16:32, Ingo Molnar wrote:
>>>>>
>>>
>>> Hi Juergen,
>>>
>>>>> * Juergen Gross <[email protected]> wrote:
>>>>>
>>>>>> On 15/01/18 15:56, Borislav Petkov wrote:
>>>>>>> On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
>>>>>>>> Ingo, with my finding that above boot failure is related to a
>>>>>>>> bug in
>>>>>>>> openSUSE's grub2 (I've verified it soesn't exist in upstream
>>>>>>>> grub2),
>>>>>>>
>>>>>>> The box I'm seeing this on has SLES12-SP2 grub:
>>>>>>>
>>>>>>> Version : 2.02~beta2-115.9.1
>>>>>>>
>>>>>>> Does it have the same bug?
>>>>>>
>>>>>> The patch introducing this problem is from 2012. So I guess: yes.
>>>>>
>>>>> I suspect this makes it a widespread, unintended ABI. Can we detect
>>>>> and somehow avoid it?
>>>>>
>>>>> The boot protocol ABI sucks if it's fragile against such mistakes.
>>>>
>>>> Well, copying sizeof(setup_header) into grub2 and then coyping back
>>>> just
>>>> 1024 bytes is plain wrong. It is a miracle nothing broke up to now.
>>>>
>>>
>>> I'm not on SUSE and hit that too on an H11DSi-NT.
>>> See: https://marc.info/?l=linux-kernel&m=151579540320553&w=2
>>
>> Where does your grub come from?
>
> https://github.com/frugalware/frugalware-current/tree/master/source/base/grub2
>
>
>
See line 409 of:
https://github.com/frugalware/frugalware-current/blob/master/source/base/grub2/0019-Add-support-for-linuxefi.patch
There you can see the memcpy with the wrong size back to the to be
booted kernel...
Juergen
On 15.01.2018 18:04, Juergen Gross wrote:
> On 15/01/18 17:56, Gabriel C wrote:
>> On 15.01.2018 17:42, Juergen Gross wrote:
>>> On 15/01/18 17:29, Gabriel C wrote:
>>>> On 15.01.2018 16:40, Juergen Gross wrote:
>>>>> On 15/01/18 16:32, Ingo Molnar wrote:
>>>>>>
>>>>
>>>> Hi Juergen,
>>>>
>>>>>> * Juergen Gross <[email protected]> wrote:
>>>>>>
>>>>>>> On 15/01/18 15:56, Borislav Petkov wrote:
>>>>>>>> On Mon, Jan 15, 2018 at 03:52:25PM +0100, Juergen Gross wrote:
>>>>>>>>> Ingo, with my finding that above boot failure is related to a
>>>>>>>>> bug in
>>>>>>>>> openSUSE's grub2 (I've verified it soesn't exist in upstream
>>>>>>>>> grub2),
>>>>>>>>
>>>>>>>> The box I'm seeing this on has SLES12-SP2 grub:
>>>>>>>>
>>>>>>>> Version : 2.02~beta2-115.9.1
>>>>>>>>
>>>>>>>> Does it have the same bug?
>>>>>>>
>>>>>>> The patch introducing this problem is from 2012. So I guess: yes.
>>>>>>
>>>>>> I suspect this makes it a widespread, unintended ABI. Can we detect
>>>>>> and somehow avoid it?
>>>>>>
>>>>>> The boot protocol ABI sucks if it's fragile against such mistakes.
>>>>>
>>>>> Well, copying sizeof(setup_header) into grub2 and then coyping back
>>>>> just
>>>>> 1024 bytes is plain wrong. It is a miracle nothing broke up to now.
>>>>>
>>>>
>>>> I'm not on SUSE and hit that too on an H11DSi-NT.
>>>> See: https://marc.info/?l=linux-kernel&m=151579540320553&w=2
>>>
>>> Where does your grub come from?
>>
>> https://github.com/frugalware/frugalware-current/tree/master/source/base/grub2
>>
>>
>>
>
> See line 409 of:
>
> https://github.com/frugalware/frugalware-current/blob/master/source/base/grub2/0019-Add-support-for-linuxefi.patch
>
> There you can see the memcpy with the wrong size back to the to be
> booted kernel...
>
I see .. however Fedora have it too , Debian also..
https://src.fedoraproject.org/rpms/grub2/blob/master/f/0083-Add-support-for-linuxefi.patch#_409