Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch" [4].  This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes.

After that I created a patch for reverting this commit for new git test kernels. [3]

The kernel compiles and boots with this patch on my AmigaOnes. Please find attached the kernel config files.

Please check the first bad commit.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] http://wiki.amiga.org/index.php?title=X5000
[3] https://forum.hyperion-entertainment.com/viewtopic.php?f=35&t=4377
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=434fb1e7444a2efc3a4ebd950c7f771ebfcffa31
[5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
[6] https://forum.hyperion-entertainment.com/viewtopic.php?p=53074#p53074
[7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3

[AMD Public Use]

+ Gustavo, amd-gfx

-----Original Message-----
From: Christian Zigotzky <redacted>
Sent: Friday, April 30, 2021 8:00 AM
To: gustavoars@kernel.org; Deucher, Alexander 
[off-list ref]
Cc: R.T.Dickinson <redacted>; Darren Stevens <<redacted> 
zone.net>; mad skateman [off-list ref]; linuxppc-dev 
[off-list ref]; Olof Johansson [off-list ref]; 
Maling list - DRI developers [off-list ref]; Michel 
Dänzer [off-list ref]; Christian Zigotzky [off-list ref]
Subject: Radeon NI: GIT kernel with the nislands_smc commit doesn't 
boot on a Freescale P5040 board and P.A.Semi Nemo board

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ 
board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI 
graphics cards (Cayman XT) [3] don't boot with the latest git kernel 
anymore after the commit "drm/radeon/nislands_smc.h: Replace 
one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch" [4].
This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with 
flexible-array member in struct NISLANDS_SMC_SWSTATE branch
(434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I was able to revert this commit [7] and after a new compiling, the 
kernel boots without any problems on my AmigaOnes.

After that I created a patch for reverting this commit for new git test kernels.
[3]

The kernel compiles and boots with this patch on my AmigaOnes. Please 
find attached the kernel config files.

Please check the first bad commit.

Thanks,

51 more quoted lines

On 4/30/21 10:26, Deucher, Alexander wrote:

[AMD Public Use]

+ Gustavo, amd-gfx

quoted

-----Original Message-----
From: Christian Zigotzky <redacted>
Sent: Friday, April 30, 2021 8:00 AM
To: gustavoars@kernel.org; Deucher, Alexander 
[off-list ref]
Cc: R.T.Dickinson <redacted>; Darren Stevens <<redacted> 
zone.net>; mad skateman [off-list ref]; linuxppc-dev 
[off-list ref]; Olof Johansson [off-list ref]; 
Maling list - DRI developers [off-list ref]; Michel 
Dänzer [off-list ref]; Christian Zigotzky [off-list ref]
Subject: Radeon NI: GIT kernel with the nislands_smc commit doesn't 
boot on a Freescale P5040 board and P.A.Semi Nemo board

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ 
board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI 
graphics cards (Cayman XT) [3] don't boot with the latest git kernel 
anymore after the commit "drm/radeon/nislands_smc.h: Replace 
one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch" [4].
This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with 
flexible-array member in struct NISLANDS_SMC_SWSTATE branch
(434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I was able to revert this commit [7] and after a new compiling, the 
kernel boots without any problems on my AmigaOnes.

After that I created a patch for reverting this commit for new git test kernels.
[3]

The kernel compiles and boots with this patch on my AmigaOnes. Please 
find attached the kernel config files.

2 more quoted lines

I'll have a look.

Thanks for the report!
--
Gustavo

quoted

Thanks,
Christian

[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.
wikipedia.org%2Fwiki%2FAmigaOne_X1000&data=04%7C01%7Calexand
er.deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd89
61fe4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnkn
own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PNSrApUdMrku20hH7dEKlJJ
TBi7Qp5JOkqpA4MvKqdE%3D&reserved=0
[2]
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.
a miga.org%2Findex.php%3Ftitle%3DX5000&data=04%7C01%7Calexander
.deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd8961f
e4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnknow
n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
WwiLCJXVCI6Mn0%3D%7C1000&sdata=B8Uvhs25%2FP3RfnL1AgICN3Y4
CEXeCE1yIoi3vvwvGto%3D&reserved=0
[3]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu
m.hyperion-
entertainment.com%2Fviewtopic.php%3Ff%3D35%26t%3D4377&data=
04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08d
90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63755380
8670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TokXplD
Tvg3%2BZMPLCgR1fs%2BN2X9MIfLXLW67MAM2Qsk%3D&reserved=0
[4]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%
2Fcommit%2F%3Fid%3D434fb1e7444a2efc3a4ebd950c7f771ebfcffa31&d
ata=04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346
b08d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375
53808670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JC
M4xvPEnWdckcTPbQ2Ujv%2FAiMMsFMzzl4Pr%2FRPlcMQ%3D&reserve
d=0
[5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage - 

13 more quoted lines

Hello,

Xorg always restarts again and again after the the PowerPC updates 5.13-1 [1] on my FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2]. Xorg doesn't start anymore in a virtual e5500 QEMU machine [3].

I bisected today [4].

Result: powerpc/signal32: Convert do_setcontext[_tm]() to user access block (887f3ceb51cd34109ac17bfc98695162e299e657) [5] is the first bad commit.

Please find attached the kernel config.

Please check the first bad commit.

Thanks,
Christian

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c70a4be130de333ea079c59da41cc959712bb01c
[2] http://wiki.amiga.org/index.php?title=X5000
[3] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=fedora28-2.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=53101#p53101
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=887f3ceb51cd34109ac17bfc98695162e299e657

Le 04/05/2021 à 00:25, Christian Zigotzky a écrit :

Hello,

Xorg always restarts again and again after the the PowerPC updates 5.13-1 [1] on my FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2]. Xorg doesn't start anymore in a virtual e5500 QEMU machine [3].

I bisected today [4].

Result: powerpc/signal32: Convert do_setcontext[_tm]() to user access block (887f3ceb51cd34109ac17bfc98695162e299e657) [5] is the first bad commit.

Please find attached the kernel config.

Please check the first bad commit.

I'm not sure you can conclude anything here. There is a problem in that commit, but it is fixed by 525642624783 ("powerpc/signal32: Fix erroneous SIGSEGV on RT signal return") which is the last commit of powerpc-5.13-1.

So any bisect from there will for sure point to 887f3ceb51cd ("powerpc/signal32: Convert do_setcontext[_tm]() to user access block") but that's unconclusive. If the problem is still there at the HEAD of powerpc-5.13-1, the problem is likely somewhere else.

I think you need to do the bisect again with a cherry-pick of 525642624783 at each step.

Thanks
Christophe

Thanks,
Christian

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c70a4be130de333ea079c59da41cc959712bb01c

[2] http://wiki.amiga.org/index.php?title=X5000
[3] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=fedora28-2.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=53101#p53101
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=887f3ceb51cd34109ac17bfc98695162e299e657

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start
$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn off xtables compat layer

$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

How can I fix this error?

Thanks,
Christian

On 04 May 2021 at 06:56 am, Christophe Leroy wrote:

Le 04/05/2021 à 00:25, Christian Zigotzky a écrit :

quoted

Hello,

Xorg always restarts again and again after the the PowerPC updates 5.13-1 [1] on my FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2]. Xorg doesn't start anymore in a virtual e5500 QEMU machine [3].

I bisected today [4].

Result: powerpc/signal32: Convert do_setcontext[_tm]() to user access block (887f3ceb51cd34109ac17bfc98695162e299e657) [5] is the first bad commit.

Please find attached the kernel config.

Please check the first bad commit.

I'm not sure you can conclude anything here. There is a problem in that commit, but it is fixed by 525642624783 ("powerpc/signal32: Fix erroneous SIGSEGV on RT signal return") which is the last commit of powerpc-5.13-1.

So any bisect from there will for sure point to 887f3ceb51cd ("powerpc/signal32: Convert do_setcontext[_tm]() to user access block") but that's unconclusive. If the problem is still there at the HEAD of powerpc-5.13-1, the problem is likely somewhere else.

I think you need to do the bisect again with a cherry-pick of 525642624783 at each step.

Thanks
Christophe

quoted

Thanks,
Christian

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c70a4be130de333ea079c59da41cc959712bb01c

[2] http://wiki.amiga.org/index.php?title=X5000
[3] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=fedora28-2.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=53101#p53101
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=887f3ceb51cd34109ac17bfc98695162e299e657

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn off xtables compat layer

$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

How can I fix this error?

This problably means that the step is at a commit which is prior to the first bad commit you identified at previous step. If you narrow the bisect as explained above, it shouldn't happen unless git decides it needs to descend a branch to a merge point. In that case just do 'git cherry-pick --abort" and go without the fix.

Note that once you have cherry picked the fix and tested the result, you have to apply the result to HEAD~ (the commit before the cherry-pick).
- git bisect good HEAD~
- git bisect bad HEAD~

Christophe

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

Maybe we should look in the PowerPC updates directly. The CPUs of the AmigaOne X5000 and virtual e5500 QEMU machine belong to BookE cpu family. The AmigaOne X1000 isn't affected by this issue because the PA6T belongs to the Book3S cpu family. [1]

I found this in the PowerPC updates 5.13-1:  - Convert 64-bit BookE to do interrupt entry/exit in C.

Maybe we should look more in the modified BookE files:

arch/powerpc/kernel/head_booke.h [2]
arch/powerpc/kernel/head_fsl_booke.S [3]

Please check the BookE commits in the PowerPC updates 5.13-1. You don't need an AmigaOne X5000 for testing because the virtual e5500 QEMU machine is also affected.

Thanks,
Christian

[1] https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/head_booke.h?id=c70a4be130de333ea079c59da41cc959712bb01c
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/head_fsl_booke.S?id=c70a4be130de333ea079c59da41cc959712bb01c

quoted

Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn off xtables compat layer

$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

How can I fix this error?

This problably means that the step is at a commit which is prior to the first bad commit you identified at previous step. If you narrow the bisect as explained above, it shouldn't happen unless git decides it needs to descend a branch to a merge point. In that case just do 'git cherry-pick --abort" and go without the fix.

Note that once you have cherry picked the fix and tested the result, you have to apply the result to HEAD~ (the commit before the cherry-pick).
- git bisect good HEAD~
- git bisect bad HEAD~

Christophe

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

2 more quoted lines

No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it freezes before any output.

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and mine.

In that case, just use the SHA corresponding to the merge:

7 more quoted lines

You can use my kernels and distributions.

Download Fedora 28 PPC64: http://www.xenosoft.de/fedora28-2.img.tar.gz
Download size: 4.1 GB
MD5 checksum: 1784ca69651531522161498720a89414

Default username and password:
Username: amigaone
Password: amigaone
Root Password: amigaone

You can start the MATE desktop with "startx".

Download MintPPC (Debian Sid) PPC32: http://www.xenosoft.de/MintPPC32-X5000.tar.gz
MD5 checksum: b31c1c1ca1fcf5d4cdf110c4bce11654

The password for both 'root' and 'mintppc' is 'mintppc'.

Download kernel 5.12.0 for the AmigaOne X5000 and for the virtual e5500 QEMU machine without the bad commit: http://www.xenosoft.de/linux-image-5.12-X1000_X5000.tar.gz
Download git kernel for the AmigaOne X5000 and for the virtual e5500 QEMU machine with the bad commit: http://www.xenosoft.de/linux-image-5.13-alpha3-X1000_X5000.tar.gz

QEMU command with KVM on the X5000: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4

QEMU command for Fedora 28 without KVM and with VNC connect: qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=fedora28-2.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1

QEMU command for MintPPC without KVM and with VNC connect: qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and mine.

10 more quoted lines

Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

20 more quoted lines

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision

26 more quoted lines

OK, there is another issue after the second bisecting step. The boot stops after loading the dtb and uImage file. I can't solve 2 issues with bisecting at the same time.

Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:

28 more quoted lines

Xorg restarts again and again.

Here are some interesting error messages:

May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) at 800000 nip ff6a770 lr ff6a760 code 1 in libglib-2.0.so.0.4800.2[feaf000+11f000]
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401 3920ffff 91210054 8061005c 2f830000 419c0014 38800000 4bfc93e5
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920ffff 9121005c 2f8f0000 419e0008 <93ef0000> 418e000c 81210040 913b0000

May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault (11) at 8 nip 92dbc8 lr 92dae8 code 1 in packagekitd[920000+51000]
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 38800080 3be001f4 4cc63182 4802c8ad 4bffff64 60000000 81210018 80be8048
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 7fa6eb78 38800010 807e801c 3be0ffff <80e90008> 4cc63182 4802c881 4bffff38

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:

28 more quoted lines

In that case, you can use 'git bisect skip' to skip the one that is not booting at all.

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and mine.

34 more quoted lines

It doesn't work, it remains stuck.

But I'm probably not in the best situation: I'm on a PC running Windows 7, with Virtualbox running Fedora core 33 and I try to run powerpc QEMU on the fedora core 33. Maybe too many layers to succeed.

Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :

Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

40 more quoted lines

Yes it shows you get a segfault for some reason.
So yes, 887f3ceb51cd3 could have been the reason but 525642624783 fixes it already.

Therefore I think a proper bisect is needed to identify the culprit commit to understand the reason and fix it.

You are running a 32 bits userspace on a 64 bits kernel ?

Am 04.05.21 um 16:48 schrieb Christophe Leroy:

Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

51 more quoted lines

I use 32-bit and 64-bit userlands with 64-bit kernels. Both userlands are affected by the Xorg issue.

Am 04.05.21 um 16:41 schrieb Christophe Leroy:

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

33 more quoted lines

In my point of view 'git bisect skip' isn't a good idea because I will not find out if the skipped commit is good or bad and maybe the first bad commit.

Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :

Am 04.05.21 um 16:41 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

quoted

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

quoted

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

quoted

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

quoted

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

quoted

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

quoted

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

35 more quoted lines

The second problem may be completely unrelated to the first one so it could work.

In any case, if 'git bisect' finds out that the bad commit is in the middle of a skipped area, it will tell you. So I think it is worth it.

The second solution could be to first focus on that 'boot stops after loading problem' and try to find out which commit introduces the bug, then which one fixes it. But it may not be necessary.

Other solution, as you were thinking that the conversion of 'booke' to C interrupt entry/exit, you can also try around that: See if d738ee8 has the problem and 2e2a441 doesn't have the problem.

If so, you can bisect between those two commits (There are 8 commits inbetween).

On 04 May 2021 at 05:17pm, Christophe Leroy wrote:

Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 04:41pm Christophe Leroy wrote:

quoted

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 12:07pm, Christian Zigotzky wrote:

quoted

On 04 May 2021 at 11:49am, Christophe Leroy wrote:

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

OK, there is another issue after the second bisecting step. The boot stops after loading the dtb and uImage file. I can't solve 2 issues with bisecting at the same time.

In that case, you can use 'git bisect skip' to skip the one that is not booting at all.

In my point of view 'git bisect skip' isn't a good idea because I will not find out if the skipped commit is good or bad and maybe the first bad commit.

The second problem may be completely unrelated to the first one so it could work.

In any case, if 'git bisect' finds out that the bad commit is in the middle of a skipped area, it will tell you. So I think it is worth it.

The second solution could be to first focus on that 'boot stops after loading problem' and try to find out which commit introduces the bug, then which one fixes it. But it may not be necessary.

Other solution, as you were thinking that the conversion of 'booke' to C interrupt entry/exit, you can also try around that: See if d738ee8 has the problem and 2e2a441 doesn't have the problem.

If so, you can bisect between those two commits (There are 8 commits inbetween).

Hi Christophe,

I am bisecting with skipping the boot issue currently. Unfortunately it seems there is another bug. I had to skip two times because the kernel didn't compile.

Bisecting log:

1) git bisect start -- arch/powerpc

2) git bisect good 887f3ceb51cd3~

