Kernel Panics on corebooted systems with linux 4.19 ( >4.9)

[Kinky Nekoboi]

Happend again for other Users/boards

please somebody good investigate this further.

see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930029

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931639

[Felix Held]

Hi!

Since I didn't see that being mentioned in the bug reports: Is this with or without microcode updates being applied in coreboot? If the crashes only happens without those being applied, it's not a coreboot problem.

Maybe we should add a "-no_ucode" or simply a "-tainted" to the bios version reported if no microcode updates are applied in coreboot to make sure that we're not debugging some non-coreboot issue there.
Haven't really looked into it, but might be non-trivial to implement though, since there are quite a few way how to not apply or apply microcode updates and this doesn't depend on just one configuration switch.

Regards
Felix

[Kinky Nekoboi]

Tested it both with microcode and without microcode. It doesent changes
the behaviour.

Am 09.07.19 um 11:43 schrieb Felix Held:
> Hi!
>
> Since I didn't see that being mentioned in the bug reports: Is this
> with or without microcode updates being applied in coreboot? If the
> crashes only happens without those being applied, it's not a coreboot
> problem.
>
> Maybe we should add a "-no_ucode" or simply a "-tainted" to the bios
> version reported if no microcode updates are applied in coreboot to
> make sure that we're not debugging some non-coreboot issue there.
> Haven't really looked into it, but might be non-trivial to implement
> though, since there are quite a few way how to not apply or apply
> microcode updates and this doesn't depend on just one configuration
> switch.
>
> Regards
> Felix

[Felix Held]

Hi!
> Tested it both with microcode and without microcode. It doesent changes
> the behaviour.

Uh, that's indeed not good then. Have you tried if this also happens with older coreboot versions or when running under the vendor firmware?

Regards
Felix

[Enrico Weigelt, metux IT consult]

On 09.07.19 11:52, Kinky Nekoboi wrote:
> Tested it both with microcode and without microcode. It doesent changes
> the behaviour.

Did you also test it w/ recent mainline kernel ?
(w/ CONFIG_DEBUG_SPINLOCK enabled)

(personally, I've long given up walking through Debian's kernel mess,
just use upstream 'make deb-pkg' directly)

This particular bug smells like a kernel bug to be:
> [    0.989765] BUG: unable to handle kernel NULL pointer dereference at

00000000
<snip>
> [    1.104206] Call Trace:
> [    1.106638]  deactivate_slab.isra.71+0x2d2/0x630
> [    1.111232]  ? bootstrap+0x1f/0x12c
> [    1.114693]  ? kmem_cache_alloc+0x1b8/0x1c0
> [    1.118854]  bootstrap+0x66/0x12c
> [    1.122148]  kmem_cache_init+0x8c/0x145
> [    1.125962]  start_kernel+0x2a6/0x52c
> [    1.129602]  secondary_startup_64+0xa4/0xb0
> [    1.133759] Modules linked in:
> [    1.136791] CR2: 0000000000000000
> [    1.140094] ---[ end trace a6e00f6a2ecfb185 ]---
> [    1.144679] RIP: 0010:_raw_spin_lock+0xc/0x20
> [    1.149011] Code: 01 00 00 75 05 48 89 d8 5b c3 e8 1f f7 9a ff eb

f4 66 66 2b

--mtx

[Kinky Nekoboi]

That is a good hint,

i have build several kernels ... but all newer ones arent booting..

i guess i will build another one with CONFIG_DEBUG_SPINLOCK enabled.

I am on vacation right now and have no physical access to the affected
machine right now. Will try it next week.

I would like to know if any one here has an KGPE-D16 running with an
newer linux kernel ( I always thougt this would be the mainboard of 1st
choice for coreboot and it would be much more used)

best regards

the nekoboi

Am 15.07.19 um 13:24 schrieb Enrico Weigelt, metux IT consult:
> On 09.07.19 11:52, Kinky Nekoboi wrote:
> > Tested it both with microcode and without microcode. It doesent changes
> > the behaviour.
>
> Did you also test it w/ recent mainline kernel ?
> (w/ CONFIG_DEBUG_SPINLOCK enabled)
>
> (personally, I've long given up walking through Debian's kernel mess,
> just use upstream 'make deb-pkg' directly)
>
> This particular bug smells like a kernel bug to be:
> > [    0.989765] BUG: unable to handle kernel NULL pointer dereference at
>
> 00000000
>
> <snip>
> > [    1.104206] Call Trace:
> > [    1.106638]  deactivate_slab.isra.71+0x2d2/0x630
> > [    1.111232]  ? bootstrap+0x1f/0x12c
> > [    1.114693]  ? kmem_cache_alloc+0x1b8/0x1c0
> > [    1.118854]  bootstrap+0x66/0x12c
> > [    1.122148]  kmem_cache_init+0x8c/0x145
> > [    1.125962]  start_kernel+0x2a6/0x52c
> > [    1.129602]  secondary_startup_64+0xa4/0xb0
> > [    1.133759] Modules linked in:
> > [    1.136791] CR2: 0000000000000000
> > [    1.140094] ---[ end trace a6e00f6a2ecfb185 ]---
> > [    1.144679] RIP: 0010:_raw_spin_lock+0xc/0x20
> > [    1.149011] Code: 01 00 00 75 05 48 89 d8 5b c3 e8 1f f7 9a ff eb
> f4 66 66 2b
>
> --mtx