RPi3 not using SMP?

[Mark Millard]

On 2020-Feb-8, at 03:44, Michael Tuexen <tuexen at freebsd.org> wrote:

> 
> 
>> On 8. Feb 2020, at 03:46, Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:
>> 
>> 
>> 
>> On 2020-Feb-7, at 17:19, bob prohaska <fbsd at www.zefox.net> wrote:
>> 
>>> For some weeks now an RPi3 running -current has seemed rather slow....
>>> 
>>> On looking at the early part of the boot message the processor
>>> attributes seem rather scant:
>>> 
>>> ......
>>> elease APs...APs not started
>>> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>>> Instruction Set Attributes 0 = <CRC32>
>>> Instruction Set Attributes 1 = <>
>>>      Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
>>>      Processor Features 1 = <>
>>>   Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,1TB PA>
>>>   Memory Model Features 1 = <8bit VMID>
>>>   Memory Model Features 2 = <32bit CCIDX,48bit VA>
>>>          Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8>
>>>          Debug Features 1 = <>
>>>      Auxiliary Features 0 = <>
>>>      Auxiliary Features 1 = <>
>>> CPU  1: (null) (null) r0p0 affinity:  0
>>> CPU  2: (null) (null) r0p0 affinity:  0
>>> CPU  3: (null) (null) r0p0 affinity:  0
>>> ............
>>> In a top window, STATE is reported as RUN, rather than the
>>> former CPUn.
>>> 
>>> Is a software switch now required to enable multiprocessing?
>>> 
>>> Or, could it be related to  the lines:
>>> psci0: PSCI version number mismatched with DT 
>>> as pointed out by Mark M in reference to the cpu_reset failed
>>> problem, which is still manifest? 
>>> 
>>> The kernel is at r357644.
>> 
>> Head -r356767's kernel does not have this problem for RPi3/4 used as
>> aarch64 FreeBSD.
>> 
>> Head -r356776 and later all have this problem for both RPi3 and RPi4.
>> 
>> Note: There are no head versions between those.
> Did you ping Jeff (CCed), since it is his commit and he might know what is going on?

My messages that contained additional evidence had
jeff listed, including the one that you replied to.

I've tended to remove Jeff from my messages that did
not contain new evidence, including this message.

I've not come up with any new ways to get potentially
useful information. Other things than PSCI may be
messed up. It is just the PSCI is the only thing with
identified evidence and some known way to test for
the problem being present vs. not.

> Best regards
> Michael
>> 
>> The console log shows evidence of the problem much earlier.
>> Instead of saying:
>> 
>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>> psci0: PSCI version 0.2 compatible
>> 
>> (once) it says:
>> 
>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>> psci0: PSCI version number 0 mismatched with DT, default 2
>> device_attach: psci0 attach returned 6
>> 
>> (and those 3 lines repeat in various places) for which none of
>> them show up for -r356767 .
>> 
>> Without identifying and using PSCI, the extra cores will not
>> start and the cpu(s) will not reset. (PSCI is the ARM interface
>> for doing such things.)
>> 
>> I've no clue why, but the version number it gets in my RPi4
>> experiments is 0. My only guess is that at some point
>> memory important to ARM's PSCI operation has been touched
>> and is no longer valid for the PSCI operation.
> 
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)