Author Topic: An XWorkplace CPU Temperature Widget for AMD CPUs  (Read 10079 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1428
  • Karma: +28/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #15 on: March 07, 2025, 03:28:11 pm »
Find attached.

...and the results are:

Code: [Select]
[G:\TEST\CPUTEMPT]cputemp
MMIO Configuration Base Address:0x00000000E0000000
Northbridge caps: 0x2F04F1E
Temperature core 0 (0x39E00F5F):57.88 °C

A couple of notes:

1) I currently do NOT have MMIO enabled in my BIOS, I can turn this ON if you suspect this has any bearing on the output

I ask this since looking at your source I see multiple references to MMIO, but as best as I can tell this is needed to get that physical to linear mapping, is that correct? If so, I do not think it matters whether MMIO is enabled or not.

2) Is that actual core temp, or package temp?

I ask this b/c my motherboard (MSI 990FXA-GD80) has a DEBUG LED display mounted on the it that amongst other things (such as BIOS process codes and errors) displays the 'CPU Temperature'....the only problem is that nowhere does it actually spell out whether this is the core or package temp.

Anyways, my box has consistently shown 49-50C on that LED display while your util shows 57C, so I'm wondering if you are picking up the package temp maybe?

As I understand it the package temp is always higher than the core simply b/c it does not have the sort of active cooling that the cores do. Typically that sensor is located in the CPU mounting socket with very little airflow so temps there stay a tad higher simply because of the fact that the various CPU pins themselves heat up as the current is being drawn by the CPU itself.

Also, for what its worth given the research I've done into this (FX specific): CPU temp/core temp it is not very accurate at less than 40C given that it isn't a sensor but an algorithm so it is sort of guessing/computing with much larger error at temperatures much less than 40C. I found that '40C' a bit artibrary though, different folks seems to call out different +/- values around that 40C though.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5352
  • Karma: +127/-1
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #16 on: March 07, 2025, 05:00:58 pm »
For comparison, on my I5 the sl cputemp.exe, starting at idle and replying here, I get,
Code: [Select]
W:\sys\apps>cputemp.exe
System Load - Processor temperature monitor.

Core 0/1/2/3: 26/33/Offline/Offline
Core 0/1/2/3: 26/34/Offline/Offline
Core 0/1/2/3: 26/34/33/Offline
Core 0/1/2/3: 27/32/34/Offline
Core 0/1/2/3: 27/35/34/24
Core 0/1/2/3: 27/36/35/37
Core 0/1/2/3: 27/36/35/37
Core 0/1/2/3: 27/36/35/38
Core 0/1/2/3: 28/36/35/38
Core 0/1/2/3: 28/36/36/Offline

The widget shows CPU #0 and doing a mouse over a tips window shows all CPU's that are online.
As an aside, I've recently read in a couple of places that after a few years, the thermal paste should be replaced, perhaps why cores 1-3 run hotter then core 0 as this computer is from 2018.

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #17 on: March 08, 2025, 01:55:15 pm »
When you talk about "MMIO" I think you are referring to the IOMMU unit that can remap physical to another physical address, for virtualization purposes.

When I talk about "MMIO" , I mean to say that PCI config space is not accessed via the two well known I/O registers 0xCF8 and 0xCFC but instead, it is accessed via a memory address. The physical base address of that space is as your output shows and then, a virtual offset is added to that base address and the virtual offset is composed of the bus number, the device number, the function number and a PCI register offset. And since all that is still a physical address, it then has to be mapped to a linear address (by SW and the code sample does that).

So yes, the IOMMU unit is not related to this.

As to temperature: I have no clue as to exactly what temperature this refers to. And what's even more odd, if you run it a couple of times, it will jump in temperatue. The only thing that I understood from the FX BIOS programmers spec is that not the real measurement temperature is returned but instead, a control temperature. But you can somewhat couple the control temperature to the measures temperature and the code sample tries to do that ( you can have the control temperature somewhat follow the measurement temperature).
I also tried to use Dos SetThreadAffinity to force the thread onto the first logical Processor but the DosSetThreadAffinity bogs down the system if you restrict thread 1 to only execute on the first logical processor. I'll need to further experiment.
« Last Edit: March 08, 2025, 05:22:25 pm by Lars »

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1428
  • Karma: +28/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #18 on: March 08, 2025, 08:06:55 pm »
