[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