3) git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

4) git bisect bad
5) git bisect skip It stopped after loading the dtb and uImage. Maybe a third bug.
6) git bisect skip It stopped after loading the dtb and uImage.
7) git bisect skip It stopped after loading the dtb and uImage.
8) git bisect skip It stopped after loading the dtb and uImage.
9) git bisect skip It stopped after loading the dtb and uImage. ([472724111f0f72042deb6a9dcee9578e5398a1a1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR)
10) git bisect skip It stopped after loading the dtb and uImage. ([ceff77efa4f8d9f02d8442171b325d3b7068fe5e] powerpc/64e/interrupt: Use new interrupt context tracking scheme)
11) git bisect skip It stopped after loading the dtb and uImage. ([7dcc37b3eff97379b194adb17eb9a8270512dd1d] powerpc/xive: Map one IPI interrupt per node)
12) git bisect skip It stopped after loading the dtb and uImage. ([097157e16cf8bf91b9cf6fbda05d234d3599c01f] powerpc/64e/interrupt: reconcile irq soft-mask state in C)
13) git bisect skip It didn't compile.
Error messages:

arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function `.interrupt_exit_user_prepare':
interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1199: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

([fd6db2892ebaa1383a93b4a609c65b96e615510a] powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler)

14) git bisect skip It stopped after loading the dtb and uImage. ([0c2472de23aea5ce9139a3e887191925759d1259] powerpc/64e/interrupt: use new interrupt return)
15) git bisect skip It stopped after loading the dtb and uImage. ([097157e16cf8bf91b9cf6fbda05d234d3599c01f] powerpc/64e/interrupt: reconcile irq soft-mask state in C)
16) git bisect skip It didn't compile.
Error messages:

arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'

18 more lines

Le 05/05/2021 à 14:43, Christian Zigotzky a écrit :

On 04 May 2021 at 05:17pm, Christophe Leroy wrote:

quoted

Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 04:41pm Christophe Leroy wrote:

quoted

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 12:07pm, Christian Zigotzky wrote:

quoted

On 04 May 2021 at 11:49am, Christophe Leroy wrote:

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

OK, there is another issue after the second bisecting step. The boot stops after loading the dtb and uImage file. I can't solve 2 issues with bisecting at the same time.

In that case, you can use 'git bisect skip' to skip the one that is not booting at all.

In my point of view 'git bisect skip' isn't a good idea because I will not find out if the skipped commit is good or bad and maybe the first bad commit.

The second problem may be completely unrelated to the first one so it could work.

In any case, if 'git bisect' finds out that the bad commit is in the middle of a skipped area, it will tell you. So I think it is worth it.

The second solution could be to first focus on that 'boot stops after loading problem' and try to find out which commit introduces the bug, then which one fixes it. But it may not be necessary.

Other solution, as you were thinking that the conversion of 'booke' to C interrupt entry/exit, you can also try around that: See if d738ee8 has the problem and 2e2a441 doesn't have the problem.

If so, you can bisect between those two commits (There are 8 commits inbetween).

Hi Christophe,

I am bisecting with skipping the boot issue currently. Unfortunately it seems there is another bug. I had to skip two times because the kernel didn't compile.

Should I continue bisecting?

You can find the other steps (21 and higher) here: https://forum.hyperion-entertainment.com/viewtopic.php?p=53103#p53103

Ok, so let's summarise:

887f3ceb51cd = Xorg doesn't work
887f3ceb51cd is the "first bad commit" identified by your first "bisect"
887f3ceb51cd~ = 627b72bee84d works ok
c70a4be130de = Xorg doesn't work

Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg working ?

Can you provide 'git bisect log' ?

It seems there is some mismatch between the commit and the description. For instance, you say fd6db2892eba and 14b3c9d24a7a don't build. I see no reason for that, I agree there is that build failure but with dc6231821a14, 0c2472de23ae, 3db8aa10de9a and 097157e16cf8. That is fixed by ceff77efa4f8. Note that that build failure should not occur if you have CONFIG_CONTEXT_TRACKING, but it is not our problem for the time being.

Anyway, what I learn from your details is:

56bec2f9d4d0 is the first one you tested which stops after loading the dtb and uImage.

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 ?


ceff77efa4f8 is the last one you tested which stops after loading the dtb and uImage.
49c1d07fd04f is bad (Xorg not working)

Can you bisect between ceff77efa4f8[good] and 49c1d07fd04f[bad] to identify first commit that doesn't stop after loading the dtb and uImage ? (Here you have to make a mental exercice:
the ones that stop after loading dtb/uImage are the 'good' and the ones booting OK are the 'bad')

Once you have found out what breaks booting and what makes it work again, then we should be able to progress on the investigation.

Thanks
Christophe

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.

Thanks,
Christian

On 6. May 2021, at 08:13, Christophe Leroy [off-list ref] wrote:



quoted

Le 05/05/2021 à 14:43, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 05:17pm, Christophe Leroy wrote:
Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 04:41pm Christophe Leroy wrote:

quoted

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

quoted

On 04 May 2021 at 12:07pm, Christian Zigotzky wrote:

quoted

On 04 May 2021 at 11:49am, Christophe Leroy wrote:

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

OK, there is another issue after the second bisecting step. The boot stops after loading the dtb and uImage file. I can't solve 2 issues with bisecting at the same time.

In that case, you can use 'git bisect skip' to skip the one that is not booting at all.

In my point of view 'git bisect skip' isn't a good idea because I will not find out if the skipped commit is good or bad and maybe the first bad commit.

The second problem may be completely unrelated to the first one so it could work.

In any case, if 'git bisect' finds out that the bad commit is in the middle of a skipped area, it will tell you. So I think it is worth it.

The second solution could be to first focus on that 'boot stops after loading problem' and try to find out which commit introduces the bug, then which one fixes it. But it may not be necessary.

Other solution, as you were thinking that the conversion of 'booke' to C interrupt entry/exit, you can also try around that: See if d738ee8 has the problem and 2e2a441 doesn't have the problem.

If so, you can bisect between those two commits (There are 8 commits inbetween).

Hi Christophe,
I am bisecting with skipping the boot issue currently. Unfortunately it seems there is another bug. I had to skip two times because the kernel didn't compile.

quoted

Should I continue bisecting?
You can find the other steps (21 and higher) here: https://forum.hyperion-entertainment.com/viewtopic.php?p=53103#p53103

Ok, so let's summarise:

887f3ceb51cd = Xorg doesn't work

29 more quoted lines

Hi,

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 ?

Thanks
Christophe

I have started bisecting again.

Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106

On 6. May 2021, at 10:09, Christophe Leroy [off-list ref] wrote:

Hi,

quoted

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 ?

Thanks
Christophe

Hi Christian,

On 4/30/21 06:59, Christian Zigotzky wrote:

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman
XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in
struct NISLANDS_SMC_SWSTATE branch" [4].  This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch
(434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I have a fix ready for this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?h=testing/drm-nislands

I wonder if you could help me to test it with your environment, please.
It should be applied on top of mainline.

Thank you!
--
Gustavo

I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes.

After that I created a patch for reverting this commit for new git test kernels. [3]

The kernel compiles and boots with this patch on my AmigaOnes. Please find attached the kernel config files.

Please check the first bad commit.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] http://wiki.amiga.org/index.php?title=X5000
[3] https://forum.hyperion-entertainment.com/viewtopic.php?f=35&t=4377
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=434fb1e7444a2efc3a4ebd950c7f771ebfcffa31
[5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device
virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4
-vnc :1
[6] https://forum.hyperion-entertainment.com/viewtopic.php?p=53074#p53074
[7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3

Hi Gustavo,

Great! I will test it. Many thanks for your help.

Cheers,
Christian

On 7. May 2021, at 01:55, Gustavo A. R. Silva [off-list ref] wrote:

Hi Christian,

quoted

On 4/30/21 06:59, Christian Zigotzky wrote:
Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman
XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in
struct NISLANDS_SMC_SWSTATE branch" [4].  This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch
(434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I have a fix ready for this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?h=testing/drm-nislands

I wonder if you could help me to test it with your environment, please.
It should be applied on top of mainline.

Thank you!
--
Gustavo

quoted

I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes.

After that I created a patch for reverting this commit for new git test kernels. [3]

The kernel compiles and boots with this patch on my AmigaOnes. Please find attached the kernel config files.

Please check the first bad commit.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] http://wiki.amiga.org/index.php?title=X5000

7 more quoted lines

Hi Gustavo,

Your patch works! Thanks a lot! I tested it with my Freescale P5040 board and P.A.Semi Nemo board with a connected AMD Radeon HD6970 NI graphics cards (Cayman
XT) today.

Have a nice day,
Christian


On 07 May 2021 at 08:43am, Christian Zigotzky wrote:

Hi Gustavo,

Great! I will test it. Many thanks for your help.

Cheers,
Christian

quoted

On 7. May 2021, at 01:55, Gustavo A. R. Silva [off-list ref] wrote:

Hi Christian,

quoted

On 4/30/21 06:59, Christian Zigotzky wrote:
Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman
XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in
struct NISLANDS_SMC_SWSTATE branch" [4].  This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch
(434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I have a fix ready for this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?h=testing/drm-nislands

I wonder if you could help me to test it with your environment, please.
It should be applied on top of mainline.

Thank you!
--
Gustavo

quoted

I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes.

After that I created a patch for reverting this commit for new git test kernels. [3]

The kernel compiles and boots with this patch on my AmigaOnes. Please find attached the kernel config files.

Please check the first bad commit.

13 more quoted lines

On 06 May 2021 at 03:58 pm, Christian Zigotzky wrote:

I have started bisecting again.

Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106 <https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106>

quoted

On 6. May 2021, at 10:09, Christophe Leroy [off-list ref] wrote:


- Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg working ?

git checkout 887f3ceb51cd
git cherry-pick 525642624783

Result: Xorg works.

quoted

- 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 ?

Thanks
Christophe

git bisect start
git bisect good 887f3ceb51cd
git bisect bad 56bec2f9d4d0
git bisect good -- Xorg restarts again and again but we are looking for the first bad commit that stops the boot after loading the dtb and uImage.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.

Result:

56bec2f9d4d05675cada96772a8a93010f4d82bf is the first bad commit
commit 56bec2f9d4d05675cada96772a8a93010f4d82bf
Author: Michael Ellerman [off-list ref]
Date:   Wed Mar 31 11:38:40 2021 +1100

    powerpc/mm/64s: Add _PAGE_KERNEL_ROX

    In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we
    removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform
    specific PAGE and PMD flags and definitions") and added definitions
    for each MMU family.

    However we missed adding a definition for 64s, which was not really a
    bug because it's currently not used.

    But we'd like to use PAGE_KERNEL_ROX in a future patch so add a
    definition now.

    Signed-off-by: Michael Ellerman [off-list ref]
    Link: https://lore.kernel.org/r/20210331003845.216246-1-mpe@ellerman.id.au

:040000 040000 ff8171830c08e4f99852947a5c3b62e784220a26 85aff144e5219bce4eb6adb2ac32c6459cac22d0 M    arch

---

git cherry-pick 525642624783

Output:

powerpc/signal32: Fix erroneous SIGSEGV on RT signal return

7 more lines

On 08 May 2021 at 06:39pm, Christian Zigotzky wrote:

On 06 May 2021 at 03:58 pm, Christian Zigotzky wrote:

quoted

I have started bisecting again.

Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106 <https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106>

quoted

On 6. May 2021, at 10:09, Christophe Leroy [off-list ref] wrote:


- Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg working ?

git checkout 887f3ceb51cd
git cherry-pick 525642624783

Result: Xorg works.

quoted

quoted

- 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 ?

Thanks
Christophe

git bisect start
git bisect good 887f3ceb51cd
git bisect bad 56bec2f9d4d0
git bisect good -- Xorg restarts again and again but we are looking for the first bad commit that stops the boot after loading the dtb and uImage.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.

Result:

56bec2f9d4d05675cada96772a8a93010f4d82bf is the first bad commit
commit 56bec2f9d4d05675cada96772a8a93010f4d82bf
Author: Michael Ellerman [off-list ref]
Date:   Wed Mar 31 11:38:40 2021 +1100

    powerpc/mm/64s: Add _PAGE_KERNEL_ROX

    In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we
    removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform
    specific PAGE and PMD flags and definitions") and added definitions
    for each MMU family.

26 more quoted lines

Hi All,

I compiled and tested the latest git kernel with the new PowerPC updates 5.13-2 today. Unfortunately the Xorg issue still exists.
If I revert the PowerPC updates 5.13-1 and 5.13-2 then Xorg works without any problems.

Please check the BookE changes in the PowerPC updates 5.13-1 because my Book3S machines aren't affected by this issue.

Thanks,
Christian

Thanks for testing

Le 08/05/2021 à 18:39, Christian Zigotzky a écrit :

On 06 May 2021 at 03:58 pm, Christian Zigotzky wrote:

quoted

I have started bisecting again.

Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106 <https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106>

quoted

On 6. May 2021, at 10:09, Christophe Leroy [off-list ref] wrote:


- Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg working ?

git checkout 887f3ceb51cd
git cherry-pick 525642624783

Good to know. So this confirms your problem is not related to the commit you bisected initially

Result: Xorg works.

quoted

quoted

- 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 ?

Thanks
Christophe

git bisect start
git bisect good 887f3ceb51cd
git bisect bad 56bec2f9d4d0
git bisect good -- Xorg restarts again and again but we are looking for the first bad commit that stops the boot after loading the dtb and uImage.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.

Result:

56bec2f9d4d05675cada96772a8a93010f4d82bf is the first bad commit
commit 56bec2f9d4d05675cada96772a8a93010f4d82bf
Author: Michael Ellerman [off-list ref]
Date:   Wed Mar 31 11:38:40 2021 +1100

     powerpc/mm/64s: Add _PAGE_KERNEL_ROX

Here I'm a bit sceptique. This is a book3s related patch and it's only an additional define no I can't see how it can break the boot on book3e.

I see that's the top of the range I asked you to bisect on, so there is something wrong in the analysis.

Based on the information you gave in https://forum.hyperion-entertainment.com/viewtopic.php?p=53103&sid=c8fc65914bfcba65489240cd5eb7e836#p53103 , I rerun your bisect and established the following log:

git bisect start '--' 'arch/powerpc'
# good: [627b72bee84d6652e0af26617e71ce2b3c18fcd5] powerpc/signal32: Convert restore_[tm]_user_regs() to user access block
git bisect good 627b72bee84d6652e0af26617e71ce2b3c18fcd5
# bad: [c70a4be130de333ea079c59da41cc959712bb01c] Merge tag 'powerpc-5.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
# bad: [49c1d07fd04f54eb588c4a1dfcedc8d22c5ffd50] powerpc/powernv: Enable HAIL (HV AIL) for ISA v3.1 processors
git bisect bad 49c1d07fd04f54eb588c4a1dfcedc8d22c5ffd50
# skip: [01c1b9984a12a379f332c39c4b1fd96e473b93b0] powerpc/rtas-proc: remove unused RMO_READ_BUF_MAX
git bisect skip 01c1b9984a12a379f332c39c4b1fd96e473b93b0
# skip: [107dadb046178173dea18e0a78ff8ea3cc27c213] powerpc/perf: Make symbol 'isa207_pmu_format_attr' static
git bisect skip 107dadb046178173dea18e0a78ff8ea3cc27c213
# skip: [56bec2f9d4d05675cada96772a8a93010f4d82bf] powerpc/mm/64s: Add _PAGE_KERNEL_ROX
git bisect skip 56bec2f9d4d05675cada96772a8a93010f4d82bf
# skip: [2235dea17d56238642121a8085b71d68598534bb] powerpc/pseries/pmem: Make symbol 'drc_pmem_match' static
git bisect skip 2235dea17d56238642121a8085b71d68598534bb
# skip: [2c02e656a29d5f64193eb93da92781bcf0517146] powerpc/64s: Use htab_convert_pte_flags() in hash__mark_rodata_ro()
git bisect skip 2c02e656a29d5f64193eb93da92781bcf0517146
# skip: [472724111f0f72042deb6a9dcee9578e5398a1a1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
git bisect skip 472724111f0f72042deb6a9dcee9578e5398a1a1
# skip: [ceff77efa4f8d9f02d8442171b325d3b7068fe5e] powerpc/64e/interrupt: Use new interrupt context tracking scheme
git bisect skip ceff77efa4f8d9f02d8442171b325d3b7068fe5e
# skip: [7dcc37b3eff97379b194adb17eb9a8270512dd1d] powerpc/xive: Map one IPI interrupt per node
git bisect skip 7dcc37b3eff97379b194adb17eb9a8270512dd1d
# skip: [097157e16cf8bf91b9cf6fbda05d234d3599c01f] powerpc/64e/interrupt: reconcile irq soft-mask state in C
git bisect skip 097157e16cf8bf91b9cf6fbda05d234d3599c01f


Then I looked at the list of commits in the kernel, and identified all the ones marked with ZZ or ZZZ as the ones which are up to now identified as not booting. And 56bec2f9d4d05675cada96772a8a93010f4d82bf is the first commit that you skipped.

Did I do an error in my analysis ?

BAD *   c70a4be130de Merge tag 'powerpc-5.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
|\

179 more lines

Le 09/05/2021 à 14:27, Christian Zigotzky a écrit :

On 08 May 2021 at 06:39pm, Christian Zigotzky wrote:

quoted

On 06 May 2021 at 03:58 pm, Christian Zigotzky wrote:

quoted

I have started bisecting again.

Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106 <https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106>

quoted

On 6. May 2021, at 10:09, Christophe Leroy [off-list ref] wrote:


- Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg working ?

git checkout 887f3ceb51cd
git cherry-pick 525642624783

Result: Xorg works.

quoted

quoted

- 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 ?

Thanks
Christophe

git bisect start
git bisect good 887f3ceb51cd
git bisect bad 56bec2f9d4d0
git bisect good -- Xorg restarts again and again but we are looking for the first bad commit that stops the boot after loading the dtb and uImage.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.

Result:

56bec2f9d4d05675cada96772a8a93010f4d82bf is the first bad commit
commit 56bec2f9d4d05675cada96772a8a93010f4d82bf
Author: Michael Ellerman [off-list ref]
Date:   Wed Mar 31 11:38:40 2021 +1100

    powerpc/mm/64s: Add _PAGE_KERNEL_ROX

    In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we
    removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform
    specific PAGE and PMD flags and definitions") and added definitions

34 more quoted lines

On my side, book3e (corenet64_smp_defconfig) built with GCC 10.1 works well with QEMU 2.11.2

A kernel built with the configuration you provided doesn't boot on QEMU, no output at all, even with kernel v5.12.

What versions of GCC and QEMU are you using ?

Thanks
Christophe

On 09 May 2021 at 07:43 pm, Christophe Leroy wrote:

On my side, book3e (corenet64_smp_defconfig) built with GCC 10.1 works well with QEMU 2.11.2

A kernel built with the configuration you provided doesn't boot on QEMU, no output at all, even with kernel v5.12.

What versions of GCC and QEMU are you using ?

Thanks
Christophe

Hi Christophe,

I use the following QEMU versions (qemu-system-ppc64):

- QEMU 5.0.0 (Debian 1:5.0-5) ELF 32-bit PowerPC with or without KVM on Debian Sid 32-bit userland with some 64-bit kernels [1] [3] [11] [12] [13] [14] [15] [16] [17]
- QEMU 5.2.0 ELF 64-bit x86_64 on Ubuntu 18.04 64-bit [2]
- QEMU 5.2.0 Mach-O 64-bit on macOS Catalina 10.15.7
- QEMU 5.2.0 on Windows Server 2016 [4] [5] [6] [7] [8] [9] [10]

The kernels work really well with my kernel configuration in QEMU (see screenshots [1] - [17]). You can also see the kernel 5.12 in virtual QEMU machines in the screenshots.
I work very often with my kernels in e5500 QEMU machines on Linux, macOS, and Windows.

I build my kernels with the GCC 7.5.0. We are testing very intensive all kernel builds in our test threads [18] [19] [20] and the kernel 5.12 works very well on our AmigaOnes and in virtual
e5500 QEMU machines.

Cheers,
Christian

[1] https://i.pinimg.com/originals/94/a1/56/94a156481ab469dd6cd0eba97bd88855.png
[2] https://i.pinimg.com/originals/93/5a/97/935a9792ca4b76b569eeb40857b2162f.png
[3] https://i.pinimg.com/originals/c5/0d/85/c50d85d7e8f20b4caa1a439faf751964.png
[4] https://i.pinimg.com/originals/cb/1d/12/cb1d12610c197a5e24f4a549c4dc56fe.png
[5] https://i.pinimg.com/originals/46/e0/1a/46e01a5ef174cc65420d760b074e2f23.png
[6] https://i.pinimg.com/originals/15/3c/9c/153c9cba276542528721d313812f232a.png
[7] https://i.pinimg.com/originals/b7/dc/c0/b7dcc0d04d8a7d8e771c888403aa9f6f.png
[8] https://i.pinimg.com/originals/1f/37/0e/1f370e80ec9805c93d3bd30c0c3a6926.png
[9] https://i.pinimg.com/originals/7c/4b/1a/7c4b1a602a0760865a1722ef1608cedf.png
[10] https://i.pinimg.com/originals/c3/89/19/c3891928d359500ab5e7484357b4ab01.png
[11] https://i.pinimg.com/originals/e4/53/00/e4530020d4292b36cd1dd22a20f2ba93.png
[12] https://i.pinimg.com/originals/fa/92/5b/fa925bbe132caf6d7f84bdc4090690c6.png
[13] https://i.pinimg.com/originals/4f/b0/14/4fb01476edd7abe6be1e1203a8e7e152.png
[14] https://i.pinimg.com/originals/f1/23/a4/f123a448743b8039b0b5fba320daee7c.png
[15] https://i.pinimg.com/originals/6e/3b/59/6e3b59fe10276c5644b15622a81f43f1.png
[16] https://i.pinimg.com/originals/f2/a5/e3/f2a5e34e2015381b0cb87cc51232a8bc.png
[17] https://i.pinimg.com/originals/57/d9/83/57d98324cd055b7ae00a87ad5a45a42f.png
[18] https://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4612
[19] https://forum.hyperion-entertainment.com/viewtopic.php?f=35&t=4611
[20] https://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4564

Hi Christian,

On 5/8/21 06:33, Christian Zigotzky wrote:

Hi Gustavo,

Your patch works! Thanks a lot! I tested it with my Freescale P5040 board and P.A.Semi Nemo board with a connected AMD Radeon HD6970 NI graphics cards (Cayman
XT) today.

Awesome! :)

Thank you!
--
Gustavo

Have a nice day,
Christian


On 07 May 2021 at 08:43am, Christian Zigotzky wrote:

quoted

Hi Gustavo,

Great! I will test it. Many thanks for your help.

Cheers,
Christian

quoted

On 7. May 2021, at 01:55, Gustavo A. R. Silva [off-list ref] wrote:

Hi Christian,

quoted

On 4/30/21 06:59, Christian Zigotzky wrote:
Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman
XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in
struct NISLANDS_SMC_SWSTATE branch" [4].  This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch
(434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I have a fix ready for this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?h=testing/drm-nislands

I wonder if you could help me to test it with your environment, please.
It should be applied on top of mainline.

Thank you!
-- 
Gustavo

quoted

I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes.

20 more quoted lines

Hi Christophe,

On 9. May 2021, at 19:37, Christophe Leroy [off-list ref] wrote:

Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is somewhere in the new interrupt code.

ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme

Could you please create a patch for reverting the new interrupt code? I would like to confirm your result.

Thanks for your help,
Christian

BAD *   c70a4be130de Merge tag 'powerpc-5.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
|\
| * 525642624783 powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
| * f9cd5f91a897 powerpc: Avoid clang uninitialized warning in __get_user_size_allowed
| * adb68c38d8d4 powerpc/papr_scm: Mark nvdimm as unarmed if needed during probe
| * ee1bc694fbae powerpc/kvm: Fix build error when PPC_MEM_KEYS/PPC_PSERIES=n
| * 30c400886bad powerpc/kasan: Fix shadow start address with modules
| * fc5590fd56c9 powerpc/kernel/iommu: Use largepool as a last resort when !largealloc
| * 3c0468d4451e powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs
| * ee6b25fa7c03 powerpc/44x: fix spelling mistake in Kconfig "varients" -> "variants"
| * cc7130bf119a powerpc/iommu: Annotate nested lock for lockdep
| * 4be518d83880 powerpc/iommu: Do not immediately panic when failed IOMMU table allocation
| * 7f1fa82d7994 powerpc/iommu: Allocate it_map by vmalloc
| * 0db11461677a selftests/powerpc: remove unneeded semicolon
| * caea7b833d86 powerpc/64s: remove unneeded semicolon
| * f3d03fc748d4 powerpc/eeh: remove unneeded semicolon
| * 290f7d8ce2b1 powerpc/selftests: Add selftest to test concurrent perf/ptrace events
| * c65c64cc7bbd powerpc/selftests/perf-hwbreak: Add testcases for 2nd DAWR
| * c9cb0afb4eaa powerpc/selftests/perf-hwbreak: Coalesce event creation code
| * dae4ff8031b4 powerpc/selftests/ptrace-hwbreak: Add testcases for 2nd DAWR
| * 421a7483878c powerpc/configs: Add IBMVNIC to some 64-bit configs
| * da650ada1009 selftests/powerpc: Add uaccess flush test
| * 8a87a5077143 powerpc/52xx: Fix an invalid ASM expression ('addi' used instead of 'add')
| * 0f197ddce403 powerpc/64s: Fix mm_cpumask memory ordering comment
| * 66d9b7492887 powerpc/perf: Fix the threshold event selection for memory events in power10
| * b4ded42268ee powerpc/perf: Fix sampled instruction type for larx/stcx
| * 0bd3f9e953bd powerpc/legacy_serial: Use early_ioremap()
| * 9ccba66d4d2a powerpc/64: Fix the definition of the fixmap area
| * 389586333c02 powerpc: make ALTIVEC select PPC_FPU
| * 7d9462765707 powerpc/64s: Add FA_DUMP to defconfig
| * d936f8182e1b powerpc/powernv: Fix type of opal_mpipl_query_tag() addr argument
| * 2e341f56a16a powerpc/fadump: Fix sparse warnings
| * 39352430aaa0 powerpc: Move copy_inst_from_kernel_nofault()
| * 41d6cf68b5f6 powerpc: Rename probe_kernel_read_inst()
| * 6449078d5011 powerpc: Make probe_kernel_read_inst() common to PPC32 and PPC64
| * 6ac7897f08e0 powerpc: Remove probe_user_read_inst()
| * ee7c3ec3b4b1 powerpc/ebpf32: Use standard function call for functions within 32M distance
| * e7de0023e123 powerpc/ebpf32: Rework 64 bits shifts to avoid tests and branches
| * d228cc496966 powerpc/ebpf32: Fix comment on BPF_ALU{64} | BPF_LSH | BPF_K

142 more quoted lines

Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

Hi Christophe,

quoted

On 9. May 2021, at 19:37, Christophe Leroy [off-list ref] wrote:

Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is somewhere in the new interrupt code.

I'm not convinced, but let's give it a try.

quoted

ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme

Could you please create a patch for reverting the new interrupt code? I would like to confirm your result.

Please fetch https://github.com/chleroy/linux.git and try the branch for_christian.

This is a revert of approx a dozen of commits around the changes to 64e on top of v5.13-rc1.

If the top of the branch works for you, it would be great if you can find out which one of the reverts fixes the problem for real.

Thanks
Christophe

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:

Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

quoted

Hi Christophe,

quoted

On 9. May 2021, at 19:37, Christophe Leroy [off-list ref] wrote:

Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is somewhere in the new interrupt code.

I'm not convinced, but let's give it a try.

quoted

quoted

ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme

Could you please create a patch for reverting the new interrupt code? I would like to confirm your result.

Please fetch https://github.com/chleroy/linux.git and try the branch for_christian.

This is a revert of approx a dozen of commits around the changes to 64e on top of v5.13-rc1.

If the top of the branch works for you, it would be great if you can find out which one of the reverts fixes the problem for real.

Thanks
Christophe

It's working! Great! I can use the RC1 on my FSL P5040. Thank you! The issue is definitely somewhere in the interrupt code. Please tell me the next steps.

- Christian

Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:

quoted

Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

quoted

Hi Christophe,

quoted

On 9. May 2021, at 19:37, Christophe Leroy [off-list ref] wrote:

Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is somewhere in the new interrupt code.

I'm not convinced, but let's give it a try.

quoted

quoted

ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme

Could you please create a patch for reverting the new interrupt code? I would like to confirm your result.

Please fetch https://github.com/chleroy/linux.git and try the branch for_christian.

This is a revert of approx a dozen of commits around the changes to 64e on top of v5.13-rc1.

If the top of the branch works for you, it would be great if you can find out which one of the reverts fixes the problem for real.

Thanks
Christophe

It's working! Great! I can use the RC1 on my FSL P5040. Thank you! The issue is definitely somewhere in the interrupt code. Please tell me the next steps.

Can you bisect between 5.13-rc1 and the top of the 'for_christian' branch to find the first 'good' commit ?

Take care it is an "up side down" bisect, a 'good' is one that does _not_ work and a 'bad' is a commit that works.

git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616

Christophe

On 13 May 2021 at 5:51pm, Christophe Leroy wrote:

Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :

quoted

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:

quoted

Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

quoted

Hi Christophe,

quoted

On 9. May 2021, at 19:37, Christophe Leroy [off-list ref] wrote:

Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is somewhere in the new interrupt code.

I'm not convinced, but let's give it a try.

quoted

quoted

ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme

Could you please create a patch for reverting the new interrupt code? I would like to confirm your result.

Please fetch https://github.com/chleroy/linux.git and try the branch for_christian.

This is a revert of approx a dozen of commits around the changes to 64e on top of v5.13-rc1.

If the top of the branch works for you, it would be great if you can find out which one of the reverts fixes the problem for real.

Thanks
Christophe

It's working! Great! I can use the RC1 on my FSL P5040. Thank you! The issue is definitely somewhere in the interrupt code. Please tell me the next steps.

Can you bisect between 5.13-rc1 and the top of the 'for_christian' branch to find the first 'good' commit ?

Take care it is an "up side down" bisect, a 'good' is one that does _not_ work and a 'bad' is a commit that works.

git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616

2 more quoted lines

Hi Christophe,

Yes, I can. Shall I use the branch 'for_christian' or the default linux git for bisecting? I have tried it already with the branch 'for_christian' but it doesn't compile.

git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616

Output: [d66b1d1aab0c1caad11eca417f515b86ec0bebe9] Revert "powerpc/64e/interrupt: Use new interrupt context tracking scheme"

Result:

arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function `.interrupt_exit_user_prepare':
interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1191: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

