"cquirke (MVP Win9x)" wrote in message
...
On Sun, 05 Sep 2004 00:23:02 GMT, "Ron Reaugh"
"cquirke (MVP Win9x)" wrote in message
On Tue, 31 Aug 2004 21:53:00 GMT, "Ron Reaugh"

Why is the temp fix to rename update.sys?

Update.sys is the driver file that locks up when XP SP2 boots on a
system that has Prescott processor running revision 8 or 7.
Just why that happens - i.e. what SP2's larger Update.sys is doing
that older SP1a's Update.sys doesn't do - remains a mystery to me.

What does either/both update.sys's job?? I was under the impression that
update.sys loads microcode into processors. Is that true?

I don't think it pushes microcode to the processor; more likely it
tests to see if the required microcode revision level is present.

And does a hard hang if it's NOT...hmmm? I think some of the wording in the
original Cari threads described update.sys as a microcode loader.

I say this because I tested as follows:

Old BIOS, Rev 0 CPU, SP1a, SP1a Update.sys - OK
Old BIOS, Rev 0 CPU, SP2, SP2 Update.sys - Fail

Please define "Fail"...You mean boot hang?

Old BIOS, Rev 0 CPU, SP2, SP1a Update.sys - OK
New BIOS, Rev 11 CPU, SP2, SP1a Update.sys - OK
New BIOS, Rev 11 CPU, SP2, SP2 Update.sys - OK

If it were Update.sys and not BIOS that rev'd up CPU, I'd expect:

Suspect assumptions. Both might do microcode updates. I fail to see what
the following list is or proposes beyond the list above.

Old BIOS, Rev 0 CPU, SP1a, SP1a Update.sys - OK
Old BIOS, Rev 0 CPU, SP2, SP2 Update.sys - Fail
Old BIOS, Rev 0 CPU, SP2, SP1a Update.sys - OK
New BIOS, Rev 0 CPU, SP2, SP1a Update.sys - OK
New BIOS, Rev 11 CPU, SP2, SP2 Update.sys - OK


A nice little embarrassing side question: From what deficiency does one's
system suffer by having CPU revision = 8 microcode versus the obviously
superiorg CPU revision = 11 microcode??? Both 'work' with SP2.

What really needs to be done in SP1 and/or SP2 is test some known cases for
say Northwood using the Intel boot version of the Frequency ID utility vs
Win version and see if CPU revision = value is ever different.

It also would be realy neat if there was some nice list somewhere of ALL the
different microcode versions for each CPU stepping and what exactly the
difference of each is.

But the CPU rev went into effect as soon as I used the new BIOS,

Well, yeah that's what happens with microcode in BIOS as it gets into the
CPU during POST.

even
while still using the smaller Update.sys from SP1a.

I wonder what 'bigger' job SP2's update.sys has to do?

I read some stuff on microcode updates that suggests at least some of
these have to be done early in POST, i.e. before RAM check.

"some of these" What are "these"? Is a reword: 'some microcode updates
might need to be done very early on in POST before RAM check'?

I imagine
the process of rev'ing CPU would blow out the CPU's context and make
it difficult, if not impossible, to resume protected mode processing,
return from function calls, retain register and MMX state, whatever.

I'll bet it's tractable or at least it may have always been thought to be
tractable until this came upG.

A buggy SP2 update.sys with respect to the Prescott seems to
be what's really behind this whole issue, right?

Not really - it certainly brings to light the difference between
Prescott as-shipped and Prescott as patched by BIOS to revision 7
microcode (steppings 2, 3 aka C0) or 8 (stepping 4 aka D0).

That assumes facts NOT in evidence and in fact assumes facts that you
already said you didn't know.

Agreed, I think. I mean, I agree that there are lots of facts I don't
know; I don't think there's any hidden-by-NDA stuff behind the
conclusions I've reached. In fact AFAIK there's nothing I learned
through NDA that hasn't since been publically stated.

...in response to my question: "A buggy SP2 update.sys with
respect to the Prescott seems to be what's really behind this
whole issue, right?"

OK; at face value, that may be literally true. Certainly, no SP2
Update.sys, no lockups on starting XP SP2.

But FUD swirls around whether Prescott Rev 0 is in fact fit for use.

It runs SP2 and does NOT blue screen all over the place. Now define "fit
for use" beyond that. Especially the apparent MS decision that
non-bootability was preferrable to allowing arrival at that unfit for use
state. I used the word 'decision' advisedly as the issue was known in June.

Intel's spin is that Prescott should receive appropriate microcode
updates from BIOS, otherwise that system should be considered unfit
for use.

What about 8 vs 11?

Whether that's "blame-the-OEMs" or "use our mobos, not
theirs" chest-thumping or not, I can only guess.

Interestingly apparently even some of Intel's own 865/875 mobo's didn't get
the 8 level microcode until 11:59:59PM if not 12:01:00 AM. Given that then
how did the others have a chance yet apparently some 8 microcode was in some
3rd party mobos pre Aug. 1. Hmmm was what I just said convoluted...I think
so....how could that be...???

There's more to this story and I'm VERY curious. Why else do you think I'm
stalking the threads on this issueg?

I've seen some opinions within MS that echo the "PC that doesn't rev
up Prescott shouldn't be used" line; again, whether that's based on
taking Intel's position at face value, or the visible tip of a greater
understanding of what is involved, I don't know.

There is one school of thought that the mobo mfgs' job is DONE microcode
wise once they EVER deliver ANY version of "production level microcode" for
a given CPU+stepping. Once that's done then any further CPU errata is the
responsibility of the OS and that's what update.sys does.

We need a precise definition of "production level microcode" which again is
phraseology apparently from Intel used/quoted in Cari's early posts.

With this FUD in mind, I chose to echo the party line that running SP2
with SP1a's Update.sys should not be seen as a definitive solution,
and that the real solution is a BIOS that revs Prescott properly.

That assume facts not in evidence not the least of which is our lack of a
full understanding of what exactly update.sys actually does.

Whether that reserve is technically baseless, I don't know.

SP2+Prescott was known/reported in June in RC2 if not BEFORE.

Interesting assertion; I wasn't aware of this.

If one follows all the early Cari posts and forum threads that led to a
different forum thread that DID describe RC2 + Prescott boot hang in mid
June.

Now let's see...there was some thread I saw recently where somebody was
claiming that some high percentage of recently shipped systems likely
included 865/875+Prescott....must have been some wackog or the fact that
the issue was detected back in RC2 is OBVIOUS.

What's update.sys's job???

That's a very good question and (you guessed it!) I don't know that
either, but I would like to know. My guess is it may be what
determines what processor is present, and thus which code pathways can
be used by the OS (e.g. SIMD3? SIMD2? SIMD1? 3DNow!? etc.)

How does that 'guess' fit with the name update.sys and 'bigger' ?