Hi Lars,

When you talk about "MMIO" I think you are referring to the IOMMU unit that can remap physical to another physical address, for virtualization purposes.

When I talk about "MMIO" , I mean to say that PCI config space is not accessed via the two well known I/O registers 0xCF8 and 0xCFC but instead, it is accessed via a memory address.
...
So yes, the IOMMU unit is not related to this.

Indeed that was the MMIO I was thinking of and reading up on in the meantime to understand how this might be imapcting what's being produced. OK, cool...thank you for clarifying as I was most certainly venturing down the wrong path!

As to temperature: I have no clue as to exactly what temperature this refers to. And what's even more odd, if you run it a couple of times, it will jump in temperatue.

Yes, that is what I saw here as well. That temp sometimes fluctuates very little even while the m/b DEBUG LED did spike by the normal 3C deg when I ran the SYSBENCH float tests. Other times (like right now as I'm typing this post) I see a big 10C drop:

Code: [Select]
[G:\test\cputempt]cputemp
MMIO Configuration Base Address:0x00000000E0000000
Northbridge caps: 0x2F04F1E
Temperature core 0 (0x3CA00F5F):60.63 °C

[G:\test\cputempt]cputemp
MMIO Configuration Base Address:0x00000000E0000000
Northbridge caps: 0x2F04F1E
Temperature core 0 (0x3B800F5F):59.50 °C

[G:\test\cputempt]cputemp
MMIO Configuration Base Address:0x00000000E0000000
Northbridge caps: 0x2F04F1E
Temperature core 0 (0x3BA00F5F):59.63 °C

[G:\test\cputempt]cputemp
MMIO Configuration Base Address:0x00000000E0000000
Northbridge caps: 0x2F04F1E
Temperature core 0 (0x33C00F5F):51.75 °C

The only thing that I understood from the FX BIOS programmers spec is that not the real measurement temperature is returned but instead, a control temperature. But you can somewhat couple the control temperature to the measures temperature and the code sample tries to do that ( you can have the control temperature somewhat follow the measurement temperature).

I think you are talking about that whole Tctl logic, yes? I've printed out the 2 pages from the Guide and it would appear that the temp being calculated by the processor TCC logic is what then feeds into the other elements.

What's confusing about this is that the PDF talks about how these are used for internal CPU functionality such as P-state change, or even the actual THERMTIRP (which is the critical CPU temp approach warning), it really doesn't spell out at all anything else.

I did also look through all the 3.10-3.14 MSRs registers, but to this amateour eye nothing obvious popped out! lol

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #19 on: March 09, 2025, 08:27:23 am »
Yes, I was talking about control temperature. As far as I understood, you do not get directly returned the measured temperature but the control temperature can be kind of tied to follow the measured temperature and the control temperature is used to shut off the core/CPU/whatever in case it becomes critical. The CurTmp field in the temperature register returns the control temperature. The one thing that strikes me as odd is that you can make the control temperature climb when your measured temperature climbs. That seems to contradict its purpose ...

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #20 on: March 09, 2025, 02:07:22 pm »
Found out what the problem was: I need to use DosSetThreadAffinity to force the execution onto a specfic logical Processor. Plus, it is better to leave the other settings in the CPU temperature register unmodified.
DosSetThreadAffinity has the oddity that if I specify affinity = {1,0} (that is, only logical processor 1) it will block the system, so I need to specify {3,0} for whatever reason to make it work.

In order to report all temperatures, I would need to walk through all logical processors (by using DosSetThreadAffinity) but I think I am going to stick to logical processor number 1 (the CPU widget only displays one temperature anyway).
Will attach what I have right now, just hold on ...

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #21 on: March 09, 2025, 02:20:08 pm »
Hi Dariusz,

try the attached. If you look at the output, check "local APIC ID" to see if it is constant (it should never change from one invocation to the next).
Feel free to modify the code and propose different stuff.

My experience is that logical processor 1 is always the hottest as it is most busy under OS/2 (logical processor 1 has special role under OS/2: will exclusively run IRQ handlers, for example).

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1428
  • Karma: +28/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #22 on: March 09, 2025, 07:24:50 pm »
Hi Lars,

try the attached. If you look at the output, check "local APIC ID" to see if it is constant (it should never change from one invocation to the next).
Feel free to modify the code and propose different stuff.

Yup, that works. I am consistenty seeing just 'Local APIC:0x01':

Code: [Select]
[G:\test\cputemp]cputemp
AMD CPU: Family:0x15, Model:0x02, Local APIC:0x01
MMIO Configuration Base Address:0x00000000E0000000
Temperature core 0 (0x3B800F5F):59.50 °C

[G:\test\cputemp]cputemp
AMD CPU: Family:0x15, Model:0x02, Local APIC:0x01
MMIO Configuration Base Address:0x00000000E0000000
Temperature core 0 (0x3B400F5F):59.25 °C

[G:\test\cputemp]cputemp
AMD CPU: Family:0x15, Model:0x02, Local APIC:0x01
MMIO Configuration Base Address:0x00000000E0000000
Temperature core 0 (0x3C600F5F):60.38 °C

My experience is that logical processor 1 is always the hottest as it is most busy under OS/2 (logical processor 1 has special role under OS/2: will exclusively run IRQ handlers, for example).

I think this makes sense, but I'll say this: I have been consistently surprised that acpistat reports the most IRQs being handled by P002 on my box:

Code: [Select]
The version of ACPI.PSD that is installed is 3.23.16
The system is operating in Symmetric mode (Mode 2)
The kernel is 14.203_SMP
The retail PSD is installed

Number of interrupts available: 60
IRQ 00 count 5727838
IRQ 01 count 41176
IRQ 04 count 970024
IRQ 07 count 86
IRQ 08 count 161109395
IRQ 09 count 525
IRQ 12 count 560805
IRQ 14 count 2181
IRQ 16 count 10601
IRQ 17 count 14
IRQ 18 count 320483
IRQ 19 count 3487544
MSI 46 count 6689081

========== CPU0 ==================
ACPI name [P001]
IPIGenCount = 4708113    IPICount  = 68489594   HaltCount = 0
IPIPsdCount = 0          IdleCount = 186081463  BusyCount = 7350809
========== CPU1 ==================
ACPI name [P002]
IPIGenCount = 171725589  IPICount  = 37725731   HaltCount = 4
IPIPsdCount = 0          IdleCount = 34529681   BusyCount = 34529679
========== CPU2 ==================
ACPI name [P003]
IPIGenCount = 45044918   IPICount  = 61734043   HaltCount = 4
IPIPsdCount = 0          IdleCount = 35391949   BusyCount = 35391948
========== CPU3 ==================
ACPI name [P004]
IPIGenCount = 52654385   IPICount  = 60671812   HaltCount = 4
IPIPsdCount = 0          IdleCount = 35551057   BusyCount = 35551056
========== CPU4 ==================
ACPI name [P005]
IPIGenCount = 49883419   IPICount  = 61011487   HaltCount = 4
IPIPsdCount = 0          IdleCount = 35997515   BusyCount = 35997513
========== CPU5 ==================
ACPI name [P006]
IPIGenCount = 53737973   IPICount  = 60473144   HaltCount = 4
IPIPsdCount = 0          IdleCount = 36198100   BusyCount = 36198099
========== CPU6 ==================
ACPI name [P007]
IPIGenCount = 47435079   IPICount  = 61374857   HaltCount = 4
IPIPsdCount = 0          IdleCount = 35395312   BusyCount = 35395311
========== CPU7 ==================
ACPI name [P008]
IPIGenCount = 47665206   IPICount  = 61374014   HaltCount = 4
IPIPsdCount = 0          IdleCount = 35555379   BusyCount = 35555378

...unless of course that "IPIGenCount" value <> IRQ count?

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #23 on: March 10, 2025, 08:07:09 am »
1) as a test: if you modify the affinity mask of DosSetThreadAffinity to say 0x4,0, you will always see LocalAPIC 2 being displayed and as I suspect, with the temperature value of that logical processor that has that LocalAPIC ID, so it will be different. You can test ...

