Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dariusz Piatkowski

Pages: [1] 2 3 ... 95
1
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« 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?

2
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« 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

3
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« 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.

4
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 06, 2025, 04:06:53 am »
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???

5
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 05, 2025, 12:24:34 am »
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!

6
Networking / Re: inetcfg.ini - window size, but why this result?
« on: March 04, 2025, 05:41:28 am »
Hello Remy!

Which OS/2 driver do you use and what's your network chipset ?

I also use the MMRE driver here:

Code: [Select]
Signature:       @#Arca Noae LLC:1.1.9#@##1## 18 Sep 2023 13:35:25     DAZAR1
 ::::9::SVN105@@RealTek 8139C+/8169/8169S/8110S/8168/8111/8101E PCI NIC driver
Vendor:          Arca Noae LLC
Revision:        1.01.9
Date/Time:       18 Sep 2023 13:35:25
Build Machine:   DAZAR1
FixPak Version:  SVN105
File Version:    1.1.9
Description:     RealTek 8139C+/8169/8169S/8110S/8168/8111/8101E PCI NIC driver

I always have this king of issue (I found one setting which "seems" having reduced stallen state)

I have a chipset which is support by MMRE driver,  I have a correct speed on some link but awfull on  other like when I download updates from Smedley site. (speed never goes above 138KB !  - under windows, up to 2MB or trying using Aos from under a virtual box using a different driver than MMRE, speed goes up to 1.8MB and never got a stall status !)

Hmm, so this is slightly different symptom than what I'm seeing, but that is not to say that the root cause may be different.

Strangely enough in my case I can actually change these window sizes AFTER the application has been started, and that seems to be alright, it does not cause any problems. However trying to change first and then start the app will cause a guaranteed failure to connect.

I reported this problem several times to ArcaOS since Arcos 2.0 and each time, it ended with no problem found, for them MMRE is well operationnal....
The MMRE driver is unable to correctly work with in my case Realtek® 8111G Gigabit LAN

My MSI motherboard specs the Realtek RTL8111E NIC hardware and is reported as follows:

Code: [Select]
Bus 2 (PCI Express), Device Number 0, Device Function 0
 Vendor 10ECh Realtek Semiconductor Co., Ltd.
 Device 8168h RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
 Command 0007h (I/O Access, Memory Access, BusMaster)
 Status 0010h (Has Capabilities List, Fast Timing)
 Revision 06h, Header Type 00h, Bus Latency Timer 00h
 Self test 00h (Self test not supported)
 Cache line size 64 Bytes (16 DWords)
 PCI Class Network, type Ethernet
 Subsystem ID 76401462h Unknown
 Subsystem Vendor 1462h Micro-Star International Co., Ltd. [MSI]
 Address 0 is an I/O Port : D000h..D0FFh
 Address 1 is not present or not configured!
 Address 2 is a Memory Address (64-bit, Prefetchable) : FE904000h..FE904FFFh
 Address 4 is a Memory Address (64-bit, Prefetchable) : FE900000h..FE903FFFh
 System IRQ 46, INT# A
...

7
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 04, 2025, 05:27:31 am »
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:

Code: [Select]
+*_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:

Code: [Select]
+*_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.

8
Networking / inetcfg.ini - window size, but why this result?
« on: March 03, 2025, 05:13:19 am »
So a couple of days ago the AOS testers list was asked with giving some new SEND & RECEIVE window sizes a try.

Ever since I went to a 1Gig fibre line I had tweaked my inetcfg.ini to use the max allowable value for both TCP & UDP windows.

However this request prompted me to test and surprisingly enough I found that the smaller window size actually caused a repeatable 20-25% improvement when doing a speedtest run.

OK, nice...so I permanently updated my inetcfg.ini with these values, and carried along.

Today I needed to reboot my machine, all was good. The box re-started fine, I brought up my regular apps: PMMail, Thunderbird, RDP, Firefox...but whoa...hang on...why isn't Firefox taking me anywhere????

Yeah, it just sat there, spinning, "connecting..." but it would never go anywhere.

So I check the other apps: PMMail is good, but TB...nope, same story as FF.

I whip up the speedtest CLI...nope, not going anywhere either.

After numerous trials I determined that the window sizing was impacting certain apps. Further on, I found that on my machine anything smaller than 131,072 (so 128K) would cause the above described "stall", while anything bigger consistenty 'just works'!!! ugh???

