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
scritto:
[...]
You also said in a previous mail that your original issue also
happens
when CONFIG_VMAP_STACK is not selected. The above bug being linked
to
CONFIG_VMAP_STACK, maybe it would be easier to bisect with
CONFIG_VMAP_STACK unselected.
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 ?
Thanks
Christophe
