> Unfortunately this generates a resource conflict with motherboard resources.
Once some time long ago (in w2k timeframe or such), the Windows architects - probably with a joint effort with the ACPI spec authors - decided to ban accessing the IO ports listed in the ACPI table as "motherboard resources".
The goal was to only allow ACPI BIOS to do this, and not anyone else.
For me, this idea failed miserably, since 100% of CPU temperature/voltage/fan speed monitoring products _use some hacks to bypass the recommended ways (where the recommended ways is to support this in ACPI table and expose to WMI)_.
The community of MS + BIOS vendors just plain failed to impose the standard way of doing this.
The cleanest among these hacks is what Asus does. It provides the root-enumerated pseudo-device of ATK0110 in their ACPI table, and some AsAcpi.sys driver for it, to be installed.
Then, when you have AsAcpi in the kernel, their tools like AsusProbe do work - by sending IOCTLs to AsAcpi, which calls ACPI methods or touches IO ports.
> The other option is to use the smbus/I2c but then there would be
> synchronization issues.
This can also be a good idea.
So, the ideas in the order or decreasing "implementation cleanness":
a) if you have control over BIOS and its ACPI tables - write ACPI methods to implement the temp/voltage/fan sensors, the methods must touch these IO ports. Then access the values via WMI - even VBScript will be OK.
b) write a driver, in it, invoke an ACPI method call from the ACPI BIOS to do the job
c) write a driver, in it, just stupidly access the hardcoded IO ports without ever arbitrating them by means of PnP
d) reset the IO permission bitmap and do the same as c) does, but from user mode.
--
Maxim S. Shatskih
Windows DDK MVP
http://www.storagecraft.com
Similar Threads
Linear Mode
