David / Joerg,
On 4/10/2021 5:03 PM, David Coe wrote:
>
> The immediately obvious difference is the with the enormous count seen on
> mem_dte_mis on the older Ryzen 2400G. Will do some RTFM but anyone with
> comments and insight?
>
> 841,689,151,202,939 amd_iommu_0/mem_dte_mis/ (33.44%)
>
> Otherwise, all seems to running smoothly (especially for a distribution still
> in β). Bravo and many thanks all!
The initial hypothesis is that the issue happens only when users specify more
number of events than
the available counters, which Perf will time-multiplex the events onto the
counters.
Looking at the Perf and AMD IOMMU PMU multiplexing logic, it requires:
1. Stop the counter (i.e. set CSOURCE to zero to stop counting)
2. Save the counter value of the current event
3. Reload the counter value of the new event (previously saved)
4. Start the counter (i.e. set CSOURCE to count new events)
The problem here is that when the driver writes zero to CSOURCE register in
step 1, this would enable power-gating,
which prevents access to the counter and result in writing/reading value in
step 2 and 3.
I have found a system that reproduced this case (w/ unusually large number of
count), and debug the issue further.
As a hack, I have tried skipping step 1, and it seems to eliminate this issue.
However, this is logically incorrect,
and might result in inaccurate data depending on the events.
Here are the options:
1. Continue to look for workaround for this issue.
2. Find a way to disable event time-multiplexing (e.g. only limit the number of
counters to 8)
if power gating is enabled on the platform.
3. Back to the original logic where we had the pre-init check of the counter
vlues, which is still the safest choice
at the moment unless
Regards,
Suravee
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1917203
Title:
AMD-Vi: Unable to read/write to IOMMU perf counter
Status in linux package in Ubuntu:
In Progress
Bug description:
This boot warning (concealed by grub not taking over the fbcon console
on a solo installation but always present on a multi-boot) has been
bothering Linux users of AMD Ryzen machines for some time.
The problem is currently under discussion at kernel level
<https://bugzilla.kernel.org/show_bug.cgi?id=201753>.
One solution proposed by Suravee Suthikulpanit
<[email protected]> <https://lkml.org/lkml/2021/2/8/486>
works but inserts a boot-up delay of (at least) 100 msec. A second
option by Alexander Monakov <[email protected]>
<https://bugzilla.kernel.org/show_bug.cgi?id=201753> also works but
inserts no delay and more-or-less just moves one line of code.
I've tried both solutions with kernel rebuilds for both Breezy kernel
5.8.18 and Hirsute kernel 5.10.11 and both work on my AMD Ryzen 2400G.
Could I encourage your kernel experts to evaluate the situation (I
think SuSE folk already are).
My suggestion (as a humble user :-) ) would be to fold Alex's simple
patch into your own list of kernel tweeks and get the correction out
with the upcoming Hirsute release.
Best regards and all respect!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1917203/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
