-snip
Analysis of the situation is still a bit sketchy, but this is the best
picture that I have been able to piece together from various reports
that I have read. The "problem" is not with SP2, it's with early
Prescott BIOS', again, as best as I can determine.
Apparently that's not entirely true. Even with the older or non-existent
microcode update(CPU revision = 0) from the mobo's BIOS, SP2 installs and
works IF the SP2 update.sys is RENAMED or replaced with SP1 update.sys. One
poster in this NG has hypothesized that the Prescott microcode in SP2's
update.sys is flat out SP2 incompatible. If the mobo's BIOS's Prescott
microcode is 8(some hints the value might be 7) or greater then SP2's
update.sys does NOT install anything and all is well. If that hypothesis is
correct then MS really DID screw up as the issue was reported at least 40
days before RTM.
If the hypothesis is correct then wouldn't it be quick and easy for MS to
release a hotfix update.sys and take the heat off all the mobo vendors'
BIOSs. There seems to be great pressure from MS's innards that it's a mobo
BIOS problem BUT there's significant evidence otherwise. The original
investigators of this issue soon determined that Intel is the only one in
the mobo industry keeping their microcode updates current. The other mobo
mfgs seem to be of the opinion that any early "production microcode" version
for a CPU is all that's EVER needed. Many folks say that CPU microcode
updates are the OS's responsibility to install. What the hell is update.sys
for if not that anyway?
How is this issue handled by other OSs? Whose responsibility is CPU
microcode updates in non-MS OSs?
In any case this has all demonstrated that there is a major HOLE in
something somewhere regarding CPU microcode revisions. Who is minding the
CPU microcode store?