3.37 VID works perfectly with the P8400
One less thing to worry about.
I totally overlooked this. I've been mostly concentrating on the Desktop CPUs but I'm glad that I've got this issue and the SLFM issue and IDA issue fixed now. One more issue to go. The FSB MHz issue.
http://www.fileden.com/files/2008/3/3/1794507/MHzTest.zip
I needed to do an update to my MHz testing program to properly support your IDA capable CPU.
I'm very interested to see what it shows.
The new Core i7 and i5 CPUs have what's called an invariant TSC or time stamp counter. What that means is the the internal counter will count at a continuous pace, regardless if a core goes into a C state or sleep state. This makes calculating MHz fool proof without having to load the CPU in a busy loop.
I think the Core 2 CPUs don't have this feature. When they enter a deep sleep state, the internal TSC counter stops counting.
To calculate MHz it is a very simple task. You do a RDTSC or read time stamp counter, wait a second, read the time stamp counter again and then it's pretty simple math to calculate how many cycles per second a CPU is running at. If a core or cores go to sleep, then you can see this method falls apart and will return a lower MHz number than your actual bus speed. If your FSB is at 333.3 MHz and it shows 166.6 MHz then that's a sign that the core or cores must have been asleep half the time.
As I said before, one way around this is to put the CPU into a busy loop to prevent it from going into a sleep state then you are guaranteed to get an accurate count when you do a rdtsc to read the counter. Obviously you wouldn't want to do this very often or for very long. No one wants a monitoring program to be unnecessarily loading their CPU, especially laptop owners. In my opinion, CPU-Z is doing too much of this loading.
Once I see your results somebody then I'll tell you a couple of possible solutions to get RealTemp looking better. I'm also going to modify my program tomorrow to see how long you need to load a CPU to get an accurate MHz number. Does SetFSB or similar program work on your computer or is the FSB speed fixed?
The interesting thing I found about burebista's testing is that this testing program does the same MHz calculation twice, once for each core. Even when the MHz is sagging at idle, both cores tend to report the same MHz are very close to it which to me is a sign that both cores must be going to sleep the same amount of time. I'm not sure what your mobile CPU will show.
Edit: I just read the CPUID docs some more and found another way to calculate MHz that might get around this problem that is compatible with Core 2 CPUs. I'll test that tomorrow.
My laptop uses some Silego cost reduced ck505 wannabe that doesn't support a programmable divider. The best I can do is a spread spectrum shift of ~1MHz 
