Good news...
I've just finished compatibility testing with 180.48 and found no problems so new driver has been marked as compatible one in the database. Right now it's midnight here so I'm gonna sleep a bit and release 2.20 tomorrow in the morning (I'm in GMT +3 timezone). Here is the final changes list:

- Added ForceWare 178.xx and 180.xx drivers families support.
- Updated databases for Detonator and ForceWare drivers. Added databases for ForceWare 178.13, 178.15, 178.24, 180.10, 180.20, 180.42, 180.43, 180.44, 180.47 and 180.48.
- Added Catalyst 8.9, 8.10 and 8.11 driver families detection.
- Added workaround for broken error reporting system of PowerPlay clock control interfaces in Catalyst 8.10 hotfix 2 and Catalyst 8.11 driver families. Due to internal bug these drivers report incorrect error codes in PowerPlay clock control calls, causing overclocking tools like RivaTuner, ATITool or AMDGPUClockTool to stop working properly. Until the problem is fixed in the Catalyst driver RivaTuner provides temporary workaround by disabling error control for PowerPlay clock control calls on the Catalyst 8.10 hotfix 2 and newer drivers. Please take a note that the workaround can be forcibly disabled via ATIPowerPlayErrorReportingWorkaround registry entry.
- Added driver-level fan control support for ForceWare 180.xx drivers family.
Updated PCI DeviceID database for both AMD and NVIDIA display adapters.
- Added NVIDIA G98 graphics processors support.
- Added AMD RADEON HD 4830 display adapters family support.
- Added support for direct assess to flashrom chips of AMD RV7xx graphics processors family.
- Updated exceptions list for bundled D3DOverrider utility.
- Seriously redesigned hardware access layer provides drastically improved multi-GPU support. Now RivaTuner no longer uses single device selection ideology and supports simultaneous access to multiple physical display devices or GPUs in the most popular and frequently used modules, such as hardware monitoring module, profile launcher and task scheduler.
- Drastically increased performance of routines applying clock frequencies and fan speed when experimental cloning modes are enabled. Due to new multi-GPU oriented hardware access layer all display devices can be accessed simultaneously, it saves CPU time required on switching current display device and reinitializing hardware access layer in ther previous version.
- Now RivaTuner displays physical GPU index in the main tab on multi-GPU systems to simplify identifying independent physical devices and logical devices of the same physical GPU (e.g. two independent RAMDACs located on the same physical GPU).
- Improved hardware monitoring module:
- New multi-GPU oriented hardware access layer allows simultaneous monitoring of all supported physical display adapters and GPUs installed in the system. Simultaneous monitoring is available for both multi-monitor configurations and SLI/Crossfire modes.
- Improved API for hardware monitoring plugins:
- Added new GetSourceCaps function allowing the plugins to report different capabilities specific for exported data sources. This function helps hardware monitoring core to identify system wide and multi-GPU support capable data sources.
- Added set of new hardware access functions allowing the plugins to access multiple physical display devices simultaneously and provide multi-GPU monitoring.
- All GPU sensor specific plugins (e.g. ADT7473.dll) have been updated to support new API functions and provide multi-GPU monitoring support.
- All system wide plugins (e.g. CPU.dll) have been updated to support reporting system wide data source capability.
- Improved ADT7473.dll plugin.
- Now the plugin's database may include hardcoded pulses per revolution counters for some display adapter models to provide correct fan speed monitoring on the systems with counters improperly calibrated in VGA BIOS (e.g. some GeForce 8800GT models).
- Improved software TSS calibration algorithm for RV7xx graphics processors family.
- Improved launcher module:
New multi-GPU oriented hardware access layer allows associating launch items with any desired physical or logical display device and launching the profiles specific for this device without changing current display device selection.
- Now RivaTuner no longer records launcher events into hardware monitoring event history panel by default. Now you may enable launcher event history logging into event history panel properties if necessary.
- Improved scheduler module:
- New multi-GPU oriented monitoring module and launcher allow using the scheduler to program independent dynamic gamma, fan and clock control algorithms for each physical display device installed in the system.
- New 'Pause scheduler' module allows you to suspend the scheduler's activity if necessary.
- New 'Sampling period' setting allows you to override default sampling period for scheduled tasks associated with hardware monitoring module. Custom sampling period setting can be useful if hardware monitoring module polls hardware frequently but too frequent scheduled tasks execution is not desired. Please take a note that in case of defining multiple scheduled tasks with different sampling periods the maximum sampling period defined for a data source is being used.
- New 'Task freezing period' setting allows you to define so called task freezing period for scheduled tasks associated with hardware monitoring module. Task freezing period setting is useful when it is necessary to program a few tasks with different execution priorities. Executing a task with non-zero task freezing period causes the scheduler module to suspend execution of all tasks associated with the same data source until task freezing period is over and to put such tasks into the queue. The last queued task will be executed in the end of task freezing period.
- Now RivaTuner restarts hardware monitoring range based tasks on hardware monitoring module startup, on hardware monitoring history clearing and on resuming the scheduler module from pause.
- Now RivaTuner no longer records scheduler events into hardware monitoring event history panel by default. Now you may enable scheduler event history logging into event history panel properties if necessary.
- Improved low-level hardware overclocking module for ATI display adapters:
- Now RivaTuner hides low-level overclocking tab on PowerPlay support capable display adapters (RV630 and newer series) when overclocking functionality is not available (e.g. on the secondary GPUs in Crossfire mode under Windows XP).
- Now RivaTuner locks obsolete options in additional overclocking properties on PowerPlay support capable display adapters (RV630 and newer series).
- Now undocumented command line based hardware access interfaces also support queued current display device selection via /SD and /SELECTDEVICE command line switches.
- More tweaks improving target value generation accuracy have been done into floating point duty cycle calculation routines for all types of internal and external fan controllers.

