xp sp2 download, computer won't boot up now

On Sun, 05 Sep 2004 20:24:42 GMT, "Ron Reaugh"
"cquirke (MVP Win9x)" wrote in message
On Sun, 05 Sep 2004 00:23:02 GMT, "Ron Reaugh"

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?

It hard-hangs if Prescott is insufficiently rev'd (by BIOS).

I think some of the wording in the original Cari threads
described update.sys as a microcode loader.

That may be, but it doesn't seem to work that way, if the results of
my testing are anything to go by.

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?

Yes, I mean the stereotypical hard lock that applies to normal, last
good, safe and safe command bootups, and that is cleared by disabling
L1 and L2 cache in CMOS setup.

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.

Only if Update.sys and BIOS rev'd to exactly the same revision level,
would you see that mileage. Let's say Update.sys rev'd to 8, and BIOS
rev'd to 7, you'd get this...

New BIOS, no SP2 Update.sys in effect = rev 7
New BIOS, SP2 Update.sys in effect = rev 8

....whereas I get same rev if SP2's Update.sys is in effect or not.

Mind you, that could imply Update.sys looks for a lower threshold rev
and pushes that only if the existing level is lower, e.g...

SP2 Update.sys sees rev 7, dies trying to push rev 8
SP2 Update.sys sees rev 7, pushes rev 8 OK
SP2 Update.sys sees rev 8+, does nothing

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.

No idea. Until now, I've never had to care about the gory details of
Intel's bugfixes as pushed by BIOS on Intel's behalf - but now I'm
beginning to wonder how many of those "needs newwer BIOS" posts were
really "needs newer CPU bugfixes".

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.

Hmm... Northwood steppings and revs aren't the same as Prescott; each
time the higher cog changes, all lower cogs cease to relate to
previous values. For example, if the family number isn't the same,
comparing steppings is meaningless, etc.

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.

Exactly. I can't find that at Intel, though that's the obvious place
to expect to find it - and Intel's usually good at that stuff,
Collins' complaints notwithstanding.

I can get good .pdf coverage of BIOS revisions for Intel's Bayfield
mobos, and which mobo batch numbers ship with which BIOS, and the BIOS
update details do say "apply newest CPU updates" or some such.

I can find good .pdf coverage of CPU errata on a per-stepping basis.

What I cannot find, is what errata are fixed by which microcode
revision patch, and which microcode revision patch is pushed by which
version of Intel's BIOS for the Bayfield mobos.

In fact, there's very little to suggest that BIOS pushing of microcode
revisions is happening. It's all "pay no attention to the man behind
the curtain", and then when SP2 catches them out, it's spun as "those
OEMs aren't supporting our processor properly". Hmm.

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.

Yep.

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

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

Me2. It's all binary, so I can't tell if it's slabs of microcode to
be pushed, or extra raw programming logic.

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'?

Yes; sorry to be vague on source, but it was arb links that Google
found - may have been forum posts of Linux project notes.

... 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.

Heh heh... the man behind the curtain gets his revenge!

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.

Have you tested every aspect of SP2?

Especially the apparent MS decision that non-bootability was
preferrable to allowing arrival at that unfit for use state.

I don't think that was a design decision at all - I suspect this is
yer genuine "oops, code doesn't behave as expected" bug.

I used the word 'decision' advisedly as the issue was known in June.

That's interesting; in which case, the decision may have been to leave
it like that. The question is, does the system really need whatever
Update.sys is doing, or not?

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

What about 8 vs 11?

Quite!

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.

Yes, I've watched that, and drew similar conclusions. Bought 2 x
Bayfields this week, and both are hitherto-unseen -409 batch, and in
boxes too (unusual for this particular distie). Stock purge?

Given that then how did the others have a chance yet apparently
some 8 microcode was in some 3rd party mobos pre Aug 1.

Well. that's the thing. Does Intel play favorites? Are OEMs expected
to visit Intel's fine print section on a regular basis, just in case
there's some earth-shattering news being mumbled there?

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

Yep, I'm interested too.

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.