----

Thanks,
Christian

Le 13/05/2021 à 18:35, Christian Zigotzky a écrit :

On 13 May 2021 at 5:51pm, Christophe Leroy wrote:

quoted

Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :

quoted

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:

quoted

Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

quoted

Hi Christophe,

quoted

On 9. May 2021, at 19:37, Christophe Leroy [off-list ref] wrote:

Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is somewhere in the new interrupt code.

I'm not convinced, but let's give it a try.

quoted

quoted

ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme

Could you please create a patch for reverting the new interrupt code? I would like to confirm your result.

Please fetch https://github.com/chleroy/linux.git and try the branch for_christian.

This is a revert of approx a dozen of commits around the changes to 64e on top of v5.13-rc1.

If the top of the branch works for you, it would be great if you can find out which one of the reverts fixes the problem for real.

Thanks
Christophe

It's working! Great! I can use the RC1 on my FSL P5040. Thank you! The issue is definitely somewhere in the interrupt code. Please tell me the next steps.

Can you bisect between 5.13-rc1 and the top of the 'for_christian' branch to find the first 'good' commit ?

Take care it is an "up side down" bisect, a 'good' is one that does _not_ work and a 'bad' is a commit that works.

git bisect start
git bisect bad 1c8f441f1485

22 more quoted lines

Ah yes, I remember this problem.

