| Newsgroups |
gmane.os.freebsd.devel.arm |
| Message-ID |
<[email protected]> |
> On 14. Apr 2024, at 14:17, John F Carr <[email protected]> wrote:
>
> See bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277559. It was suspected to be specific to the heterogenous Rockchip RK3399 but perhaps it is more widespread.
>
> When I first hit the bug there was a 30-50% chance that the first kldload vmm would hang the system so hard I couldn't even invoke the debugger with break on a serial console. Later, with no relevant changes to source code, it would take about 2,000 load/unload pairs to hang the system. If that 1-in-2000 chance is typical this bug could affect all systems. Give it a try on your 128 core system:
>
> # while kldload vmm ; do echo -n . ; kldunload vmm ; done
I tried 70000 times on the 128 core system: No problem.
On the 32 core system the problem occurs every time I call kldload vmm.
Tried 5 times, happened 5 times.
From my point of view, the behavior is deterministic on both systems.
Best regards
Michael
>
> If anybody can tell me how to debug at the hardware level using JTAG, I can give it a try on my RockPro64 and see where the kernel is stuck. I have used hardware level debugging tools, but they were always black boxes my employer bought with instructions included.
>
>> On Apr 14, 2024, at 04:50, [email protected] wrote:
>>
>> Dear all,
>>
>> using the sources for kernel/world of yesterday running
>> kldload vmm
>> on a 128 core Ampere system runs just fine:
>>
>> CPU 0: ARM Neoverse-N1 r3p1 affinity: 18 0 0
>> Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG,IDC>
>> Instruction Set Attributes 0 = <DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL>
>> Instruction Set Attributes 1 = <RCPC-8.3,DCPoP>
>> Instruction Set Attributes 2 = <>
>> Processor Features 0 = <CSV3,CSV2,RAS,GIC,AdvSIMD+HP,FP+HP,EL3,EL2,EL1,EL0 32>
>> Processor Features 1 = <PSTATE.SSBS MSR>
>> Memory Model Features 0 = <TGran4,TGran64,TGran16,SNSMem,BigEnd,16bit ASID,256TB PA>
>> Memory Model Features 1 = <XNX,PAN+ATS1E1,LO,HPD+TTPBHA,VH,16bit VMID,HAF+DS>
>> Memory Model Features 2 = <EVT-8.2,32bit CCIDX,48bit VA,UAO,CnP>
>> Debug Features 0 = <DoubleLock,SPE,2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3p1,Debugv8p2>
>> Debug Features 1 = <>
>> Auxiliary Features 0 = <>
>> Auxiliary Features 1 = <>
>> AArch32 Instruction Set Attributes 5 = <RDM,CRC32,SHA2,SHA1,AES+VMULL,SEVL>
>> AArch32 Media and VFP Features 0 = <FPRound,FPSqrt,FPDivide,DP VFPv3+v4,SP VFPv3+v4,AdvSIMD>
>> AArch32 Media and VFP Features 1 = <SIMDFMAC,FPHP Arith,SIMDHP Arith,SIMDSP,SIMDInt,SIMDLS,FPDNaN,FPFtZ>
>>
>> However, doing the same on a 32 core Ampere system results in
>> the system becoming unresponsive. No reaction on the console,
>> no message there, no response over the network.
>>
>> CPU 0: APM eMAG 8180 r3p2 affinity: 0 0
>> Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
>> Instruction Set Attributes 0 = <CRC32,SHA2,SHA1,AES+PMULL>
>> Instruction Set Attributes 1 = <>
>> Instruction Set Attributes 2 = <>
>> Processor Features 0 = <GIC,AdvSIMD,FP,EL3,EL2,EL1 32,EL0 32>
>> Processor Features 1 = <>
>> Memory Model Features 0 = <TGran4,TGran64,TGran16,SNSMem,BigEnd,16bit ASID,4TB PA>
>> Memory Model Features 1 = <8bit VMID>
>> Trying to mount root from ufs:/dev/ada0p2 [rw]...
>> Memory Model Features 2 = <32bit CCIDX,48bit VA>
>> Debug Features 0 = <DoubleLock,2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8>
>> Debug Features 1 = <>
>> Auxiliary Features 0 = <>
>> Auxiliary Features 1 = <>
>> AArch32 Instruction Set Attributes 5 = <CRC32,SHA2,SHA1,AES+VMULL,SEVL>
>> AArch32 Media and VFP Features 0 = <FPRound,FPSqrt,FPDivide,DP VFPv3+v4,SP VFPv3+v4,AdvSIMD>
>> AArch32 Media and VFP Features 1 = <SIMDFMAC,FPHP DP Conv,SIMDHP SP Conv,SIMDSP,SIMDInt,SIMDLS,FPDNaN,FPFtZ>
>>
>> Any idea, what is going wrong?
>>
>> Best regards
>> Michael
>
>