That makes sense in a way: The OS must run on the system, period. If
the OS "needs" something on the system, then it must not only supply
that change, but also make the change purely within the scope of the
OS (so it doesn't break system compat with other OSs with other needs)

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

I interpret that to mean the baseline rev that was documented to be
required for proper Prescott support. But Prescott probably "grew up
in public", given that mobo dev has to parallel CPU dev a la the beta
blues. Mobos made months before Prescott release may be based on
earlier documentation with a lower (or no) microcode baseline.

It could also be interpreted to mean that earlier microcode revs were
never released, i.e. the first production rev was 7 or 8 (the
baselines required, possibly why MS dev'd on these).

In which case, Intel's spin is implying OEMs are using earlier revs
that weren't supposed to get out of the lab, like 1 thru 6. While in
reality, it looks as if BIOSs simply aren't aware of the need to push
microcode at all; they ASSume the CPU actually works as-is. Imagine!

Key questions: When did Intel declare Prescott documentation to be
final (i.e. "take these stone tablets down from the mount, and be
fruitful and multiply") and was the "needs mcode 7/8" part of that
spec, or later? If later, how much later? Released how, and to whom?

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.

Yep; that's what I mean by FUD.

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.

I'd have asserted that (i.e. that many recent systems would have
shipped with Prescott on those chipsets, at a time when it was thought
that only those chipsets were affected).

But I only hit the problem (and started a-hollerin') very soon after
RTM. I never tested any of the betas or RCs.

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

That's a very good question ... 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' ?

Extra programming logic to test for SIMD3 support, etc.



--------------- ----- ---- --- -- - - -
Dreams are stack dumps of the soul
--------------- ----- ---- --- -- - - -

"cquirke (MVP Win9x)" wrote in message
...
On Sun, 05 Sep 2004 20:24:42 GMT, "Ron Reaugh"
"cquirke (MVP Win9x)" wrote in message
On Sun, 05 Sep 2004 00:23:02 GMT, "Ron Reaugh"

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?

It hard-hangs if Prescott is insufficiently rev'd (by BIOS).

That sounds like a bug meaning that we should see a hotfixed update.sys
soon.

I think some of the wording in the original Cari threads
described update.sys as a microcode loader.

That may be, but it doesn't seem to work that way, if the results of
my testing are anything to go by.

Please supply more detail. What way does it seem to work in your testing?

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?

Yes, I mean the stereotypical hard lock that applies to normal, last
good, safe and safe command bootups, and that is cleared by disabling
L1 and L2 cache in CMOS setup.

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.

Only if Update.sys and BIOS rev'd to exactly the same revision level,

OK, so now your are saying that update.sys IS a microcode loader?

would you see that mileage. Let's say Update.sys rev'd to 8, and BIOS
rev'd to 7, you'd get this...

New BIOS, no SP2 Update.sys in effect = rev 7
New BIOS, SP2 Update.sys in effect = rev 8

YES! Now can anyone report that update.sys ever changes the 'CPU revision
=' for a Prescott or any other CPU type? If the BIOS has the required 7[8]
level then what does update.sys leave it as?

...whereas I get same rev if SP2's Update.sys is in effect or not.

That seems to follow the reports that I've seen.

Mind you, that could imply Update.sys looks for a lower threshold rev
and pushes that only if the existing level is lower, e.g...

And that process is broken for the Prescott.

SP2 Update.sys sees rev 7, dies trying to push rev 8

Obviously a bug in update.sys's code or in the update.sys concept.

SP2 Update.sys sees rev 7, pushes rev 8 OK

Has that ever been observed.

SP2 Update.sys sees rev 8+, does nothing

Some have reported an 11 or B for very recent BIOSs so we got Prescott XP
SP2 running on various microcode levels?

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.

No idea. Until now, I've never had to care about the gory details of
Intel's bugfixes as pushed by BIOS on Intel's behalf - but now I'm
beginning to wonder how many of those "needs newwer BIOS" posts were
really "needs newer CPU bugfixes".

YES, who is minding that store?

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.

Hmm... Northwood steppings and revs aren't the same as Prescott;

Of course.

each
time the higher cog changes, all lower cogs cease to relate to
previous values. For example, if the family number isn't the same,
comparing steppings is meaningless, etc.

Well, the issue was whether update.sys ever pushes anything into a
Northwood that's detectable by 'Frequency ID'.

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.

Exactly. I can't find that at Intel, though that's the obvious place
to expect to find it - and Intel's usually good at that stuff,
Collins' complaints notwithstanding.

I can get good .pdf coverage of BIOS revisions for Intel's Bayfield
mobos, and which mobo batch numbers ship with which BIOS, and the BIOS
update details do say "apply newest CPU updates" or some such.

I can find good .pdf coverage of CPU errata on a per-stepping basis.

What I cannot find, is what errata are fixed by which microcode
revision patch, and which microcode revision patch is pushed by which
version of Intel's BIOS for the Bayfield mobos.

In fact, there's very little to suggest that BIOS pushing of microcode
revisions is happening.

YES, who is minding that store.

It's all "pay no attention to the man behind
the curtain", and then when SP2 catches them out, it's spun as "those
OEMs aren't supporting our processor properly". Hmm.

HMMM is right.

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.

Yep.

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

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

Me2. It's all binary, so I can't tell if it's slabs of microcode to
be pushed, or extra raw programming logic.

Where are the hackers when we need em(they're probably all off breakin the
encryptiong)G?

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'?

Yes; sorry to be vague on source, but it was arb links that Google
found - may have been forum posts of Linux project notes.

... 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.

Heh heh... the man behind the curtain gets his revenge!

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.

Have you tested every aspect of SP2?

Not relevant. It doesn't hang during boot.

Especially the apparent MS decision that non-bootability was
preferrable to allowing arrival at that unfit for use state.

I don't think that was a design decision at all - I suspect this is
yer genuine "oops, code doesn't behave as expected" bug.

I used the word 'decision' advisedly as the issue was known in June.

That's interesting; in which case, the decision may have been to leave
it like that. The question is, does the system really need whatever
Update.sys is doing, or not?

What is clear is the SP2 RTM did NOT need a hard boot hang on Intel's latest
CPU.

There's gotta be more to this story.

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

What about 8 vs 11?

Quite!

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.

Yes, I've watched that, and drew similar conclusions. Bought 2 x
Bayfields this week, and both are hitherto-unseen -409 batch, and in
boxes too (unusual for this particular distie). Stock purge?

Given that then how did the others have a chance yet apparently
some 8 microcode was in some 3rd party mobos pre Aug 1.

Well. that's the thing. Does Intel play favorites?

And a favorite is NOT their own mobos? I don't think so. I'm lookin at
something more like no one has been watching this store. Some mobo mfg got
an 8 level from the Intel's OEM CPU group and included it in a BIOS because
they had it. Behind the curtain and no responsibility and no checks and
balances may be the problem.

Are OEMs expected
to visit Intel's fine print section on a regular basis, just in case
there's some earth-shattering news being mumbled there?

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

Yep, I'm interested too.

The microcode distribution process has never been documented AFAIK.

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.

That makes sense in a way: The OS must run on the system, period. If
the OS "needs" something on the system, then it must not only supply
that change, but also make the change purely within the scope of the
OS (so it doesn't break system compat with other OSs with other needs)

And how overall CPU microcode fits into that is a damn good question.

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

I interpret that to mean the baseline rev that was documented to be
required for proper Prescott support. But Prescott probably "grew up
in public", given that mobo dev has to parallel CPU dev a la the beta
blues. Mobos made months before Prescott release may be based on
earlier documentation with a lower (or no) microcode baseline.

It could also be interpreted to mean that earlier microcode revs were
never released, i.e. the first production rev was 7 or 8 (the
baselines required, possibly why MS dev'd on these).

Curious the number of Prescott systems that ran SP1 just fine while 'Freq
ID' showed = 0(no microcode).

In which case, Intel's spin is implying OEMs are using earlier revs
that weren't supposed to get out of the lab, like 1 thru 6. While in
reality, it looks as if BIOSs simply aren't aware of the need to push
microcode at all; they ASSume the CPU actually works as-is. Imagine!

Key questions: When did Intel declare Prescott documentation to be
final (i.e. "take these stone tablets down from the mount, and be
fruitful and multiply") and was the "needs mcode 7/8" part of that
spec, or later? If later, how much later? Released how, and to whom?

But IF that 7/8 declaration of finality means anything important then what
does todays 11/B mean? Why did they even bother to even build 11/B if 7/8
was sufficient?

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.

Yep; that's what I mean by FUD.

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.

I'd have asserted that (i.e. that many recent systems would have
shipped with Prescott on those chipsets, at a time when it was thought
that only those chipsets were affected).

But I only hit the problem (and started a-hollerin') very soon after
RTM. I never tested any of the betas or RCs.

Let's see, if I were the manager of the SP2 testing group..then should I be
expecting early termination....Prescott+SP2 should have been a hipri June
test of RC2 INHOUSE! Same thing for the Intel mobo test group and RC2..who
is lookin for a jobg?

There's gotta be more to this story!

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

That's a very good question ... 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' ?

Extra programming logic to test for SIMD3 support, etc.

How many lines of code to check CPU type and stepping? More likely
something else OR just more microcode pages.

On Thu, 09 Sep 2004 04:01:47 GMT, "Ron Reaugh"
"cquirke (MVP Win9x)" wrote in message
On Sun, 05 Sep 2004 20:24:42 GMT, "Ron Reaugh"
"cquirke (MVP Win9x)" wrote in message
On Sun, 05 Sep 2004 00:23:02 GMT, "Ron Reaugh"

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?

It hard-hangs if Prescott is insufficiently rev'd (by BIOS).

That sounds like a bug meaning that we should see a hotfixed update.sys

All very well, but unless that update.sys gets slipstreamed into SP2
before SP2 is installed, it won't avoid the apparently system-killing
result; an OS that can't boot in any way at all.

That may be, but it doesn't seem to work that way, if the results of
my testing are anything to go by.

Please supply more detail. What way does it seem to work in your testing?

I'd guess one of two possibilities:

1) Push mcode to Prescott

In this simple scenario, Update.sys pushes a set rev to Prescott. If
this were the case, you'd expect all SP2 Prescott stats to show the
same rev, which would differ from that pushed by BIOS alone (i.e. when
using no Update.sys, or SP1a's Update.sys)

My testing points away from this, and tonight I'll pin that down
further - I'm building 2 PCs with Bayfield 865G mobos (-409, June 2004
BIOS) by Intel, and the Celerons are stepping C0 and D0. Pre-SP2
testing shows these are C0, rev B and D0, rev E respectively.

If this scenario were true, however, then you'd have to posit a cause
of the crash that only applies with earlier mcode revs; presumably on
the basis of an Intel erratum later mcode revs fix.

2) Test for mcode level, patch if not OK

Is Prescott?
- Is stepping 2 or 3 (C0)?
- Yes; is mcode rev 7 or better?
- Yes - do nothing
- No - patch to rev 7 (hard lock)
- Is stepping 4 (D0)?
- Yes; is mcode rev 8 or better?
- Yes - do nothing
- No - patch to rev 8 (hard lock)

That could be any generic bug in the mcode updating process, e.g.
overlooking issues that arise when reving CPU microcode while CPU is
in Protected Mode, or has to preserve registers or internal state
flags, or has to maintain stack sanity, whatever.

3) Test CPU etc. but no mcode rev at all

This is what I suspect is the case; that Update.sys doesn't push mcode
rev at all, but is sensitive to mcode rev for one reason or another -
again, most likely due to an Intel erratum that laster mcode fixes.

The testing Update.sys does might involve L1/L2 cache awareness,
looking for level of SIMD support, that sort of thing.

Only if Update.sys and BIOS rev'd to exactly the same revision level,

OK, so now your are saying that update.sys IS a microcode loader?

No; I'm speculating that if it were an mcode loader, what would have
to apply for the test results that I see. I don't know if Update.sys
is a mcode pusher or not, that's what my testing aims to find out.

would you see that mileage. Let's say Update.sys rev'd to 8, and BIOS
rev'd to 7, you'd get this...

New BIOS, no SP2 Update.sys in effect = rev 7
New BIOS, SP2 Update.sys in effect = rev 8

YES! Now can anyone report that update.sys ever changes the 'CPU revision
=' for a Prescott or any other CPU type? If the BIOS has the required 7[8]
level then what does update.sys leave it as?

Watch this space, for C0 rev B and D0 rev E

Also, not sure if Prescott defends newer mcode against attempts to
push a lower mcode. If it does, then SP2's attempt to push rev 7 to
rev E will simply bounce off - and that would mean a generic failure
in the rev update process could apply (in that only when an
under-rev'd Prescott facilitates an update attempt, does it fail)

I wonder how many of those "needs newwer BIOS" posts were
really "needs newer CPU bugfixes".

YES, who is minding that store?

Well, Intel's a powerful company and as a mobo OEM, you have to do
whatever it takes to keep them happy. A motherboard that has an Intel
CPU socket is useless without Intel CPUs (banking on VIA's cut-down
alternative CPU is not a viable strategy).

So it would not surprise me to find Intel has everyone lined up to
deliver CPU mcode fixes on their behalf. Check out how the most
recent CPU "socket" passes the problem of bent CPU pins from Intel to
the mobo vendor, even tho swapping mobo has a far more devastating
impact on an OS installation than a CPU swap. That's a cynical,
self-serving "f^%$ the user" change if ever I saw one.

There's a story behind this, but it may be impossible to evaluate.

Well, the issue was whether update.sys ever pushes anything into a
Northwood that's detectable by 'Frequency ID'.

Ah, yes - a nice large body of PCs to test and gather data from

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.

Have you tested every aspect of SP2?

Not relevant. It doesn't hang during boot.

It's extremely relevant if you are to assert that preventing the boot
hang is all you need to test, when it comes to running XP SP2 (or XP
in general) on Prescott that's insufficiently rev'd.

If you told me today your Prescott rev 0 was solid on SP2, then
mentioned next week that your newest games all crash, I'd wonder
whether DirectX 9c's newest features were breaking on Pcott 0.

Well. that's the thing. Does Intel play favorites?

And a favorite is NOT their own mobos?

Well, YMMV with Intel's own Bayfields, depending on what -40x level
they are. That determines BIOS version, among other things (i.e. an
old -40x may not be same as a later -40x just because you did a BIOS
catch-up). This week's Bayfields are -409, with June 2004 BIOS; if
that is the "required" BIOS, then the date of that BIOS suggests it's
just about impossible for anyone else to keep up.

Curious the number of Prescott systems that ran SP1 just fine while 'Freq
ID' showed = 0(no microcode).

Quite - and posters who blame the user for SP2 installation failures
should consider that. There's no way a happy SP0/1 on rev 0 could
predict the need to update BIOS before installing SP2.

Suggesting that we should automatically revise BIOS before any SP is a
really bad idea, for two reasons:
- a failed BIOS update can be catastrophic
- don't commit multiple changes at once (e.g. new BIOS + new SP)

That's why I get angry with those who assert "there's nothing wrong
with SP2, it's just lame users who don't maintain thier PCs properly".

But IF that 7/8 declaration of finality means anything important then what
does todays 11/B mean? Why did they even bother to even build 11/B if 7/8
was sufficient?

You're asking a larger Q here, and that is; how are CPU errata managed
throughout the industry. Generally these days it's only compiler, OS
and maybe decvice driver writers who get close enough to the CPU to
trip over the timing details etc. that these errata involve.

That's aside from errata that apply below the digital layer of
abstraction, i.e. analog-level issues about how far away the nearest
charge-pump capacitor can be, etc. Those errata are significant to
hardware developers rather than coders.

So I imagine what happens is that hware makers and low-level coders
would be in Intel's information loop, probably subject to NDA, and
they would build workarounds for these errata into thier products.

In fact, this in itself can cause problems, if a revision fixes a bug
in a way that breaks the workaround for that bug. This is a familiar
toe-stubber that predates Prescott by a decade or few.

Fixing errata may be required for future clock speeds. For example,
let's say Pin 78 is documented to slew within 1.5 ms but actually
takes 1.7 ms. At 3GHz, that may fall within limits, but at 4.5GHz it
may not - so by the time Intel makes 4.5GHz cores, you'd hope they'd
have the fix built into the current stepping.

If it wasn't built into that stepping (say, because the flaw was
discovered too late) then the fix could be pushed as a mcode rev.

But I only hit the problem (and started a-hollerin') very soon after
RTM. I never tested any of the betas or RCs.

Let's see, if I were the manager of the SP2 testing group..then should I be
expecting early termination....Prescott+SP2 should have been a hipri June
test of RC2 INHOUSE! Same thing for the Intel mobo test group and RC2..who
is lookin for a jobg?

Let's say testers did a lot of "does it crash the PC?" testing during
the alpha and beta phases, then assumed those battles were sorted and
concentrated on app testing for the rest of the beta. And as you
know, Prescott shipped from June, quite late in the beta.

Unless you were aware that SP2 changes the way low-level OS code works
to the point of tripping over hware details, would you re-test the
"does it crash the PC?" stuff on what appears to be just a newer point
revision of a familiar CPU? In-house testers intimate with the
development and source code might, but "outside" testers may not.

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

Extra programming logic to test for SIMD3 support, etc.

How many lines of code to check CPU type and stepping? More likely
something else OR just more microcode pages.

I dunno, how many tests are there to do? Are there big lookup tables
of test data involved? Is the test code written quickly in some
language that creates code that is unlikely to crash, but bloated?

I could easily see the code getting that bloated, even if not much was
added, if they simply chose not to compact the code when they compiled
it for some reason or another. It's hard to draw conclusions here.




--------------- ------- ----- ---- --- -- - - - -
Sucess-proof your business! Tip #37
When given an NDA to sign, post it on your web site
--------------- ------- ----- ---- --- -- - - - -

"cquirke (MVP Win9x)" wrote in message
...
On Thu, 09 Sep 2004 04:01:47 GMT, "Ron Reaugh"
"cquirke (MVP Win9x)" wrote in message
On Sun, 05 Sep 2004 20:24:42 GMT, "Ron Reaugh"
"cquirke (MVP Win9x)" wrote in message
On Sun, 05 Sep 2004 00:23:02 GMT, "Ron Reaugh"

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?

It hard-hangs if Prescott is insufficiently rev'd (by BIOS).

That sounds like a bug meaning that we should see a hotfixed update.sys

All very well, but unless that update.sys gets slipstreamed into SP2
before SP2 is installed, it won't avoid the apparently system-killing
result; an OS that can't boot in any way at all.


Right but that would address the claim by MS/Intel that after the workaround
running with no or SP1's update.sys could lead to instabilities.

Someone I think from HP/Compaq land has already claimed that MS has agreed
to a SP2a by 10/1.

That may be, but it doesn't seem to work that way, if the results of
my testing are anything to go by.

Please supply more detail. What way does it seem to work in your
testing?

I'd guess one of two possibilities:

1) Push mcode to Prescott

In this simple scenario, Update.sys pushes a set rev to Prescott. If
this were the case, you'd expect all SP2 Prescott stats to show the
same rev, which would differ from that pushed by BIOS alone (i.e. when
using no Update.sys, or SP1a's Update.sys)

Exactly.

My testing points away from this, and tonight I'll pin that down
further - I'm building 2 PCs with Bayfield 865G mobos (-409, June 2004
BIOS) by Intel, and the Celerons are stepping C0 and D0. Pre-SP2
testing shows these are C0, rev B and D0, rev E respectively.

If this scenario were true, however, then you'd have to posit a cause
of the crash that only applies with earlier mcode revs; presumably on
the basis of an Intel erratum later mcode revs fix.

2) Test for mcode level, patch if not OK

Is Prescott?
- Is stepping 2 or 3 (C0)?
- Yes; is mcode rev 7 or better?
- Yes - do nothing
- No - patch to rev 7 (hard lock)
- Is stepping 4 (D0)?
- Yes; is mcode rev 8 or better?
- Yes - do nothing
- No - patch to rev 8 (hard lock)

That could be any generic bug in the mcode updating process, e.g.
overlooking issues that arise when reving CPU microcode while CPU is
in Protected Mode, or has to preserve registers or internal state
flags, or has to maintain stack sanity, whatever.

3) Test CPU etc. but no mcode rev at all

This is what I suspect is the case; that Update.sys doesn't push mcode
rev at all, but is sensitive to mcode rev for one reason or another -
again, most likely due to an Intel erratum that laster mcode fixes.

The testing Update.sys does might involve L1/L2 cache awareness,
looking for level of SIMD support, that sort of thing.

Only if Update.sys and BIOS rev'd to exactly the same revision level,

OK, so now your are saying that update.sys IS a microcode loader?

No; I'm speculating that if it were an mcode loader, what would have
to apply for the test results that I see. I don't know if Update.sys
is a mcode pusher or not, that's what my testing aims to find out.

Very eager to hear your conclusions.

would you see that mileage. Let's say Update.sys rev'd to 8, and BIOS
rev'd to 7, you'd get this...

New BIOS, no SP2 Update.sys in effect = rev 7
New BIOS, SP2 Update.sys in effect = rev 8

YES! Now can anyone report that update.sys ever changes the 'CPU
revision
=' for a Prescott or any other CPU type? If the BIOS has the required
7[8]
level then what does update.sys leave it as?

Watch this space, for C0 rev B and D0 rev E

Also, not sure if Prescott defends newer mcode against attempts to
push a lower mcode. If it does, then SP2's attempt to push rev 7 to
rev E will simply bounce off - and that would mean a generic failure
in the rev update process could apply (in that only when an
under-rev'd Prescott facilitates an update attempt, does it fail)

I wonder how many of those "needs newwer BIOS" posts were
really "needs newer CPU bugfixes".

YES, who is minding that store?

Well, Intel's a powerful company and as a mobo OEM, you have to do
whatever it takes to keep them happy. A motherboard that has an Intel
CPU socket is useless without Intel CPUs (banking on VIA's cut-down
alternative CPU is not a viable strategy).

So it would not surprise me to find Intel has everyone lined up to
deliver CPU mcode fixes on their behalf.

Then there needs to be some visibility to the community such that we can see
who is doing it right and not. There needs to be for each BIOS version a
list of microcode included.

Check out how the most
recent CPU "socket" passes the problem of bent CPU pins from Intel to
the mobo vendor, even tho swapping mobo has a far more devastating
impact on an OS installation than a CPU swap. That's a cynical,
self-serving "f^%$ the user" change if ever I saw one.

There's a story behind this, but it may be impossible to evaluate.

Well, the issue was whether update.sys ever pushes anything into a
Northwood that's detectable by 'Frequency ID'.

Ah, yes - a nice large body of PCs to test and gather data from

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.

Have you tested every aspect of SP2?

Not relevant. It doesn't hang during boot.

It's extremely relevant if you are to assert that preventing the boot
hang is all you need to test, when it comes to running XP SP2 (or XP
in general) on Prescott that's insufficiently rev'd.

If you told me today your Prescott rev 0 was solid on SP2, then
mentioned next week that your newest games all crash, I'd wonder
whether DirectX 9c's newest features were breaking on Pcott 0.

Well. that's the thing. Does Intel play favorites?

And a favorite is NOT their own mobos?

Well, YMMV with Intel's own Bayfields, depending on what -40x level
they are. That determines BIOS version, among other things (i.e. an
old -40x may not be same as a later -40x just because you did a BIOS
catch-up). This week's Bayfields are -409, with June 2004 BIOS; if
that is the "required" BIOS, then the date of that BIOS suggests it's
just about impossible for anyone else to keep up.

Curious the number of Prescott systems that ran SP1 just fine while 'Freq
ID' showed = 0(no microcode).

Quite - and posters who blame the user for SP2 installation failures
should consider that. There's no way a happy SP0/1 on rev 0 could
predict the need to update BIOS before installing SP2.

Suggesting that we should automatically revise BIOS before any SP is a
really bad idea, for two reasons:
- a failed BIOS update can be catastrophic

I disagree totally. Before this issue for several years now the rule of
thumb has always been to flash the latest BIOS just like nay other DD or SW
update. Failed BIOS updates are a vastly overblown risk. In any case
"catastrophic"..just no.

- don't commit multiple changes at once (e.g. new BIOS + new SP)

Unless they appear simultaneously in which case one should take the hint.
If not simultaneously then by my rule one would have already flashed the new
BIOS.

That's why I get angry with those who assert "there's nothing wrong
with SP2, it's just lame users who don't maintain thier PCs properly".

But IF that 7/8 declaration of finality means anything important then
what
does todays 11/B mean? Why did they even bother to even build 11/B if
7/8
was sufficient?

You're asking a larger Q here, and that is; how are CPU errata managed
throughout the industry.

That's been the primary question I've been asking from the beginning.

Generally these days it's only compiler, OS
and maybe decvice driver writers who get close enough to the CPU to
trip over the timing details etc. that these errata involve.

That's aside from errata that apply below the digital layer of
abstraction, i.e. analog-level issues about how far away the nearest
charge-pump capacitor can be, etc. Those errata are significant to
hardware developers rather than coders.

That is likely all true for the details of the microcode BUT not true for
the knowledge on a revision number.

So I imagine what happens is that hware makers and low-level coders
would be in Intel's information loop, probably subject to NDA, and
they would build workarounds for these errata into thier products.

In fact, this in itself can cause problems, if a revision fixes a bug
in a way that breaks the workaround for that bug. This is a familiar
toe-stubber that predates Prescott by a decade or few.

Fixing errata may be required for future clock speeds. For example,
let's say Pin 78 is documented to slew within 1.5 ms but actually
takes 1.7 ms.

ns, I assume you mean.

At 3GHz, that may fall within limits, but at 4.5GHz it
may not - so by the time Intel makes 4.5GHz cores, you'd hope they'd
have the fix built into the current stepping.

If it wasn't built into that stepping (say, because the flaw was
discovered too late) then the fix could be pushed as a mcode rev.

But I only hit the problem (and started a-hollerin') very soon after
RTM. I never tested any of the betas or RCs.

Let's see, if I were the manager of the SP2 testing group..then should I
be
expecting early termination....Prescott+SP2 should have been a hipri June
test of RC2 INHOUSE! Same thing for the Intel mobo test group and
RC2..who
is lookin for a jobg?

Let's say testers did a lot of "does it crash the PC?" testing during
the alpha and beta phases, then assumed those battles were sorted and
concentrated on app testing for the rest of the beta. And as you
know, Prescott shipped from June, quite late in the beta.

No, I got my Prescott 2.8s in April(Mar?) retail!

Unless you were aware that SP2 changes the way low-level OS code works
to the point of tripping over hware details, would you re-test the
"does it crash the PC?" stuff on what appears to be just a newer point
revision of a familiar CPU? In-house testers intimate with the
development and source code might, but "outside" testers may not.

Not buying that overall.

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

Extra programming logic to test for SIMD3 support, etc.

How many lines of code to check CPU type and stepping? More likely
something else OR just more microcode pages.

I dunno, how many tests are there to do? Are there big lookup tables
of test data involved? Is the test code written quickly in some
language that creates code that is unlikely to crash, but bloated?

I could easily see the code getting that bloated, even if not much was
added, if they simply chose not to compact the code when they compiled
it for some reason or another. It's hard to draw conclusions here.