Intel Core 2 Temperature Issues

[Ron Krebs]

The machine still has to POST. POST is the very first thing that a
machine does. THEN it will look for a bios update issue. The POST code
is mostly a test of the CPU itself and very basic functionality that the
CPU needs to do ANYTHING. The CPU must be able to execute instructions,
read and write memory (and establish a stack) or nothing is going to
happen, nothing, period. The POST code may be broken up into segments,
and the attempt to reflash the bios might be between the segments
(segment 1 ... test the CPU and memory read/write with interrupts
disabled; segment 2 (perhaps after an attempt to reflash) ... test the
motherboard and advanced chipset functions).

Then how do they make good on the claim?

Questions:

1) Must you POST before you can read the BIOS (are these two separate
events)? Or is the reading of the BIOS a subset of the POST?
2) Is it possible for microcode to be read prior to the detecting of the
CPU?
3) What other conditions can cause failure to POST besides incorrect CPU?
Unsupported memory? Faulty chipsets?
4) If a BIOS is corrupt, will the machine still POST?

Ron

 

[Barry Watzman]

You must POST to a minimal level before you can do ANYTHING.

POST consists of the CPU correctly executing a series of subroutines
that test it's functions. Some non-CPU motherboard functions are also
tested (the bios is checksummed, the tick timer and interrupt are
tested, there is a basic video test, memory is tested ... exactly what
varies by bios).

You have to detect the CPU before you can update it's microcode.
Detecting the CPU is easy, the CPU has a CPU ID instruction. The fun
begins when the ID of the CPU doesn't exist in an of the tables of
supported CPUs found in the BIOS. Personally, I think that as a whole,
BIOS' are inadequately tolerant in this regard: They might not want to
boot Windows, but they could still do enough to allow a bios update,
however many just croak dead in this scenario.

Lots of things can cause total POST failure, including memory problems,
video problems, motherboard problems (especially timers and interrupts).

If the BIOS is corrupt, the machine will POST but the result will be a
POST failure (e.g. you can complete POST successfully or
unsuccessfully). Note that a bios can be wrong (for a different
motherboard or a different CPU) but that does not make it corrupt. I'd
say that the definition of a corrupt bios is a bios whose checksum
doesn't match what it's supposed to be. However, that doesn't mean it's
the right bios for the motherboard or CPU on which it is running.
Again, the writer of the BIOS has some control here as to what he does
in this situation and how "tolerant" he is when a problem is discovered.

 

[Ron Krebs]

You must POST to a minimal level before you can do ANYTHING.

POST consists of the CPU correctly executing a series of subroutines
that test it's functions. Some non-CPU motherboard functions are also
tested (the bios is checksummed, the tick timer and interrupt are
tested, there is a basic video test, memory is tested ... exactly what
varies by bios).

You have to detect the CPU before you can update it's microcode.
Detecting the CPU is easy, the CPU has a CPU ID instruction. The fun
begins when the ID of the CPU doesn't exist in an of the tables of
supported CPUs found in the BIOS. Personally, I think that as a whole,
BIOS' are inadequately tolerant in this regard: They might not want to
boot Windows, but they could still do enough to allow a bios update,
however many just croak dead in this scenario.

Lots of things can cause total POST failure, including memory problems,
video problems, motherboard problems (especially timers and interrupts).

If the BIOS is corrupt, the machine will POST but the result will be a
POST failure (e.g. you can complete POST successfully or
unsuccessfully). Note that a bios can be wrong (for a different
motherboard or a different CPU) but that does not make it corrupt. I'd
say that the definition of a corrupt bios is a bios whose checksum
doesn't match what it's supposed to be. However, that doesn't mean it's
the right bios for the motherboard or CPU on which it is running.
Again, the writer of the BIOS has some control here as to what he does
in this situation and how "tolerant" he is when a problem is discovered.

Thanks, Barry for the explanation.

Ron

 

[kony]

Then how do they make good on the claim?

Questions:

1) Must you POST before you can read the BIOS (are these two separate
events)? Or is the reading of the BIOS a subset of the POST?

The system is fully *running* during POSTing. First the
bios is read from the EEPROM, being decompressed into memory
by the CPU, and executed. POSTing is merely what the BIOS
tells the system to do (next).

2) Is it possible for microcode to be read prior to the detecting of the
CPU?

Yes, it "could" be done in theory but not in practice as the
microcode will not apply to all CPUs, thus the CPU has to be
ID'd to make a determination.

3) What other conditions can cause failure to POST besides incorrect CPU?
Unsupported memory? Faulty chipsets?

Too many to mention, hardware defect of many kinds, flaky
power (could be PSU problem or system short prevents whole
system turn-on (depends on the scenario you think of when
considering a broad topic like "not POSTing"), dead parts,
instable system settings, wrong jumpers, unsupported memory
(and/or, supposedly technically compatible but still
instable for whatever other reason)... and I'm sure I left
out a few possibilities. In general failing to post is a
sign the system isn't workable and the POST was just the
first thing it would have done, if it could run.

4) If a BIOS is corrupt, will the machine still POST?

Depends on how corrupt. It is possible a few bits are wrong
and it posts, but as likely those bits were important enough
(or enough of them) to prevent POST.

 

[Mitch Crane]

Yes, there isnt any other way to implement what they say it can do.

Not a full-blown BIOS, however. Most likey the BIOS is checksumed or
otherwise tested for integrity and if that passes it jumps to the POST
process. If that doesn't pass then it looks for the BIOS file on attached
media so it can reflash.

 

[Rod Speed]

Not a full-blown BIOS, however.

