xeno74 wrote: ↑Sun May 02, 2021 3:01 am... You can install ["lspci"] with "apt install pciutils" as root.
I had tried "apt-get install lspci." Probably too late for me to (re?)learn how to use apt.
Now "lspci" works, but says nothing about "SI" or "NI," only that it is Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]. I already knew it was 7000 series, and when I look that up it says "Southern Islands," so now I know what SI and NI (6000 series) stand for. Thanks. How long will I remember?
kilaueabart wrote: ↑Sun May 02, 2021 7:25 pm
I had tried "apt-get install lspci." Probably too late for me to (re?)learn how to use apt.
Now "lspci" works, but says nothing about "SI" or "NI," only that it is Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]. I already knew it was 7000 series, and when I look that up it says "Southern Islands," so now I know what SI and NI (6000 series) stand for. Thanks. How long will I remember?
Many thanks for your answer. It seems, that SI graphics cards aren’t affected by the boot issue.
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Fri Feb 19 17:56:48 2021 +0100
powerpc/mm: Move the linear_mapping_mutex to the ifdef where it is used
The mutex linear_mapping_mutex is defined at the of the file while its
only two user are within the CONFIG_MEMORY_HOTPLUG block.
A compile without CONFIG_MEMORY_HOTPLUG set fails on PREEMPT_RT because
its mutex implementation is smart enough to realize that it is unused.
Move the definition of linear_mapping_mutex to ifdef block where it is
used.
Fixes: 1f73ad3e8d755 ("powerpc/mm: print warning in arch_remove_linear_mapping()")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210219165648.2505482-1-bigeasy@linutronix.de
:040000 040000 b302c47d33c9abc346f8f40a25e1c3fea7aaa1a1 d901ba0772167c5bfcfae83b05b0c8dc31e03b72 M arch
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date: Fri Mar 19 11:06:58 2021 +0000
powerpc/signal32: Convert do_setcontext[_tm]() to user access block
Add unsafe_get_user_sigset() and transform PPC32 get_sigset_t()
into an unsafe version unsafe_get_sigset_t().
Then convert do_setcontext() and do_setcontext_tm() to use
user_read_access_begin/end.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/9273ba664db769b8d9c7540ae91395e346e4945e.1616151715.git.christophe.leroy@csgroup.eu
:040000 040000 70b717cd4e7540b3979b05dbe25a276dde0dfd16 91a5ce612e5bb3abcb0721b9990e6ce1643dacc1 M arch
Christophe wrote:
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.
As you suspect the problem to be specific to powerpc, I can do
git bisect start -- arch/powerpc
You said that powerpc-5.13-1 is bad so you can narrow the search I think:
git bisect bad powerpc-5.13-1 or git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
git bisect good 887f3ceb51cd3~
git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
git bisect bad (NISLANDS_SMC_HW_PERFORMANCE_LEVEL levels[1])
git bisect bad (NISLANDS_SMC_HW_PERFORMANCE_LEVEL levels[1]) It stops after loading the dtb and uImage. Maybe a third bug.
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.
I reported the result to the PowerPC kernel developers today.