Can you select CONFIG_VIRT_CPU_ACCOUNTING_GEN in your configuration ?

Otherwise, I can try to fix the branch.

Christophe

On 13 May 2021 at 07:00pm, Christophe Leroy wrote:

Le 13/05/2021 à 18:35, Christian Zigotzky a écrit :

quoted

On 13 May 2021 at 5:51pm, Christophe Leroy wrote:

quoted

Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :

quoted

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:

quoted

Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

quoted

Hi Christophe,

quoted

On 9. May 2021, at 19:37, Christophe Leroy [off-list ref] wrote:

Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is somewhere in the new interrupt code.

I'm not convinced, but let's give it a try.

quoted

quoted

ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme

Could you please create a patch for reverting the new interrupt code? I would like to confirm your result.

Please fetch https://github.com/chleroy/linux.git and try the branch for_christian.

This is a revert of approx a dozen of commits around the changes to 64e on top of v5.13-rc1.

If the top of the branch works for you, it would be great if you can find out which one of the reverts fixes the problem for real.

Thanks
Christophe

It's working! Great! I can use the RC1 on my FSL P5040. Thank you! The issue is definitely somewhere in the interrupt code. Please tell me the next steps.

Can you bisect between 5.13-rc1 and the top of the 'for_christian' branch to find the first 'good' commit ?

