[FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

Christophe Leroy christophe.leroy at csgroup.eu
Thu May 6 18:09:06 AEST 2021


Le 06/05/2021 à 09:56, Christian Zigotzky a écrit :
> Hi Christophe,
> Ok, so let's summarise from my side.
> The issue is in the PowerPC updates 5.13-1. I reverted these and after that the issue is gone.
> We know that only BookE machines are affected. Book3S machines are working with the PowerPC updates.
> I think it’s not directly an Xorg issue. It’s more a symptom that Xorg restarts again and again. In my point of view the changes for BookE machines in the PowerPC updates are responsible for this issue.
> Bisecting costs a lot of time and I don’t have time for my main work anymore.
> Bisecting is good but sometime you have to check your code yourself. We know all facts and now it’s time to check the code because of BookE compatibility.
> @All
> You can test it with QEMU as well. I provide some virtual machines and kernels for testing. Guys, it is really important that you test your changes before you release them.

So, summary from my side:

You popped up telling that commit 887f3ceb51cd was the reason of your problem. As I am the one who 
released that commit, I took a look, and identified that 525642624783 should have fixed it.

You are working with a 64 bits kernel. My domain is 32 bits kernels.

I have no problem at all with corenet64_smp_defconfig booting QEMU with any of the commits you pointed.

On my side QEMU doesn't work at all with the configuration you provided, I don't get any output at 
all on the screen.

So how can we progress ?

I know bisecting is not always easy, and for sure you must have spend a lot of time with all those 
skipped steps. But it provided us good information anyway and I'm sure we could progress quickly if 
you can do the few tests I suggested in my last email:

- Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg working ?
- Can you bisect between 887f3ceb51cd[good] and 56bec2f9d4d0[bad] to identify first bad commit that 
stops after loading the dtb and uImage ?
- Once that first bad commit is identified, can you check whether the preceeding commit with 
cherry-picked 525642624783 has Xorg working or not ?


More information about the Linuxppc-dev mailing list