Hello Christophe,

Il giorno ven, 21/08/2020 alle 16.03 +0200, Christophe Leroy ha
> Thanks.
> The Oops in the video shows that the issue is at 0x1bcac and msr
> value 
> shows that Instruction MMU is disabled. So this corresponds to
> address 
> 0xc001bcac. In the vmlinux you sent me this address is in 
> power_save_ppc32_restore()
> This issue is fixed by 
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/7bce32ccbab3ba3e3e0f27da6961bf6313df97ed.1581663140.git.christophe.le...@c-s.fr/
> 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:



Reply via email to