Take care it is an "up side down" bisect, a 'good' is one that does _not_ work and a 'bad' is a commit that works.

33 more quoted lines

I selected this. After that it compiles.

1. git bisect good - Xorg restarts again and again
    Output: [f9aa0ac1e9e82b60401ad567bdabc30598325bc1] Revert "powerpc/64e/interrupt: use new interrupt return"
2. git bisect good - Xorg restarts again and again
    Output: [cd6d259a14704741bf0cd1dcadb84c0de22d7f77] Revert "powerpc/64e/interrupt: always save nvgprs on interrupt"
3. git bisect bad - Xorg works
    Output: [9bfa20ef2ae54d3b9088dfbcde4ef97062cf5ef2] Revert "powerpc/interrupt: update common interrupt code for"
4. git bisect good - Xorg restarts again and again
    Output:

cd6d259a14704741bf0cd1dcadb84c0de22d7f77 is the first bad commit
commit cd6d259a14704741bf0cd1dcadb84c0de22d7f77
Author: Christophe Leroy [off-list ref]
Date:   Thu May 13 09:52:06 2021 +0000

    Revert "powerpc/64e/interrupt: always save nvgprs on interrupt"

    This reverts commit 4228b2c3d20e9f80b847f809c38e6cf82864fa50.

:040000 040000 156542c857ad72776b69bb67b2f244afeeb7abd3 92ea86ed097fce16238b0c2f2b343473894e4e8e M    arch

- Christian

Excerpts from Christian Zigotzky's message of May 14, 2021 6:20 am:

On 13 May 2021 at 07:00pm, Christophe Leroy wrote:

quoted

Ah yes, I remember this problem.

Can you select CONFIG_VIRT_CPU_ACCOUNTING_GEN in your configuration ?

Otherwise, I can try to fix the branch.

Christophe

I selected this. After that it compiles.

1. git bisect good - Xorg restarts again and again
     Output: [f9aa0ac1e9e82b60401ad567bdabc30598325bc1] Revert 
"powerpc/64e/interrupt: use new interrupt return"
2. git bisect good - Xorg restarts again and again
     Output: [cd6d259a14704741bf0cd1dcadb84c0de22d7f77] Revert 
"powerpc/64e/interrupt: always save nvgprs on interrupt"
3. git bisect bad - Xorg works
     Output: [9bfa20ef2ae54d3b9088dfbcde4ef97062cf5ef2] Revert 
"powerpc/interrupt: update common interrupt code for"
4. git bisect good - Xorg restarts again and again
     Output:

cd6d259a14704741bf0cd1dcadb84c0de22d7f77 is the first bad commit
commit cd6d259a14704741bf0cd1dcadb84c0de22d7f77
Author: Christophe Leroy [off-list ref]
Date:   Thu May 13 09:52:06 2021 +0000

     Revert "powerpc/64e/interrupt: always save nvgprs on interrupt"

     This reverts commit 4228b2c3d20e9f80b847f809c38e6cf82864fa50.

:040000 040000 156542c857ad72776b69bb67b2f244afeeb7abd3 
92ea86ed097fce16238b0c2f2b343473894e4e8e M    arch

Thank you both very much for chasing this down.

I think I see the problem, it's clobbering r14 and r15 for some 
interrupts. Something like this is required, I'll give it more
review and testing though.

Thanks,
Nick

---

diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 7c3654b0d0f4..b91ef04f1ce2 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S

@@ -535,6 +535,10 @@ __end_interrupts:
 				PROLOG_ADDITION_2REGS)
 	mfspr	r14,SPRN_DEAR
 	mfspr	r15,SPRN_ESR
+	std	r14,_DAR(r1)
+	std	r15,_DSISR(r1)
+	ld	r14,PACA_EXGEN+EX_R14(r13)
+	ld	r15,PACA_EXGEN+EX_R15(r13)
 	EXCEPTION_COMMON(0x300)
 	b	storage_fault_common
 

@@ -544,6 +548,10 @@ __end_interrupts:
 				PROLOG_ADDITION_2REGS)
 	li	r15,0
 	mr	r14,r10
+	std	r14,_DAR(r1)
+	std	r15,_DSISR(r1)
+	ld	r14,PACA_EXGEN+EX_R14(r13)
+	ld	r15,PACA_EXGEN+EX_R15(r13)
 	EXCEPTION_COMMON(0x400)
 	b	storage_fault_common
 

@@ -557,6 +565,10 @@ __end_interrupts:
 				PROLOG_ADDITION_2REGS)
 	mfspr	r14,SPRN_DEAR
 	mfspr	r15,SPRN_ESR
+	std	r14,_DAR(r1)
+	std	r15,_DSISR(r1)
+	ld	r14,PACA_EXGEN+EX_R14(r13)
+	ld	r15,PACA_EXGEN+EX_R15(r13)
 	EXCEPTION_COMMON(0x600)
 	b	alignment_more	/* no room, go out of line */
 

@@ -565,10 +577,10 @@ __end_interrupts:
 	NORMAL_EXCEPTION_PROLOG(0x700, BOOKE_INTERRUPT_PROGRAM,
 				PROLOG_ADDITION_1REG)
 	mfspr	r14,SPRN_ESR
-	EXCEPTION_COMMON(0x700)
 	std	r14,_DSISR(r1)
-	addi	r3,r1,STACK_FRAME_OVERHEAD
 	ld	r14,PACA_EXGEN+EX_R14(r13)
+	EXCEPTION_COMMON(0x700)
+	addi	r3,r1,STACK_FRAME_OVERHEAD
 	bl	program_check_exception
 	REST_NVGPRS(r1)
 	b	interrupt_return

@@ -725,11 +737,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 	 * normal exception
 	 */
 	mfspr	r14,SPRN_DBSR
-	EXCEPTION_COMMON_CRIT(0xd00)
 	std	r14,_DSISR(r1)
-	addi	r3,r1,STACK_FRAME_OVERHEAD
 	ld	r14,PACA_EXCRIT+EX_R14(r13)
 	ld	r15,PACA_EXCRIT+EX_R15(r13)
+	EXCEPTION_COMMON_CRIT(0xd00)
+	addi	r3,r1,STACK_FRAME_OVERHEAD
 	bl	DebugException
 	REST_NVGPRS(r1)
 	b	interrupt_return

@@ -796,11 +808,11 @@ kernel_dbg_exc:
 	 * normal exception
 	 */
 	mfspr	r14,SPRN_DBSR
-	EXCEPTION_COMMON_DBG(0xd08)
 	std	r14,_DSISR(r1)
-	addi	r3,r1,STACK_FRAME_OVERHEAD
 	ld	r14,PACA_EXDBG+EX_R14(r13)
 	ld	r15,PACA_EXDBG+EX_R15(r13)
+	EXCEPTION_COMMON_DBG(0xd08)
+	addi	r3,r1,STACK_FRAME_OVERHEAD
 	bl	DebugException
 	REST_NVGPRS(r1)
 	b	interrupt_return

@@ -931,11 +943,7 @@ masked_interrupt_book3e_0x2c0:
  * original values stashed away in the PACA
  */
 storage_fault_common:
-	std	r14,_DAR(r1)
-	std	r15,_DSISR(r1)
 	addi	r3,r1,STACK_FRAME_OVERHEAD
-	ld	r14,PACA_EXGEN+EX_R14(r13)
-	ld	r15,PACA_EXGEN+EX_R15(r13)
 	bl	do_page_fault
 	b	interrupt_return
 

@@ -944,11 +952,7 @@ storage_fault_common:
  * continues here.
  */
 alignment_more:
-	std	r14,_DAR(r1)
-	std	r15,_DSISR(r1)
 	addi	r3,r1,STACK_FRAME_OVERHEAD
-	ld	r14,PACA_EXGEN+EX_R14(r13)
-	ld	r15,PACA_EXGEN+EX_R15(r13)
 	bl	alignment_exception
 	REST_NVGPRS(r1)
 	b	interrupt_return

On 14 May 2021 at 00:58am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 14, 2021 6:20 am:

quoted

On 13 May 2021 at 07:00pm, Christophe Leroy wrote:

quoted

Ah yes, I remember this problem.

Can you select CONFIG_VIRT_CPU_ACCOUNTING_GEN in your configuration ?

Otherwise, I can try to fix the branch.

Christophe

I selected this. After that it compiles.

1. git bisect good - Xorg restarts again and again
      Output: [f9aa0ac1e9e82b60401ad567bdabc30598325bc1] Revert
"powerpc/64e/interrupt: use new interrupt return"
2. git bisect good - Xorg restarts again and again
      Output: [cd6d259a14704741bf0cd1dcadb84c0de22d7f77] Revert
"powerpc/64e/interrupt: always save nvgprs on interrupt"
3. git bisect bad - Xorg works
      Output: [9bfa20ef2ae54d3b9088dfbcde4ef97062cf5ef2] Revert
"powerpc/interrupt: update common interrupt code for"
4. git bisect good - Xorg restarts again and again
      Output:

cd6d259a14704741bf0cd1dcadb84c0de22d7f77 is the first bad commit
commit cd6d259a14704741bf0cd1dcadb84c0de22d7f77
Author: Christophe Leroy [off-list ref]
Date:   Thu May 13 09:52:06 2021 +0000

      Revert "powerpc/64e/interrupt: always save nvgprs on interrupt"

      This reverts commit 4228b2c3d20e9f80b847f809c38e6cf82864fa50.

:040000 040000 156542c857ad72776b69bb67b2f244afeeb7abd3
92ea86ed097fce16238b0c2f2b343473894e4e8e M    arch

Thank you both very much for chasing this down.

I think I see the problem, it's clobbering r14 and r15 for some
interrupts. Something like this is required, I'll give it more
review and testing though.

108 more quoted lines

Hi Nicholas,

I compiled the RC1 with your patch today and Xorg works without any problems.

Many thanks! It was a long way.

Cheers,
Christian

Hello,

Xorg doesn't start anymore in a virtual e5500 QEMU KVM HV machine [1] with the VirtIO GPU after the DRM updates 'drm-next-2021-11-03' [2] on a Freescale P5040 board (A-EON AmigaOne X5000/40) [3]. (See error messages [4] [5])
I reverted the VirtIO GPU changes from the latest DRM updates [2]. After that, the VirtIO GPU works without any problems. The VirtIO GPU works also before the release of the latest DRM updates [2]. (See screenshot [6])

Could you please check the VirtIO GPU changes in the latest DRM updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-keyboard-pci -device virtio-mouse-pci -smp 3
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56d33754481fe0dc7436dc4ee4fbd44b3039361d
[3] http://wiki.amiga.org/index.php?title=X5000
[4] Error messages in a virtual MintPPC machine (Debian):

Debian GNU/Linux bullseye/sid debian ttyS0

