Dear Linux folks,
On the Marvell Prestera switch, Linux 5.10.4 prints the error (with an
additional info level message) below.
[ 0.000000] Linux version 5.10.4 (robimarko@onlbuilder9)
(aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU
Binutils for Debian) 2.28) #1 SMP PREEMPT Thu Mar 11 10:22:09 UTC 2021
[…]
[ 1.996658] hw perfevents: unable to count PMU IRQs
[ 2.001825] hw perfevents: /ap806/config-space@f0000000/pmu:
failed to register PMU devices!
```
# lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Model: 1
BogoMIPS: 50.00
L1d cache: 32K
L1i cache: 48K
L2 cache: 512K
NUMA node0 CPU(s): 0-3
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
# cat /proc/cpuinfo
processor : 0
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 1
[…]
```
Please find the output of `dmesg` attached.
How can the IRQs be counted?
Kind regards,
Paul
On 2021-03-25 21:39, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On the Marvell Prestera switch, Linux 5.10.4 prints the error (with an
> additional info level message) below.
>
> [ 0.000000] Linux version 5.10.4 (robimarko@onlbuilder9)
> (aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU
> Binutils for Debian) 2.28) #1 SMP PREEMPT Thu Mar 11 10:22:09 UTC 2021
> […]
> [ 1.996658] hw perfevents: unable to count PMU IRQs
> [ 2.001825] hw perfevents: /ap806/config-space@f0000000/pmu:
> failed to register PMU devices!
>
> ```
> # lscpu
> Architecture: aarch64
> Byte Order: Little Endian
> CPU(s): 4
> On-line CPU(s) list: 0-3
> Thread(s) per core: 1
> Core(s) per socket: 4
> Socket(s): 1
> NUMA node(s): 1
> Model: 1
> BogoMIPS: 50.00
> L1d cache: 32K
> L1i cache: 48K
> L2 cache: 512K
> NUMA node0 CPU(s): 0-3
> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
> # cat /proc/cpuinfo
> processor : 0
> BogoMIPS : 50.00
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant : 0x0
> CPU part : 0xd08
> CPU revision : 1
> […]
> ```
>
> Please find the output of `dmesg` attached.
>
> How can the IRQs be counted?
Well, that message simply means we got an error back from
platform_irq_count(), which in turn implies that
platform_get_irq_optional() failed. Most likely we got -EPROBE_DEFER
back from of_irq_get() because the relevant interrupt controller wasn't
ready by that point - especially since that's the o9nly error code that
platform_irq_cont() will actually pass. It looks like that should end up
getting propagated all the way out appropriately, so the PMU driver
should defer and be able to probe OK once the mvebu-pic driver has
turned up to provide its IRQ. We could of course do a better job of not
shouting error messages for a non-fatal condition....
As for why the PMU doesn't eventually show up, my best guess would be
either an issue with the mvebu-pic driver itself probing, and/or perhaps
something in fw_devlink going awry - inspecting sysfs should shed a bit
more light on those.
Robin.
Dear Robin,
Thank you for the quick reply.
Am 26.03.21 um 13:29 schrieb Robin Murphy:
> On 2021-03-25 21:39, Paul Menzel wrote:
>> On the Marvell Prestera switch, Linux 5.10.4 prints the error (with an
>> additional info level message) below.
>>
>> [ 0.000000] Linux version 5.10.4 (robimarko@onlbuilder9) (aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU Binutils for Debian) 2.28) #1 SMP PREEMPT Thu Mar 11 10:22:09 UTC 2021
>> […]
>> [ 1.996658] hw perfevents: unable to count PMU IRQs
>> [ 2.001825] hw perfevents: /ap806/config-space@f0000000/pmu: failed to register PMU devices!
[…]
>> Please find the output of `dmesg` attached.
>>
>> How can the IRQs be counted?
>
> Well, that message simply means we got an error back from
> platform_irq_count(), which in turn implies that
> platform_get_irq_optional() failed. Most likely we got -EPROBE_DEFER
> back from of_irq_get() because the relevant interrupt controller wasn't
> ready by that point - especially since that's the o9nly error code that
> platform_irq_cont() will actually pass. It looks like that should end up
> getting propagated all the way out appropriately, so the PMU driver
> should defer and be able to probe OK once the mvebu-pic driver has
> turned up to provide its IRQ. We could of course do a better job of not
> shouting error messages for a non-fatal condition....
Yes, that would be great.
> As for why the PMU doesn't eventually show up, my best guess would be
> either an issue with the mvebu-pic driver itself probing, and/or perhaps
> something in fw_devlink going awry - inspecting sysfs should shed a bit
> more light on those.
I just noticed, I missed
[ 3.298670] hw perfevents: enabled with armv8_cortex_a72 PMU
driver, 7 counters available
a good second. So the interrupt controller indeed seems to take longer
to be ready.
I guess, I’d need to boot with `initcall_debug` to find out the callers
of the PMU functions.
Kind regards,
Paul