OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Lars on March 02, 2025, 02:39:56 pm
-
I am using XWorkplace 1.0.17 and recently I added the "CPU temperature" widget to XCenter to keep track of CPU temperature.
Unfortunately, it will always display 0 °C.
I am using an AMD CPU and I suppose, that is the problem. Needless to say that I have ACPI installed and working (but ACPI power management turned off, see below).
I have no clue what widget DLL implements the CPU temp widget and I don't know where I can find the source code.
1) can someone point me to the source code ? That could be my starting point of implementing a widget
2) does the existing widget build upon ACPI functionality to query temperature ? If yes, then I would suspect that this functionality does not work for AMD CPUs but I don't know. Does anyone have any insight ?
3) I currently have ACPI power management turned off (for performance reasons). Does power management have to be active so that CPU temperature can be queried via ACPI (if ACPI is involved) ?
-
In the meantime, I found the source code for the CPU Temperature Widget.
It uses ACPI to query temperature. I consequently tried "acpistat.exe" to see what it returns:
Thermal information:
No Thermal information is available for this computer
Question is: why does ACPI not offer temp check ? When I start the computer, I can go into its BIOS and it will give me extended temperature info for CPU as well as for MB. Does that mean that querying the temperature is specific for this board and not covered by what ACPI offers ?
Enabling ACPI power management did not make a bit of a difference.
-
Hey Lars!
I am using XWorkplace 1.0.17 and recently I added the "CPU temperature" widget to XCenter to keep track of CPU temperature.
Unfortunately, it will always display 0 °C.
I am using an AMD CPU and I suppose, that is the problem. Needless to say that I have ACPI installed and working (but ACPI power management turned off, see below).
So as I understood the whole ACPI ecosystem it is not necessary for things like power management to be activated in order for the hardware to report runtime metrics.
Whether it is Intel, AMD or others (CPUs or chipsets) so long as the motherboard vendor implements the proper ACPI functionality, the subsequent OS or APP software should have the ability to query the various ACPI components.
Take a look at the officials specs https://uefi.org/specifications (https://uefi.org/specifications), ACPI is at 6.5a level now. They also show a good number of technical/whitepaper docs on there that help with digesting all of this.
I have no clue what widget DLL implements the CPU temp widget and I don't know where I can find the source code.
1) can someone point me to the source code ? That could be my starting point of implementing a widget
OK, so when installing ACPI support you have the option of installing the ACPI Toolkit. In my case the stuff sits in \acpi\toolkit where you'll find the header files, libs, some docs and a good measure of sample code.
2) does the existing widget build upon ACPI functionality to query temperature ? If yes, then I would suspect that this functionality does not work for AMD CPUs but I don't know. Does anyone have any insight ?
Great topic, so in the other thread (CPU shutdown) I mentioned that I was trying to digest the ACPI framework in order to expose this information, basically thinking along the lines of what you articulated in your post here.
So far here is how all of it appear to glue together using the TEMPERATURE topic as an example (this is very much WIP on my part, so I'm sure I'm missing some stuff and most likely misunderstanding things):
1) in the \acpi\toolkit\samples directory look at the acpitree.c code, where you'll find this section:
if (DevInfo->Type == ACPI_TYPE_THERMAL)
{
printf(" Thermal State:\n");
AcpiTkWalkResources(ObjHandle,
"_TMP",
internal_PrintResourceInfo,
(void *) NestingLevel);
}
if (DevInfo)
{
AcpiTkOsFree(DevInfo);
}
return AE_OK;
In particular the key here is that reference to "_TMP" in the AcpiTkWalkResources API call, which the toolkit docs explain as:
Parse an ACPI Resource List.
AcpiStatus = AcpiTkWalkResources(Device, &Name, UserFunction, &UserContext);
PARAMETERS
Device (ACPI_HANDLE) - input
A handle to the Device for which one of the resource lists will be walked:
Name (char *) - input
Name of a resource method (either a _CRS or _PRS method.)
UserFunction (ACPI_WALK_RESOURCE_CALLBACK *) - input
A pointer to a user-written function that is invoked for each resource object within the resource list. (See the interface specification for the user function below.)
UserContext (void *) - input
A value that will be passed as a parameter to the user function each time it is invoked.
RETURN VALUE
Status (ACPI_STATUS) - output
Exception code that indicates success or reason for failure.
Functional Description:
This function is equivalent to the AcpiWalkResources function described in the Intel ACPI Component Architecture User Guide and Programmer Reference.
In other words, that "_TMP" is the "Name of a resource method" that you are interested in obtaining information about/from. Further on, if you look this up in the official ACPI docs you'll find that following:
11.4 (Thermal Objects) => 11.4.18 (_TMP Temperature)
...with the following (rather criptic details being shown):
11.4.18 _TMP (Temperature)
This control method returns the thermal zone’s current operating temperature.
Arguments:
None
Return Value:
An Integer containing the current temperature of the thermal zone (in tenths of degrees Kelvin)
The return value is the current temperature of the thermal zone in tenths of degrees Kelvin. For example, 300.0K is represented by the integer 3000.
OK, but not all is lost. There are other "resouce methods" you can use to obtain all the information you need, these are nicely listed in the main table at the start of 11.4 (Thermal Objects) section.
Soooo...I am thinking that what AOS (DavidA in particular) provided us with is the ability (through ACPI framework) to access such "resource methods". What I am not sure is whether ALL such ACPI currently defined methods are available, or just a subset.
With ACPI framework there is that whole notion of motherboard firmware (BIOS) needing to support the various ACPI calls, which in fact are pseudo-code (similar to how the JVM stuff works) and which the OS/APP layer issues and the firmware understands and is capable of responding to.
This is well documented in CH19 of that ACPI Specs document, as well as CH20 which talks about "ACPI MACHINE LANGUAGE (AML) SPECIFICATION".
What I am unclear about at this point in time is as to whether the ASL & AML stuff is completely transparent to us (at the API level for example)? I think the answer is YES, but yet our ACPI package ships with iasl.exe, which is:
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20210331
Copyright (c) 2000 - 2021 Intel Corporation
Supports ACPI Specification Revision 6.3
Usage: iasl [Options] [Files]
....so the plot thickens!!! lol
NOTE: I think ASL is used to actually dynamically define & create the whole ACPI set of tables which can then be loaded into BIOS at runtime, thus allowing the OS to further customize the particular behaviour/functionality present on specific hardware. That way you could in fact "patch" faulty motherboard hardware and have the BIOS execute this stuff. This is a pure stipulation on my part though as I honestly do not understand this enough at this point in time...
-
The source for the temperature widget I use is at http://os2.snc.ru/pub/SystemLoad/SL-src-20200302.zip (http://os2.snc.ru/pub/SystemLoad/SL-src-20200302.zip). It does not use ACPI, which doesn't support this Intel box, but rather seems to directly read the temperature sensors on the CPU. You have to look at rdmsr.sys source.
Used to be and perhaps still is that a lot of these sensors were on the smbus and each chip set would need a driver.
-
By now I found out that my system ACPI contains a _TZ_, a thermalzone device that is, but it does not contain a _TMP method. Looks like a different way is needed. I hope that AMD supports the same proprietary way to query the temperature sensors that the systemload widget uses.
-
Got a little further:
1) the "SystemLoad" temperature widget from Digi only works for Intel CPUs. He is reading from an MSR to query the temperature value. And that MSR does not exist on AMD CPUs (unfortunately not all MSRs are part of the base X86 architecture ...). The XCenter widget (I think) also leads to repeated traps on my system (CPU: FX-8350, which is a Vishera release of the Bulldozer architecture) once the WPS attempts to load until the system finally completely freezes.
2) stumbled across a Windows utility to read out temperatures. And for AMD, they say that they are reading a register from the Northbridge (and that seemingly works for many later AMD CPUs and should also include the FX-8350 and @Dariusz it should therefore also include the FX-8370 ...). In order to find the spec: is the Northbridge built into the CPU or is is part of a separate chipset ?
-
Hey Lars!
1) the "SystemLoad" temperature widget from Digi only works for Intel CPUs. He is reading from an MSR to query the temperature value. And that MSR does not exist on AMD CPUs (unfortunately not all MSRs are part of the base X86 architecture ...). The XCenter widget (I think) also leads to repeated traps on my system (CPU: FX-8350, which is a Vishera release of the Bulldozer architecture) once the WPS attempts to load until the system finally completely freezes.
Ahh, to be somewhat expected given that the "olden way" of getting at this info was to query specific hardware locations...so as you found out given the lack of industry standard, which to be honest I can't imagine any vendor to ever agree on this type of stuff, they all want to do stuff 'their way', would require you to hit the CPU/CHIPSET specific locations on the new hardware
2) stumbled across a Windows utility to read out temperatures. And for AMD, they say that they are reading a register from the Northbridge (and that seemingly works for many later AMD CPUs and should also include the FX-8350 and @Dariusz it should therefore also include the FX-8370 ...). In order to find the spec: is the Northbridge built into the CPU or is is part of a separate chipset ?
So for our Vishera CPUs the Northbridge is actually contained on the CPU die. This actually is composed of the System Request Interface, Memory Controller, DRAM Controllers and crossbar (Copy & Paste from the 'AMD Piledriver BIOS and Kernel Developer's Guide). There still is a motherboard Northbridge, but that functionality is nowhere what it used to be. Instead stuff like 990FXA (which my MSI 990FXA-GD80 board has) handles the connectivity between the CPU and the rest of the system, so think along the lines of PCIe lanes, HyperTransport, etc. Southbridge on the other hand handles stuff like SATA, RAID, USB, conventional PCI bus, etc.
Some motherboards of course provide alternatives, so USB3 for example being implemented through a different chipset altogether.
As it happens that AMD BIOS and Kernel Dev Guide has a full listing of ALL the availble registers. So you could look that up (it is a PDF) and see if you match against what that Windows util is using?
Now, I will say this: it would be awfully nice to have the acpidecode utility so that the dump of your ACPI tables (which can be obtained through the our APIC implementation with acpidump) could be translated to a more human readable mapping
Having said that, way back when, as in around ACPI 3.18 the ACPI utils used to be released as a binaries. Since then the AOS releases have gone to all of these utils being lumped into the "samples" directory of the Toolkit, which of course you can try compiling. I suppose that's probably my next step seeing that doing so would at least give me the most up-to-date versions for the ACPI system we have today.
Regardless, I've attached two outputs:
1) acpi_object
- this is the result of the old acpitest.exe
2) acpi_tree
- this is actually a version of the acpidump that gives you a nice hierarchical snapshot of what hardware you currently have an most importnatly of all, which devices support which ACPI methods!!!
So here is a little section of it:
+*_PR_ T:[Scope]
|
+*SSDT T:[Region]
|
+*DCOR T:[Integer]
|
+*TBLD T:[Integer]
|
+*NPSS T:[Integer]
|
+*HNDL T:[Integer]
|
+*APSS T:[Package]
|
+*P001 T:[Processor]
|
+*TYPE T:[Integer]
|
+*_PDC T:[Method]
|
+*P002 T:[Processor]
|
+*TYPE T:[Integer]
|
+*_PDC T:[Method]
This represents the processor table where each P00x object shows an available _PDC method, which the ACPI 6.5a specs document as follows: "Processor Driver Capabilities – inform AML of processor driver capabilities.".
Now, I do not know that this is the right place for the full answer...well, I do, and it is NOT (LOL), but it certainly seems like a viable path to pursue b/c now I could take some of the Toolkit sample source code and modify to get the specific details I'm after.
Digging into this a tad more I do actually find the 'Thermal Zones' scope in that ACPI tree:
+*_SB_ T:[Device]
Current state:
Possible State:
|
+*PR00 T:[Package]
|
+*AR00 T:[Package]
|
+*PR20 T:[Package]
|
+*AR20 T:[Package]
|
+*PR21 T:[Package]
...
So at least one can look up the very specific syntax to use in order to get the specific 'temperature' details we are interested in.
More to come on this for sure as unlocking the ACPI approach would get us CPU/chipset agnostic way to query up the information...the big assumption here of course being that the ACPI implementation we are using isn't just Intel specific, and seeing how ACPI is an industry standard these days, I'm thinking this should cover non-Intel stuff as well.
-
Hi Dariusz,
my ACPI is crippled, it's very old and does not support many of the new ACPI objects. And then, I don't know if with our ACPI.PSD there is a way to overload ACPI tables on the fly.
But this webpage gave me the clue how for AMD you can read temperature directly from PCI config space:
https://www.alcpu.com/CoreTemp/howitworks.html
Then I found the AMD BIOS Writer's Guide:
https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/42301_15h_Mod_00h-0Fh_BKDG.pdf
The register to read is the "Reported Temperature Control" PCI config space register Device 18h Function 3 Byte Offset A4h (so yes, in principle, the ACPI tables could be extended by AML code that just reads that specific PCI config space register but I am far from an expert on ACPI).
Now I need some time to "borrow" the XWorkplace Temperature Widget code and hack together a widget for AMD.
And then I have to find out exactly what AMD CPUs support that PCI config space register. Don't want to crash anyone's system ...
-
Run 'testlog acpi' then look at the last 5000+ lines: it's all there. Also, run 'iasl.exe' to see if any of its many options are of use to you.
-
Run 'testlog acpi' then look at the last 5000+ lines: it's all there. Also, run 'iasl.exe' to see if any of its many options are of use to you.
It is there if your ACPI supports it. It does not work on my system: ACPI is of no help on my system. I also used "acpimanager" to get a visual representation of my ACPI. Nothing of use can be found in my ACPI tables.
I will need to use proprietary methods to read CPU temperature and AMD works differently than Intel: AMD uses PCI config space and Intel uses a dedicated MSR.
AcpiManager: https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/util/power/ACPIManager_00-14.zip
-
Hey Lars!
my ACPI is crippled, it's very old and does not support many of the new ACPI objects. And then, I don't know if with our ACPI.PSD there is a way to overload ACPI tables on the fly.
Not sure the age of your hardware, but the early years of ACPI were plagued by buggy BIOS firmware, etc., so this may not be all that surprising.
Then I found the AMD BIOS Writer's Guide:
https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/42301_15h_Mod_00h-0Fh_BKDG.pdf
The register to read is the "Reported Temperature Control" PCI config space register Device 18h Function 3 Byte Offset A4h (so yes, in principle, the ACPI tables could be extended by AML code that just reads that specific PCI config space register but I am far from an expert on ACPI).
Yeah, spot on. I was thinking to myself that if ACPI is not workable then querrying up the right register might still get you to the right spot. That PDF is the bible for the FX CPUs. Keep the following in mind: there really are TWO CPU temperatures: core and package. The core stuff does not store/output an actual temperature, rather it is an offset from what AMD considers the MAX safe temp for this particular CPU. Which means you need to do a little bit of a calculation to try to either get it back to a F/C-degree scale, or you can simply call this value out as "xx Deg. away from MAX Temp". The ACPI logic (as well as the processor itself) use this information to determine when a critical thermal shutdown needs to be initiated. The PDF describes this as well.
And then I have to find out exactly what AMD CPUs support that PCI config space register. Don't want to crash anyone's system ...
LOL, I know the feeling...I trapped my box yesterday as I ran the acpistat command from that 3.18 ACPI release against my current installed ACPI base...oops...you'd think it would perhaps fail a bit more gracefuly!
-
Hi Dariusz,
by now I have hacked together a proof of concept. Since you have a FX 8380 CPU (I think), would you be willing to test ? Beware, the test prog has no strict error checking but I can provide the source code to you ...
You will also need to install:
https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi
which is my driver + DLL to execute code in Ring 0 (necessary for the test program to read MSRs, also used to map physical to linear address).
-
Lars!
..by now I have hacked together a proof of concept. Since you have a FX 8380 CPU (I think), would you be willing to test ? Beware, the test prog has no strict error checking but I can provide the source code to you ...
You will also need to install:
https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi
which is my driver + DLL to execute code in Ring 0 (necessary for the test program to read MSRs, also used to map physical to linear address).
OK, so the install of that SysCall WPI is done...but everything in that source tree is dated Dec-2020 and earliert, so I'm guessing this does not contain any of the stuff you were working on...or am I missing something?
In other words: happy to test, I just don't know what it is that I should be trying to test???
-
Correct, the test proggie I will still need to attach here. Will do so.
-
Find attached.
-
Find attached.
...and the results are:
[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.
-
For comparison, on my I5 the sl cputemp.exe, starting at idle and replying here, I get,
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.
-
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.
-
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:
[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
-
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 ...
-
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 ...
-
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).
-
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':
[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:
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?
-
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.
-
@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.
-
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
-
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:
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.
-
Hi Lars
Any chance of a standalone/non-widget version in the future?
Regards
Pete
-
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
-
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.
-
Hi Lars
Any chance of a standalone/non-widget version in the future?
Regards
Pete
Yes, sure. I just thought that everybody would be keen on an XCenter widget ...
-
Bad news: I found the document for Family 15h AMD CPUs and not for Family 19h as I claimed (and I updated the test proggie accordingly).
According to what I found on the internet, the document for Family 19h (Zen Architecture, including Ryzen CPUs) is under NDA (thank you AMD). Therefore, I can only hope that it works as it did for Family 15h but I am not optimistic. They seem to change the mechanism to read CPU temperature pretty often.
I think all of this is a hopeless case. Doug, if your system properly supports reading the temperature via ACPI, then this is certainly the best way to go. Does the conventional CPU Temperature widget of the monitor widget classes work for you ? That is based on ACPI. I yes, an AMD CPU specific widget is completely unnecessary for you.
-
My ASUS ROG Zephyrus G14 2024 comes with an AMD Ryzen 9 8945HS CPU.
The CPU Temperature Widget shipped with ArcaOS 5.1.1 (Native Installation, Windows 11 and Linux Mint as well native) works out of the box, see attached picture.
-
Lars,
I tried your new version and it doesn't work on my processor. Thank you for trying.
The cpu temperature widget contained in standard xcenter monitor.dll also doesn't work. I think I saw somewhere that ACPI on this machine does not report temperature in the proper way - and my memory was I saw that in the acpid log file - but I turned logging back on and now can't find that message. So maybe I am mis-remembering this.
This is only a 6 core processor, with the factory cooler for the processor, in a desktop case with good ventilation. I am not too worried about excessive processor temperatures. I don't compile large projects, like Dave or Jack. I have a wattage meter on the machine and the highest consumption spike I have seen is 120 watts - and that is during bootup.
Thanks again Lars for your work on this, and all the other projects you have done for OS/2.
-
Hey Lars!
@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.
Appreciate the update, however I have never actually used the XCenter itself, nor any of the widgets. I'm in the thick of a lot of project work at the moment, thus my late response, but let me come up for air over the next week or so and I'll try to do a test install here.
As always: Thank You!