Can anyone explain this please?

Here are the contents of my inetcfg.ini:

Code: [Select]
#Inetcfg:       CURRENT DEFAULT MINIMUM MAXIMUM

keepalive       60      7800    0       7800    KeepAlive (sec)
tcpswinsize     131072  32768   1024    246723  TCP SendWindow Size
tcprwinsize     131072  32768   1024    246723  TCP RecvWindow Size
udpswinsize     131072  9216    1024    246723  UDP SendWindow Size
udprwinsize     131072  41600   1024    246723  UDP RecvWindow Size
lingertime      120     120     0       65535   Linger Time (sec)
probecnt        8       8       1       8       Number Of KeepAlive Probes
ipforward       0       0       0       1       IP Forwarding flag ON/OFF
mtudiscover     1       1       0       1       TCP Path MTU Discovery ON/OFF
arpkillc        1200    1200    180     15300   ARP Complete TimeOut (sec)
arpkilli        180     180     60      1200    ARP InComplete TimeOut (sec)
lipcstswinsize  10240   10240   1024    246723  LIPC Stream SendWindow Size
lipcstrwinsize  10240   10240   1024    246723  LIPC Stream RecvWindow Size
lipcdgswinsize  2048    2048    1024    246723  LIPC Dgram SendWindow Size
lipcdgrwinsize  4096    4096    1024    246723  LIPC Dgram RecvWindow Size
synattack       0       0       0       1       SYN Attack Flag ON/OFF
syncookie       0       0       0       1       SYN Cookie Flag ON/OFF
firewall        0       0       0       1       FIREWALL ON/OFF
multidefrt      1       1       0       1       Multiple Default Routes ON/OFF
winscale        1       1       0       1       TCP Window Scale ON/OFF
timestmp        1       0       0       1       TCP TimeStamps ON/OFF
realslow        20      20      1       100     TCP TW Q Slow Timeout ticks
perfhttp        1       1       0       1       Fast Path HTTP ON/OFF
tcpttl          64      64      1       255     TCP  TTL (hops)
udpttl          64      64      1       255     UDP  TTL (hops)
icmpttl         64      64      1       255     ICMP TTL (hops)
fragttl         60      60      1       255     Fragment TTL (sec)
reusetw         1       1       0       1       Reuse Time Wait ON/OFF
msl             30      30      1       16384   TCP MaxSegLifeTime (sec)
cc              0       0       0       1       TTCP function ON/OFF
sack            1       0       0       1       Selective ACK ON/OFF

9
Programming / Re: stopping cpus
« on: March 02, 2025, 04:44:27 pm »
Hi Doug!

When running ACPISTAT my Ryzen 5/MSI motherboard shows no thermal information available, while the Intel i5 8th gen/HP machine does shows thermal information.  The Ryzen also doesn't support throttling or performance control; the i5 supports throttling.

So the 'throttling' functionality is something that used to be the orginal/default way of enabling power savings: after all if you were to tell the CPU to get down to just 25% of it's TOTAL output, you would subsequently see less voltage and current draw, less W being produced, and less thermal output.

Today however this functionality has been obsoleted by Power States, where the CPUs themselves are sophisticated enough to calculate the right combination of CPU frequency, voltage needed to support execution at that frequency, and the monitoring of the resulting temperature being generated. Now all that still has to be tied into/with with actual OS level execution and that's where the various ACPI methods come in, and in our case this is why the OS/2 implementation of ACPI uses the PowerManager daemon.

I am curious Darius what ACPISTAT shows on your Ryzen.

So in my case I'm actually using an older AMD CPU, FX-8370, which is a Vishera release of the Bulldozer architecture.