Sure, there wouldnt be any point in that.

Most likey the BIOS is checksumed or otherwise tested for integrity
and if that passes it jumps to the POST process. If that doesn't pass
then it looks for the BIOS file on attached media so it can reflash.

Correct. Tho it would obviously make sense to check for
basic cpu functionality before attempting to reflash that
way, and likely to go for a safe way of running the cpu too.

 

[Ron Krebs]

The system is fully *running* during POSTing. First the
bios is read from the EEPROM, being decompressed into memory
by the CPU, and executed. POSTing is merely what the BIOS
tells the system to do (next).




Yes, it "could" be done in theory but not in practice as the
microcode will not apply to all CPUs, thus the CPU has to be
ID'd to make a determination.



Too many to mention, hardware defect of many kinds, flaky
power (could be PSU problem or system short prevents whole
system turn-on (depends on the scenario you think of when
considering a broad topic like "not POSTing"), dead parts,
instable system settings, wrong jumpers, unsupported memory
(and/or, supposedly technically compatible but still
instable for whatever other reason)... and I'm sure I left
out a few possibilities. In general failing to post is a
sign the system isn't workable and the POST was just the
first thing it would have done, if it could run.



Depends on how corrupt. It is possible a few bits are wrong
and it posts, but as likely those bits were important enough
(or enough of them) to prevent POST.

Ok so the BIG question is, would the CrashFree or EZ Flash utility read and
flash the BIOS, IF the current BIOS does not recognize the Conroe?

Ron

 

[Rod Speed]

Ok so the BIG question is, would the CrashFree or EZ Flash utility read
and flash the BIOS, IF the current BIOS does not recognize the Conroe?

What matters isnt whether it can recognise the Conroe, all it needs to
be able to do is run it, using conservative settings, so it can do the flash.

 

[Ron Krebs]

be able to do is run it, using conservative settings, so it can do the flash.

So, Rod are you saying that a hotflash of the BIOS chip or the use of a
earlier CPU to boot from would NOT be necessary in light of the capabilities
of these motherboard utilities? I'm not sure whether your last phrase "it
can do the flash" is an assertion or a conditional proviso.

Ron

 

[Rod Speed]

So, Rod are you saying that a hotflash of the BIOS chip or the use of
a earlier CPU to boot from would NOT be necessary in light of the
capabilities of these motherboard utilities?

No, I am saying that that part of the bios only
needs to be able to use conservative settings to
be able to run the cpu so that it can do the flash.

In other words it doesnt need to be able to recognise Conroe cpus
and be able to use the optimal settings for that particular cpu, it
can leave that stuff for the rest of the bios thats written with the flash.

I'm not sure whether your last phrase "it can do
the flash" is an assertion or a conditional proviso.

See above.

 

[Gerry_uk]

Hi Phil,

But you agreed from my first post that the ASUS Probe reading could not
be right. ASUS also released a BIOS update for my board after the
tomshardware article was written, specifically related to temperature
"accuracy". The later BIOS gives much higher readings than the old BIOS.

(although, my board is not a P5B so perhaps the P5B readings are perfect)

Either way, I'm still concerned that tomshardware did not use anything
other than ASUS Probe.

 

[Anon]

According to Asus, "if the BIOS becomes corrupted, CrashFree BIOS 2 allows
the user to perform a recovery using the motherboard support CD". If that CD
was an older version that didn't support the Core 2 duo, crashfree couldn't
help you.

 

[Barry Watzman]

What he means is that a BIOS that is very conservatively written can
continue running at some minimal level using a CPU that it doesn't
recognize but that is "x86" compatible (e.g. it's an Intel processor).
And he's right. There is a conscious decision being made by the BIOS
authors to simply "quit" (or at the very least not continue) when they
see a CPU that they don't recognize. But continuing to run, at least
enough to allow a flash update, is absolutely physically possible.

 

[Rod Speed]

According to Asus, "if the BIOS becomes corrupted, CrashFree BIOS 2
allows the user to perform a recovery using the motherboard support
CD". If that CD was an older version that didn't support the Core 2
duo, crashfree couldn't help you.

Not necessarily if that part of the bios that allows the rest of the bios
to be flashed from the support CD run the cpu with conservative values
that will work fine with the Conroe and they actually allow you to load
the bios image from just about anything, including the support CD.

 

[Vic Smith]

Hi,

I'm experiencing problems with Intel Core 2 E6800 temperatures on my
ASUS mainboard, but part of the problem is I don't even know if the
values I'm seeing reported on screen are correct or not!

I've created a quick web page with a screen shot and details here

<http://www.xp20.dircon.co.uk/hardware/>

Does these readings make sense?

You might find this relevent/interesting.

http://www.anandtech.com/printarticle.aspx?i=2385
"For the heat test, we use a laser thermometer to record the
temperatures of various key components. It is important to note that
these are surface temperatures only and not a reliable means of
determining core temperatures. Most system BIOSes report temperatures
for the CPU, but in the past, we have found that differences in BIOS
programming can cause a difference of 10 C or more."

--Vic

 

[Gerry_uk]

Thanks Vic,

http://www.anandtech.com/printarticle.aspx?i=2385
", but in the past, we have found that differences in BIOS
programming can cause a difference of 10 C or more."

Yup, this is exactly the behavior I've experienced with ASUS BIOS and
ASUS Probe.

 

[Ed]

Thanks Vic,



Yup, this is exactly the behavior I've experienced with ASUS BIOS and
ASUS Probe.

And you should unless you turn off the HALT command in the OS (windows,
linux). At idle CPU should always be cooler in OS then in BIOS.