Stuck temp sensor on E8400?

[brettjrob]

Just put together a new rig two days ago, and I've been very happy so far... until deciding to check on my core temps. In BIOS, my system and CPU temps are both ~31-34C, which seems great. But when I fire up any application to check on the core temps - HWMonitor, CoreTemp, RealTemp, etc. - core 0 is about the same as the above, while core 1 is (supposedly) massively overheating. HWMonitor reports 40C and 75C, respectively; RealTemp reports 34C and 65C, respectively.

It seems clear that the temperature sensor for the second core is whacked, as unless I'm mistaken, it is physically implausible that there would be a 35C difference across the CPU. So my question is, what do I do? I'm running at stock speeds right now, but may want to OC in the future when I get an aftermarket HSF. If I do OC, will it be safe to just use the core 0 reading and assume the second core is near the same value? Should I just return this CPU?

 

[BonzaiDuck]

There is no certainty that my insights and speculations correctly reflect your problem -- but . . . . you need to consider some things.

First, Anandtech published an article on the E8500 -- a notch above your processor but essentially the same design:

Intel's 45nm Dual-Core E8500: The Best Just Got Better

Over the last year, I had made some sensible deductions about how Intel sets their warranty voltage-spec as shown on the retail-box label. This article explains how they choose the WARRANTY PERIOD, but the same intuitive logic may, I think, be extended to the choice of a voltage-"retail-box"-maximum. The probability distributions for processor failure are exponential increasing with time in this article, and one would deduce that a probability distribution of failure for any in a range of voltages at any POINT in time is also exponential from some baseline, known "absolutely safe" voltage.

But I enjoy listening to myself talk. Read especially the information about E8x00 temperature sensors.

What I have discovered is that a chipset available on the market from just before the January 08 Penryn release would most likely have been designed to be "Penryn-compatible" by mobo-makers other than Intel (you say you have a Gigabyte board). EVEN SO -- it is most likely, as it was in my own case -- that a BIOS revision would've been necessary to accommodate the newer Penryn features.

For instance, on my (nVidia 680i chipset) board, a chipset release between Sept and Oct of 07 would show a tCASE temperature of 10C, when in fact the temperature should've been between 20 and 30+C for a 70+F room-ambient. The next BIOS revisions -- just prior to Penryn release -- gave a 50C idle tCASE -- totally out of whack with what one would expect from a CPU of Penryn wattage and TDP. Finally, a BIOS release early this month (Aug 08 -- and almost two years since my board's commercial release) -- has corrected the problem, now more than six months since the Wolfdale E8x00 CPUs hit the street.

So you may want to look into the most recent BIOS revision(s) for your P35 board. While I wouldn't know the particulars as to why an older BIOS would read the newer CPU's temperature sensors in the way you describe, I can at least imagine the possibility.

 

[brettjrob]

BonzaiDuck,

Thank you for the suggestions. Unfortunately, my BIOS is already flashed to the latest version, so either it is a motherboard issue that has still yet to be addressed by Gigabyte, or the actual sensor on the CPU is stuck. I'm leaning towards the latter, especially since the "Sensor Test" feature in RealTemp indicated that my "cooler" core shot up 9 C going from idle to load, whereas the "overheating" core only moved by 1 C.

So basically, unless I'm missing something, I'm definitely dealing with a stuck sensor. My question is what I should do: return the CPU (from NewEgg, so a hassle), or not? And if not, is it safe to OC and just assume the temperature for the non-stuck core is representative of both?