From: Robin Murphy <robin.murphy@arm.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
LKML <linux-kernel@vger.kernel.org>,
Vadym Kochan <vadym.kochan@plvision.eu>,
Oleksandr Mazur <oleksandr.mazur@plvision.eu>,
Robert Marko <robert.marko@sartura.hr>
Subject: Re: Marvell: hw perfevents: unable to count PMU IRQs
Date: Fri, 26 Mar 2021 12:29:16 +0000 [thread overview]
Message-ID: <ec735dae-5448-dcf4-9537-898977ebc8f4@arm.com> (raw)
In-Reply-To: <dc43adf0-daa3-b939-e0ed-5d0c8d01bd91@molgen.mpg.de>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
LKML <linux-kernel@vger.kernel.org>,
Vadym Kochan <vadym.kochan@plvision.eu>,
Oleksandr Mazur <oleksandr.mazur@plvision.eu>,
Robert Marko <robert.marko@sartura.hr>
Subject: Re: Marvell: hw perfevents: unable to count PMU IRQs
Date: Fri, 26 Mar 2021 12:29:16 +0000 [thread overview]
Message-ID: <ec735dae-5448-dcf4-9537-898977ebc8f4@arm.com> (raw)
In-Reply-To: <dc43adf0-daa3-b939-e0ed-5d0c8d01bd91@molgen.mpg.de>
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-26 12:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-25 21:39 Marvell: hw perfevents: unable to count PMU IRQs Paul Menzel
2021-03-25 21:39 ` Paul Menzel
2021-03-26 12:29 ` Robin Murphy [this message]
2021-03-26 12:29 ` Robin Murphy
2021-03-26 14:34 ` Paul Menzel
2021-03-26 14:34 ` Paul Menzel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec735dae-5448-dcf4-9537-898977ebc8f4@arm.com \
--to=robin.murphy@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oleksandr.mazur@plvision.eu \
--cc=pmenzel@molgen.mpg.de \
--cc=robert.marko@sartura.hr \
--cc=vadym.kochan@plvision.eu \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.