debian login: BUG: Kernel NULL pointer dereference on read at 0x00000018
Faulting instruction address: 0xc00000000075055c
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 0 PID: 2418 Comm: Xorg Not tainted 5.16.0-a2_A-EON_X5000-07264-gff0700f03609-dirty #1
NIP:  c00000000075055c LR: c000000000750550 CTR: c000000000750548
REGS: c00000000ae737f0 TRAP: 0300   Not tainted (5.16.0-a2_A-EON_X5000-07264-gff0700f03609-dirty)
MSR:  0000000090029002 <CE,EE,ME>  CR: 24022288  XER: 00000000
DEAR: 0000000000000018 ESR: 0000000000000000 IRQMASK: 0
GPR00: c0000000001bd678 c00000000ae73a90 c000000001993600 c00000000a077000
GPR04: c00000000ae73c10 0000000000000001 c00000000a098270 c00000000cafc400
GPR08: c0000000017f2f88 0000000000000000 c0000000018e2418 018c3e5000413614
GPR12: 0000000084082282 c000000001a68000 00000000ffaee5a4 0000000000ee613c
GPR16: 0000000000efa53c 0000000000ca5040 000000000000000c 0000000000000000
GPR20: c000000002892598 c00000000a077030 0000000000000000 000000000a077000
GPR24: 000000000af9d300 c00000000af9d300 0000000000000000 c00000000a077000
GPR28: c00000000a448280 c000000002892580 c00000000a098260 c00000000a5aa400
NIP [c00000000075055c] .virtio_gpu_poll+0x14/0x134
LR [c000000000750550] .virtio_gpu_poll+0x8/0x134
Call Trace:

6 more lines

--- interrupt: c00 at 0x33c634

NIP:  000000000033c634 LR: 0000000000e11ea8 CTR: 0000000000000000
REGS: c00000000ae73e80 TRAP: 0c00   Not tainted (5.16.0-a2_A-EON_X5000-07264-gff0700f03609-dirty)
MSR:  000000001002d002 <CE,EE,PR,ME>  CR: 46000224  XER: 00000000
IRQMASK: 0
GPR00: 00000000000000ed 00000000ffaee3d0 00000000f7aa8340 0000000000000003
GPR04: 0000000000000001 000000000000000c 00000000ffaee3e8 00000000018c3e48
GPR08: 0000000000000011 0000000000000000 0000000000000000 0000000000000000
GPR12: 0000000000000000 0000000000edfff4 00000000ffaee5a4 0000000000ee613c
GPR16: 0000000000efa53c 0000000000ca5040 0000000000000000 0000000000c97330
GPR20: 0000000000c9b800 00000000fffffffc 0000000000000003 0000000001641fb0
GPR24: 000000000174f270 0000000000e0c800 0000000000000001 000000000000000c
GPR28: 0000000001642220 00000000018c3e50 0000000000ee7628 0000000000000003
NIP [000000000033c634] 0x33c634
LR [0000000000e11ea8] 0xe11ea8

--- interrupt: c00

Instruction dump:
48000ad9 60000000 7fe3fb78 4befb0f5 60000000 38210080 485fbc44 7c0802a6
485fbbcd f821ff71 ebe300c0 e93f0088 <e9290018> 2fa90000 40de001c 4bef71fd
---[ end trace 24595e2ea6e47c05 ]---

[5] Error messages in a virtual Void PPC machine:

=> Initialization complete, running stage 2...
- runit: leave stage: /etc/runit/1
- runit: enter stage: /etc/runit/2
runsvchdir: default: current.
urandom_read: 1 callbacks suppressed
random: dbus-daemon: uninitialized urandom read (12 bytes read)
udevd[2362]: starting version 3.2.10
udevd[2362]: starting eudev-3.2.10
elogind-daemon[2441]: New seat seat0.
elogind-daemon[2441]: Watching system buttons on /dev/input/event1 (QEMU Virtio Keyboard)
BUG: Kernel NULL pointer dereference on read at 0x00000018
Faulting instruction address: 0xc00000000075055c
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 0 PID: 2443 Comm: Xorg Not tainted 5.16.0-a2_A-EON_X5000-07264-gff0700f03609-dirty #1
NIP:  c00000000075055c LR: c000000000750550 CTR: c000000000750548
REGS: c00000000a7ab7f0 TRAP: 0300   Not tainted (5.16.0-a2_A-EON_X5000-07264-gff0700f03609-dirty)
MSR:  0000000090029002 <CE,EE,ME>  CR: 24022288  XER: 00000000
DEAR: 0000000000000018 ESR: 0000000000000000 IRQMASK: 0
GPR00: c0000000001bd678 c00000000a7aba90 c000000001993600 c0000000028da400
GPR04: c00000000a7abc10 0000000000000001 c000000009a55800 c0000000028c2900
GPR08: c0000000017f2f88 0000000000000000 c0000000018e2418 00e8bdf0003205d4
GPR12: 0000000084082282 c000000001a68000 0000000000a53230 0000000000000000
GPR16: 0000000000000001 00000000009435d4 000000000000000b 0000000000000000
GPR20: c00000000a98cc98 c0000000028da430 0000000000000000 00000000028da400
GPR24: 000000000a036600 c00000000a036600 0000000000000000 c0000000028da400
GPR28: c000000009a55800 c00000000a98cc80 c00000000a02a210 c000000009b0b200
NIP [c00000000075055c] .virtio_gpu_poll+0x14/0x134
LR [c000000000750550] .virtio_gpu_poll+0x8/0x134
Call Trace:
[c00000000a7aba90] [c00000000a7abb10] 0xc00000000a7abb10 (unreliable)
[c00000000a7abb20] [c0000000001bd678] .ep_item_poll+0x5c/0x80

19 more lines

--- interrupt: c00

Instruction dump:
48000ad9 60000000 7fe3fb78 4befb0f5 60000000 38210080 485fbc44 7c0802a6
485fbbcd f821ff71 ebe300c0 e93f0088 <e9290018> 2fa90000 40de001c 4bef71fd
---[ end trace ece66d7be00861fa ]---

[6] https://i.ibb.co/SwjTyJk/Kernel-5-16-alpha1-Power-PC.png

Hi Christophe,

The Cyrus+ board with FSL P50x0 SoC [1] doesn't boot with the PowerPC updates 5.16-1 [2].

I was able to revert the new PowerPC updates 5.16-1 [2]. After a new compiling, the kernel boots without any problems on the Cyrus+ board.

I bisected today [3]. 52bda69ae8b5102fe08c9db10f4a1514478e07d3 (powerpc/fsl_booke: Tell map_mem_in_cams() if init is done) [4] is the first bad commit.

I was able to revert the first bad commit [3]. I had to revert the commit d5970045cf9e266d9a43941ac0866865fd22a36a additionally because of a compiling error. After a new compiling, the kernel boots without any problems.

I created a patch for an easy reverting the bad commit (including the other dependent commit) [3]. With this patch we can do further our kernel tests.

Could you please check the first bad commit [4]?

Please find attached the kernel config.

Thanks,
Christian

[1] http://wiki.amiga.org/index.php?title=X5000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c0b0c676ac2d84f69568715af91e45b610fe17a
[3] https://forum.hyperion-entertainment.com/viewtopic.php?p=54387#p54387
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=52bda69ae8b5102fe08c9db10f4a1514478e07d3

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

+ Olof Johansson
+ linux-pci@vger.kernel.org

Le 08/11/2021 à 15:48, Christian Zigotzky a écrit :

Hi Christophe,

The Cyrus+ board with FSL P50x0 SoC [1] doesn't boot with the PowerPC updates 5.16-1 [2].

I was able to revert the new PowerPC updates 5.16-1 [2]. After a new compiling, the kernel boots without any problems on the Cyrus+ board.

I bisected today [3]. 52bda69ae8b5102fe08c9db10f4a1514478e07d3 (powerpc/fsl_booke: Tell map_mem_in_cams() if init is done) [4] is the first bad commit.

Yes, the bad commit is obviously ... bad.

That commit should have just added an additional argument set to 'true' while not changing anything else.

Apparently it went wrong in mm/nohash/tlb.c

I will send a fixup early next week as I'm AFK at the moment.


Christophe

On Tue, Nov 09, 2021 at 04:10:14PM +0100, Christian Zigotzky wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new compiling,

the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Sorry for the breakage, and thank you very much for the report.  Can
you please collect the complete dmesg logs before and after the
pci-v5.16 changes and the "sudo lspci -vv" output from before the
changes?

You can attach them at https://bugzilla.kernel.org if you don't have
a better place to put them.

