ipleb said:
Hi Paul - thanks for your comments - I have also tried a small app
called CPUID - this gave the following data:
it tells me I am running an Intel Xeon 5110 - a socket 771 lga package
- weird as my mobo is obviously a socket 775
The core speed is at 1600 with a multiplyer of x8.0 bus speed at
200mhz and a rated FSB of 800mhz
I have two ddr2 533 pc2 4300 1gig chips and two ddr2 533 pc2 4300
512mb chips to give a total of 3gigs
The DRAM freq is at 266/7 and the max bandwidth of each chip is
pc2-4300 (266Mhz)
Does that shed any light?
It is definately the right bios update, and I can't remember whether
the problem started post bios update or post ram install
Finally - if the PC boots ok and run ok and all seems good - in real
terms does it actually make a difference that it is showing as an XEON
cpu and not a Core 2Duo ???
Thanks
Simon
I agree with your basic idea, that this is irrelevant. For the most
part it is. But there is still the issue of the "Revision" listed for
the processor.
Microcode patches are issued by Intel, to correct errors in the processor.
Every processor has a list of around a hundred minor to serious problems.
Usually they don't affect the processor that much, and maybe you'd survive
the boot sequence even if the microcode patch was not installed. When
the processor is released, Intel should have a microcode patch from
day one, for the problems they've discovered since the masks were generated.
There are two opportunities to patch the microcode. The BIOS has a file inside
it, with a name like CPUCODE.EXE, that contains eight or more microcode
patches. Each patch has a checksum that the processor can verify, and the
BIOS code can tell when a "patch" "takes". The patch is stored in a small
RAM inside the processor. One of the fields in the patch, contains the
revision number of the patch, which is how people keep track of what
is installed.
When an OS like WinXP or Vista boots, there is a "microcode loader" available
as a driver for the OS. The "microcode loader" can check to see if a patch
has been loaded, and load a later one if available. (How Microsoft gets the
patches to the end user is unclear. Windows Update?)
Now, if we go back to the Intel Processor Identification Utility again,
it has a "revision" field. That field is extracted from the microcode
patch that was loaded into the processor. Either the BIOS loads one
or the OS loads one.
Now, what happens if neither the BIOS nor the OS, are savvy about
your processor ? If that happens, the "Revision" field will be 00.
That is how you'd know the processor was unpatched.
If microcode is not loading, it would be because the processor
is a "stranger". Now, why it is a stranger isn't clear to me.
A "busted" processor seems a little inconvenient, because
the odds of just a few gates being broken in the processor
are pretty slim. Especially when the gates are "visible".
When Intel was testing, the tester machine would have tested
and noticed if the identity info was wrong. (There can be
broken gates which are "hidden" from a test pattern, but in
this case, we know your problem is perfectly visible to
the tester machine. It should have been caught.)
So check the revision field. If it is a value other than "00"
or "0", you're safe and can carry on. If the value is zero,
then it means your processor is unpatched. Whether the machine
could crash because of that, only Intel knows for sure.
This is the info on my Intel machine.
Processor Name: Intel(R) Pentium(R) 4 CPU 2.80C GHz
Type: 0
Family: F
Model: 2
Stepping: 9
Revision: 17 <---- Non zero, so has been patched OK.
Other than that detail, it wouldn't matter.
Could you verify again, what board you're using ? Is it P5N-D ?
Paul