2) "IPIGenCount" reflects the number of times a core generates an IPI (Inter Processor Interrupt) to CPU0 to get its attention for various reasons (synchronisation, requesting exclusive access to a resource, whatever)..
In other words: that core does not handle an interrupt but instead, it generates an interrupt (to CPU0) and it is not an interrupt routed via an interrupt controller but rather within the chip itself. I don't know what "IPICount" is. Maybe this is indeed the other way around, any other CPU generating an IPI to that CPU, in which case there is some interrupt handling going on on all cores besides CPU0. But Hardware devices induced interrupts routed via an interrupt controller (all those IRQ and MSI interrupts, say USB Host controller, Network controller, audio device, timer tick device etc.) will always only be handled by CPU0.
« Last Edit: March 10, 2025, 08:20:06 am by Lars »

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #24 on: March 28, 2025, 06:42:01 pm »
@Dariusz: I have now made an XCenter Widget of it. Can you test ?

By the way: having the SYSCALL driver installed is no longer necessary. You do not need anything besides the Widget.
Source is included.


Doug Clark

  • Sr. Member
  • ****
  • Posts: 366
  • Karma: +12/-1
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #25 on: March 29, 2025, 12:11:51 am »
Lars,

I downloaded and ran cputemp.wpi and it doesn't show up in the "create a new widget" popup menu.  cputamd.dll and cputamd.sys are in
c:\sys\apps\xwps\plugins\xcenter 

