[PATCH 0/4] perf/arm-cmn: Add CMN-650 and CMN-700

Robin Murphy robin.murphy at arm.com
Tue May 10 14:05:52 PDT 2022


On 2022-05-10 20:38, Qian Cai wrote:
> On Tue, May 10, 2022 at 06:50:56PM +0100, Robin Murphy wrote:
>> Hmm, can you narrow it down a bit more to a particular patch and/or a
>> specific reproducer? I don't see how it could really be crashing
>> dereferencing event->pmu, especially since none of the code this early in
>> event_init has even changed recently :/
> 
> Right, there is an old bug that sometimes the debuginfo on kernel
> modules is not accurate on arm64, so gdb and faddr2line gave the wrong
> line. Anyway, using the printk() method, we were faulted on this line.
> 
> +       /* This is sufficiently annoying to recalculate, so cache it */
> +       hw->filter_sel = arm_cmn_filter_sel(cmn->model, type, eventid);

Aha, that's a much more believable culprit - 0x38 also stood out as an 
offset in the attribute structures.

> Also, it can be reproduced within 5-min by running,
> 
> $ trinity -C 128 -cperf_event_open

I can already guess what I've done, and just reproduced the crash 
directly on the first try :)

I'll work on the fix tomorrow, thanks for the report and info!

>> Something's definitely screwy here though... these ID numbers should have a
>> device type above them. Was this dumped with patch #1 applied, and if not do
>> they show as "????" when it is?
> 
> Yes, with the series applied, we have,

Ah, turns out I can no longer get away with being lazy and not masking 
the device_type field properly when reading connect_info, as some of the 
adjacent bits are no longer reserved since the debugfs code was first 
written - I've not played with a CAL config of any of the newer stuff, 
or I might have noticed sooner.

But at least that tweak to differentiate unknown from unconnected has 
now paid for itself :D

Cheers,
Robin.



More information about the linux-arm-kernel mailing list