From: Christian Zigotzky <hidden> Date: 2021-05-01 06:45:27
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
-----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 <darren@stevens-
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,
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 -
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu
m.hyperion-
entertainment.com%2Fviewtopic.php%3Fp%3D53074%23p53074&data
=04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08
d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375538
08670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RXfSlY
A3bDEFas0%2Fk2vMWsl2l0nuhS2ecjZgSBLc%2Bs4%3D&reserved=0
[7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3
From: Gustavo A. R. Silva <hidden> Date: 2021-04-30 17:00:29
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 <darren@stevens-
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.
I'll have a look.
Thanks for the report!
--
Gustavo
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
From: Christian Zigotzky <hidden> Date: 2021-05-04 07:22:52
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
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
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
From: Christian Zigotzky <hidden> Date: 2021-05-04 09:10:18
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
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
Christophe
Do you use a BookE machine?
No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it
freezes before any output.
From: Christian Zigotzky <hidden> Date: 2021-05-04 09:47:19
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:
git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
Christophe
Do you use a BookE machine?
No I don't unfortunately, and I have tried booting in QEMU a kernel
built with your config, but it freezes before any output.
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.
In that case, just use the SHA corresponding to the merge:
git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
Christophe
Do you use a BookE machine?
No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it
freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
From: Christian Zigotzky <hidden> Date: 2021-05-04 10:08:14
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
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?
No I don't unfortunately, and I have tried booting in QEMU a kernel
built with your config, but it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
I am bisecting currently.
$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
From: Christian Zigotzky <hidden> Date: 2021-05-04 11:03:52
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
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?
No I don't unfortunately, and I have tried booting in QEMU a kernel
built with your config, but it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
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.
From: Christian Zigotzky <hidden> Date: 2021-05-04 13:49:53
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:
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?
No I don't unfortunately, and I have tried booting in QEMU a
kernel built with your config, but it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
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.
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:
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?
No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but
it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
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.
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.
In that case, just use the SHA corresponding to the merge:
git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
Christophe
Do you use a BookE machine?
No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it
freezes before any output.
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
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
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?
No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config,
but it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
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.
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
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 ?
From: Christian Zigotzky <hidden> Date: 2021-05-04 14:53:55
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.
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?
No I don't unfortunately, and I have tried booting in QEMU a
kernel built with your config, but it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
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.
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
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 ?
I use 32-bit and 64-bit userlands with 64-bit kernels. Both userlands
are affected by the Xorg issue.
From: Christian Zigotzky <hidden> Date: 2021-05-04 15:00:51
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.
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?
No I don't unfortunately, and I have tried booting in QEMU a
kernel built with your config, but it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
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.
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.
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?
No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config,
but it freezes before any output.
You can use my kernels and distributions.
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
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).
From: Christian Zigotzky <hidden> Date: 2021-05-05 12:45:31
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'
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
([14b3c9d24a7a5c274a9df27d245516f466d3bc5f] powerpc/syscalls: switch to
generic syscalltbl.sh)
17) git bisect skip It stopped after loading the dtb and uImage.
([08a022ad3dfafc7e33d4529015e14bb75179cacc] powerpc/powernv/memtrace:
Allow mmaping trace buffers)
18) git bisect skip It stopped after loading the dtb and uImage.
([e5d56763525e65417dad0d46572b234fa0008e40] powerpc/rtas: rename
RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE)
19) git bisect skip It stopped after loading the dtb and uImage.
([98db179a78dd8379e9d2cbfc3f00224168a9344c] powerpc/64s: power4 nap
fixup in C)
20) git bisect skip It stopped after loading the dtb and uImage.
([c13ff6f3251318f5e1ff5b1a6d05f76996db672a] powerpc/rtas: improve
ppc_rtas_rmo_buf_show documentation)
Should I continue bisecting?
You can find the other steps (21 and higher) here:
https://forum.hyperion-entertainment.com/viewtopic.php?p=53103#p53103
Thanks,
Christian
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.
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
From: Christian Zigotzky <hidden> Date: 2021-05-06 07:57:56
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.
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,
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
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
From: Gustavo A. R. Silva <hidden> Date: 2021-05-07 00:42:44
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.
From: Christian Zigotzky <hidden> Date: 2021-05-07 06:44:02
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.
From: Christian Zigotzky <hidden> Date: 2021-05-08 11:36:08
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.
- 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
Author: Christophe Leroy [off-list ref]
Date: Fri Apr 23 13:52:10 2021 +0000
1 file changed, 2 insertions(+), 2 deletions(-)
---
Xorg works after compiling with the cherry-pick of 525642624783.
- 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
Author: Christophe Leroy [off-list ref]
Date: Fri Apr 23 13:52:10 2021 +0000
1 file changed, 2 insertions(+), 2 deletions(-)
---
Xorg works after compiling with the cherry-pick of 525642624783.
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
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
|\
| * 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
| * 867e762480f4 powerpc/32: Use r2 in wrtspr() instead of r0
| * f56607e85ee3 selftests/timens: Fix gettime_perf to work on powerpc
| * 92d9d61be519 powerpc/mce: save ignore_event flag unconditionally for UE
| * eacf4c020265 powerpc: Enable OPTPROBES on PPC32
| * 693557ebf407 powerpc/inst: ppc_inst_as_u64() becomes ppc_inst_as_ulong()
| * e522331173ec powerpc/irq: Enhance readability of trap types
| * 7fab639729ce powerpc/32s: Enhance readability of trap types
| * 0f5eb28a6ce6 powerpc/8xx: Enhance readability of trap types
| * a9d2f9bb225f powerpc/pseries/iommu: Fix window size for direct mapping with pmem
| * e4e8bc1df691 powerpc/kvm: Fix PR KVM with KUAP/MEM_KEYS enabled
| * ed8029d7b472 powerpc/pseries: Stop calling printk in rtas_stop_self()
| * 3027a37c06be powerpc: Only define _TASK_CPU for 32-bit
| * 39d0099f9439 powerpc/pseries: Add shutdown() to vio_driver and vio_bus
| * af31fd0c9107 powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
| * 2886e2df10be Documentation/powerpc: Add proper links for manual and tests
| * 29c9a2699e71 powerpc/pseries: Set UNISOLATE on dlpar_cpu_remove() failure
| * 0e3b3ff83ce2 powerpc/pseries: Introduce dlpar_unisolate_drc()
| * 864ec4d40c83 powerpc/pseries/mce: Fix a typo in error type assignment
| * cbd3d5ba46b6 powerpc/fadump: Fix compile error since trap type change
| * d8a1d6c58986 powerpc/perf: Add platform specific check_attr_config
| * a38cb4171928 Merge branch 'topic/ppc-kvm' into next
| |\
| | * 732f21a3053c KVM: PPC: Book3S HV: Ensure MSR[HV] is always clear in guest MSR
| | * 946cf44ac6ce KVM: PPC: Book3S HV: Ensure MSR[ME] is always set in guest MSR
| | * da487a5d1bee powerpc/64s: remove KVM SKIP test from instruction breakpoint handler
| | * 5eee8371828a powerpc/64s: Remove KVM handler support from CBE_RAS interrupts
| | * 0fd85cb83fbd KVM: PPC: Book3S HV: Fix CONFIG_SPAPR_TCE_IOMMU=n default hcalls
| | * 6c12c4376bbb KVM: PPC: Book3S HV: remove unused kvmppc_h_protect argument
| | * 4b5f0a0d49e6 KVM: PPC: Book3S HV: Remove redundant mtspr PSPB
| | * 72c15287210f KVM: PPC: Book3S HV: Prevent radix guests setting LPCR[TC]
| | * bcc92a0d6d6e KVM: PPC: Book3S HV: Disallow LPCR[AIL] to be set to 1 or 2
| | * 67145ef4960f KVM: PPC: Book3S HV: Add a function to filter guest LPCR bits
| | * a19b70abc69a KVM: PPC: Book3S HV: Nested move LPCR sanitising to sanitise_hv_regs
| | * 5088eb4092df KVM: PPC: Book3S HV P9: Restore host CTRL SPR after guest exit
BAD | * | 49c1d07fd04f powerpc/powernv: Enable HAIL (HV AIL) for ISA v3.1 processors
| * | 6980d13f0dd1 powerpc/smp: Set numa node before updating mask
| * | 7153d4bf0b37 powerpc/traps: Enhance readability for trap types
| * | 7de21e679e6a powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h
| * | c1e53367dab1 powerpc/smp: Cache CPU to chip lookup
| * | 131c82b6a1d2 Revert "powerpc/topology: Update topology_core_cpumask"
| * | c47f892d7aa6 powerpc/smp: Reintroduce cpu_core_mask
| * | e9e16917bc38 powerpc/xive: Use the "ibm, chip-id" property only under PowerNV
| * | 38d0b1c9cec7 powerpc/pseries: extract host bridge from pci_bus prior to bus removal
| * | 0751fdf28041 macintosh/via-pmu: Fix build warning
| * | 7767d9ac89ce powerpc/papr_scm: Fix build error due to wrong printf specifier
| * | d6481a7195df powerpc/configs: Add PAPR_SCM to pseries_defconfig
| * | 7098f8f0cf03 powerpc/mm/radix: Make radix__change_memory_range() static
| * | 74205b3fc2ef powerpc/vdso: Add support for time namespaces
| * | 1c4bce675385 powerpc/vdso: Separate vvar vma from vdso
| * | 808094fcbf41 lib/vdso: Add vdso_data pointer as input to __arch_get_timens_vdso_data()
| * | 58efe9f696cf lib/vdso: Mark do_hres_timens() and do_coarse_timens() __always_inline()
| * | 8f6cc75a97d1 powerpc: move norestart trap flag to bit 0
| * | 8dc7f0229b78 powerpc: remove partial register save logic
| * | c45ba4f44f6b powerpc: clean up do_page_fault
| * | d738ee8d56de powerpc/64e/interrupt: handle bad_page_fault in C
ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme
ZZ | * | 097157e16cf8 powerpc/64e/interrupt: reconcile irq soft-mask state in C
| * | 3db8aa10de9a powerpc/64e/interrupt: NMI save irq soft-mask state in C
ZZ | * | 0c2472de23ae powerpc/64e/interrupt: use new interrupt return
| * | dc6231821a14 powerpc/interrupt: update common interrupt code for
| * | 4228b2c3d20e powerpc/64e/interrupt: always save nvgprs on interrupt
| * | 5a5a893c4ad8 powerpc/syscall: switch user_exit_irqoff and trace_hardirqs_off order
ZZ | * | 2e2a441d2c0b powerpc/perf: Infrastructure to support checking of attr.config*
| * | 59fd366b9bef powerpc/fadump: make symbol 'rtas_fadump_set_regval' static
| * | 7e9ab144c128 powerpc/mem: Use kmap_local_page() in flushing functions
| * | 6c96020882b1 powerpc/mem: Inline flush_dcache_page()
| * | 67b8e6af191a powerpc/mem: Help GCC realise __flush_dcache_icache() flushes single pages
| * | 52d490437ffb powerpc/mem: flush_dcache_icache_phys() is for HIGHMEM pages only
| * | cd97d9e8b5aa powerpc/mem: Optimise flush_dcache_icache_hugepage()
| * | e618c7aea1f2 powerpc/mem: Call flush_coherent_icache() at higher level
| * | 131637a17dc9 powerpc/mem: Remove address argument to flush_coherent_icache()
| * | bf26e0bbd2f8 powerpc/mem: Declare __flush_dcache_icache() static
| * | b26e8f27253a powerpc/mem: Move cache flushing functions into mm/cacheflush.c
| * | ff0b4155ae99 powerpc/powernv: make symbol 'mpipl_kobj' static
| * | f234ad405a35 powerpc/xmon: Make symbol 'spu_inst_dump' static
| * | cc331eee03ea powerpc/perf/hv-24x7: Make some symbols static
ZZZ | * | 107dadb04617 powerpc/perf: Make symbol 'isa207_pmu_format_attr' static
ZZZ | * | 2235dea17d56 powerpc/pseries/pmem: Make symbol 'drc_pmem_match' static
| * | 193e4cd8ed9d powerpc/pseries: Make symbol '__pcpu_scope_hcall_stats' static
ZZ | * | 472724111f0f powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
| * | 672bff581e19 powerpc/syscalls: switch to generic syscallhdr.sh
XX | * | 14b3c9d24a7a powerpc/syscalls: switch to generic syscalltbl.sh
ZZ | * | e5d56763525e powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE
ZZ | * | 0649cdc82379 powerpc/rtas: move syscall filter setup into separate function
| * | 0ab1c929ae38 powerpc/rtas: remove ibm_suspend_me_token
ZZZ | * | 01c1b9984a12 powerpc/rtas-proc: remove unused RMO_READ_BUF_MAX
ZZ | * | c13ff6f32513 powerpc/rtas: improve ppc_rtas_rmo_buf_show documentation
| * | 5ae5bc12d072 powerpc/eeh: Fix EEH handling for hugepages in ioremap space.
XX | * | fd6db2892eba powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler
ZZ | * | 7dcc37b3eff9 powerpc/xive: Map one IPI interrupt per node
| * | 33e4bc594643 powerpc/xive: Fix xmon command "dxi"
| * | 6bf66eb8f404 powerpc/xive: Simplify the dump of XIVE interrupts under xmon
| * | a74ce5926b20 powerpc/xive: Drop check on irq_data in xive_core_debug_show()
| * | 5159d9872823 powerpc/xive: Simplify xive_core_debug_show()
| * | 1835e72942b5 powerpc/xive: Remove useless check on XIVE_IPI_HW_IRQ
| * | 7d348494136c powerpc/xive: Introduce an IPI interrupt domain
| * | 078277acbd7c powerpc/smp: Make some symbols static
| * | 95d143923379 macintosh/via-pmu: Make some symbols static
| * | 4204ecd598cb windfarm: make symbol 'wf_thread' static
| * | 13ddd0e3acf9 macintosh/windfarm: Make symbol 'pm121_sys_state' static
| * | f6f1f48e8b3b powerpc/mce: Make symbol 'mce_ue_event_work' static
| * | 7f262b4dcf7e powerpc/security: Make symbol 'stf_barrier' static
| * | 80edc68e0479 powerpc/32s: Define a MODULE area below kernel text all the time
| * | 9132a2e82adc powerpc/8xx: Define a MODULE area below kernel text
| * | 2ec13df16704 powerpc/modules: Load modules closer to kernel text
| * | a5d6a3e73acb powerpc/mm: Add cond_resched() while removing hpte mappings
| * | 75b7c05ebf90 powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall
| * | af072b1a9d4d powerpc/signal32: Fix build failure with CONFIG_SPE
| * | c46bbf5d2def powerpc/32: Remove powerpc specific definition of 'ptrdiff_t'
| * | b27dadecdf91 powerpc: iommu: fix build when neither PCI or IBMVIO is set
| * | 01ed0510941a powerpc/pseries: remove unneeded semicolon
ZZ | * | 98db179a78dd powerpc/64s: power4 nap fixup in C
| * | 10f8f96179ec powerpc/perf: Fix PMU constraint check for EBB events
| * | 812aa68ef7d4 selftests/powerpc: Suggest memtrace instead of /dev/mem for ci memory
ZZ | * | 08a022ad3dfa powerpc/powernv/memtrace: Allow mmaping trace buffers
| * | acd4dfeb49c8 powerpc/kexec: Don't use .machine ppc64 in trampoline_64.S
| * | c6b4c9147f8b powerpc/64: Move security code into security.c
| * | bd573a81312f powerpc/mm/64s: Allow STRICT_KERNEL_RWX again
| * | 87e65ad7bd3a powerpc/mm/64s/hash: Add real-mode change_memory_range() for hash LPAR
| * | 6f223ebe9c3f powerpc/mm/64s/hash: Factor out change_memory_range()
ZZZ | * | 2c02e656a29d powerpc/64s: Use htab_convert_pte_flags() in hash__mark_rodata_ro()
| * | b56d55a5aa4a powerpc/pseries: Add key to flags in pSeries_lpar_hpte_updateboltedpp()
ZZZ | * | 56bec2f9d4d0 powerpc/mm/64s: Add _PAGE_KERNEL_ROX
| * | 29e3ea8cbd29 selftests/powerpc: Test for spurious kernel memory faults on radix
| * | b8b2f37cf632 powerpc/64s: Fix pte update for kernel memory on radix
| * | 4763d3782764 powerpc: Spelling/typo fixes
| * | b0b3b2c78ec0 powerpc: Switch to relative jump labels
| * | 40272035e1d0 powerpc/bpf: Reallocate BPF registers to volatile registers when possible on PPC32
| * | 51c66ad849a7 powerpc/bpf: Implement extended BPF on PPC32
| * | 355a8d26cd04 powerpc/asm: Add some opcodes in asm/ppc-opcode.h for PPC32 eBPF
| * | c426810fcf9f powerpc/bpf: Change values of SEEN_ flags
| * | 4ea76e90a97d powerpc/bpf: Move common functions into bpf_jit_comp.c
| * | f1b1583d5faa powerpc/bpf: Move common helpers into bpf_jit.h
| * | ed573b57e77a powerpc/bpf: Change register numbering for bpf_set/is_seen_register()
| * | 6944caad78fc powerpc/bpf: Remove classical BPF support for PPC32
| * | c7393a71eb1a powerpc/signal32: Simplify logging in sigreturn()
BAD? | * | 887f3ceb51cd powerpc/signal32: Convert do_setcontext[_tm]() to user access block
GOOD | * | 627b72bee84d powerpc/signal32: Convert restore_[tm]_user_regs() to user access block
| * | 036fc2cb1dc2 powerpc/signal32: Reorder user reads in restore_tm_user_regs()
Christophe
- 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
Author: Christophe Leroy [off-list ref]
Date: Fri Apr 23 13:52:10 2021 +0000
1 file changed, 2 insertions(+), 2 deletions(-)
---
Xorg works after compiling with the cherry-pick of 525642624783.
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.
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
From: Christian Zigotzky <hidden> Date: 2021-05-09 21:47:35
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
From: Gustavo A. R. Silva <hidden> Date: 2021-05-09 23:52:14
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.
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
From: Christian Zigotzky <hidden> Date: 2021-05-13 15:20:35
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
From: Christian Zigotzky <hidden> Date: 2021-05-13 16:36:40
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
Christophe
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
git bisect good 6efb943b8616
Christophe
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
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
From: Christian Zigotzky <hidden> Date: 2021-05-13 20:22:13
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.
git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616
Christophe
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
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
- Christian
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-05-13 22:58:59
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
---
From: Christian Zigotzky <hidden> Date: 2021-05-14 00:20:27
On 14 May 2021 at 00:58am, Nicholas Piggin wrote:
quoted hunk
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.
Thanks,
Nick
---
From: Christian Zigotzky <hidden> Date: 2021-11-09 14:47:36
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
From: Christian Zigotzky <hidden> Date: 2021-11-09 15:11:24
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,
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
From: Krzysztof Wilczyński <hidden> Date: 2021-11-09 22:40:44
[+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.
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
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
af9d82626c8f PCI/ACPI: Remove OSC_PCI_SUPPORT_MASKS and OSC_PCI_CONTROL_MASKS
9a0a1417d3bb PCI: Tidy comments
06dc660e6eb8 PCI: Rename pcibios_add_device() to pcibios_device_add()
e3f4bd3462f6 PCI: Mark Atheros QCA6174 to avoid bus reset
3a19407913e8 PCI/P2PDMA: Apply bus offset correctly in DMA address calculation
Out of these, I agree that most of them seem harmless, these would
be the ones I'd try to look at more closely, or maybe revert for testing:
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
e1b0d0bb2032 PCI: Re-enable Downstream Port LTR after reset or hotplug
7c3855c423b1 PCI: Coalesce host bridge contiguous apertures
3a19407913e8 PCI/P2PDMA: Apply bus offset correctly in DMA address calculation
Arnd
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
af9d82626c8f PCI/ACPI: Remove OSC_PCI_SUPPORT_MASKS and OSC_PCI_CONTROL_MASKS
9a0a1417d3bb PCI: Tidy comments
06dc660e6eb8 PCI: Rename pcibios_add_device() to pcibios_device_add()
e3f4bd3462f6 PCI: Mark Atheros QCA6174 to avoid bus reset
3a19407913e8 PCI/P2PDMA: Apply bus offset correctly in DMA address calculation
Out of these, I agree that most of them seem harmless, these would
be the ones I'd try to look at more closely, or maybe revert for testing:
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
e1b0d0bb2032 PCI: Re-enable Downstream Port LTR after reset or hotplug
7c3855c423b1 PCI: Coalesce host bridge contiguous apertures
3a19407913e8 PCI/P2PDMA: Apply bus offset correctly in DMA address calculation
From: Damien Le Moal <hidden> Date: 2021-11-10 04:01:21
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:
@@ -79,7 +79,7 @@ enum {*takeanexceptionallylongtimetorecoverfromreset.*/staticconstunsignedlongata_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 */
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.
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
From: Christian Zigotzky <hidden> Date: 2021-11-10 18:08:24
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.
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]
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
From: Marc Zyngier <maz@kernel.org> Date: 2021-11-10 19:10:32
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.
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]
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?
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.
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
af9d82626c8f PCI/ACPI: Remove OSC_PCI_SUPPORT_MASKS and OSC_PCI_CONTROL_MASKS
9a0a1417d3bb PCI: Tidy comments
06dc660e6eb8 PCI: Rename pcibios_add_device() to pcibios_device_add()
e3f4bd3462f6 PCI: Mark Atheros QCA6174 to avoid bus reset
3a19407913e8 PCI/P2PDMA: Apply bus offset correctly in DMA address calculation
Out of these, I agree that most of them seem harmless, these would
be the ones I'd try to look at more closely, or maybe revert for testing:
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
e1b0d0bb2032 PCI: Re-enable Downstream Port LTR after reset or hotplug
7c3855c423b1 PCI: Coalesce host bridge contiguous apertures
3a19407913e8 PCI/P2PDMA: Apply bus offset correctly in DMA address calculation
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.
From: Christian Zigotzky <hidden> Date: 2021-11-11 05:26:20
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.
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]
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?
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.
From: Marc Zyngier <maz@kernel.org> Date: 2021-11-11 07:14:02
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.
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]
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?
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.
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.
From: Christian Zigotzky <hidden> Date: 2021-11-11 07:48:39
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.
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]
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?
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.
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.
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.
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?
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.
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.
From: Marc Zyngier <maz@kernel.org> Date: 2021-11-11 17:39:41
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.
@@ -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){+boolintc=of_property_read_bool(ipar,"interrupt-controller");+/**Nowcheckifcursorisaninterrupt-controllerand*ifitisthenwearedone,unlessthereisan*interrupt-mapwhichtakesprecedence.*/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");return0;}
@@ -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);+return0;+}+gotofail;+}/**Successfullyparsedaninterrrupt-maptranslation;copynew
--
Without deviation from the norm, progress is not possible.
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?
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
From: Christian Zigotzky <hidden> Date: 2021-11-12 09:41:37
On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
quoted hunk
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.
@@ -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){+boolintc=of_property_read_bool(ipar,"interrupt-controller");+/**Nowcheckifcursorisaninterrupt-controllerand*ifitisthenwearedone,unlessthereisan*interrupt-mapwhichtakesprecedence.*/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");return0;}
@@ -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);+return0;+}+gotofail;+}/**Successfullyparsedaninterrrupt-maptranslation;copynew
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
[ 0.000000] barrier-nospec: using ORI speculation barrier
[ 0.000000] barrier-nospec: patched 413 locations
[ 0.000000] Top of RAM: 0x280000000, Total RAM: 0x200000000
[ 0.000000] Memory hole size: 2048MB
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x000000027fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff]
[ 0.000000] node 0: [mem 0x0000000100000000-0x000000027fffffff]
[ 0.000000] Initmem setup node 0 [mem
0x0000000000000000-0x000000027fffffff]
[ 0.000000] percpu: Embedded 25 pages/cpu s64152 r0 d38248 u524288
[ 0.000000] pcpu-alloc: s64152 r0 d38248 u524288 alloc=1*1048576
[ 0.000000] pcpu-alloc: [0] 0 1
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages:
2068480
[ 0.000000] Kernel command line: root=/dev/sdb4
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11,
8388608 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10,
4194304 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 8067920K/8388608K available (19672K kernel code,
2856K rwdata, 7752K rodata, 7428K init, 678K bss, 320688K reserved, 0K
cma-reserved)
[ 0.000000] ftrace: allocating 45669 entries in 269 pages
[ 0.000000] ftrace: allocated 268 pages with 3 groups
[ 0.000000] trace event string verifier disabled
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay
is 100 jiffies.
[ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[ 0.000000] mpic: Setting up MPIC "PASEMI-OPIC" version 1.3 at
fc000000, max 2 CPUs
[ 0.000000] mpic: ISU size: 1024, shift: 10, mask: 3ff
[ 0.000000] mpic: Initializing for 1024 sources
[ 0.000000] random: get_random_u64 called from
.start_kernel+0x970/0xbc4 with crng_init=0
[ 0.000000] time_init: decrementer frequency = 66.666666 MHz
[ 0.000000] time_init: processor frequency = 1800.000000 MHz
[ 0.000001] clocksource: timebase: mask: 0xffffffffffffffff
max_cycles: 0xf6018975a, max_idle_ns: 440795204712 ns
[ 0.000009] clocksource: timebase mult[f000003] shift[24] registered
[ 0.000019] clockevent: decrementer mult[1111110e] shift[32] cpu[0]
[ 0.000241] Console: colour dummy device 80x25
[ 0.000443] printk: console [tty0] enabled
[ 0.000461] pid_max: default: 32768 minimum: 301
[ 0.000581] Mount-cache hash table entries: 16384 (order: 5, 131072
bytes, linear)
[ 0.000625] Mountpoint-cache hash table entries: 16384 (order: 5,
131072 bytes, linear)
[ 0.001129] mpic: requesting IPIs...
[ 0.001498] rcu: Hierarchical SRCU implementation.
[ 0.001678] smp: Bringing up secondary CPUs ...
[ 0.002118] smp: Brought up 1 node, 2 CPUs
[ 0.002533] devtmpfs: initialized
[ 0.005905] Found PA-PXP PCI host bridge.
[ 0.005916] PCI host bridge /pxp@0,e0000000 (primary) ranges:
[ 0.005946] IO 0x00000000fc800000..0x00000000fcffffff ->
0x0000000000000000
[ 0.005962] MEM 0x0000000080000000..0x00000000e00fffff ->
0x0000000080000000
[ 0.005975] MEM 0x00000000fd800000..0x00000000fd800fff ->
0x00000000fd800000
[ 0.005986] MEM 0x0000080000000000..0x00000bffffffffff ->
0x0000080000000000
[ 0.006000] no ISA IO ranges or unexpected isa range, mapping 64k
[ 0.006010] ISA bridge (early) is /pxp@0,e0000000/io-bridge@0
[ 0.006158] i8259 legacy interrupt controller initialized
[ 0.006224] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.006242] futex hash table entries: 512 (order: 4, 65536 bytes, linear)
[ 0.006501] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.006967] thermal_sys: Registered thermal governor 'step_wise'
[ 0.007372] PCI: Probing PCI hardware
[ 0.008645] PCI host bridge to bus 0000:00
[ 0.008660] pci_bus 0000:00: root bus resource [io 0x10000-0x80ffff]
(bus address [0x0000-0x7fffff])
[ 0.008674] pci_bus 0000:00: root bus resource [mem
0x80000000-0xe00fffff]
[ 0.008684] pci_bus 0000:00: root bus resource [mem
0xfd800000-0xfd800fff]
[ 0.008693] pci_bus 0000:00: root bus resource [mem
0x80000000000-0xbffffffffff]
[ 0.008703] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.008713] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
[ 0.008744] NEMO SB600 IOB base e0000000
[ 0.008778] pci 0000:00:00.0: [1959:a001] type 00 class 0x060000
[ 0.008883] ISA bridge PCI attached: 0000:00:00.0
[ 0.008955] pci 0000:00:01.0: [1959:a009] type 00 class 0x058000
[ 0.009146] pci 0000:00:03.0: [1959:a00c] type 00 class 0x080080
[ 0.009313] pci 0000:00:04.0: [1959:a00a] type 00 class 0x050000
[ 0.009478] pci 0000:00:05.0: [1959:a00a] type 00 class 0x050000
[ 0.009690] pci 0000:00:08.0: [1959:a000] type 00 class 0x0b2000
[ 0.009844] pci 0000:00:09.0: [1959:a000] type 00 class 0x0b2000
[ 0.010145] pci 0000:00:10.0: [1959:a002] type 01 class 0x060400
[ 0.010189] pci 0000:00:10.0: enabling Extended Tags
[ 0.010232] pci 0000:00:10.0: PME# supported from D0 D3hot D3cold
[ 0.010370] pci 0000:00:10.1: [1959:a002] type 01 class 0x060400
[ 0.010404] pci 0000:00:10.1: enabling Extended Tags
[ 0.010444] pci 0000:00:10.1: PME# supported from D0 D3hot D3cold
[ 0.010561] pci 0000:00:10.2: [1959:a002] type 01 class 0x060400
[ 0.010595] pci 0000:00:10.2: enabling Extended Tags
[ 0.010635] pci 0000:00:10.2: PME# supported from D0 D3hot D3cold
[ 0.010749] pci 0000:00:10.3: [1959:a002] type 01 class 0x060400
[ 0.010783] pci 0000:00:10.3: enabling Extended Tags
[ 0.010822] pci 0000:00:10.3: PME# supported from D0 D3hot D3cold
[ 0.010972] pci 0000:00:11.0: [1959:a002] type 01 class 0x060400
[ 0.011008] pci 0000:00:11.0: enabling Extended Tags
[ 0.011047] pci 0000:00:11.0: PME# supported from D0 D3hot D3cold
[ 0.011201] pci 0000:00:11.1: [1959:a002] type 01 class 0x060400
[ 0.011236] pci 0000:00:11.1: enabling Extended Tags
[ 0.011276] pci 0000:00:11.1: PME# supported from D0 D3hot D3cold
[ 0.011396] pci 0000:00:11.2: [1959:a002] type 01 class 0x060400
[ 0.011430] pci 0000:00:11.2: enabling Extended Tags
[ 0.011470] pci 0000:00:11.2: PME# supported from D0 D3hot D3cold
[ 0.011586] pci 0000:00:11.3: [1959:a002] type 01 class 0x060400
[ 0.011620] pci 0000:00:11.3: enabling Extended Tags
[ 0.011660] pci 0000:00:11.3: PME# supported from D0 D3hot D3cold
[ 0.011857] pci 0000:00:14.0: [1959:a005] type 00 class 0x020000
[ 0.011981] pci 0000:00:14.1: [1959:a005] type 00 class 0x020000
[ 0.012105] pci 0000:00:14.2: [1959:a005] type 00 class 0x020000
[ 0.012227] pci 0000:00:14.3: [1959:a005] type 00 class 0x020000
[ 0.012394] pci 0000:00:15.0: [1959:a006] type 00 class 0x020000
[ 0.012527] pci 0000:00:15.1: [1959:a006] type 00 class 0x020000
[ 0.012776] pci 0000:00:1a.0: [1959:a007] type 00 class 0x0801ff
[ 0.012942] pci 0000:00:1b.0: [1959:a00b] type 00 class 0x088000
[ 0.013101] pci 0000:00:1c.0: [1959:a003] type 00 class 0x0c0500
[ 0.013123] pci 0000:00:1c.0: reg 0x10: [io 0x800200-0x80023f]
[ 0.013253] pci 0000:00:1c.1: [1959:a003] type 00 class 0x0c0500
[ 0.013274] pci 0000:00:1c.1: reg 0x10: [io 0x800240-0x80027f]
[ 0.013394] pci 0000:00:1c.2: [1959:a003] type 00 class 0x0c0500
[ 0.013415] pci 0000:00:1c.2: reg 0x10: [io 0x800280-0x8002bf]
[ 0.013568] pci 0000:00:1d.0: [1959:a004] type 00 class 0x070003
[ 0.013590] pci 0000:00:1d.0: reg 0x10: [io 0x8003f8-0x8003ff]
[ 0.013708] pci 0000:00:1d.1: [1959:a004] type 00 class 0x070003
[ 0.013728] pci 0000:00:1d.1: reg 0x10: [io 0x8002f8-0x8002ff]
[ 0.013895] pci 0000:00:1e.0: [1959:a008] type 00 class 0x0601ff
[ 0.013916] pci 0000:00:1e.0: reg 0x10: [io 0x800400-0x8004ff]
[ 0.013929] pci 0000:00:1e.0: reg 0x14: [io 0x800500-0x8005ff]
[ 0.056717] IOMMU table initialized, virtual merging enabled
[ 0.056849] pci 0000:01:00.0: [1002:6718] type 00 class 0x030000
[ 0.056875] pci 0000:01:00.0: reg 0x10: [mem 0x90000000-0x9fffffff
64bit pref]
[ 0.056894] pci 0000:01:00.0: reg 0x18: [mem 0xa0020000-0xa003ffff 64bit]
[ 0.056908] pci 0000:01:00.0: reg 0x20: [io 0x12000-0x120ff]
[ 0.056926] pci 0000:01:00.0: reg 0x30: [mem 0xa0000000-0xa001ffff pref]
[ 0.056942] pci 0000:01:00.0: enabling Extended Tags
[ 0.056989] pci 0000:01:00.0: supports D1 D2
[ 0.057135] pci 0000:01:00.1: [1002:aa80] type 00 class 0x040300
[ 0.057159] pci 0000:01:00.1: reg 0x10: [mem 0xa0040000-0xa0043fff 64bit]
[ 0.057196] pci 0000:01:00.1: enabling Extended Tags
[ 0.057240] pci 0000:01:00.1: supports D1 D2
[ 0.061218] pci 0000:00:10.0: PCI bridge to [bus 01]
[ 0.061235] pci 0000:00:10.0: bridge window [io 0x12000-0x12fff]
[ 0.061245] pci 0000:00:10.0: bridge window [mem 0x90000000-0xa00fffff]
[ 0.062093] pci 0000:00:10.1: PCI bridge to [bus 02]
[ 0.062939] pci 0000:00:10.2: PCI bridge to [bus 03]
[ 0.063783] pci 0000:00:10.3: PCI bridge to [bus 04]
[ 0.064331] pci 0000:05:12.0: [1002:4380] type 00 class 0x01018f
[ 0.064359] pci 0000:05:12.0: reg 0x10: [io 0x11040-0x11047]
[ 0.064376] pci 0000:05:12.0: reg 0x14: [io 0x1105c-0x1105f]
[ 0.064392] pci 0000:05:12.0: reg 0x18: [io 0x11048-0x1104f]
[ 0.064408] pci 0000:05:12.0: reg 0x1c: [io 0x11058-0x1105b]
[ 0.064431] pci 0000:05:12.0: reg 0x20: [io 0x11010-0x1101f]
[ 0.064448] pci 0000:05:12.0: reg 0x24: [mem 0xa0209000-0xa02093ff]
[ 0.064478] pci 0000:05:12.0: set SATA to AHCI mode
[ 0.064653] pci 0000:05:13.0: [1002:4387] type 00 class 0x0c0310
[ 0.064681] pci 0000:05:13.0: reg 0x10: [mem 0xa0207000-0xa0207fff]
[ 0.064836] pci 0000:05:13.1: [1002:4388] type 00 class 0x0c0310
[ 0.064863] pci 0000:05:13.1: reg 0x10: [mem 0xa0208000-0xa0208fff]
[ 0.065019] pci 0000:05:13.2: [1002:4389] type 00 class 0x0c0310
[ 0.065047] pci 0000:05:13.2: reg 0x10: [mem 0xa0206000-0xa0206fff]
[ 0.065203] pci 0000:05:13.3: [1002:438a] type 00 class 0x0c0310
[ 0.065230] pci 0000:05:13.3: reg 0x10: [mem 0xa0205000-0xa0205fff]
[ 0.065384] pci 0000:05:13.4: [1002:438b] type 00 class 0x0c0310
[ 0.065411] pci 0000:05:13.4: reg 0x10: [mem 0xa0204000-0xa0204fff]
[ 0.065582] pci 0000:05:13.5: [1002:4386] type 00 class 0x0c0320
[ 0.065610] pci 0000:05:13.5: reg 0x10: [mem 0xa0209800-0xa02098ff]
[ 0.065698] pci 0000:05:13.5: supports D1 D2
[ 0.065706] pci 0000:05:13.5: PME# supported from D0 D1 D2 D3hot
[ 0.065851] pci 0000:05:14.0: [1002:4385] type 00 class 0x0c0500
[ 0.065877] pci 0000:05:14.0: reg 0x10: [io 0x11020-0x1102f]
[ 0.065894] pci 0000:05:14.0: reg 0x14: [mem 0xa0209400-0xa02097ff]
[ 0.066051] pci 0000:05:14.1: [1002:438c] type 00 class 0x010183
[ 0.066078] pci 0000:05:14.1: reg 0x10: [io 0x11030-0x11037]
[ 0.066094] pci 0000:05:14.1: reg 0x14: [io 0x11054-0x11057]
[ 0.066110] pci 0000:05:14.1: reg 0x18: [io 0x11038-0x1103f]
[ 0.066126] pci 0000:05:14.1: reg 0x1c: [io 0x11050-0x11053]
[ 0.066142] pci 0000:05:14.1: reg 0x20: [io 0x11000-0x1100f]
[ 0.066169] pci 0000:05:14.1: legacy IDE quirk: reg 0x18: [io
0x10170-0x10177]
[ 0.066178] pci 0000:05:14.1: legacy IDE quirk: reg 0x1c: [io 0x10376]
[ 0.066293] pci 0000:05:14.2: [1002:4383] type 00 class 0x040300
[ 0.066325] pci 0000:05:14.2: reg 0x10: [mem 0xa0200000-0xa0203fff 64bit]
[ 0.066401] pci 0000:05:14.2: PME# supported from D0 D3hot D3cold
[ 0.066523] pci 0000:05:14.3: [1002:438d] type 00 class 0x060100
[ 0.066698] pci 0000:05:14.4: [1002:4384] type 01 class 0x060400
[ 0.067143] pci 0000:00:11.0: PCI bridge to [bus 05-06]
[ 0.067159] pci 0000:00:11.0: bridge window [io 0x10000-0x13fff]
[ 0.067169] pci 0000:00:11.0: bridge window [mem 0xa0100000-0xa03fffff]
[ 0.067196] pci_bus 0000:06: extended config space not accessible
[ 0.067391] pci 0000:06:05.0: [10ec:8139] type 00 class 0x020000
[ 0.067424] pci 0000:06:05.0: reg 0x10: [io 0x13000-0x130ff]
[ 0.067450] pci 0000:06:05.0: reg 0x14: [mem 0xa0312000-0xa03120ff]
[ 0.067510] pci 0000:06:05.0: reg 0x30: [mem 0xa0300000-0xa030ffff pref]
[ 0.067558] pci 0000:06:05.0: supports D1 D2
[ 0.067565] pci 0000:06:05.0: PME# supported from D1 D2 D3hot
[ 0.067710] pci 0000:06:06.0: [109e:036e] type 00 class 0x040000
[ 0.067743] pci 0000:06:06.0: reg 0x10: [mem 0xa0310000-0xa0310fff pref]
[ 0.067965] pci 0000:06:06.1: [109e:0878] type 00 class 0x048000
[ 0.067997] pci 0000:06:06.1: reg 0x10: [mem 0xa0311000-0xa0311fff pref]
[ 0.068871] pci 0000:05:14.4: PCI bridge to [bus 06]
[ 0.068886] pci 0000:05:14.4: bridge window [io 0x13000-0x13fff]
[ 0.068898] pci 0000:05:14.4: bridge window [mem 0xa0300000-0xa03fffff]
[ 0.069751] pci 0000:00:11.1: PCI bridge to [bus 07]
[ 0.070598] pci 0000:00:11.2: PCI bridge to [bus 08]
[ 0.071437] pci 0000:00:11.3: PCI bridge to [bus 09]
[ 0.071480] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 09
[ 0.071658] PCI 0000:00 Cannot reserve Legacy IO [io 0x10000-0x10fff]
[ 0.071671] pci 0000:00:10.0: bridge window [mem
0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align
100000
[ 0.071697] pci 0000:00:11.0: bridge window [mem
0x00100000-0x000fffff 64bit pref] to [bus 05-06] add_size 200000
add_align 100000
[ 0.071714] pci 0000:00:11.1: bridge window [io 0x1000-0x0fff] to
[bus 07] add_size 1000
[ 0.071726] pci 0000:00:11.1: bridge window [mem
0x00100000-0x000fffff 64bit pref] to [bus 07] add_size 200000 add_align
100000
[ 0.071741] pci 0000:00:11.1: bridge window [mem
0x00100000-0x000fffff] to [bus 07] add_size 200000 add_align 100000
[ 0.071756] pci 0000:00:11.2: bridge window [io 0x1000-0x0fff] to
[bus 08] add_size 1000
[ 0.071767] pci 0000:00:11.2: bridge window [mem
0x00100000-0x000fffff 64bit pref] to [bus 08] add_size 200000 add_align
100000
[ 0.071782] pci 0000:00:11.2: bridge window [mem
0x00100000-0x000fffff] to [bus 08] add_size 200000 add_align 100000
[ 0.071796] pci 0000:00:11.3: bridge window [io 0x1000-0x0fff] to
[bus 09] add_size 1000
[ 0.071808] pci 0000:00:11.3: bridge window [mem
0x00100000-0x000fffff 64bit pref] to [bus 09] add_size 200000 add_align
100000
[ 0.071823] pci 0000:00:11.3: bridge window [mem
0x00100000-0x000fffff] to [bus 09] add_size 200000 add_align 100000
[ 0.071861] pci 0000:00:10.0: BAR 9: assigned [mem
0x80000000000-0x800001fffff 64bit pref]
[ 0.071877] pci 0000:00:11.0: BAR 9: assigned [mem
0x80000200000-0x800003fffff 64bit pref]
[ 0.071889] pci 0000:00:11.1: BAR 8: assigned [mem 0x80000000-0x801fffff]
[ 0.071901] pci 0000:00:11.1: BAR 9: assigned [mem
0x80000400000-0x800005fffff 64bit pref]
[ 0.071913] pci 0000:00:11.2: BAR 8: assigned [mem 0x80200000-0x803fffff]
[ 0.071926] pci 0000:00:11.2: BAR 9: assigned [mem
0x80000600000-0x800007fffff 64bit pref]
[ 0.071937] pci 0000:00:11.3: BAR 8: assigned [mem 0x80400000-0x805fffff]
[ 0.071950] pci 0000:00:11.3: BAR 9: assigned [mem
0x80000800000-0x800009fffff 64bit pref]
[ 0.071961] pci 0000:00:11.1: BAR 7: assigned [io 0x14000-0x14fff]
[ 0.071972] pci 0000:00:11.2: BAR 7: assigned [io 0x15000-0x15fff]
[ 0.071983] pci 0000:00:11.3: BAR 7: assigned [io 0x16000-0x16fff]
[ 0.071999] pci 0000:00:10.0: PCI bridge to [bus 01]
[ 0.072008] pci 0000:00:10.0: bridge window [io 0x12000-0x12fff]
[ 0.072019] pci 0000:00:10.0: bridge window [mem 0x90000000-0xa00fffff]
[ 0.072029] pci 0000:00:10.0: bridge window [mem
0x80000000000-0x800001fffff 64bit pref]
[ 0.072041] pci 0000:00:10.1: PCI bridge to [bus 02]
[ 0.072053] pci 0000:00:10.2: PCI bridge to [bus 03]
[ 0.072065] pci 0000:00:10.3: PCI bridge to [bus 04]
[ 0.072082] pci 0000:05:14.4: PCI bridge to [bus 06]
[ 0.072093] pci 0000:05:14.4: bridge window [io 0x13000-0x13fff]
[ 0.072104] pci 0000:05:14.4: bridge window [mem 0xa0300000-0xa03fffff]
[ 0.072118] pci 0000:00:11.0: PCI bridge to [bus 05-06]
[ 0.072127] pci 0000:00:11.0: bridge window [io 0x10000-0x13fff]
[ 0.072137] pci 0000:00:11.0: bridge window [mem 0xa0100000-0xa03fffff]
[ 0.072147] pci 0000:00:11.0: bridge window [mem
0x80000200000-0x800003fffff 64bit pref]
[ 0.072159] pci 0000:00:11.1: PCI bridge to [bus 07]
[ 0.072168] pci 0000:00:11.1: bridge window [io 0x14000-0x14fff]
[ 0.072178] pci 0000:00:11.1: bridge window [mem 0x80000000-0x801fffff]
[ 0.072188] pci 0000:00:11.1: bridge window [mem
0x80000400000-0x800005fffff 64bit pref]
[ 0.072200] pci 0000:00:11.2: PCI bridge to [bus 08]
[ 0.072209] pci 0000:00:11.2: bridge window [io 0x15000-0x15fff]
[ 0.072219] pci 0000:00:11.2: bridge window [mem 0x80200000-0x803fffff]
[ 0.072229] pci 0000:00:11.2: bridge window [mem
0x80000600000-0x800007fffff 64bit pref]
[ 0.072241] pci 0000:00:11.3: PCI bridge to [bus 09]
[ 0.072249] pci 0000:00:11.3: bridge window [io 0x16000-0x16fff]
[ 0.072259] pci 0000:00:11.3: bridge window [mem 0x80400000-0x805fffff]
[ 0.072270] pci 0000:00:11.3: bridge window [mem
0x80000800000-0x800009fffff 64bit pref]
[ 0.072284] pci_bus 0000:00: resource 4 [io 0x10000-0x80ffff]
[ 0.072295] pci_bus 0000:00: resource 5 [mem 0x80000000-0xe00fffff]
[ 0.072305] pci_bus 0000:00: resource 6 [mem 0xfd800000-0xfd800fff]
[ 0.072314] pci_bus 0000:00: resource 7 [mem 0x80000000000-0xbffffffffff]
[ 0.072324] pci_bus 0000:01: resource 0 [io 0x12000-0x12fff]
[ 0.072333] pci_bus 0000:01: resource 1 [mem 0x90000000-0xa00fffff]
[ 0.072343] pci_bus 0000:01: resource 2 [mem
0x80000000000-0x800001fffff 64bit pref]
[ 0.072354] pci_bus 0000:05: resource 0 [io 0x10000-0x13fff]
[ 0.072363] pci_bus 0000:05: resource 1 [mem 0xa0100000-0xa03fffff]
[ 0.072373] pci_bus 0000:05: resource 2 [mem
0x80000200000-0x800003fffff 64bit pref]
[ 0.072383] pci_bus 0000:06: resource 0 [io 0x13000-0x13fff]
[ 0.072393] pci_bus 0000:06: resource 1 [mem 0xa0300000-0xa03fffff]
[ 0.072402] pci_bus 0000:07: resource 0 [io 0x14000-0x14fff]
[ 0.072412] pci_bus 0000:07: resource 1 [mem 0x80000000-0x801fffff]
[ 0.072421] pci_bus 0000:07: resource 2 [mem
0x80000400000-0x800005fffff 64bit pref]
[ 0.072431] pci_bus 0000:08: resource 0 [io 0x15000-0x15fff]
[ 0.072441] pci_bus 0000:08: resource 1 [mem 0x80200000-0x803fffff]
[ 0.072450] pci_bus 0000:08: resource 2 [mem
0x80000600000-0x800007fffff 64bit pref]
[ 0.072460] pci_bus 0000:09: resource 0 [io 0x16000-0x16fff]
[ 0.072469] pci_bus 0000:09: resource 1 [mem 0x80400000-0x805fffff]
[ 0.072479] pci_bus 0000:09: resource 2 [mem
0x80000800000-0x800009fffff 64bit pref]
[ 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
[ 0.082932] HugeTLB registered 16.0 MiB page size, pre-allocated 0 pages
[ 0.099632] raid6: altivecx8 gen() 4750 MB/s
[ 0.116688] raid6: altivecx4 gen() 4666 MB/s
[ 0.133744] raid6: altivecx2 gen() 4253 MB/s
[ 0.150794] raid6: altivecx1 gen() 3729 MB/s
[ 0.167859] raid6: int64x8 gen() 2118 MB/s
[ 0.184915] raid6: int64x8 xor() 1114 MB/s
[ 0.201961] raid6: int64x4 gen() 2569 MB/s
[ 0.219020] raid6: int64x4 xor() 1083 MB/s
[ 0.236070] raid6: int64x2 gen() 2200 MB/s
[ 0.253129] raid6: int64x2 xor() 1168 MB/s
[ 0.270173] raid6: int64x1 gen() 1501 MB/s
[ 0.287238] raid6: int64x1 xor() 459 MB/s
[ 0.287246] raid6: using algorithm altivecx8 gen() 4750 MB/s
[ 0.287252] raid6: using intx1 recovery algorithm
[ 0.287526] SCSI subsystem initialized
[ 0.287622] libata version 3.00 loaded.
[ 0.287734] usbcore: registered new interface driver usbfs
[ 0.287768] usbcore: registered new interface driver hub
[ 0.287795] usbcore: registered new device driver usb
[ 0.287907] EDAC MC: Ver: 3.0.0
[ 0.288213] Advanced Linux Sound Architecture Driver Initialized.
[ 0.288624] clocksource: Switched to clocksource timebase
[ 0.579813] VFS: Disk quotas dquot_6.6.0
[ 0.579872] VFS: Dquot-cache hash table entries: 512 (order 0, 4096
bytes)
[ 0.583168] NET: Registered PF_INET protocol family
[ 0.583501] IP idents hash table entries: 131072 (order: 8, 1048576
bytes, linear)
[ 0.585890] tcp_listen_portaddr_hash hash table entries: 4096 (order:
4, 65536 bytes, linear)
[ 0.585951] TCP established hash table entries: 65536 (order: 7,
524288 bytes, linear)
[ 0.586231] TCP bind hash table entries: 65536 (order: 8, 1048576
bytes, linear)
[ 0.586689] TCP: Hash tables configured (established 65536 bind 65536)
[ 0.586773] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear)
[ 0.586866] UDP-Lite hash table entries: 4096 (order: 5, 131072
bytes, linear)
[ 0.587060] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.587418] RPC: Registered named UNIX socket transport module.
[ 0.587430] RPC: Registered udp transport module.
[ 0.587436] RPC: Registered tcp transport module.
[ 0.587442] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.588064] pci 0000:01:00.1: D0 power state depends on 0000:01:00.0
[ 0.588806] PCI: CLS 64 bytes, default 128
[ 0.589686] OF: /localbus@f0000000/cf@1000000: could not find phandle 14
[ 0.589709] OF: /localbus@f0000000/cf@1000000: could not find phandle 1
[ 0.589726] OF: /localbus@f0000000/cf@1000000: could not find phandle 10
[ 0.589744] OF: /localbus@f0000000/cf@1000000: could not find phandle 11
[ 0.590166] libphy: pasemi gpio mdio bus: probed
[ 0.978292] Initialise system trusted keyrings
[ 0.978376] workingset: timestamp_bits=62 max_order=21 bucket_order=0
[ 0.978735] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.979061] NFS: Registering the id_resolver key type
[ 0.979080] Key type id_resolver registered
[ 0.979087] Key type id_legacy registered
[ 0.979107] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.979115] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver
Registering...
[ 0.979437] Key type cifs.idmap registered
[ 0.979645] ntfs: driver 2.1.32 [Flags: R/W].
[ 0.979677] ntfs3: Max link count 4000
[ 0.979684] ntfs3: Read-only LZX/Xpress compression included
[ 0.979780] fuse: init (API version 7.35)
[ 1.035583] xor: measuring software checksum speed
[ 1.038421] 8regs : 3488 MB/sec
[ 1.041493] 8regs_prefetch : 3213 MB/sec
[ 1.044209] 32regs : 3631 MB/sec
[ 1.047272] 32regs_prefetch : 3220 MB/sec
[ 1.048919] altivec : 6024 MB/sec
[ 1.048931] xor: using function: altivec (6024 MB/sec)
[ 1.048939] Key type asymmetric registered
[ 1.048945] Asymmetric key parser 'x509' registered
[ 1.049016] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 251)
[ 1.049028] io scheduler mq-deadline registered
[ 1.049035] io scheduler kyber registered
[ 1.049060] io scheduler bfq registered
[ 1.051738] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 1.052403] serial8250.0: ttyS0 at I/O 0x8003f8 (irq = 73, base_baud
= 8333333) is a 16550A
[ 1.052656] serial8250.0: ttyS1 at I/O 0x8002f8 (irq = 74, base_baud
= 8333333) is a 16550A
[ 1.053189] 0000:00:1d.0: ttyS0 at I/O 0x8003f8 (irq = 73, base_baud
= 8333333) is a 16550A
[ 1.053529] 0000:00:1d.1: ttyS1 at I/O 0x8002f8 (irq = 74, base_baud
= 8333333) is a 16550A
[ 1.054168] Registering PA Semi RNG
[ 1.054268] Linux agpgart interface v0.103
[ 1.054366] [drm] radeon kernel modesetting enabled.
[ 1.054886] [drm] initializing kernel modesetting (CAYMAN
0x1002:0x6718 0x1682:0x3130 0x00).
[ 1.221841] ATOM BIOS: CAYMAN
[ 1.221921] radeon 0000:01:00.0: VRAM: 2048M 0x0000000000000000 -
0x000000007FFFFFFF (2048M used)
[ 1.221937] radeon 0000:01:00.0: GTT: 1024M 0x0000000080000000 -
0x00000000BFFFFFFF
[ 1.221948] [drm] Detected VRAM RAM=2048M, BAR=256M
[ 1.221954] [drm] RAM width 256bits DDR
[ 1.221962] radeon 0000:01:00.0: dma_iommu_get_required_mask:
returning bypass mask 0x3ffffffff
[ 1.222016] [drm] radeon: 2048M of VRAM memory ready
[ 1.222025] [drm] radeon: 1024M of GTT memory ready.
[ 1.222046] [drm] Loading CAYMAN Microcode
[ 1.222066] [drm] Internal thermal controller with fan control
[ 1.228927] [drm] radeon: dpm initialized
[ 1.228978] [drm] GART: num cpu pages 262144, num gpu pages 262144
[ 1.262917] [drm] PCIE GART of 1024M enabled (table at
0x0000000000162000).
[ 1.263044] radeon 0000:01:00.0: WB enabled
[ 1.263056] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr
0x0000000080000c00
[ 1.277343] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr
0x0000000000072118
[ 1.277357] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr
0x0000000080000c04
[ 1.277367] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr
0x0000000080000c08
[ 1.277377] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr
0x0000000080000c0c
[ 1.277387] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr
0x0000000080000c10
[ 1.277745] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[ 1.277791] [drm] radeon: irq initialized.
[ 1.296589] [drm] ring test on 0 succeeded in 2 usecs
[ 1.296611] [drm] ring test on 3 succeeded in 3 usecs
[ 1.296635] [drm] ring test on 4 succeeded in 4 usecs
[ 1.472123] [drm] ring test on 5 succeeded in 2 usecs
[ 1.472138] [drm] UVD initialized successfully.
[ 1.472538] [drm] ib test on ring 0 succeeded in 0 usecs
[ 1.472629] [drm] ib test on ring 3 succeeded in 0 usecs
[ 1.472699] [drm] ib test on ring 4 succeeded in 0 usecs
[ 2.658650] [drm:.uvd_v1_0_ib_test] *ERROR* radeon: fence wait timed out.
[ 2.658673] [drm:.radeon_ib_ring_tests] *ERROR* radeon: failed
testing IB on ring 5 (-110).
[ 2.660317] [drm] Radeon Display Connectors
[ 2.660329] [drm] Connector 0:
[ 2.660335] [drm] DP-1
[ 2.660340] [drm] HPD5
[ 2.660344] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438
0x643c 0x643c
[ 2.660354] [drm] Encoders:
[ 2.660359] [drm] DFP1: INTERNAL_UNIPHY2
[ 2.660365] [drm] Connector 1:
[ 2.660370] [drm] DP-2
[ 2.660374] [drm] HPD4
[ 2.660378] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448
0x644c 0x644c
[ 2.660388] [drm] Encoders:
[ 2.660392] [drm] DFP2: INTERNAL_UNIPHY2
[ 2.660398] [drm] Connector 2:
[ 2.660402] [drm] HDMI-A-1
[ 2.660407] [drm] HPD6
[ 2.660412] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468
0x646c 0x646c
[ 2.660421] [drm] Encoders:
[ 2.660425] [drm] DFP3: INTERNAL_UNIPHY1
[ 2.660431] [drm] Connector 3:
[ 2.660435] [drm] DVI-D-1
[ 2.660440] [drm] HPD1
[ 2.660444] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458
0x645c 0x645c
[ 2.660454] [drm] Encoders:
[ 2.660458] [drm] DFP4: INTERNAL_UNIPHY1
[ 2.660463] [drm] Connector 4:
[ 2.660468] [drm] DVI-I-1
[ 2.660472] [drm] HPD3
[ 2.660477] [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478
0x647c 0x647c
[ 2.660487] [drm] Encoders:
[ 2.660491] [drm] DFP5: INTERNAL_UNIPHY
[ 2.660496] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 2.833919] [drm] fb mappable at 0x90371000
[ 2.833931] [drm] vram apper at 0x90000000
[ 2.833937] [drm] size 7680000
[ 2.833943] [drm] fb depth is 24
[ 2.833948] [drm] pitch is 6400
[ 2.933738] [drm:.ni_dpm_set_power_state] *ERROR*
ni_restrict_performance_levels_before_switch failed
[ 3.060825] Console: switching to colour frame buffer device 200x75
[ 3.156454] radeon 0000:01:00.0: [drm] fb0: radeon frame buffer device
[ 3.156945] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0
on minor 0
[ 3.160478] loop: module loaded
[ 3.161124] ahci 0000:05:12.0: version 3.0
[ 3.161176] ahci 0000:05:12.0: controller can't do 64bit DMA, forcing
32bit
[ 3.161727] ahci 0000:05:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps
0xf impl SATA mode
[ 3.162272] ahci 0000:05:12.0: flags: ncq sntf ilck pm led clo pmp
pio slum part ccc
[ 3.164017] scsi host0: ahci
[ 3.164442] scsi host1: ahci
[ 3.164938] scsi host2: ahci
[ 3.165370] scsi host3: ahci
[ 3.165593] ata1: SATA max UDMA/133 abar m1024@0xa0209000 port
0xa0209100 irq 9
[ 3.166077] ata2: SATA max UDMA/133 abar m1024@0xa0209000 port
0xa0209180 irq 9
[ 3.166542] ata3: SATA max UDMA/133 abar m1024@0xa0209000 port
0xa0209200 irq 9
[ 3.167020] ata4: SATA max UDMA/133 abar m1024@0xa0209000 port
0xa0209280 irq 9
[ 3.168364] scsi host4: pata_atiixp
[ 3.169004] scsi host5: pata_atiixp
[ 3.169255] ata5: PATA max UDMA/100 cmd 0x11030 ctl 0x11054 bmdma
0x11000 irq 9
[ 3.169743] ata6: DUMMY
[ 3.170502] libphy: Fixed MDIO Bus: probed
[ 3.172095] PA Semi PWRficient DMA library initialized (20 tx, 64 rx
channels)
[ 3.173148] eth0: PA Semi GMAC: intf 5, hw addr 02:00:e0:0a:30:00
[ 3.173596] pasemi_mac 0000:00:15.0: no mac address in device tree,
not configuring
[ 3.174300] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22,
2004)
[ 3.174756] 8139cp 0000:06:05.0: This (id 10ec:8139 rev 10) is not an
8139C+ compatible chip, use 8139too
[ 3.175533] 8139too: 8139too Fast Ethernet driver 0.9.28
[ 3.176879] 8139too 0000:06:05.0 eth1: RealTek RTL8139 at
0x(____ptrval____), 00:e0:e8:16:5f:64, IRQ 4
[ 3.177647] PPP generic driver version 2.4.2
[ 3.178039] PPP BSD Compression module registered
[ 3.178321] PPP Deflate Compression module registered
[ 3.178637] NET: Registered PF_PPPOX protocol family
[ 3.178962] orinoco 0.15 (David Gibson
[off-list ref], Pavel Roskin [off-list ref], et al)
[ 3.178968] orinoco_plx 0.15 (Pavel Roskin [off-list ref], David
Gibson [off-list ref], Daniel Barlow [off-list ref])
[ 3.179023] orinoco_pci 0.15 (Pavel Roskin [off-list ref], David
Gibson [off-list ref] & Jean Tourrilhes [off-list ref])
[ 3.179537] electra-cf f0000000.cf: at mem 0xf0000000 io 0xf1000000
irq 17
[ 3.180218] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 3.180702] ehci-pci: EHCI PCI platform driver
[ 3.181047] ehci-pci 0000:05:13.5: EHCI Host Controller
[ 3.181446] ehci-pci 0000:05:13.5: new USB bus registered, assigned
bus number 1
[ 3.181968] ehci-pci 0000:05:13.5: applying AMD SB600/SB700 USB
freeze workaround
[ 3.182489] ehci-pci 0000:05:13.5: debug port 1
[ 3.182836] ehci-pci 0000:05:13.5: irq 12, io mem 0xa0209800
[ 3.189631] ehci-pci 0000:05:13.5: USB 2.0 started, EHCI 1.00
[ 3.190088] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002, bcdDevice= 5.16
[ 3.190670] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 3.191161] usb usb1: Product: EHCI Host Controller
[ 3.191454] usb usb1: Manufacturer: Linux
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty ehci_hcd
[ 3.192123] usb usb1: SerialNumber: 0000:05:13.5
[ 3.212136] hub 1-0:1.0: USB hub found
[ 3.231948] hub 1-0:1.0: 10 ports detected
[ 3.252221] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 3.272329] ohci-pci: OHCI PCI platform driver
[ 3.292394] ohci-pci 0000:05:13.0: OHCI PCI host controller
[ 3.312511] ohci-pci 0000:05:13.0: new USB bus registered, assigned
bus number 2
[ 3.332912] ohci-pci 0000:05:13.0: irq 9, io mem 0xa0207000
[ 3.409702] usb usb2: New USB device found, idVendor=1d6b,
idProduct=0001, bcdDevice= 5.16
[ 3.430734] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 3.451718] usb usb2: Product: OHCI PCI host controller
[ 3.472562] usb usb2: Manufacturer: Linux
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty ohci_hcd
[ 3.478825] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 3.493020] usb usb2: SerialNumber: 0000:05:13.0
[ 3.493259] hub 2-0:1.0: USB hub found
[ 3.512120] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 3.532400] hub 2-0:1.0: 2 ports detected
[ 3.551574] ata2: SATA link down (SStatus 0 SControl 300)
[ 3.572326] ohci-pci 0000:05:13.1: OHCI PCI host controller
[ 3.591355] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 3.612244] ohci-pci 0000:05:13.1: new USB bus registered, assigned
bus number 3
[ 3.631480] ata3.00: ATAPI: HL-DT-ST DVDRAM GH22NS50, TN01, max UDMA/100
[ 3.652503] ohci-pci 0000:05:13.1: irq 10, io mem 0xa0208000
[ 3.672504] ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
[ 3.735426] random: fast init done
[ 3.758824] ata4.00: ATA-8: ESA3SF1240GB, 4.C.V, max UDMA/133
[ 3.761756] usb usb3: New USB device found, idVendor=1d6b,
idProduct=0001, bcdDevice= 5.16
[ 3.779172] ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
[ 3.801009] usb usb3: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 3.821495] ata3.00: configured for UDMA/100
[ 3.843419] usb usb3: Product: OHCI PCI host controller
[ 3.863821] ata4.00: 468862128 sectors, multi 16: LBA48 NCQ (depth
32), AA
[ 3.885517] usb usb3: Manufacturer: Linux
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty ohci_hcd
[ 3.885523] usb usb3: SerialNumber: 0000:05:13.1
[ 3.891826] hub 3-0:1.0: USB hub found
[ 3.917168] ata4.00: ATA Identify Device Log not supported
[ 3.958641] hub 3-0:1.0: 2 ports detected
[ 3.971380] ata4.00: SB600 AHCI: limiting to 255 sectors per cmd
[ 4.029869] ohci-pci 0000:05:13.2: OHCI PCI host controller
[ 4.062345] usb 2-1: new low-speed USB device number 2 using ohci-pci
[ 4.085640] ata1.00: ATA-8: ST2000DM001-9YN164, CC4B, max UDMA/133
[ 4.087801] ohci-pci 0000:05:13.2: new USB bus registered, assigned
bus number 4
[ 4.135980] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card
inserted into slot 0
[ 4.147460] ata1.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth
32), AA
[ 4.165736] pcmcia 0.0: pcmcia: registering new device pcmcia0.0
(IRQ: 17)
[ 4.183897] ohci-pci 0000:05:13.2: irq 11, io mem 0xa0206000
[ 4.211231] ata4.00: ATA Identify Device Log not supported
[ 4.257486] ata4.00: SB600 AHCI: limiting to 255 sectors per cmd
[ 4.283009] ata4.00: configured for UDMA/133
[ 4.309715] ata1.00: ATA Identify Device Log not supported
[ 4.333835] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[ 4.334715] usb usb4: New USB device found, idVendor=1d6b,
idProduct=0001, bcdDevice= 5.16
[ 4.359098] ata1.00: ATA Identify Device Log not supported
[ 4.379777] usb usb4: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 4.401686] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[ 4.425310] usb usb4: Product: OHCI PCI host controller
[ 4.447640] ata1.00: configured for UDMA/133
[ 4.471329] usb usb4: Manufacturer: Linux
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty ohci_hcd
[ 4.471334] usb usb4: SerialNumber: 0000:05:13.2
[ 4.471836] hub 4-0:1.0: USB hub found
[ 4.493767] scsi host6: pata_pcmcia
[ 4.517859] scsi 0:0:0:0: Direct-Access ATA ST2000DM001-9YN1 CC4B
PQ: 0 ANSI: 5
[ 4.540306] ata7: PATA max PIO0 cmd 0x811000 ctl 0x81100e irq 17
[ 4.564947] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks:
(2.00 TB/1.82 TiB)
[ 4.641724] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 4.663257] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 4.663339] hub 4-0:1.0: 2 ports detected
[ 4.738929] ohci-pci 0000:05:13.3: OHCI PCI host controller
[ 4.740471] scsi 2:0:0:0: CD-ROM HL-DT-ST DVDRAM GH22NS50
TN01 PQ: 0 ANSI: 5
[ 4.768267] sd 0:0:0:0: [sda] Write Protect is off
[ 4.786318] ohci-pci 0000:05:13.3: new USB bus registered, assigned
bus number 5
[ 4.809852] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 4.810013] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 4.832875] ata7.00: CFA: SanDisk SDCFB-256, HDX 2.33, max PIO4
[ 4.864688] usb 2-1: New USB device found, idVendor=04d9,
idProduct=1503, bcdDevice= 3.10
[ 4.881221] ata7.00: 501760 sectors, multi 0: LBA
[ 4.881357] ohci-pci 0000:05:13.3: irq 10, io mem 0xa0205000
[ 4.906295] usb 2-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 4.906301] usb 2-1: Product: USB Keyboard
[ 4.906306] usb 2-1: Manufacturer:
[ 4.940649] ata7.00: Read log page 0x00 failed, Emask 0x1
[ 4.999828] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2
(SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1)
[ 5.006126] ata7.00: ATA Identify Device Log not supported
[ 5.030765] usb 3-1: new low-speed USB device number 2 using ohci-pci
[ 5.081110] ata7.00: Read log page 0x00 failed, Emask 0x1
[ 5.109981] usb usb5: New USB device found, idVendor=1d6b,
idProduct=0001, bcdDevice= 5.16
[ 5.129283] ata7.00: ATA Identify Device Log not supported
[ 5.154171] usb usb5: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 5.205769] sda: p4 size 18446744071956107760 extends beyond EOD,
[ 5.230608] usb usb5: Product: OHCI PCI host controller
[ 5.230614] usb usb5: Manufacturer: Linux
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty ohci_hcd
[ 5.230623] usb usb5: SerialNumber: 0000:05:13.3
[ 5.254566] enabling native capacity
[ 5.306505] hub 5-0:1.0: USB hub found
[ 5.384924] sr 2:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dvd-ram
cd/rw xa/form2 cdda tray
[ 5.384957] hub 5-0:1.0: 2 ports detected
[ 5.409138] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 5.434914] ohci-pci 0000:05:13.4: OHCI PCI host controller
[ 5.486163] ohci-pci 0000:05:13.4: new USB bus registered, assigned
bus number 6
[ 5.486415] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2
(SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1)
[ 5.511615] ohci-pci 0000:05:13.4: irq 11, io mem 0xa0204000
[ 5.563643] sda: p4 size 18446744071956107760 extends beyond EOD,
truncated
[ 5.590647] sd 0:0:0:0: [sda] Attached SCSI disk
[ 5.620862] usb usb6: New USB device found, idVendor=1d6b,
idProduct=0001, bcdDevice= 5.16
[ 5.620954] sr 2:0:0:0: Attached scsi CD-ROM sr0
[ 5.646591] usb usb6: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 5.674487] usb usb6: Product: OHCI PCI host controller
[ 5.674676] sr 2:0:0:0: Attached scsi generic sg1 type 5
[ 5.700210] usb usb6: Manufacturer: Linux
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty ohci_hcd
[ 5.700216] usb usb6: SerialNumber: 0000:05:13.4
[ 5.724716] scsi 3:0:0:0: Direct-Access ATA ESA3SF1240GB V
PQ: 0 ANSI: 5
[ 5.756738] usb 3-1: New USB device found, idVendor=046a,
idProduct=000c, bcdDevice= 8.10
[ 5.776359] sd 3:0:0:0: [sdb] 468862128 512-byte logical blocks: (240
GB/224 GiB)
[ 5.802314] usb 3-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 5.827444] sd 3:0:0:0: [sdb] Write Protect is off
[ 5.854083] hub 6-0:1.0: USB hub found
[ 5.878987] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 5.905425] hub 6-0:1.0: 2 ports detected
[ 5.930185] sd 3:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 5.955836] sd 3:0:0:0: Attached scsi generic sg2 type 0
[ 5.981355] usbcore: registered new interface driver usblp
[ 6.034298] scsi 6:0:0:0: Direct-Access ATA SanDisk SDCFB-25
2.33 PQ: 0 ANSI: 5
[ 6.062753] sd 6:0:0:0: [sdc] 501760 512-byte logical blocks: (257
MB/245 MiB)
[ 6.090218] sd 6:0:0:0: Attached scsi generic sg3 type 0
[ 6.090268] sd 6:0:0:0: [sdc] Write Protect is off
[ 6.143553] sd 6:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 6.143834] usbcore: registered new interface driver usb-storage
[ 6.171758] usbcore: registered new interface driver usbserial_generic
[ 6.173722] sdb: sdb1 sdb2 < sdb5 sdb6 > sdb3 sdb4
[ 6.197876] usbserial: USB Serial support registered for generic
[ 6.222916] sd 3:0:0:0: [sdb] Attached SCSI disk
[ 6.248827] usbcore: registered new interface driver ftdi_sio
[ 6.272884] sd 6:0:0:0: [sdc] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[ 6.298116] usbserial: USB Serial support registered for FTDI USB
Serial Device
[ 6.351325] usbcore: registered new interface driver option
[ 6.353315] sdc: sdc1
[ 6.377769] usbserial: USB Serial support registered for GSM modem
(1-port)
[ 6.401974] usb 6-1: new full-speed USB device number 2 using ohci-pci
[ 6.454874] mousedev: PS/2 mouse device common for all mice
[ 6.455301] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[ 6.481450] usbcore: registered new interface driver synaptics_usb
[ 6.534824] usbcore: registered new interface driver iforce
[ 6.562511] usbcore: registered new interface driver xpad
[ 6.590406] usbcore: registered new interface driver usb_acecad
[ 6.617930] usbcore: registered new interface driver aiptek
[ 6.644915] usbcore: registered new interface driver hanwang
[ 6.671439] usbcore: registered new interface driver kbtab
[ 6.697522] rtc_cmos rtc_cmos: not accessible
[ 6.723231] i2c_dev: i2c /dev entries driver
[ 6.750148] IR NEC protocol handler initialized
[ 6.775548] IR RC5(x/sz) protocol handler initialized
[ 6.800784] IR RC6 protocol handler initialized
[ 6.826136] IR JVC protocol handler initialized
[ 6.851243] IR Sony protocol handler initialized
[ 6.875871] IR SANYO protocol handler initialized
[ 6.877740] usb 6-1: New USB device found, idVendor=0a12,
idProduct=0001, bcdDevice=88.91
[ 6.898488] IR Sharp protocol handler initialized
[ 6.919924] usb 6-1: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[ 6.942634] IR MCE Keyboard/mouse protocol handler initialized
[ 6.964106] usb 6-1: Product: CSR8510 A10
[ 6.986809] IR XMP protocol handler initialized
[ 7.049632] i2c i2c-10: Detected TI TMP423 chip at 0x4c
[ 7.123825] EDAC MC0: Giving out device to module pasemi_edac
controller pasemi,pwrficient-mc: DEV 0000:00:04.0 (POLLED)
[ 7.148039] EDAC MC1: Giving out device to module pasemi_edac
controller pasemi,pwrficient-mc: DEV 0000:00:05.0 (POLLED)
[ 7.183592] input: USB Keyboard as
/devices/pci0000:00/0000:00:11.0/0000:05:13.0/usb2/2-1/2-1:1.0/0003:04D9:1503.0001/input/input0
[ 7.258634] usb 6-2: new full-speed USB device number 3 using ohci-pci
[ 7.282690] hid-generic 0003:04D9:1503.0001: input: USB HID v1.10
Keyboard [ USB Keyboard] on usb-0000:05:13.0-1/input0
[ 7.325528] input: USB Keyboard System Control as
/devices/pci0000:00/0000:00:11.0/0000:05:13.0/usb2/2-1/2-1:1.1/0003:04D9:1503.0002/input/input1
[ 7.402763] input: USB Keyboard Consumer Control as
/devices/pci0000:00/0000:00:11.0/0000:05:13.0/usb2/2-1/2-1:1.1/0003:04D9:1503.0002/input/input2
[ 7.427938] hid-generic 0003:04D9:1503.0002: input: USB HID v1.10
Device [ USB Keyboard] on usb-0000:05:13.0-1/input1
[ 7.458556] input: HID 046a:000c as
/devices/pci0000:00/0000:00:11.0/0000:05:13.1/usb3/3-1/3-1:1.0/0003:046A:000C.0003/input/input3
[ 7.484913] hid-generic 0003:046A:000C.0003: input: USB HID v1.00
Mouse [HID 046a:000c] on usb-0000:05:13.1-1/input0
[ 7.511230] usbcore: registered new interface driver usbhid
[ 7.536989] usbhid: USB HID core driver
[ 7.562841] no UART detected at 0x1
[ 7.588946] usbcore: registered new interface driver snd-usb-audio
[ 7.614455] usbcore: registered new interface driver snd-ua101
[ 7.639612] usbcore: registered new interface driver snd-usb-usx2y
[ 7.639751] usb 6-2: New USB device found, idVendor=03ee,
idProduct=6901, bcdDevice= 2.00
[ 7.664159] usbcore: registered new interface driver snd-usb-caiaq
[ 7.687139] usb 6-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 7.711584] usbcore: registered new interface driver snd-usb-6fire
[ 7.734355] usb 6-2: Product: MITSUMI0
[ 7.758870] usbcore: registered new interface driver snd-usb-hiface
[ 7.781027] usb 6-2: Manufacturer: MITSUMI0
[ 7.781814] usb-storage 6-2:1.0: USB Mass Storage device detected
[ 7.805267] usbcore: registered new interface driver snd-bcd2000
[ 7.827419] scsi host7: usb-storage 6-2:1.0
[ 7.851040] usbcore: registered new interface driver snd_usb_pod
[ 7.924429] usbcore: registered new interface driver snd_usb_podhd
[ 7.949755] usbcore: registered new interface driver snd_usb_toneport
[ 7.974904] usbcore: registered new interface driver snd_usb_variax
[ 8.001495] ipip: IPv4 and MPLS over IPv4 tunneling driver
[ 8.026479] Initializing XFRM netlink socket
[ 8.050936] NET: Registered PF_INET6 protocol family
[ 8.076057] Segment Routing with IPv6
[ 8.100278] In-situ OAM (IOAM) with IPv6
[ 8.124614] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 8.149423] NET: Registered PF_PACKET protocol family
[ 8.173796] NET: Registered PF_KEY protocol family
[ 8.196669] Key type dns_resolver registered
[ 8.219434] drmem: No dynamic reconfiguration memory found
[ 8.242079] No cpufreq driver, powersavings modes disabled
[ 8.264372] Using PA6T idle loop (spin)
[ 8.286246] Loading compiled-in X.509 certificates
[ 8.308478] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no
[ 8.332960] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[ 8.356381] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 8.378632] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
[ 8.401114] ALSA device list:
[ 8.423353] cfg80211: failed to load regulatory.db
[ 8.423367] No soundcards found.
[ 8.473902] EXT4-fs (sdb4): mounted filesystem with ordered data
mode. Opts: (null). Quota mode: none.
[ 8.498866] VFS: Mounted root (ext4 filesystem) readonly on device 8:20.
[ 8.525149] devtmpfs: mounted
[ 8.554942] Freeing unused kernel image (initmem) memory: 7428K
[ 8.580600] Kernel memory protection not selected by kernel config.
[ 8.606377] Run /sbin/init as init process
[ 8.632072] with arguments:
[ 8.632075] /sbin/init
[ 8.632078] with environment:
[ 8.632080] HOME=/
[ 8.632082] TERM=linux
[ 8.757046] systemd[1]: System time before build time, advancing clock.
[ 8.807918] systemd[1]: systemd 245.5-3 running in system mode. (+PAM
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN
+PCRE2 default-hierarchy=hybrid)
[ 8.863795] systemd[1]: Detected architecture ppc64.
[ 8.944790] scsi 7:0:0:0: Direct-Access MITSUMI USB UFDD 061M
0.00 PQ: 0 ANSI: 0 CCS
[ 8.945312] sd 7:0:0:0: Attached scsi generic sg4 type 0
[ 9.040772] sd 7:0:0:0: [sdd] 2880 512-byte logical blocks: (1.47
MB/1.41 MiB)
[ 9.041272] systemd[1]: Set hostname to <Fienix>.
[ 9.104777] sd 7:0:0:0: [sdd] Write Protect is off
[ 9.130963] sd 7:0:0:0: [sdd] Mode Sense: 00 46 02 00
[ 9.232814] sd 7:0:0:0: [sdd] No Caching mode page found
[ 9.260401] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[ 9.631896] random: systemd: uninitialized urandom read (16 bytes read)
[ 9.659591] systemd[1]: system-getty.slice: unit configures an IP
firewall, but the local system does not support BPF/cgroup firewalling.
[ 9.685758] systemd[1]: (This warning is only shown for the first
unit using IP firewalling.)
[ 9.712169] systemd[1]: Created slice system-getty.slice.
[ 9.764653] random: systemd: uninitialized urandom read (16 bytes read)
[ 9.789436] systemd[1]: Created slice system-modprobe.slice.
[ 9.838997] random: systemd: uninitialized urandom read (16 bytes read)
[ 9.862399] systemd[1]: Created slice User and Session Slice.
[ 9.910425] systemd[1]: Started Dispatch Password Requests to Console
Directory Watch.
[ 9.959537] systemd[1]: Started Forward Password Requests to Wall
Directory Watch.
[ 10.009994] systemd[1]: Condition check resulted in Arbitrary
Executable File Formats File System Automount Point being skipped.
[ 10.034884] sdd: sdd1
[ 10.034944] systemd[1]: Reached target Local Encrypted Volumes.
[ 10.108573] systemd[1]: Reached target User and Group Name Lookups.
[ 10.160128] systemd[1]: Reached target Slices.
[ 10.211492] systemd[1]: Reached target Swap.
[ 10.224794] sd 7:0:0:0: [sdd] Attached SCSI removable disk
[ 10.287818] systemd[1]: Listening on RPCbind Server Activation Socket.
[ 10.340055] systemd[1]: Listening on Syslog Socket.
[ 10.392885] systemd[1]: Listening on fsck to fsckd communication Socket.
[ 10.446122] systemd[1]: Listening on initctl Compatibility Named Pipe.
[ 10.518755] systemd[1]: Condition check resulted in Journal Audit
Socket being skipped.
[ 10.545084] systemd[1]: Listening on Journal Socket (/dev/log).
[ 10.599772] systemd[1]: Listening on Journal Socket.
[ 10.654584] systemd[1]: Listening on udev Control Socket.
[ 10.709340] systemd[1]: Listening on udev Kernel Socket.
[ 10.765834] systemd[1]: Mounting Huge Pages File System...
[ 10.822232] systemd[1]: Mounting POSIX Message Queue File System...
[ 10.878087] systemd[1]: Mounting Kernel Debug File System...
[ 10.934031] systemd[1]: Mounting Kernel Trace File System...
[ 10.992435] systemd[1]: Starting Create list of static device nodes
for the current kernel...
[ 11.046862] systemd[1]: Condition check resulted in Load Kernel
Module drm being skipped.
[ 11.075135] systemd[1]: Condition check resulted in Set Up Additional
Binary Formats being skipped.
[ 11.103037] systemd[1]: Starting File System Check on Root Device...
[ 11.158532] systemd[1]: Starting Journal Service...
[ 11.216555] systemd[1]: Starting Load Kernel Modules...
[ 11.273883] systemd[1]: Starting udev Coldplug all Devices...
[ 11.328936] systemd[1]: Mounted Huge Pages File System.
[ 11.380144] systemd[1]: Mounted POSIX Message Queue File System.
[ 11.442063] systemd[1]: Mounted Kernel Debug File System.
[ 11.495459] systemd[1]: Mounted Kernel Trace File System.
[ 11.546689] systemd[1]: Finished Create list of static device nodes
for the current kernel.
[ 11.602613] systemd[1]: Finished File System Check on Root Device.
[ 11.654110] systemd[1]: Finished Load Kernel Modules.
[ 11.705304] systemd[1]: Started Journal Service.
[ 12.460319] random: crng init done
[ 12.484063] random: 7 urandom warning(s) missed due to ratelimiting
[ 16.628718] EXT4-fs (sdb4): re-mounted. Opts: errors=remount-ro.
Quota mode: none.
[ 16.704836] systemd-journald[680]: Received client request to flush
runtime journal.
[ 16.707532] systemd-journald[680]: File
/var/log/journal/5e7ed5c6779c413ea5ee69ea7d714121/system.journal
corrupted or uncleanly shut down, renaming and replacing.
[ 17.949919] snd_hda_intel 0000:01:00.1: Force to snoop mode by module
option
[ 18.096439] snd_hda_intel 0000:05:14.2: Force to snoop mode by module
option
[ 18.310054] input: HDA ATI HDMI HDMI/DP,pcm=3 as
/devices/pci0000:00/0000:00:10.0/0000:01:00.1/sound/card0/input4
[ 18.344429] snd_bt87x 0000:06:06.1: bt87x0: Using board 1, analog,
digital (rate 32000 Hz)
[ 18.371025] 8139too 0000:06:05.0 enp6s5: renamed from eth1
[ 18.405916] mc: Linux media interface: v0.10
[ 18.533664] Bluetooth: Core ver 2.22
[ 18.533724] NET: Registered PF_BLUETOOTH protocol family
[ 18.533728] Bluetooth: HCI device and connection manager initialized
[ 18.533746] Bluetooth: HCI socket layer initialized
[ 18.533752] Bluetooth: L2CAP socket layer initialized
[ 18.533769] Bluetooth: SCO socket layer initialized
[ 18.633172] videodev: Linux video capture interface: v2.00
[ 18.765542] pasemi_mac 0000:00:14.3 enp0s20f3: renamed from eth0
[ 18.767270] snd_hda_codec_idt hdaudioC1D3: autoconfig for
STAC92HD700: line_outs=4 (0xd/0xf/0x10/0x11/0x0) type:line
[ 18.809554] snd_hda_codec_idt hdaudioC1D3: speaker_outs=0
(0x0/0x0/0x0/0x0/0x0)
[ 18.831465] snd_hda_codec_idt hdaudioC1D3: hp_outs=1
(0xa/0x0/0x0/0x0/0x0)
[ 18.853180] snd_hda_codec_idt hdaudioC1D3: mono: mono_out=0x0
[ 18.874639] snd_hda_codec_idt hdaudioC1D3: dig-out=0x21/0x0
[ 18.895764] snd_hda_codec_idt hdaudioC1D3: inputs:
[ 18.916794] snd_hda_codec_idt hdaudioC1D3: Front Mic=0xb
[ 18.937629] snd_hda_codec_idt hdaudioC1D3: Rear Mic=0xe
[ 18.958268] snd_hda_codec_idt hdaudioC1D3: Line=0xc
[ 18.978599] snd_hda_codec_idt hdaudioC1D3: CD=0x12
[ 19.017813] usbcore: registered new interface driver btusb
[ 19.102053] Bluetooth: hci0: CSR: Unbranded CSR clone detected;
adding workarounds and force-suspending once...
[ 19.122586] Bluetooth: hci0: CSR: Failed to suspend the device for
our Barrot 8041a02 receive-issue workaround
[ 19.164360] input: HDA ATI SB Front Mic as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input5
[ 19.371081] input: HDA ATI SB Rear Mic as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input6
[ 19.534180] input: HDA ATI SB Line as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input7
[ 19.686287] bttv: driver version 0.9.19 loaded
[ 19.709247] bttv: using 8 buffers with 2080k (520 pages) each for capture
[ 19.740670] input: HDA ATI SB Line Out Front as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input8
[ 19.754750] bttv: Bt8xx card found (0)
[ 19.789940] input: HDA ATI SB Line Out Surround as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input9
[ 19.807143] bttv: 0: Bt878 (rev 17) at 0000:06:06.0, irq: 5, latency:
255, mmio: 0xa0310000
[ 19.839853] input: HDA ATI SB Line Out CLFE as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input10
[ 19.864668] bttv: 0: detected: Hauppauge WinTV [card=10], PCI
subsystem ID is 0070:13eb
[ 19.887950] bttv: 0: using: Hauppauge (bt878) [card=10,autodetected]
[ 19.897998] input: HDA ATI SB Line Out Side as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input11
[ 19.917744] bttv: 0: Hauppauge/Voodoo msp34xx: reset line init [5]
[ 19.978854] input: HDA ATI SB Front Headphone as
/devices/pci0000:00/0000:00:11.0/0000:05:14.2/sound/card1/input12
[ 20.036191] tveeprom: Hauppauge model 44804, rev D148, serial# 6430449
[ 20.060037] tveeprom: tuner model is LG TP18PSB11D (idx 48, type 29)
[ 20.083753] tveeprom: TV standards PAL(B/G) (eeprom 0x04)
[ 20.107808] tveeprom: audio processor is None (idx 0)
[ 20.131671] tveeprom: has no radio
[ 20.155905] bttv: 0: Hauppauge eeprom indicates model#44804
[ 20.178228] bttv: 0: tuner type=29
[ 20.266849] bttv: 0: audio absent, no audio device found!
[ 20.310887] tuner: 13-0061: Tuner -1 found with type(s) Radio TV.
[ 20.345589] tuner-simple 13-0061: creating new instance
[ 20.345599] tuner-simple 13-0061: type set to 29 (LG PAL_BG (TPI8PSB11D))
[ 20.346821] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up to
100ms)
[ 20.370626] bttv: PLL set ok
[ 20.462363] bttv: 0: registered device video0
[ 20.462754] bttv: 0: registered device vbi0
[ 21.437740] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 21.437749] Bluetooth: BNEP filters: protocol multicast
[ 21.437759] Bluetooth: BNEP socket layer initialized
[ 21.802099] Bluetooth: hci0: expected 8706 bytes, got 36 bytes
[ 23.902081] 8139too 0000:06:05.0 enp6s5: link down
[ 26.152031] enp0s20f3: Link is up at 1000 Mbps, full duplex.
[ 26.171163] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20f3: link becomes ready
[ 30.290828] Bluetooth: RFCOMM TTY layer initialized
[ 30.290851] Bluetooth: RFCOMM socket layer initialized
[ 30.290866] Bluetooth: RFCOMM ver 1.11
[ 103.076207] FAT-fs (sdc1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.
From: Christian Zigotzky <hidden> Date: 2021-11-12 10:12:12
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.
@@ -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
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
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
From: Christian Zigotzky <hidden> Date: 2021-11-12 11:01:14
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.
@@ -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
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
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
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
From: Marc Zyngier <maz@kernel.org> Date: 2021-11-12 13:41:52
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.
@@ -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){+boolintc=of_property_read_bool(ipar,"interrupt-controller");+/**Nowcheckifcursorisaninterrupt-controllerand*ifitisthenwearedone,unlessthereisan*interrupt-mapwhichtakesprecedence.*/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");return0;}
@@ -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);+return0;+}+gotofail;+}/**Successfullyparsedaninterrrupt-maptranslation;copynew
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Thanks for testing it. I'll turn that into a proper patch.
M.
--
Without deviation from the norm, progress is not possible.
From: Christian Zigotzky <hidden> Date: 2021-11-12 14:16:15
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.
@@ -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){+boolintc=of_property_read_bool(ipar,"interrupt-controller");+/**Nowcheckifcursorisaninterrupt-controllerand*ifitisthenwearedone,unlessthereisan*interrupt-mapwhichtakesprecedence.*/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");return0;}
@@ -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);+return0;+}+gotofail;+}/**Successfullyparsedaninterrrupt-maptranslation;copynew
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Thanks for testing it. I'll turn that into a proper patch.
M.
Could you please explain your patch? I am not a developer. I work for
the A-EON Linux FLS.
- Christian
From: Marc Zyngier <maz@kernel.org> Date: 2021-11-12 14:46:47
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.
@@ -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){+boolintc=of_property_read_bool(ipar,"interrupt-controller");+/**Nowcheckifcursorisaninterrupt-controllerand*ifitisthenwearedone,unlessthereisan*interrupt-mapwhichtakesprecedence.*/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");return0;}
@@ -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);+return0;+}+gotofail;+}/**Successfullyparsedaninterrrupt-maptranslation;copynew
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Thanks for testing it. I'll turn that into a proper patch.
M.
Could you please explain your patch?
Please refer to the commit message[1].
I am not a developer. I work for the A-EON Linux FLS.