Good news...
I've just finished compatibility testing with 180.48 and found no problems so new driver has been marked as compatible one in the database. Right now it's midnight here so I'm gonna sleep a bit and release 2.20 tomorrow in the morning (I'm in GMT +3 timezone).

I can't add new tasks in Schedulers, the OK button is grayed out in Task editor (hw range and threshold)

EDIT /// - Solved, had to input period milliseconds.

Click to expand...

Yeah that one got me too, I ended up using a Data Sampling Period of 0 Milliseconds and a Task Freezing Period of 0 Milliseconds. This appears to be working just ducky so far however I'm not entirely sure what I'm doing anyone have any comments/suggestions on appropriate numbers ?

Yeah that one got me too, I ended up using a Data Sampling Period of 500 Milliseconds and a Task Freezing Period of 100 Milliseconds. This appears to be working just ducky so far however I'm not entirely sure what I'm doing anyone have any comments/suggestions on appropriate numbers ?

Cheers; Snarl

Click to expand...

Set both to 0 to disable both custom sampling rate and task freezing features. The meaning of both parameters has been discussed in deatails earlier in this thread during designing new features.

Did you write the CPU.DLL RDTSC/clock counting asm routines to read the perf mon counters from the msr's for the clock frequency monitoring plugin?

It seems that the plugin is reading the maximum qualified frequency of the CPU, reading MSR 0x17h[12:8] which gives the maximum qualified bus ratio, which returns 5 bit value of the highest selectable cpu multiplier or not correctly dividing the TSC by the selected bus ratio. This is usually not a problem unless the bus ratio is changed downwards to a lower value, and the measured CPU frequency is reported incorrectly.

For Intel Core 2 CPUID 06_0FH and 06_17H the selected bus ratio can be found at:

CLOCK_FLEX_MAX MSR 0x2A[26:22]

ie, 0x00111b = 7

I dont mean to sound like I am critisizing you or anything in case it comes across the wrong way! Thought the MSR register address and bit range would be helpful if you were able to use them, as finding them yourself takes time you probably dont have!

I repeated many times that CPU plugin is a sample demostating 100% hardware independent solution and it will always stay fully hardware independent so it will only rely on standard TSC (which is screwed on Core2 architecture when multiplier is changed). Using personal codepaths for each CPU is a "no go" for it. If you wish, write your own plugin for Core2 architecture and share it with the community.