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 - Lars

Pages: [1] 2 3 ... 94
1
Applications / Re: OO 4.1.11 trouble
« on: March 18, 2025, 12:23:44 pm »
use the listing feature of wic.exe to find out if these DLLs are in "AOO-41110-GA-base-en-US.wpi" or not.
If yes and if they are in a separated package, then you can either uninstall it or not install in the first place.
I am still running AOO 4.1.2 and none of these files have ever been installed to any of the AOO subdirectories.

2
Applications / Re: OO 4.1.11 trouble
« on: March 17, 2025, 09:51:13 am »
For OpenOffice, have you somehow overriden the LIBPATH setting or the BEGINLIBPATH / ENDLIBPATH setting ?
Are you sure that libcn0.dll is actually found ?

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

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

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

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

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

8
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 06, 2025, 10:44:35 pm »
Find attached.

9
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 06, 2025, 06:29:49 pm »
Correct, the test proggie I will still need to attach here. Will do so.

10
Networking / Re: inetcfg.ini - window size, but why this result?
« on: March 05, 2025, 08:29:13 am »
I suspect that "System IRQ (disabled)" indicates that it is using MSI instead of the conventional PCI IRQ Line.
I have the same PCI output but it also says "MSI is enabled".

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


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

13
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 04, 2025, 09:08:38 am »
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 ...



14
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 03, 2025, 07:47:50 am »
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 ?

15
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: March 02, 2025, 08:23:28 pm »
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.

Pages: [1] 2 3 ... 94