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] 4 5 ... 97
31
Hi Silvan!

no need the hassle. I might create a new rpm within some days

Installed the 4.7.0 release here, a few days into this and things seems to be working quite fine.

So for what it's worth, is this post here the most appropriate/quasi-official way to provide you with that feedback in order to move the RPM from '-EXP' to '-REL'??? (seeing as I haven't seen anyone else complain of negative results)

I've often wandered who/how/when this whole thing works...

32
Martin, everyone...

...I also agreed that Arca Noae should bring a developer to the scene to finally got a modern web browser on ArcaOS. Arca Noae is the only one with resources that can help with this, the rest of the community does not generate any incomes to be directly invest on the OS...Even if it is younger developer that does not knows OS/2, at least hire him permanently to learn the OS/2 API in a few months...

Umm...folks, we are a DEAD platform...I hate to say it, but that's just the pragmatic part of me screaming in my head!!! LOL

So Martin, as much as I would love to contribute ($$$) again to this effort, the reality is that you can't simply go fishing for a resource, especially someone younger that needs to do a WHOLE STACK worth of learning only to develop a skill that's basically completely unusable anywhere else.

Yup, that's that.

The problem I have always seen as the proverbial "brick wall" of our platform is the fact that we seemingly still do not hava a ready 'out of the box' DEV enviornment. This is a significant mountain to climb for anyone that even attempts to do this.

Look, I've been professionally employed writing code (albeit Oracle PL/SQL DBMS stuff, and some other stuff) but the point is, that's sort of like learning how to ride a bike, and once you figure that out it's just a matter of getting used to different gear sets, handling, etc.

I will tell you this: having tried to upgrade our DISKIO utility (and that thing is a tiny, itsy-bitsy piece of functionality) it's been nearly impossible to find all the pertinent references that allow us to account for how things have changed between the '90s where OS/2 was still a viable platform to how things are today.

Don't get me wrong, I'm not a coding Pro, but I'm no newbie when it comes to DEV environments, IDEs, libraries, etc...so why does it always feel like getting anything off the ground on our platform is like climbing Mt. Everest???  :o ::)

33
Multimedia / Re: Updated Uniaud32 build
« on: April 26, 2025, 05:00:26 pm »
Hi Paul!

...https://smedley.id.au/tmp/uniaud32-linux-6.12.21-20250415.zip fixes the out of memory errors when manipulating mixer controls.

Good results here!

CARD info
Code: [Select]
[G:\]unimix -card
Command line mixer for UNIAUD32. Version 1.1
Detected UNIAUD version 2.02.06
Detected 1 audio adapter(s)
Card info for adapter 0:
  num: 0
  id: SB
  driver: HDA-Intel
  name: HDA ATI SB
  longname: HDA ATI SB at 0xfeb00000 irq 16
  mixer: Realtek ALC892
  componenets: HDA:10ec0892,1462640a,00100302

The last release I tested was your uniaud32-linux-6.2.12-20230414.zip drop, this booted fine, sounds worked but I always had a TRAP in mplayer (different mp4 streams, etc.).

This uniaud32-linux-6.12.21-20250415.zip does NOT exhibit this, so far so good!

Thank you!

34
Applications / Re: EXIFTool
« on: April 26, 2025, 04:03:22 pm »
...WPIView 1.1.0 is not found on hobbesarchive.

Can be found on FilePile https://www.os2site.com/sw/util/installers/wpiview110.zip..

Yeah...but...the Hobbes location does show WPIView_1-2t.zip which is appears to be a test release of an upgrade to 1.1 found at the link you Pete show above.

For what it's worth, I took a look at it and while I spotted a new button (which appears to say 'Build Too'), selecting it does not seem to actually do anything other than what the 'Extract' button does.

35
OK, that's excellent...thank You Silvan!

36
Setup & Installation / libtiff and libtiff tools - MIA in 4.6.x but...
« on: April 15, 2025, 03:05:08 pm »
Folks,

Just a quick FYI, although those who need this functionality have probably already instituted this.

The latest drop of libtiff & tools (4.6) is missing the vast majority of tiff tools. This is a known issue (as has been pointed out on our forum here already) and has been remedied with the 4.7 release (https://libtiff.gitlab.io/libtiff/releases/v4.7.0.html), which we do not have available to us yet.

Sooo...in case you are like me and need to use those tiff tools here is what you can do:

1) before upgrading your <4.6 libtiff stuff
- copy the tiff tools you need from \usr\bin to \usr\local\bin
- optionally copy the tiff libs from \usr\lib to \usr\local\lib (this is not really needed b/c the 4.6 update will force install libtiff-legacy-5 package and that has all the DLLs you need (two actually)
- copy the tiff MAN pages from \usr\share\man\man1 to \usr\local\share\man\man1

2) upgrade your <4.6 release of libtiff & tools

3) remove the doubled up EXE and MAN pages from the \usr\local\... locations

This approach has allowed me to continue using the available 4.0.9 libtool EXEs which apps like PDFMergeNX require.

BTW: The stipulation here is of course that \usr\local\... is present in your CONFIG.SYS in the appropriate LIBPATH & SET PATH lines.

37
Applications / Re: LarsenCommander - new test version
« on: April 05, 2025, 10:39:33 pm »
Hello Andi,

Sorry about the long delay in providing my feedback!

I've just released v1.09.00. See https://sourceforge.net/projects/lcmd-git/files/

Code: [Select]
Change History:
---------------
20250222 v1.9.0
- Skip sending lot of GUI (PM) messages for updating progress dialog with fast disks while copying and deleting files.
This is to work around PM memory leaks (crashes) when hammered with very much messages in a short period of time.
With fast disks copying or deleting small files takes few ms or even less. The previous logic to update the
progress bar after each file (and during a file when it is bigger) is changed to not send more than about one
message in 125ms. PM seems to be not safely ignore to much unhandled messages and starts to eat up shared memory.
Eventually this crashes the whole system when the process is not closed before. F.i. this skipps more than 69000
messages when copying the ApacheOpenOffice source code tree. The same skipping logic improves speed when deleting lot
of files. F.e. 33s instead 53s for AOO source code tree (about 70k files). More than 76000 messages where skipped with
that new delete logic.

Alright...this is by far my favourite file manager, so I do put it through it's fair share of paces.

Everything seems to be alright with the exception of the fact that the 'Bytes per second' window no longer shows the graphical throughput rate as the file copy progresses.

I repeated my file copy/move several times (between different SOURCE=>TARGET combinations and this is consistent.

So I left the above section of your post purposely because I now wonder if perhaps the "...Skip sending lot of GUI (PM) messages..." is the root cause of this???

Othwerise, things are good...thank you again for maintaning this !!!

38
Programming / Re: An XWorkplace CPU Temperature Widget for AMD CPUs
« on: April 01, 2025, 04:07:11 pm »
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!

39
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?

40
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

41
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.

42
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???

43
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!

44
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
...

45
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.

Pages: 1 2 [3] 4 5 ... 97