Hello Christophe, Il giorno ven, 21/08/2020 alle 16.03 +0200, Christophe Leroy ha scritto: [...] > 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: https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/config-5.9.0-rc1+ https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/System.map https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/VID_20200822_095621.mp4 https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/vmlinux.strip.gz Bye, Giuseppe
