On Tue, 2021-04-20 at 22:37 +0800, Chen Yu wrote:
> On Tue, Apr 20, 2021 at 09:28:06AM -0400, Calvin Walton wrote:
> > This patch has the same issue I noticed with the initial revision
> > of
> > Terry's patch - the idx_to_offset function returns type in
was missed with the off_t type - inside the function
update_msr_sum(), the offset is also stored in a variable of type int,
and as a result the background update for AMD's MSR when turbostat is
used with long durations won't work. (It's skipped because of the
offset < 0 check).
--
Calvin Walton
d to not
happen.
For short durations it still works fine since the background update
isn't used.
--
Calvin Walton
%llx
Easiest fix is probably to cast to (long long int) and use the %llx
format specifier. That should be valid with i686, x32, and amd64
userspace.
Everything else looks fine as far as I can tell, so feel free to add a
Reviewed-by: Calvin Walton
once you've fixed that warning.
--
pass the offset value in
a variable of type "int" (32bit signed integer), but the offset of the
AMD MSR_CORE_ENERGY_STAT MSR is 0xC001029A, which exceeds INT_MAX. The
offsets should all use "off_t" to get a 64bit type and avoid wrapping
or sign extension issues.
--
Calvin Walton
On Thu, 2021-04-15 at 10:26 +0800, Chen Yu wrote:
> Hi Calvin,
> On Wed, Apr 14, 2021 at 10:08:07PM -0400, Calvin Walton wrote:
> > On Wed, 2021-04-14 at 22:05 -0400, Calvin Walton wrote:
> > > The current version of turbostat exits immediately upon entering
> > > t
a bit
mask for the do_rapl bit field.
The presence of MSR_PKG_ENERGY_STAT (along with MSR_RAPL_PWR_UNIT and
MSR_CORE_ENERGY_STAT) is indicated by the RAPL_AMD_F17H bit in do_rapl,
and can be checked with:
do_rapl & RAPL_AMD_F17H
--
Calvin Walton
On Wed, 2021-04-14 at 22:05 -0400, Calvin Walton wrote:
> The current version of turbostat exits immediately upon entering the
> main loop, with error code -13. This is a regression that was
> introducted
> in these commits:
>
> 9972d5d84d76 tools/power turbostat: Enable accum
SRs exceed the range of a
signed 32-bit int.
Note that since the framework introduced only handles per-cpu MSRs but not
per-core MSRs, AMD "Core" energy is not currently accumulated over long
sampling periods.
Fixes: 9972d5d84d76982606806b2ce887f70c2f8ba60a
Signed-off-by: Calvin Walton
uot; no matter what argument is passed. The
only reason the function exists in the first place is that I thought
there might be a way to read the configured TDP from the CPU, but I
couldn't find any documentation on how to do that at the time.
Reviewed-by: Calvin Walton
--
Calvin Walton
D's family 0x18 chip
uses the same RAPL registers - or cleanly skip the CPU if they changed
it.
Please add a comment on the 0x18 case in the rapl_probe_amd function,
something like:
case 0x18: /* Hygon Dhyana */
Feel free to add a
Reviewed-by: Calvin Walton
--
Calvin Walton
vin.
>
> On Fri, Aug 17, 2018 at 12:35 PM Calvin Walton <
> calvin.wal...@kepstin.ca> wrote:
> > The package power can also be read from an MSR. It's not clear
> > exactly
> > what is included, and whether it's aggregated over all nodes or
> > report
n space. I have not yet found any public
documentation for this.
Signed-off-by: Calvin Walton
---
tools/power/x86/turbostat/turbostat.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/tu
rting, since I'm fairly confident that this'll work on all of
the Zen chips. I think this part is ready to apply now.
The second part is still a work in progress until I'm able to (or I'm
able to find someone else to) test the package power reporting on a
multi-die Zen chip.
Calvin
a
per-package total. The code has been adjusted to handle either case in a
generic way.
I haven't yet enabled collection of package power, due to being unable
to test it on multi-node systems (TR, EPYC).
Signed-off-by: Calvin Walton
---
tools/power/x86/turbostat/turbostat.c | 159
and ExtFamily values.
This matches the code in arch/x86/lib/cpu.c
Signed-off-by: Calvin Walton
---
v3: Having just looked at the arch/x86/lib/cpu.c code again, I realized
that it *didn't* actually match - the kernel code uses family >= 6 for
applying the extended model number, while I was
and ExtFamily values.
This matches the code in arch/x86/lib/cpu.c
Signed-off-by: Calvin Walton
---
I'm still working on updating the RAPL patch on top of the changes for
v4.18, but this CPUID fix doesn't have to wait.
tools/power/x86/turbostat/turbostat.c | 4 +++-
1 file changed, 3
On Thu, 2018-07-26 at 15:10 -0400, Len Brown wrote:
> Hi Calvin,
> I'll assume you are waiting for this to be tested by somebody who has
> the HW (sorry, I don't have AMD HW to test this)
> and will re-send a checkpatch.pl clean version when you have that
> result.
>
> thanks,
> -Len
I need to re
On Wed, 2018-07-18 at 18:26 -0400, Calvin Walton wrote:
> Based on the documentation provided in AMD's Open-Source
> Register Reference For AMD Family 17h Processors:
> https://support.amd.com/TechDocs/56255_OSRR.pdf
>
> I've added support for reading Cores and Package
Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf
These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_
2.24147835001674450 11754.16
93.70 0.01
3 3 40 2.6715013500 1279 262 951 2.33
95.07 0.01
Calvin Walton (2):
turbostat: Read extended processor family from CPUID
turbostat: Add support for AMD Fam 17h (
This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.
See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and
Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf
These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_
This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.
See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and
33 2.24147835001674450 11754.16
93.70 0.01
3 3 40 2.67150135001279262 951 2.33
95.07 0.01
Calvin Walton (2):
turbostat: Read extended processor family from CPUID
turbostat: Add support for AMD Fam 17
mi4_smbus 9-002c: registered rmi smb driver at 0x2c.
[ 20.425233] psmouse serio3: trackpoint: IBM TrackPoint firmware: 0x0e,
buttons: 3/3
[ 20.482937] input: TPPS/2 IBM TrackPoint as
/devices/rmi4-00/rmi4-00.fn03/serio3/input/input21
--
Calvin Walton
On Mon, 2014-09-01 at 19:42 +0100, Matt Fleming wrote:
> On Wed, 27 Aug, at 12:02:37PM, Calvin Walton wrote:
> > Hi all,
> >
> > When I tried booting the 3.17-rc2 kernel on my Lenovo ThinkPad
> > T440p
> > (16gb ram) via Gummiboot/EFI stub, it failed with
bad 4bf7111f50167133a71c23530ca852a41355e739
# good: [98a716b66cab993e15001c7ec06f637ca6f1079b] x86/efi: Use
early_memunmap() to squelch sparse errors
git bisect good
98a716b66cab993e15001c7ec06f637ca6f1079b
# first bad commit:
[4bf7111f50167133a71c23530ca852a41355e739] x86/efi: Support initrd
loaded above 4G
--
Sorry, dropped the CCs when I replied... I don't normally use the
Gmail web interface :)
On Thu, Dec 6, 2012 at 7:59 PM, Greg Kroah-Hartman
wrote:
> 3.6-stable review patch. If anyone has any objections, please let me know.
>
> ------
>
> From: Calvi
t;
> > - depends on BLOCK && SYSFS && ZSMALLOC
> > + depends on BLOCK && SYSFS
> > + select ZSMALLOC
>
> As ZSMALLOC is dependant on CONFIG_STAGING, this isn't going to work at
> all, sorry.
Perhaps you missed [PATCH 1/3] zsmalloc: p
is close to
failing - not /always/, but often. If manually overwriting the sector in
question doesn't help, you should probably look into replacing the
drive.
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
th an NM10
chipset.
I've had this board for about a year, but this is the first time I
noticed the issue because I've been running it headless for most of its
life.
Signed-off-by: Calvin Walton
---
This board:
http://www.gigabyte.us/products/product-page.aspx?pid=3549#sp
If you want
ou want to clean up the formatting of the source code, feel free to
do so; but it should be done as a separate patch from this one, so that
the individual feature changes and formatting changes can be reviewed
separately. Right now I can't even tell which parts of the patch are
fu
e nouveau driver has its own mailing list, at
nouv...@lists.freedesktop.org - and they respond to issues on the
http://bugs.freedesktop.org/ bugzilla.
--
Calvin Walton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
mes' mount option to disable creating file and
directory names that confuse windows.
Linux itself (and most native Linux programs) has no issues with
directory names containing the '\' character, of course; the only
characters that you cannot use are '/' and ASCII NUL, 0x00.
queued Allocator) (SLUB)
choice[1-2?]: 1?
The regular slab allocator that is established and known to work
well in all environments. It organizes cache hot objects in
per cpu and per node queues. SLAB is the default choice for
a slab allocator.
--
Calvin Walton <[EMAIL PROTECTED]>
-
a bug in the
driver logic.
> uname -a reports:
> Linux willow 2.6.23.1-hrt3 #1 SMP Sun Nov 4 14:51:20 GMT 2007 x86_64 GNU/Linux
The fix is simple, upgrade your kernel to 2.6.24 :)
>It's a kernel.org kernel with the patch for tickless operation on
> amd64.
Handily, the 2.6.
aphics Controller (rev 0c) (prog-if 00 [VGA])
Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo,
and a GM965 chip (using uvesafb)
>
> If there is anything else I can do to help please let me know.
>
> Carlos R. Mafra
--
Calvin Walton <[EMAIL PROTECT
ugly fuzzy, looking like a jpg
> compressed to 10%. The system is not usable on a day to basis without the
> nvidia driver.
You should probably give the nouveau[1] driver a try, if only for
testing purposes; if you are running an NV4x (G6x or G7x) card in
particular, it works a lot
39 matches
Mail list logo
