Ron Reaugh said:
I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed
CPU Revision = 7. 7 was reported with both the boot floppy version and the
XP version underp XP SP1(one).
I have now flashed BIOS 1017. The build date as shown inside BIOS setup on
the Information Screen 7/24/04.
The Intel Frequency ID app continues to show CPU Revision = 7 using the boot
floppy version of the Intel app AND using the XP version under XP SP1(one).
Yet as cited in the MS XP NG article below, what is supposed to be there is
"at least 8".
Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos then
why isn't 8 here in this recent release Asus BIOS?
The industry failure and/or competence level may be a version issue and not
a there/not there issue. Anyone?
I have a look at P4C800-E Deluxe 1017 BIOS, and you are correct. The
microcode for 0F33 is version 7.
I selected the p4p800s_se 1006se BIOS and for 0F33 the version was 9.
I think what we are missing here, is what precisely triggers a
BIOS update. For Asus, when enough crap piles up, or there are
enough complaints, or the larger OEM customers complain, they
act. Microcode updates have about the same weight as any other bug
in the BIOS. If something else is being fixed, then perhaps during
the build, they throw in the latest microcode files they have on
hand. Now, imagine an Asus BIOS for a mature board - there are
few bugs in the queue for the board, which means even though a
microcode update is pending, the priority of issuing an update
isn't high enough for that update to get done. Every company
has priorities, and Asus puts more energy into fixing the egregious
bugs in brand new motherboards, than it does into fixing the BIOS
of boards near the tail of their sales curve. (Remember, many
Asus boards are released with half-finished BIOS - time to market
is everything, and a late introduction kills the profit for the
product. Some of the Asus BIOS cannot even read the SPD of the
memory DIMMs in their first release, and memory timing uses
conservative values, until they can finish the code.)
Intel, on the other hand, would probably pride itself on releasing
a new BIOS for every board it ever made, every time the microcode
changes. But doing so, entails regression testing all those
motherboards, at huge expense.
I guess who you do business with, depends on who provides the things
people want most. The un-overclockable Intel boards don't attract
the typical home builder, but for the corporate user depending on
corporate features, Intel is probably the way to go.
And, when we talk about competence, within the last day or two, there
was a guy who flashed up his Asus DLS533 server board to the latest
BIOS, and noticed his RAID array was no longer detected by the BIOS.
When I looked at the BIOS, a module was missing from the new BIOS, so
no code to drive that hardware.
Asus does have a quality problem with the BIOS they are releasing -
two releases of A7N8X-E BIOS were pulled, I believe due to problems
with a module for a particular piece of hardware, and a wild-ass
guess is newbie employees are doing builds. This is not the only
company I've seen this happen to. I put together an update for a
Sun workstation years ago, and found some of the patched applications
had been compiled in an insecure manner, a newbie mistake that with
the availability of build scripts, is inexcusable.
To me, this indicates that regression testing of these BIOS is
slipping, for stuff like this to get through. Putting it all in
perspective, the microcode situation is just a small part of the
overall picture.
Paul
http://www.google.com/groups?q=+"[email protected]&rnum=1
An MVP there Cari had detected the issue and was pursuing it with
MS
and
Intel.
Current Intel CPUs have the ability to have their internal microcode
updated
on the fly(addenda fixed). Apparently that microcode update is done
both by
the mobo's BIOS during POST and during OS init by
%windir%\system32\drivers\update.sys.
What was determined is that MOST all the major mobo mfgs around
are
NOT
keeping their microcode current, at least for 865/875 chipset mobos,
even
with recent BIOS updates! That old CPU microcode(non-existent BIOS
microcode update apparently in many cases[=0]) was causing SP2 to hang
after
install.
One can view/report that microcode revision level by running Intel's
Frequency ID utility. The entry to look for is "CPU Revision = n" where
n
= 0 which is the microcode revision level.
Cari's conclusion as apparently gleaned from MS & Intel was that NO
major
mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel.
Cari claimed to have tried a broad range of 865 and 875 chipset mobos
with
SP2 and most all failed! She then said that she'd never use anything
except
an Intel mfged mobo again as if after her eureka moment.
Does anyone know more precise details of the overall technology involved
here and the overall industry competence with respect to CPU microcode
updates. What is the BIOS supposed to be doing here; is there any
standard? What does %windir%\system32\drivers\update.sys do exactly?
The implication is that most all of us 865/875 chipset mobo owners (and
I
assume that the issue is MUCH WIDER) have been running with all
the
CPU
bugs/addenda UNFIXED!
I don't know why this issue is blown all out of proportion.
It is an issue that is not well known which is why I'm trying to find more
details and also see what folks know in general.
It is like the second coming or something.
If an OS is so dependent on microcode being correct, a fairly simple
algorithm and small file of microcode segments would fix it.
Well then what does this do in XP?
%windir%\system32\drivers\update.sys
Microsoft
should consider moving the microcode loader up in their boot sequence,
like before some other kernel files are loaded.
I got the impression that there was some condition precedent required
in
the
BIOS and that's why %windir%\system32\drivers\update.sys didn't work
and
the
fix was to rename update.sys ??? Please clarify.
Inside an Asus BIOS, there is a file called cpucode.exe and it will
consist of perhaps 8 or so 2KB microcode segments. Apparently, at least
in some of the older BIOS, there were also a couple of 2KB
"cache segments" in the flash chip as well, and if a new processor
is detected, the microcode segment that loads successfully, is stored
in one of the two cache segments. The BIOS effectively has to
"flash itself", and contains the code to do that. There is actually
a procedure for Award BIOS, where a user can "write" the cache
segment with their own Prescott 2KB code segment, if they want to.
(I have done this on a P2B-S, to get microcode support for a Tualatin.)
The program is called CTMC from CT Heise magazine. In other words,
for the initiated, they can actually prep their BIOS to be "SP2
ready" if they want to, without waiting for Asus (AFAIK works
for Award BIOS, no idea if it works for AMI, as the hook and
methodology of the AMI BIOS could be different).
Asus updates BIOS files on a fairly regular basis. One user here
owns a T2-P Asus small form factor system, and while the Asus
cpusupport page doesn't currently list his system, he claims it
supports Prescott or the advert copy says it supports Prescott.
When I extracted the file of microcode segments for the most
recent version of that BIOS, there were no Prescott family code
segments in the file. So, indeed, in that case, support was
lacking. Other users here who have had "SP2 trouble", aren't
running the latest BIOS, so the solution there is clear.
To keep all these BIOS updated to cover the latest Intel
inprovements, means there will always be a gulf between the
latest released microcode segments and what is available for
download from Asus.
Prescotts were shipping in March.
I'm sure when a new processor is
released at Intel, it even takes Intel a day or two to update
their BIOS files, so Cari shouldn't be too smug sitting on
an Intel motherboard.
And finally, there is probably a small number of users who
have stuffed Prescott processors in non-Prescott boards,
and whatever happens, is of their own making. If your old
motherboard lists Northwood 0.13u processor support, that is
what you should be buying for it.
Seeing as microcode loading existed in my 440BX based P2B-S
motherboard, I would say the "industry competence" is there.
Well, the question is whether the appropriate microcode is getting
out in
a
timely fashion and how users are able to easily know what microcode
level
is
right. It also apparently isn't a one time thing but updates continue
to
be
made available by Intel. It appears that most the major mobo mfgs missed
this one for the 865/875+Prescott+SP2 release. It wasn't like nobody new
SP2 was coming in August. There appears to have been a mobo industry
wide(save Intel) collapse on this issue. There is also some evidence that
MS did little regarding a headsup to them or its users as this issue was
reported in June(over 40 days before SP2 RTM).
From your read of the issue how does the rename of
%windir%\system32\drivers\update.sys
temporarily fix the issue??
