Hello Giuseppe,

Le 22/08/2020 à 10:28, Giuseppe Sacco a écrit :
Hello Christophe,

Il giorno ven, 21/08/2020 alle 16.03 +0200, Christophe Leroy ha

You also said in a previous mail that your original issue also
when CONFIG_VMAP_STACK is not selected. The above bug being linked
CONFIG_VMAP_STACK, maybe it would be easier to bisect with

I was wrong. Disabling CONFIG_VMAP_STACK led me to all "good" compile
and bisect ended without finding the culprit commit.

So, I started from scratch: I rebuilt HEAD and found that it does show
the original problem I am facing, then I rebuilt it without
CONFIG_VMAP_STACK and found that it does pass (fix?) the problem, since
kernel continue booting, but then it stops with three Oops related to
command systemd-udevd.

You may find a video that displays the complete boot, vmlinux, config,
and system.map files here:

The Oopses in the video are fixed in 5.9-rc2, see my response to your other mail.

So now we know that your kernel doesn't boot when CONFIG_VMAP_STACK is set.
Can you remind the exact problem ?

One common problem with CONFIG_VMAP_STACK is when some drivers are invalidly using buffers in stack for DMA.

Couldn't try with CONFIG_DEBUG_VIRTUAL (without CONFIG_VMAP_STACK) and see if it triggers some warnings ?


Reply via email to