This box is heavily overclocked, which means higher CPU voltage, higher frequency (5GHz as opposed to the default 4GHz and 4.3GHz (boost) frequencies, which in turn requires me to implement specific BIOS settings required to support such an overclocked state. This means that in the BIOS itself I actually turned OFF AMD's C1E function, I shut off the CPU Phase Control function (which is normally motherboard specific as that allows the hardware to dynamically figure out how much power the CPU requires to support execution at a specific user-driven power level) and a few other power control functions.

In the end I do not use the ACPI PowerManager functionality since even if it wanted to control my CPU it wouldn't be able to do so since I had disabled all such BIOS level functionality. Subsequently I have no temperature readout even if I temporarily turn on PowerManager:

Code: [Select]
This system does not support CPU Performance Control via ACPI.

This system supports CPU Throttling. Current=100%

Thermal information:
  No Thermal information is available for this computer

No AC status is available for this computer

No Battery information is available for this computer
Power Manager is Enabled

10
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 02, 2025, 04:25:52 pm »
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, 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:

Code: [Select]
    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:

Code: [Select]
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):

Code: [Select]
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:

Code: [Select]
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...

11
Programming / Re: stopping cpus
« on: March 02, 2025, 12:10:07 am »
Thank you everyone for your responses. 

What utility are you using to get real-time temperatures of the processors?

NONE...and that's the problem on our platform Doug, although there were chipset specific drivers released in the past, but I believe today that's pretty much 'ancient history'.

Well, I should clarify the above statement: I do not have AOS installed, and so there may in fact be some functionality in various utils that are part of AOS.

It is for this reason that I mentioned in my earlier post me currently looking into the ACPI API functionality that perhaps might expose this, assuming our ACPI implementation handles that, which I simply have no idea.

12
Programming / Re: stopping cpus
« on: February 28, 2025, 04:51:02 pm »
Hi Doug!

...
3- Dave/Darius - I am afraid to turn off power management after reading the warnings in the ACPI docs - which basically say thermals may become a problem if you mess with power settings.  I did download the ACPI sdk and look through the documentation and I didn't see any function that seemed to address turning on or off processors.  But I might have missed something.
...
I suspect, like Darius, that either the processors aren't getting turned off, or something is turning them back on.  This appears to happen on both Ryzen and Intel processors. One using SNAP and the other using Panaroma.

From a 'good to know how to configure this' perspective the easiest way to TEST this on your machine is to DISABLE the ACPI PowerManager (as per the note that Dave posted, see acpid.cfg file). I believe ACPI daemon dynamically picks this up, so no reboot is necessary.

Then you can shut OFF the cores you do not need running and test your WIN-OS/2 use.

If this work, you know precisely HOW to get this working when you need it working. After all, re-enabling the ACPI PowerManager is just as easy as disabling it. You could literally have a little pm_off.cmd & pm_on.cmd scripts that simply replace the appropriate acpid.cfg files, which ACPI PM then recognizes.

In my experience the big CPU temperature spikes only occur when you really start pushing the machine. We are talking here heavy FLOAT ops such as running the SYSBENCH FLOAT benchmark, etc.

For example: as I play around with this stuff on my end I find that the 48C idle temp of my AMD FX-8370 CPU (8 core, 5GHz) goes up to 51C...which is a pretty tiny amount of just 3C increase. But make note that this is only achieved by deploying the Noctua NH-15D CPU cooler, which is very much in the realm of the overclocking domain.

Prior to installing this cooler I was running a Corsair A70 setup, which was showing 55C at idle and when running the SYSBENCH FLOAT tests the temp would spike all the way to 64C. Heck, a couple of times (as I was screwing around with both CPU frequency and core voltage) I actually had the whole box automatically shut-down.

Soooo....with today's systems there is a good amount of protection built-in...but it's always good to review your specific specs to know exactly what your MAX values are.

Ultimately the experimentation is what will give you the true answers.

EDIT
====