The cputamd.dll also doesn't show up on the "Classes" page on the xcenter properties

Isn't xCenter supposed to pick up all the widget DLLs that are in c:\sys\apps\xwps\plugins\xcenter ?

Thanks

Doug

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #26 on: March 29, 2025, 08:39:51 am »
Did you get an error message from XCenter? that it cannot load the widget? Do you have an AMD CPU?
Look in var/log/xwplog.log

which is the XWP error log file. It'll give information. If you get something like this:

Code: [Select]
2025-03-29 09:49:07:25 T033 plgLoadClasses (D:\prj\xwp\xwp\xworkplace-1-0\src\shared\plugins.c, line 514):
    InitModule call (export @1) failed for plugin DLL
        "D:\TOOLS\XWPS\plugins\xcenter\cputamd.dll".
    DLL returned error msg:
        No AMD CPU, CPU-Temperature (AMD) widget cannot load.

that would mean you have no AMD CPU.
« Last Edit: March 29, 2025, 09:52:20 am by Lars »

Pete

  • Hero Member
  • *****
  • Posts: 1402
  • Karma: +13/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #27 on: March 29, 2025, 03:12:43 pm »
Hi Lars

Any chance of a standalone/non-widget version in the future?


Regards

Pete

Doug Clark

  • Sr. Member
  • ****
  • Posts: 366
  • Karma: +12/-1
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #28 on: March 29, 2025, 05:45:52 pm »
Lars,

there is no log file for xwplug.log - in c:\var\log\xwplug.log
or in e:\var\log\

my unixroot is set to e:

I am running a Ryzen 5 5600x

I should add that cputemp runs with the following output:

AMD CPU: Family:0x19, Model:0x01, Local APIC:0x01
MMIO Configuration Base Address:0x00000000F0000000
Temperature core 0 (0x00000000):0.00 °C

So maybe the widget wouldn't show the temperature, based on the above output, even it it was installed in xCenter
« Last Edit: March 29, 2025, 06:12:52 pm by Doug Clark »

Lars

  • Hero Member
  • *****
  • Posts: 1426
  • Karma: +72/-0
    • View Profile
Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« Reply #29 on: March 29, 2025, 11:38:10 pm »
Hi Doug,

I just realized that for Family 19h AMD CPUs (that is: Ryzen), need to access different registers than on my Family 10h AMD CPU.
Try the attached.
« Last Edit: March 29, 2025, 11:44:37 pm by Lars »