Re: Loading vmm

From: <tuexen_at_freebsd.org>
Date: Sun, 14 Apr 2024 15:05:56 UTC
> On 14. Apr 2024, at 14:17, John F Carr <jfc@mit.edu> 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, tuexen@freebsd.org 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
> 
>