HERE (https://man.netbsd.org/acpicpu.4) is a good summary of all of these C/P/T-states, how they relate to each other, etc.

13
Programming / Re: stopping cpus
« on: February 28, 2025, 04:33:51 pm »
Dave, everyone...

Don't forget that you can disable/enable PowerMan by changing one line in \mptn\etc\acpid.cfg,
Code: [Select]
[PowerMan]

; Enable: 1=enabled, 0=disabled, default=1
Enable = 1

Correct, that is exactly how I control whether PowerManager is running, although in my case it is permanently turned OFF.

...And the ConfigCheckInterval can be changed from the default of 10 secs if you want a faster result from changing the enabled line.
Personally, my little computer will get too hot with PowerMan disabled though disabling for a while may be acceptable.
Also there is the ACPI sdk, which I've never looked at, IIRC it can be installed from the acpi.wpi.

Yeah, good point here. There certainly are numerous available parameters that one can tweak in order to get a more "fitting" configuration enabled. In my case, much like what Lars' comment highlighted, having spent a good amount of time working through these I was simply unable to get that balance. The system was always lagging in turning on the CPU/cores when I needed the extra power, this resulted in that "why are things running so slow?" kind of a feel.

I did actually reach out to DavidA (AOS) to work through this, but following several back'n'forth exchanges I was simply told "that's how it works, nothing to change here, it is correct". It is not that he is wrong, I understood all his points but perhaps the ACPI implementation on our platform just can't provide the sort of seamless power transition experience we normally see on other platforms?

14
Programming / Re: stopping cpus
« on: February 28, 2025, 04:12:50 am »
Ahhh...so I'm going to float an idea here that I have arrived at having personally fought through symptoms such as what you just described, and eventually figure out the relationships at play.

The modern day combination of OS/2 software to support/enable SMP most likely has us all using the ACPI driver, and that by default also means that we have the ACPI daemon managing the CPU/cores according to how you actually configure the system.

What this means is that APCI will attempt to use it's fairly sophisticated logic to enable things such as CPU power saving modes (think of the different CPU Cx states here). Basically these are the PowerManager settings in the acpid.cfg file sitting in \mptn\etc.

Now by DEFAULT the ACPI install has the PowerManager enabled and that also means that ACPI and NOT YOU are deciding what a particular CPU/core should be doing. Heck, on the surface acpid.cfg has enough settings there for you to almost set it up for a nearly seamless "power on when I need it" type of an experience.

....BBBUUUUTTTTT.....that also means that ACPI will insist on being the one who controls your CPU/cores and so subsequently when you are attempting to power off/disable a CPU core using an API call such as DosSetProcessorStatus, it most certainly will, but in the background ACPI will immediately take over and either undo what you just did, or if the system is nearly IDLE it may in fact let that CPU/core stay in disabled status.

This very thing caused me a boat-load of problems b/c on my OS/2 box (4.52, so non AOS install but using the same ACPI release) I occasionally have an OS/2 application that will lock my box (soft freeze, CTRL+ALT+DEL still works to power down) during app startup (I have been told maybe SNAP driver related, I think it is something else), and so I took to using a REXX wrapper to always disable all but a single CPU core before I needed to run such a program. Well, as you can imagine when I moved over to ACPI I all of a sudden was plagued by these soft locks 'once again'...I worked and worked through numerous iterations of configs until I finally discovered that the default ACPI PowerManager settings were occasionally flipping ON one of the just disabled cores and BAM...yup, the lock-up would occur.

Soooo....bottom line here is that on this 24x7 box of mine I do not care at all about how much power that sucker eats up, it is backed up by a 1500W UPS box and stays on all the time, running at full 5.2GHz core speed across all eight of it's cores!

Happy with what I have, combination works for me, but it did require me to disable the ACPI PowerManager.

So what I'm curious about Doug is what that specific error message is that you are seeing? Could it be that DosSetProcessorStatus API was patched to sync it up with the ACPI daemon's logic which is driven by the PowerManager??? That would be fancy, although I doubt that is the case.

Food for thought - I am actually trying to understand the whole ACPI system b/c I'd like to create a little utility that tells us a lot more about what the current hardware configuration, and specifically CPU runtime readings are like, we are talking the Cx core states, the actual frequency different cores are running, heck ACPI is even supposed to give you the ability to see the CPU L1/2/3 cache hit ratios, etc....cool stuff!

15
Hello Alfredo!

The topic you raise here is equally applicable to all the other programming languages on our platform.

'Knowledge is Power', right?

So I would suggest that where things start for us is in establishing a good Developer Library/References.

I've attached what such a library looks like on my machine, specifically focusing on REXX. This is a mix of freely available information, as well as PDF downloads of previously commercial books, etc.

Now you may argue that the PDFs in particular are illegal, etc., etc....OK, fine, so why not provide an executable d/l script that simply uses wget to pull this list down from any of the well recognized archive sites??? That way each end-user makes this decision for themselves!

Bottom line being: tutorial, try-by-example, all these things are great, but when you are new to something you ultimately need a solid 'something to go to in order to understand what the example code/API does', and that's the missing piece for us I think.

Pages: [1] 2 3 ... 95