On Tue, 20 Apr 2021, Suthikulpanit, Suravee wrote:
> 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?
>
dmin-guide text.
Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and
consolidation")
Signed-off-by: Alexander Monakov
Cc: Rafael Wysocki
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
---
drivers/cpufreq/Kconfig | 23 ++-
1 file changed, 6 inserti
On Sun, 11 Apr 2021, Joe Perches wrote:
> > v2: avoid pr_info(""), change pci_info() to pr_info() for a nicer
> > solution
> >
> > drivers/iommu/amd/init.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> >
AMD-Vi: Interrupt remapping enabled
Fixes: 9a295ff0ffc9 ("iommu/amd: Print extended features in one line to fix
divergent log levels")
Link:
https://lore.kernel.org/lkml/alpine.lnx.2.20.13.2104112326460.11...@monopod.intra.ispras.ru
Signed-off-by: Alexander Monakov
Cc: Paul Menzel
Cc
On Sun, 11 Apr 2021, John Ogness wrote:
> > pr_info("") will also prepend 'AMD-Vi:' to the feature list, which is
> > nice.
>
> I'd rather fix dev_info callers to allow pr_cont and then fix any code
> that is using this workaround.
Note that existing two users of pr_info("") that I found are not
On Sun, 11 Apr 2021, Joe Perches wrote:
> (cc'ing the printk maintainers)
>
[snip]
>
> This shouldn't be necessary.
> If this is true then a lot of output logging code broke.
See also my response to Paul at
https://lore.kernel.org/lkml/alpine.lnx.2.20.13.2104111410340.11...@monopod.intra.ispras
On Sun, 11 Apr 2021, Paul Menzel wrote:
> > The second line is emitted via 'pr_cont', which causes it to have a
> > different ('warn') loglevel compared to the previous line ('info').
> >
> > Commit 9a295ff0ffc9 attempted to rectify this by removing the newline
> > from the pci_info format string
with empty format string to set
the loglevel for subsequent pr_cont calls. The same solution is used in
EFI and uvesafb drivers.
Fixes: 9a295ff0ffc9 ("iommu/amd: Print extended features in one line to fix
divergent log levels")
Signed-off-by: Alexander Monakov
Cc: Paul Menzel
Cc: Jo
On Wed, 17 Mar 2021, Peter Zijlstra wrote:
> On Wed, Mar 17, 2021 at 09:48:29AM +0100, Ingo Molnar wrote:
> > > https://developer.amd.com/wp-content/resources/56323-PUB_0.78.pdf
> >
> > So:
> >
> >
> > 1215 IBS (Instruction Based Sampling) Counter Valid Value
> > May be Incorrect After Exit
On Tue, 16 Mar 2021, Adam Borowski wrote:
> On Tue, Mar 16, 2021 at 04:45:02PM +0100, Jiri Olsa wrote:
> > hi,
> > when running 'perf top' on AMD Rome (/proc/cpuinfo below)
> > with fedora 33 kernel 5.10.22-200.fc33.x86_64
> >
> > we got unknown NMI messages:
> >
> > [ 226.700160] Uhhuh. NMI re
Hello, Hans, Linux PM folks,
I'm looking for clarification regarding this patch discussion:
https://patchwork.kernel.org/project/linux-pm/patch/20180420101834.15783-2-0v3rdr...@gmail.com/
Hans said,
> Ah, so the AHCI code has runtime pm enabled by default (so there
> is another pm_runtime_allow
On Tue, 22 Dec 2020, Deucher, Alexander wrote:
> > Yes. Out-of-the-box it's a "modern standby" laptop. There's a "hidden"
> > bios menu with extra settings that apparently allows to select legacy S3.
> > I did not change it, so I'm testing the "modern" mode.
> >
> > Note that this driver fetches
On Tue, 22 Dec 2020, Deucher, Alexander wrote:
> > I've tried the "platform/x86: amd-pmc: Add AMD platform support for
> > S2Idle"
> > patch on my Acer Swift SF314-42 laptop (Renoir SoC, Ryzen 4500U CPU) and
> > hit the following issues:
> >
> > 1. The driver doesn't bind to any device. It has th
Hi folks,
I've tried the "platform/x86: amd-pmc: Add AMD platform support for S2Idle"
patch on my Acer Swift SF314-42 laptop (Renoir SoC, Ryzen 4500U CPU) and hit
the following issues:
1. The driver doesn't bind to any device. It has the following binding table:
+static const struct acpi_device_
MWAIT behavior. In passing, reword opening comment to make it clear
that the driver can load on any old and future Intel CPU with MWAIT.
Signed-off-by: Alexander Monakov
Cc: Rafael J. Wysocki
---
v2: reword remark about WBINVD (Rafael)
drivers/idle/intel_idle.c | 8 ++--
1 file changed, 6
On Mon, 12 Oct 2020, Rafael J. Wysocki wrote:
> > @@ -20,7 +20,11 @@
> > * All CPUs have same idle states as boot CPU
> > *
> > * Chipset BM_STS (bus master status) bit is a NOP
> > - * for preventing entry into deep C-stats
> > + * for preventing entry into deep C-states
> > + *
> >
on MWAIT behavior. In passing, reword opening comment
to make it clear that driver can load on any future Intel CPU with MWAIT.
Signed-off-by: Alexander Monakov
Cc: Rafael J. Wysocki
---
Hi,
I noticed that one of significant optimizations of intel_idle over
acpi_idle is elision of explicit
On Tue, 16 Jun 2020, Suravee Suthikulpanit wrote:
> > > Instead of blindly moving the code around to a spot that would just work,
> > > I am trying to understand what might be required here. In this case,
> > > the init_device_table_dma()should not be needed. I suspect it's the IOMMU
> > > invalid
'by hand', they hit the issue.
> would we really have to invoke syscall() directly -- couldn't we
> invoke pread64() directly? (eg. below)
No, the proper fix is to pass -D_FILE_OFFSET_BITS=64 to the compiler.
Here's the patch:
---8<---
From: Alexander Monakov
Date:
Ping.
On Tue, 4 Aug 2020, Alexander Monakov wrote:
> Documentation for sysfs backlight level interface requires that
> values in both 'brightness' and 'actual_brightness' files are
> interpreted to be in range from 0 to the value given in the
> 'm
Hi,
you should Сс a specialized mailing list and a relevant maintainer,
otherwise your email is likely to be ignored as LKML is an incredibly
high-volume list. Adding amd-gfx and Alex Deucher.
More thoughts below.
On Sun, 9 Aug 2020, Ignat Insarov wrote:
> Hello!
>
> This is an issue report. I
On Tue, 4 Aug 2020, Alexander Monakov wrote:
> Documentation for sysfs backlight level interface requires that
> values in both 'brightness' and 'actual_brightness' files are
> interpreted to be in range from 0 to the value given in the
> 'max_brightness&#x
ps://gitlab.freedesktop.org/drm/amd/-/issues/1242
Cc: Alex Deucher
Cc: Nicholas Kazlauskas
Signed-off-by: Alexander Monakov
---
v2: split convert_brightness to &_from_user and &_to_user (Nicholas)
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 81 +--
1 file changed, 40 insertion
ghtness remains 255 with this patch, so as far as userspace
is concerned nothing is changed apart from value given by actual_brightness
file.
Alexander
>
> Not an expert on existing implementations to point out a specific one though.
>
> Regards,
> Nicholas Kazlauskas
>
> On
the correct
range.
Introduce a helper to retrieve internal backlight range. Extend the
existing 'convert_brightness' function to handle conversion in both
directions.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=203905
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1242
Cc: Alex
On Tue, 16 Jun 2020, Suravee Suthikulpanit wrote:
> > > On 6/1/20 4:01 PM, Alexander Monakov wrote:
> > > > On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> > > >
> > > > > > Moving init_iommu_perf_ctr just after iommu_flush_all_caches
> &g
Hi,
I've already said in my patch submission (which was Cc'ed to LKML,
linux-edac and linux-hwmon so you should have been able to find it):
>> It appears SMU offsets for reading current/voltage and CCD temperature
>> have changed for this generation (reads from currently used offsets
>> yield zer
On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> Alexander
>
> On 6/1/20 4:01 PM, Alexander Monakov wrote:
> > On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> >
> > > > Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves
> > >
On Fri, 5 Jun 2020, Rafael J. Wysocki wrote:
> > This sounds like it should be a known problem, but I couldn't find any
> > mention of it in the documentation.
>
> Well, what would you expect to happen instead of what you see?
Not sure why you ask. Named workloads are pretty common for example o
Hello,
this is a question/bugreport about behavior of schedutil on serial workloads
such as rsync, or './configure', or 'make install'. These workloads are
such that there's no single task that takes a substantial portion of CPU
time, but at any moment there's at least one runnable task, and overa
On Tue, 2 Jun 2020, Shuah Khan wrote:
> I changed the logic to read config to get max banks and counters
> before checking if counters are writable and tried writing to all.
> The result is the same and all of them aren't writable. However,
> when disable the writable check and assume they are, I
> Instead of blindly moving the code around to a spot that would just work,
> I am trying to understand what might be required here. In this case,
> the init_device_table_dma()should not be needed. I suspect it's the IOMMU
> invalidate all command that's also needed here.
>
> I'm also checking wit
On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> > Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves
> > the issue. This is the earliest point in amd_iommu_init_pci where the
> > call succeeds on my laptop.
>
> According to your description, it should just need to be anywher
Hi,
Adding Shuah Khan to Cc: I've noticed you've seen this issue on Ryzen 2400GE;
can you have a look at the patch? Would be nice to know if it fixes the
problem for you too.
Thanks.
Alexander
On Fri, 29 May 2020, Alexander Monakov wrote:
> The driver performs an extra check i
after iommu_flush_all_caches resolves
the issue. This is the earliest point in amd_iommu_init_pci where the
call succeeds on my laptop.
Signed-off-by: Alexander Monakov
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Cc: io...@lists.linux-foundation.org
---
PS. I'm seeing another hiccup with IOMMU probing on
The following commit has been merged into the ras/core branch of tip:
Commit-ID: a4e91825d7e1252f7cba005f1451e5464b23c15d
Gitweb:
https://git.kernel.org/tip/a4e91825d7e1252f7cba005f1451e5464b23c15d
Author:Alexander Monakov
AuthorDate:Sun, 10 May 2020 20:48:40
Committer
The following commit has been merged into the ras/core branch of tip:
Commit-ID: 279f0b3a4b80660fba6faadc2ca2fa426bf3f7e9
Gitweb:
https://git.kernel.org/tip/279f0b3a4b80660fba6faadc2ca2fa426bf3f7e9
Author:Alexander Monakov
AuthorDate:Sun, 10 May 2020 20:48:41
Committer
The following commit has been merged into the ras/core branch of tip:
Commit-ID: b6bea24d41519e8c31e4798f1c1a3f67e540c5d0
Gitweb:
https://git.kernel.org/tip/b6bea24d41519e8c31e4798f1c1a3f67e540c5d0
Author:Alexander Monakov
AuthorDate:Sun, 10 May 2020 20:48:42
Committer
et MSR you're using in your patch. Maybe the per-core
values are less reliable, but I believe I have a test that shows per-package
figure to be inaccurate as well. It would be nice if AMD clarified how the
counters work.
And, for what (little) it's worth, the series is:
Tested-by: Alexander Monakov
Thank you.
Alexander
ev entry type
HID")
Signed-off-by: Alexander Monakov
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
drivers/iommu/amd_iommu_init.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index
patch is a prerequisite for that,
and finally edac_amd64 patch is necessary, because otherwise loading
that module produces a warning due to incomplete support.
Thank you.
Alexander Monakov (3):
x86/amd_nb: add AMD family 17h model 60h PCI IDs
hwmon: (k10temp) Add AMD family 17h model 60h PCI
Add PCI IDs for AMD Renoir (4000-series Ryzen CPUs). This is necessary
to enable support for temperature sensors via the k10temp module.
Signed-off-by: Alexander Monakov
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: Yazen Ghannam
Cc: Brian Woods
Cc: Clemens Ladisch
Cc
-by: Alexander Monakov
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: Yazen Ghannam
Cc: Brian Woods
Cc: Clemens Ladisch
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: linux-hw...@vger.kernel.org
Cc: linux-e...@vger.kernel.org
---
drivers/hwmon/k10temp.c | 1 +
1 file changed, 1
Add support for AMD Renoir (4000-series Ryzen CPUs).
Signed-off-by: Alexander Monakov
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: Yazen Ghannam
Cc: Brian Woods
Cc: Clemens Ladisch
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: linux-hw...@vger.kernel.org
Cc: linux-e
Move dump_misc_regs earlier so decoded register contents are shown
even if ECC cannot be enabled. The dump gives info such as number of
memory controllers, so it serves as a sensible smoke-check even on
platforms without ECC memory.
Signed-off-by: Alexander Monakov
Cc: Borislav Petkov
Cc: linux
information given in
Chromecast kernel driver by Jisheng Zhang.
Cc: Jisheng Zhang
Signed-off-by: Alexander Monakov
---
Hello,
Some high-level information on the chip is available in Marvell's PDF titled
"DC/DC Power Regulators Product Portfolio" [1]. Chromecast's drivers show tw
The only device-specific node names are "buck1" and "buck2" for the two
regulators present on the device. Sleep mode GPIO and per-regulator GPIO
enable pins are not exposed (the driver does not support them either).
Signed-off-by: Alexander Monakov
---
.../devicetre
Abraham I
Cc: Antoine Tenart
Signed-off-by: Alexander Monakov
---
Hello,
I'm trying to run mainline kernel on "Steam Link" device built around
Marvell BG2CD SoC, and in doing so I've found that USB almost always
fails to initialize with timeout errors when connecting to the
On Wed, 8 Jun 2016, fREW Schmidt wrote:
> I was debugging an issue I ran into (
> https://github.com/docker/docker/issues/23378) and after chatting with the
> folks in #musl and we triaged it down to a broken vDSO (tested by running
> `strace date` and seeing a clock_gettime call.)
To provide a bi
On Sun, Nov 9, 2014 at 1:13 AM, Paul E. McKenney
wrote:
>
> Did anyone try replacing the synchronize_rcu() with
> synchronize_rcu_expedited()? That should provide substantial speedups
> over synchronize_rcu().
I've just briefly tested it on my laptop, and it also helps to avoid the issue.
Alexa
50 matches
Mail list logo