You could attach the kernel config there, too, since it didn't make it
to the mailing list (vger may discard them -- see
http://vger.kernel.org/majordomo-info.html).

Bjorn

[+CC Adding Jens and Damien to get their opinion about the problem at hand]

Hello Jens and Damien,

Sorry to bother both of you, but we are having a problem that most
definitely requires someone with an extensive expertise in storage,
as per the quoted message from Christian below:

quoted

quoted

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16
updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

The error message is also not very detailed and we aren't really sure what
the issue coming from the PCI sub-system might be causing or leading to
this.

quoted

quoted

I was able to revert the new pci-v5.16 updates [2]. After a new compiling,
the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Sorry for the breakage, and thank you very much for the report.  Can
you please collect the complete dmesg logs before and after the
pci-v5.16 changes and the "sudo lspci -vv" output from before the
changes?

You can attach them at https://bugzilla.kernel.org if you don't have
a better place to put them.

You could attach the kernel config there, too, since it didn't make it
to the mailing list (vger may discard them -- see
http://vger.kernel.org/majordomo-info.html).

Bjorn and I looked at which commits that went with a recent Pull Request
from us might be causing this, but we are a little bit at loss, and were
hoping that you could give us a hand in troubleshooting this.

Thank you in advance!

	Krzysztof

On Tue, Nov 9, 2021 at 11:40 PM Krzysztof Wilczyński [off-list ref] wrote:

quoted

You could attach the kernel config there, too, since it didn't make it
to the mailing list (vger may discard them -- see
http://vger.kernel.org/majordomo-info.html).

Bjorn and I looked at which commits that went with a recent Pull Request
from us might be causing this, but we are a little bit at loss, and were
hoping that you could give us a hand in troubleshooting this.

For reference, these are the patches in that branch that touch any
interesting files,
as most of the contents are for pci-controller drivers that are not used on
powerpc at all:

$ git log --no-merges --oneline 512b7931ad05..dda4b381f05d
arch/powerpc/ drivers/of/  drivers/pci/*.[ch]  include/linux/
acd61ffb2f16 PCI: Add ACS quirk for Pericom PI7C9X2G switches
978fd0056e19 PCI: of: Allow matching of an interrupt-map local to a PCI device
041284181226 of/irq: Allow matching of an interrupt-map local to an
interrupt controller
0ab8d0f6ae3f irqdomain: Make of_phandle_args_to_fwspec() generally available
5ec0a6fcb60e PCI: Do not enable AtomicOps on VFs
7a41ae80bdcb PCI: pci-bridge-emul: Fix emulation of W1C bits
fd1ae23b495b PCI: Prefer 'unsigned int' over bare 'unsigned'
ff5d3bb6e16d PCI: Remove redundant 'rc' initialization
3331325c6347 PCI/VPD: Use pci_read_vpd_any() in pci_vpd_size()
e1b0d0bb2032 PCI: Re-enable Downstream Port LTR after reset or hotplug
ac8e3cef588c PCI/sysfs: Explicitly show first MSI IRQ for 'irq'
88dee3b0efe4 PCI: Remove unused pci_pool wrappers
b5f9c644eb1b PCI: Remove struct pci_dev->driver
2a4d9408c9e8 PCI: Use to_pci_driver() instead of pci_dev->driver
4141127c44a9 powerpc/eeh: Use to_pci_driver() instead of pci_dev->driver
f9a6c8ad4922 PCI/ERR: Reduce compile time for CONFIG_PCIEAER=n
43e85554d4ed xen/pcifront: Use to_pci_driver() instead of pci_dev->driver
34ab316d7287 xen/pcifront: Drop pcifront_common_process() tests of pcidev, pdrv
9f37ab0412eb PCI/switchtec: Add check of event support
5a72431ec318 powerpc/eeh: Use dev_driver_string() instead of struct
pci_dev->driver->name
ae232f0970ea PCI: Drop pci_device_probe() test of !pci_dev->driver
097d9d414433 PCI: Drop pci_device_remove() test of pci_dev->driver
8e9028b3790d PCI: Return NULL for to_pci_driver(NULL)
357df2fc0066 PCI: Use unsigned to match sscanf("%x") in pci_dev_str_match_path()
bf2928c7a284 PCI/VPD: Add pci_read/write_vpd_any()
b2105b9f39b5 PCI: Correct misspelled and remove duplicated words
7c3855c423b1 PCI: Coalesce host bridge contiguous apertures
e0f7b1922358 PCI: Use kstrtobool() directly, sans strtobool() wrapper
36f354ec7bf9 PCI/sysfs: Return -EINVAL consistently from "store" functions
95e83e219d68 PCI/sysfs: Check CAP_SYS_ADMIN before parsing user input

17 more lines

[+CC Adding Robert for visibility]

Hi Arnd,

Thank you looking at this!  Much appreciated.

quoted

quoted

You could attach the kernel config there, too, since it didn't make it
to the mailing list (vger may discard them -- see
http://vger.kernel.org/majordomo-info.html).

Bjorn and I looked at which commits that went with a recent Pull Request
from us might be causing this, but we are a little bit at loss, and were
hoping that you could give us a hand in troubleshooting this.

For reference, these are the patches in that branch that touch any
interesting files,
as most of the contents are for pci-controller drivers that are not used on
powerpc at all:

$ git log --no-merges --oneline 512b7931ad05..dda4b381f05d
arch/powerpc/ drivers/of/  drivers/pci/*.[ch]  include/linux/
acd61ffb2f16 PCI: Add ACS quirk for Pericom PI7C9X2G switches
978fd0056e19 PCI: of: Allow matching of an interrupt-map local to a PCI device
041284181226 of/irq: Allow matching of an interrupt-map local to an
interrupt controller
0ab8d0f6ae3f irqdomain: Make of_phandle_args_to_fwspec() generally available
5ec0a6fcb60e PCI: Do not enable AtomicOps on VFs
7a41ae80bdcb PCI: pci-bridge-emul: Fix emulation of W1C bits
fd1ae23b495b PCI: Prefer 'unsigned int' over bare 'unsigned'
ff5d3bb6e16d PCI: Remove redundant 'rc' initialization
3331325c6347 PCI/VPD: Use pci_read_vpd_any() in pci_vpd_size()
e1b0d0bb2032 PCI: Re-enable Downstream Port LTR after reset or hotplug
ac8e3cef588c PCI/sysfs: Explicitly show first MSI IRQ for 'irq'
88dee3b0efe4 PCI: Remove unused pci_pool wrappers
b5f9c644eb1b PCI: Remove struct pci_dev->driver
2a4d9408c9e8 PCI: Use to_pci_driver() instead of pci_dev->driver
4141127c44a9 powerpc/eeh: Use to_pci_driver() instead of pci_dev->driver
f9a6c8ad4922 PCI/ERR: Reduce compile time for CONFIG_PCIEAER=n
43e85554d4ed xen/pcifront: Use to_pci_driver() instead of pci_dev->driver
34ab316d7287 xen/pcifront: Drop pcifront_common_process() tests of pcidev, pdrv
9f37ab0412eb PCI/switchtec: Add check of event support
5a72431ec318 powerpc/eeh: Use dev_driver_string() instead of struct
pci_dev->driver->name
ae232f0970ea PCI: Drop pci_device_probe() test of !pci_dev->driver
097d9d414433 PCI: Drop pci_device_remove() test of pci_dev->driver
8e9028b3790d PCI: Return NULL for to_pci_driver(NULL)

22 more quoted lines

Robert would you be able build a kernel without the patches Arnd singled
out as potential curlprits?  Might be expidite some troubleshooting saving
a lot of time doing bisect.

I wonder if this will help you with the following problem:
  https://lore.kernel.org/linux-pci/CAP145pjO9zdGgutHP=of0H+L1=nSz097zf73i7ZYm2-NWuwHhQ@mail.gmail.com/

	Krzysztof

On 2021/11/10 7:40, Krzysztof Wilczyński wrote:

[+CC Adding Jens and Damien to get their opinion about the problem at hand]

Hello Jens and Damien,

Sorry to bother both of you, but we are having a problem that most
definitely requires someone with an extensive expertise in storage,
as per the quoted message from Christian below:

quoted

quoted

quoted

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16
updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

IDENTIFY is the first command sent to a device when it is being probed. This
means that at least the AHCI (is it AHCI ?) adapter found the ports and drives
connected. But the qc timeout indicates that there is no response from the
drive. This could be due to interrupts not being received for the command
completion. One thing to try would be to increase the identify command timeout
to see things simply got slow (for whatever reason) or if indeed there is no
response at all. Note that after the first timeout, normally the port is reset
and the command retried. That does not seem to be the case here. Weird...

Maybe try something like this:

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 1d4a6f1e88cd..16e105bcb899 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c

@@ -79,7 +79,7 @@ enum {
  * take an exceptionally long time to recover from reset.
  */
 static const unsigned long ata_eh_reset_timeouts[] = {
-       10000,  /* most drives spin up by 10sec */
+       30000,  /* most drives spin up by 10sec */
        10000,  /* > 99% working drives spin up before 20sec */
        35000,  /* give > 30 secs of idleness for outlier devices */
         5000,  /* and sweet one last chance */

Also note that I posted a patch a couple of days ago fixing a qc timeout for
read log commands during device probe. This is not what you are hitting here
though. I have not yet sent this to Linus.

https://lore.kernel.org/linux-ide/20211105073106.422623-1-damien.lemoal@opensource.wdc.com/

The error message is also not very detailed and we aren't really sure what
the issue coming from the PCI sub-system might be causing or leading to
this.

quoted

quoted

quoted

I was able to revert the new pci-v5.16 updates [2]. After a new compiling,
the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Sorry for the breakage, and thank you very much for the report.  Can
you please collect the complete dmesg logs before and after the
pci-v5.16 changes and the "sudo lspci -vv" output from before the
changes?

You can attach them at https://bugzilla.kernel.org if you don't have
a better place to put them.

You could attach the kernel config there, too, since it didn't make it
to the mailing list (vger may discard them -- see
http://vger.kernel.org/majordomo-info.html).

Bjorn and I looked at which commits that went with a recent Pull Request
from us might be causing this, but we are a little bit at loss, and were
hoping that you could give us a hand in troubleshooting this.

Thank you in advance!

	Krzysztof

-- 
Damien Le Moal
Western Digital Research

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq: Allow matching of an interrupt-map local to an interrupt controller) [2] is the first bad commit.

I was able to revert the first bad commit [1]. After a new compiling, the kernel detects all ATA disks without any problems.

I created a patch for an easy reverting the bad commit [1]. With this patch we can do further our kernel tests.

Could you please check the first bad commit [2]?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54398#p54398
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0412841812265734c306ba5ef8088bcb64d5d3bd

[+ Marc Zyngier, Alyssa Rosenzweig, Lorenzo Pieralisi, and Rob Herring because of the first bad commit]

On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.

I was able to revert the first bad commit [1]. After a new compiling, the
kernel detects all ATA disks without any problems.

I created a patch for an easy reverting the bad commit [1]. With this patch

12 more quoted lines

Thank you very much for the bisection and for also testing the revert!

It's easy enough to revert 041284181226 ("of/irq: Allow matching of an
interrupt-map local to an interrupt controller"), and it seems like
that's what we need to do.  I have it tentatively queued up.

That commit was part of the new support for the Apple M1 PCIe
interface, and I don't know what effect a revert will have on that
support.  Marc, Alyssa?

Bjorn

HI all,

On Wed, 10 Nov 2021 18:41:06 +0000,
Bjorn Helgaas [off-list ref] wrote:

On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.

I was able to revert the first bad commit [1]. After a new compiling, the
kernel detects all ATA disks without any problems.

24 more quoted lines

It is going to badly break the M1 support, as we won't be able to take
interrupts to detect that the PCIe link is up.

Before we apply a full blown revert and decide that this isn't
workable (and revert the whole M1 PCIe series, because they are
otherwise somewhat pointless), I'd like to understand *what* breaks
exactly.

Christian, could you point me to the full DT that this machine uses?
This would help understanding what goes wrong, and cook something for
you to test.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

[+CC Adding Robert for visibility]

Hi Arnd,

Thank you looking at this!  Much appreciated.

quoted

quoted

quoted

You could attach the kernel config there, too, since it didn't make it
to the mailing list (vger may discard them -- see
http://vger.kernel.org/majordomo-info.html).

Bjorn and I looked at which commits that went with a recent Pull Request
from us might be causing this, but we are a little bit at loss, and were
hoping that you could give us a hand in troubleshooting this.

For reference, these are the patches in that branch that touch any
interesting files,
as most of the contents are for pci-controller drivers that are not used on
powerpc at all:

$ git log --no-merges --oneline 512b7931ad05..dda4b381f05d
arch/powerpc/ drivers/of/  drivers/pci/*.[ch]  include/linux/
acd61ffb2f16 PCI: Add ACS quirk for Pericom PI7C9X2G switches
978fd0056e19 PCI: of: Allow matching of an interrupt-map local to a PCI device
041284181226 of/irq: Allow matching of an interrupt-map local to an
interrupt controller
0ab8d0f6ae3f irqdomain: Make of_phandle_args_to_fwspec() generally available
5ec0a6fcb60e PCI: Do not enable AtomicOps on VFs
7a41ae80bdcb PCI: pci-bridge-emul: Fix emulation of W1C bits
fd1ae23b495b PCI: Prefer 'unsigned int' over bare 'unsigned'
ff5d3bb6e16d PCI: Remove redundant 'rc' initialization
3331325c6347 PCI/VPD: Use pci_read_vpd_any() in pci_vpd_size()
e1b0d0bb2032 PCI: Re-enable Downstream Port LTR after reset or hotplug
ac8e3cef588c PCI/sysfs: Explicitly show first MSI IRQ for 'irq'
88dee3b0efe4 PCI: Remove unused pci_pool wrappers
b5f9c644eb1b PCI: Remove struct pci_dev->driver
2a4d9408c9e8 PCI: Use to_pci_driver() instead of pci_dev->driver
4141127c44a9 powerpc/eeh: Use to_pci_driver() instead of pci_dev->driver
f9a6c8ad4922 PCI/ERR: Reduce compile time for CONFIG_PCIEAER=n
43e85554d4ed xen/pcifront: Use to_pci_driver() instead of pci_dev->driver
34ab316d7287 xen/pcifront: Drop pcifront_common_process() tests of pcidev, pdrv

35 more quoted lines

Thanks.

I tried removing all of those (latest 5), and I had Windows/qemu boot
hangs with all of them removed.

But I cannot say for sure, because I did quite a mess with my
kernel/qemu setup, but with this code
https://github.com/torvalds/linux/commit/cb690f5238d71f543f4ce874aa59237cf53a877c
and with patch https://lkml.org/lkml/2021/11/9/836 my qemu/Win11 seems
to be booting again (even if dmesg is filled with pci-related errors
around initialization timeouts)

I think I'll try to concentrate on helping with the pic code in this
thread: https://lkml.org/lkml/2021/11/10/684 - and once it works well
with the host kernel, I'll try to figure out whether anything still
troubles the vfio/kvm code.

PS: I assumed you asked me to test it wrt my troubles with qemu/vfio/kvm/Win11.

On 10 November 2021 at 08:09 pm, Marc Zyngier wrote:

HI all,

On Wed, 10 Nov 2021 18:41:06 +0000,
Bjorn Helgaas [off-list ref] wrote:

quoted

On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.

I was able to revert the first bad commit [1]. After a new compiling, the
kernel detects all ATA disks without any problems.

39 more quoted lines

Hello Marc,

Here you are: https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

We are very happy to have the patch for reverting the bad commit because we want to test the new PASEMI i2c driver with support for the Apple M1 [1] on our Nemo boards.

Thanks for your help,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54086#p54086

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

On 10 November 2021 at 08:09 pm, Marc Zyngier wrote:

quoted

HI all,

On Wed, 10 Nov 2021 18:41:06 +0000,
Bjorn Helgaas [off-list ref] wrote:

quoted

On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.

45 more quoted lines

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.

We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 10 November 2021 at 08:09 pm, Marc Zyngier wrote:

quoted

HI all,

On Wed, 10 Nov 2021 18:41:06 +0000,
Bjorn Helgaas [off-list ref] wrote:

quoted

On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.

63 more quoted lines

I added a download link for the fdt file to the post [1]. Please read also Darren's comments in this post.

Thanks

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

On Thu, 11 Nov 2021 07:47:08 +0000,
Christian Zigotzky [off-list ref] wrote:

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.

quoted

We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

	M.

I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.

Thanks for that. The DT looks absolutely bonkers, no wonder that
things break with something like that.

But Darren's comments made me jump a bit, and I quote them here for
everyone to see:

<quote>
[...]

The dtb passed by the CFE firmware has a number of issues, which up till
now have been fixed by use of patches applied to the mainline kernel.
This occasionally causes problems with changes made to mainline.

[...]
</quote>

Am I right in understanding that the upstream kernel does not support
the machine out of the box, and that you actually have to apply out of
tree patches to make it work? That these patches have to do with the
IRQ routing?

If so, I wonder why upstream should revert a patch to work on a system
that isn't supported upstream the first place. I will still try and
come up with a solution for you. But asking for the revert of a patch
on these grounds is not, IMHO, acceptable. Also, please provide these
patches on the list so that I can help you to some extend (and I mean
*on the list*, not on a random forum that collects my information).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

On 11 November 2021 at 11:20 am, Marc Zyngier wrote:

On Thu, 11 Nov 2021 07:47:08 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.

quoted

We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

	M.

I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.

Am I right in understanding that the upstream kernel does not support
the machine out of the box, and that you actually have to apply out of
tree patches to make it work?

No, you aren't right. The upstream kernel supports the Nemo board out of the box. [1]

- Christian

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Darren+Stevens

On Thu, 11 Nov 2021 10:44:30 +0000,
Christian Zigotzky [off-list ref] wrote:

On 11 November 2021 at 11:20 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 07:47:08 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.

quoted

We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

	M.

I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.

Am I right in understanding that the upstream kernel does not support
the machine out of the box, and that you actually have to apply out of
tree patches to make it work?

No, you aren't right. The upstream kernel supports the Nemo board out
of the box. [1]

That's not the way I interpret Darren's comments, but you surely know
better than I do.

I'll try to come up with something for you to test shortly.

	M.

-- 
Without deviation from the norm, progress is not possible.

On 11 November 2021 at 12:24 pm, Marc Zyngier wrote:

On Thu, 11 Nov 2021 10:44:30 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 11:20 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 07:47:08 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.

quoted

We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

	M.

I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.

Am I right in understanding that the upstream kernel does not support
the machine out of the box, and that you actually have to apply out of
tree patches to make it work?

No, you aren't right. The upstream kernel supports the Nemo board out
of the box. [1]

That's not the way I interpret Darren's comments, but you surely know
better than I do.

I'll try to come up with something for you to test shortly.

3 more quoted lines

Great! Thanks a lot for your help!

- Christian

On Wed, 10 Nov 2021 18:07:24 +0000,
Christian Zigotzky [off-list ref] wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

	M.

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c

@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
 
 	/* Now start the actual "proper" walk of the interrupt tree */
 	while (ipar != NULL) {
+		bool intc = of_property_read_bool(ipar, "interrupt-controller");
+
 		/*
 		 * Now check if cursor is an interrupt-controller and
 		 * if it is then we are done, unless there is an
 		 * interrupt-map which takes precedence.
 		 */
 		imap = of_get_property(ipar, "interrupt-map", &imaplen);
-		if (imap == NULL &&
-		    of_property_read_bool(ipar, "interrupt-controller")) {
+		if (imap == NULL && intc) {
 			pr_debug(" -> got it !\n");
 			return 0;
 		}

@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
 
 			pr_debug(" -> imaplen=%d\n", imaplen);
 		}
-		if (!match)
+		if (!match) {
+			if (intc) {
+				pr_info("%pOF interrupt-map failed, using interrupt-controller\n", ipar);
+				return 0;
+			}
+
 			goto fail;
+		}
 
 		/*
 		 * Successfully parsed an interrrupt-map translation; copy new

-- 
Without deviation from the norm, progress is not possible.

On Thu, Nov 11, 2021 at 2:20 AM Marc Zyngier [off-list ref] wrote:

On Thu, 11 Nov 2021 07:47:08 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.

quoted

We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

    M.

I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.

Thanks for that. The DT looks absolutely bonkers, no wonder that
things break with something like that.

But Darren's comments made me jump a bit, and I quote them here for
everyone to see:

<quote>
[...]

11 more quoted lines

To my knowledge that has never been needed -- that the base platform
support is all there.

This is an old platform, and just like with the power macs, the
devicetree is indeed supplied from firmware, and as such not easily
patchable like with ARM platforms.

Last time this was an issue (to my memory) was when they enabled
automatic little endian switching in the boot path, that caused some
issues with a (bad) phandle pointer that had gone undiscovered for 10+
years.

If so, I wonder why upstream should revert a patch to work on a system
that isn't supported upstream the first place. I will still try and
come up with a solution for you. But asking for the revert of a patch
on these grounds is not, IMHO, acceptable. Also, please provide these
patches on the list so that I can help you to some extend (and I mean
*on the list*, not on a random forum that collects my information).

Early fixups of DT is the way to go here, if needed -- we do it on
some other platforms. That can happen in-kernel, and keep the new
functionality. For that we'd need to figure out what's actually wrong
with the DT as such right now.



-Olof

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

On Wed, 10 Nov 2021 18:07:24 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

41 more quoted lines

The detecting of the ATA disks works with this patch! Well done! Thanks a lot!

dmesg:

[    0.000000] hash-mmu: Page sizes from device-tree:
[    0.000000] hash-mmu: base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0
[    0.000000] hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=3
[    0.000000] hash-mmu: base_shift=20: shift=20, sllp=0x0030, avpnm=0x00000000, tlbiel=0, penc=31
[    0.000000] hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0
[    0.000000] Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24
[    0.000000] Using 1TB segments
[    0.000000] hash-mmu: Initializing hash mmu with SLB
[    0.000000] Linux version 5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty (christian@cc-build-machine.a-eon.tld) (powerpc-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #1 SMP Fri Nov 12 09:30:39 CET 2021
[    0.000000] IOBMAP L2 allocated at: (____ptrval____)
[    0.000000] ioremap() called early from .iommu_init_early_pasemi+0x10c/0x244. Use early_ioremap() instead
[    0.000000] Using A-EON Amigaone X1000 machine description
[    0.000000] Found legacy serial port 0 for /pxp@0,e0000000/serial@1d
[    0.000000]   port=7f03f8, taddr=fcff03f8, irq=0, clk=133333333, speed=115200
[    0.000000] Found legacy serial port 1 for /pxp@0,e0000000/serial@1d,1
[    0.000000]   port=7f02f8, taddr=fcff02f8, irq=0, clk=133333333, speed=115200
[    0.000000] CPU maps initialized for 1 thread per core
[    0.000000]  (thread shift is 0)
[    0.000000] Allocated 2320 bytes for 2 pacas
[    0.000000] -----------------------------------------------------
[    0.000000] phys_mem_size     = 0x200000000
[    0.000000] dcache_bsize      = 0x40
[    0.000000] icache_bsize      = 0x40
[    0.000000] cpu_features      = 0x0000010000401182
[    0.000000]   possible        = 0x000ffbebffffb18f
[    0.000000]   always          = 0x0000000000000180
[    0.000000] cpu_user_features = 0xdc000802 0x00000000
[    0.000000] mmu_features      = 0x6e000001
[    0.000000] firmware_features = 0x0000000000000000
[    0.000000] vmalloc start     = 0xc0003d0000000000
[    0.000000] IO start          = 0xc0003e0000000000
[    0.000000] vmemmap start     = 0xc0003f0000000000
[    0.000000] hash-mmu: ppc64_pft_size    = 0x0
[    0.000000] hash-mmu: htab_hash_mask    = 0xfffff
[    0.000000] -----------------------------------------------------
[    0.000000] ioremap() called early from .pas_setup_arch+0x3c/0x58. Use early_ioremap() instead

843 more lines

On 12 November 2021 at 10:40 am, Christian Zigotzky wrote:

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

quoted

On Wed, 10 Nov 2021 18:07:24 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4


Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

42 more quoted lines

Sorry, I have read the patch more carefully and I have seen that it is an analyse patch. It's not a fix. I was too quick with my joy.

- Christian

On 12 November 2021 at 11:11 am, Christian Zigotzky wrote:

On 12 November 2021 at 10:40 am, Christian Zigotzky wrote:

quoted

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

quoted

On Wed, 10 Nov 2021 18:07:24 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4


Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result

46 more quoted lines

OK, perhaps a fix after all.

if (imap == NULL && intc) // If the return value isn't NULL then there isn't an interrupt-map. That means, this part was successfully (&&) and "intc" will evaluated (Testing of interrupt-controller). OK, perhaps it is a fix after all.

Output:

[    0.072659] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072682] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072701] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072720] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072741] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072762] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072784] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072805] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072824] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072843] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072861] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.072929] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073167] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073191] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073211] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073232] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073252] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073272] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073292] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073319] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073339] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073371] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073392] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073412] OF: /pxp@0,e0000000 interrupt-map failed, using interrupt-controller
[    0.073426] PCI: Probing PCI hardware done

On Thu, Nov 11, 2021 at 02:21:46PM -0800, Olof Johansson wrote:

On Thu, Nov 11, 2021 at 2:20 AM Marc Zyngier [off-list ref] wrote:

quoted

Am I right in understanding that the upstream kernel does not support
the machine out of the box, and that you actually have to apply out of
tree patches to make it work? That these patches have to do with the
IRQ routing?

To my knowledge that has never been needed -- that the base platform
support is all there.

This is an old platform, and just like with the power macs, the
devicetree is indeed supplied from firmware, and as such not easily
patchable like with ARM platforms.

Last time this was an issue (to my memory) was when they enabled
automatic little endian switching in the boot path, that caused some
issues with a (bad) phandle pointer that had gone undiscovered for 10+
years.

quoted

If so, I wonder why upstream should revert a patch to work on a system
that isn't supported upstream the first place. I will still try and
come up with a solution for you. But asking for the revert of a patch
on these grounds is not, IMHO, acceptable. Also, please provide these
patches on the list so that I can help you to some extend (and I mean
*on the list*, not on a random forum that collects my information).

Early fixups of DT is the way to go here, if needed -- we do it on
some other platforms. That can happen in-kernel, and keep the new
functionality. For that we'd need to figure out what's actually wrong
with the DT as such right now.

Yup.  The scheme we have now (copy all info from OF, and then take over
everything at once) is not ideal at all, but treating OF systems just
like "bare" systems has advantages as well, including making it easier
to fix up the device tree if it has problems.  This is much superior to
changing all consumers (drivers etc.) to deal with the broken device
trees, so we should do it much more often :-)


Segher

On Fri, 12 Nov 2021 09:40:30 +0000,
Christian Zigotzky [off-list ref] wrote:

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

quoted

On Wed, 10 Nov 2021 18:07:24 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

42 more quoted lines

Thanks for testing it. I'll turn that into a proper patch.

	M.

-- 
Without deviation from the norm, progress is not possible.

On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:

On Fri, 12 Nov 2021 09:40:30 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

quoted

On Wed, 10 Nov 2021 18:07:24 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result

47 more quoted lines

Could you please explain your patch? I am not a developer. I work for the A-EON Linux FLS.

- Christian

On Fri, 12 Nov 2021 14:15:18 +0000,
Christian Zigotzky [off-list ref] wrote:

On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:

quoted

On Fri, 12 Nov 2021 09:40:30 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

quoted

On Wed, 10 Nov 2021 18:07:24 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

quoted

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

quoted

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt

50 more quoted lines

Please refer to the commit message[1].

I am not a developer. I work for the A-EON Linux FLS.

I have no idea what this is, unfortunately.

	M.

[1] https://lore.kernel.org/r/20211112143644.434995-1-maz@kernel.org

-- 
Without deviation from the norm, progress is not possible.