xp sp2 download, computer won't boot up now

B

baldbenny

I have downloaded xp sp2 overnight, and this morning it
asked me to restart the computer as sp2 download was
complete and the installation was in process and the
computer needed to be restarted to complete the
installation.
When I restart the computer it freezes shortly after
start up with Windows XP on screen.
If I start the computer in safe mode with networking
either on or off, The computer freezes with a heap of
sentences showing, with the last one reading the
following-
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS\System32
\Drivers\Mup.sys
If I try to restart using 'Last known good configuration'
it still freezes on the XP page with the black background.
What am I to do know?
 
V

vyking61

You're not alone! You just described the exact same
problem I experienced overnight. I'll let you know if I
find something out.
 
B

baldbenny

cheers & good luck with your PC
-----Original Message-----
You're not alone! You just described the exact same
problem I experienced overnight. I'll let you know if I
find something out.
.
 
G

Guest

sounds like a driver issue.
When you start up in safe mode (F5) make sure its the
veery basic 'safe mode - no drivers - no networking, Then
go to the control panel and do an sp2 removal in remove
programs.
Hope this helps - it worked for me and I had a very simlar
problem.
Good Luck!
Barrie
 
G

Guest

sounds like a driver issue.
When you start up in safe mode (F5) make sure its the
veery basic 'safe mode - no drivers - no networking, Then
go to the control panel and do an sp2 removal in remove
programs.
Hope this helps - it worked for me and I had a very simlar
problem.
Good Luck!
Barrie
I used this to uninstall a beta version of SP2, my system froze up after windows started. I just installed the "recommended" update of SP2, now it won't boot up in any mode! Looks like I may need to reinstall XP. I have a dual boot system, so I can retrieve any files first.
Any other suggestions are appreciated.
 
C

cquirke (MVP Win9x)

On Sat, 28 Aug 2004 07:55:33 -0700, "vyking61"
You're not alone! You just described the exact same
problem I experienced overnight. I'll let you know if I
find something out.

http://cquirke.mvps.org/sp2intel.htm

Known issue with Intel Precott processor and SP2, if BIOS doesn't push
Intel's bugfixes to the processor.

To uninstall SP2, do this:
- CMOS setup, disable L1 and L2 cache
- run XP; it will run, but very slowly... have faith!
- Add/Remove Programs, uninstall SP2
- CMOS setup, enable L1 and L2 cache

To live with SP2 (kludge), do this:
- use your maintenance OS to rename away Update.sys
- now XP SP2 will run "fine" (that's how I'm running my test PC)
- if you have SP1(a) Update.sys, can put that back if you like

To really fix the underlying issue:
- get a BIOS update that pushes microcode rev 8 to Prescott
- steppings 2, 3 = C0 are OK on rev 7
- but stepping 4 = D0 requires rev 8

If you find your mobo vendors's very latest BIOS doesn't fix the
issue, don't be surprised. Even Intel seems just-in-time on this; I
read up Intel's own 865G Bayfield mobo, and...


http://www.intel.com/design/motherbd/bf/bf_proc.htm

Outlines processor requirements, which are...

Mobo -405*, BIOS P18 Prescott Celeron D
Mobo -405*, BIOS P13 Prescott Pentium 4
Mobo -405*, BIOS P11 Pentium 4 Extreme Edition
Mobo -any, BIOS P11 Pentium 4 at 3.4GHz
Mobo -any, BIOS P06 Pentium 4 at 800MHz base
Mobo -any, BIOS P03 Pentium 4
Mobo -any, BIOS P03 Celeron

* C28144-406 req'd; all other C2???? are -405 OK
(Every Bayfield I've seen here has been C25843)


ftp://download.intel.com/design/motherbd/bf/C4159712.pdf

Page 9 links motherboard -40x rev to BIOS version; excerpt:

C25843-408 = BIOS P16
C25843-407 = BIOS P13
C25843-406 = BIOS P10
C25843-405 = BIOS P09
C25843-404 = BIOS P07
C25843-403 = BIOS P07
C25843-402 = BIOS P06
C25843-401 = BIOS P03

This contrasts with Intel's assertions that -405 is OK for
Prescott, and that only tardy 3rd-party motherboard/BIOS
vendors have failed to be Prescott-ready.

When you look at the BIOS versions, the threshold for
Prescott Pentium 4 is -407, not -405 as claimed, and not
one C25843 is fit for Prescott Celeron D.


ftp://download.intel.com/design/motherbd/bf/P19.pdf

BIOS revision history, as summarized below.

P19-0065 03/08/2004
P18-0063 22/06/2004
- latest processor update
- Celeron Badge for Prescott
P17-0061 22/04/2004
P16-0060 12/04/2004
P15-0058 05/04/2004
- latest processor update
P14-0056 10/02/2004
P13-0053 22/01/2004
- enhanced for future processor supprt
- code to diff some P4 from some Celeron
- latest processor update
P12-0051 16/12/2003
- supports P4 Extreme Edition
P11-0048 14/10/2003
P10-0046 24/09/2003
- latest processor update
P09-0043 25/08/2003
- latest processor update
P08-0038 24/06/2003
P07-0036 19/05/2003
P06-0033 23/04/2003
- latest processor update
P05-0030 16/04/2003
P04-0028 14/04/2003
P03-0024 04/04/2003
- initial BIOS release

So the "Prescott Celeron OK" BIOS revision came out in June 2004 -
same month as Prescott Celeron itself - and that version has yet to
ship with the -403 to -408 stock we buy new right now.

What does that tell you about chances of not falling into this hole?


--------------- ----- ---- --- -- - - -
Tech Support: The guys who follow the
'Parade of New Products' with a shovel.
 
B

baldbenny

Thank you for your reply.
I will study your suggestion and see if it will apply to
my situation.
Just one small thing- when I'm in command prompt, I want
to access the 'documents and settings' file but the PC
responds with access denied even though I am logged in as
a admin. How can I get arround this to recover a very
important file if all else fails?
Cheers
Bald Benny
 
R

Ron Reaugh

Why is the temp fix to rename update.sys? When can we expect a hotfix from
MS for SP2's update.sys? A buggy SP2 update.sys with respect to the
Prescott seems to be what's really behind this whole issue, right?
 
C

cquirke (MVP Win9x)

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.
When can we expect a hotfix from MS for SP2's update.sys?

Not sure if that is the path the resolution will take. Update.sys may
just be the tip of the iceberg here; the real problem is within
Intel's Prescott itself - i.e. that unless it has been updated by BIOS
on Intel's behalf, it doesn't work properly.
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).

One of the things SP2 includes is DirectX 9c, and one of the things
DirectX 9C offers is the third revision of pixel shaders. This new
revision uses floating point, which may benefit from Prescott's new
SIMD3 instructions, if these are available.

Now we get to pure guesswork on my part!

It may be that SIMD3 is buggy at microcode revisions below 7
(steppings 2, 3 aka C0) and 8 (stepping 4 aka D0), and this may be
what crashes Update.sys if the latter is trying to ascertain whether
SIMD3 support exists (so it can path DirectX to use it).

End of guesswork part. The definitive fix is to get a BIOS that
updates Prescott's microcode revision. If your mobo vendor didn't
have a suitable BIOS revision last week, look again - you may see
changes RSN. In my case, Jetway hatched BIOS 05 1 Sep 2004.


------------ ----- ---- --- -- - - - -
The most accurate diagnostic instrument
in medicine is the Retrospectoscope
 
R

Ron Reaugh

cquirke (MVP Win9x) said:
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?
Not sure if that is the path the resolution will take. Update.sys may
just be the tip of the iceberg here; the real problem is within
Intel's Prescott itself - i.e. that unless it has been updated by BIOS
on Intel's behalf, it doesn't work properly.

I thought update.sys DID update microcode on CPUs. Nicht wahr?
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. It does bring what you simply say above but
what you simply say above was 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?"
One of the things SP2 includes is DirectX 9c, and one of the things
DirectX 9C offers is the third revision of pixel shaders. This new
revision uses floating point, which may benefit from Prescott's new
SIMD3 instructions, if these are available.

Now we get to pure guesswork on my part!

It may be that SIMD3 is buggy at microcode revisions below 7
(steppings 2, 3 aka C0) and 8 (stepping 4 aka D0), and this may be
what crashes Update.sys if the latter is trying to ascertain whether
SIMD3 support exists (so it can path DirectX to use it).

And your guesswork clearly describes a buggy update.sys. The issue of
SP2+Prescott was known/reported in June in RC2 if not BEFORE.
End of guesswork part. The definitive fix is to get a BIOS that
updates Prescott's microcode revision.

Shouldn't update.sys load the correct microcode version.
If your mobo vendor didn't
have a suitable BIOS revision last week, look again - you may see
changes RSN. In my case, Jetway hatched BIOS 05 1 Sep 2004.

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

cquirke (MVP Win9x)

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.

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

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

But the CPU rev went into effect as soon as I used the new BIOS, even
while still using the smaller Update.sys from SP1a.

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. 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.
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.
Intel's spin is that Prescott should receive appropriate microcode
updates from BIOS, otherwise that system should be considered unfit
for use. Whether that's "blame-the-OEMs" or "use our mobos, not
theirs" chest-thumping or not, I can only guess.

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.

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


------------ ----- ---- --- -- - - - -
Get In Touch With Your Feelings! #37:
You are probably hungry if tempted to swallow
toothpaste for the nutritional value.
 
R

Ron Reaugh

cquirke (MVP Win9x) said:
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
superior<g> 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 up said:
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.


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 issue said:
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.


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

Ron Reaugh

Ron Reaugh said:
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.

There is a more general question here and that is industry responsibility
and user VISIBILITY of microcode version. Currently generally there is NO
reporting about what microcode version is included in any given BIOS
version. There is also NO list anywhere of what microcode version is needed
or desireable for any particular purpose. In the real world if there is no
reporting and no visibility then there is NO compliance and no
responsibility. That assertion includes 'compliance' which begs the
question...compliance with what?? What are the industry's, Intel's or MS's
rules/requirements/conventions regarding CPU microcode?

What is the precise meaning of "production level microcode"?
 
T

Terry

I'm watching this thread with interest as I have tried to update with sp2
and getting the hang. Can't even get safe mode. Curiously I also find that I
cannot flash my bios with the correct latest version as something has
changed. Chaintech 9CJS P4-3.0E 1MB, 800FSB. I am trying to do an OS repair
back to sp1a, if successful I'll try the bios flash again. Looks like it may
take a couple of attempts to get everything back again. Failing that back to
the mobo vendor with questions.

Luckily my OS is on it's own partition but I don't really fancy reloading
from fresh and spending hours loading apps. However, if I did need to do
that I will need to copy over the Docs n Settings folders to another drive,
an ealier message in this thread asked why access was denied but received no
answer, anything on that please?

Regards
 
T

Terry

It did take 2 subsequent XP repairs (one after the other) to get everything
back. The latest bios is OK for sp2 Chaintech were aware of the microcode
issue, just that the rom based flash utility is rubbish, I've been given a
different flash utility to play with. So tonight I'll flash the bios and
then give sp2 another go.

regards
 
C

cquirke (MVP Win9x)

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.
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.
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
A nice little embarrassing side question: From what deficiency does one's
system suffer by having CPU revision = 8 microcode versus the obviously
superior<g> 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.
Well, yeah that's what happens with microcode in BIOS as it gets into the
CPU during POST.
Yep.


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.
"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.
I'll bet it's tractable or at least it may have always been thought to be
tractable until this came up<G>.

Heh heh... the man behind the curtain gets his revenge!
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?
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 issue<g>?

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?
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 wacko<g> 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.
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
 
R

Ron Reaugh

cquirke (MVP Win9x) said:
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.
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?
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.



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?
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?
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'.
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.
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
encryption said:
Yes; sorry to be vague on source, but it was arb links that Google
found - may have been forum posts of Linux project notes.



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



Have you tested every aspect of SP2?

Not relevant. It doesn't hang during boot.
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.


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


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?


Yep, I'm interested too.

The microcode distribution process has never been documented AFAIK.
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.
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?
Yep; that's what I mean by FUD.



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 job<g>?

There's gotta be more to this story!
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.
 
C

cquirke (MVP Win9x)

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.
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.
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.
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)
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
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.
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.
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 job<g>?

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

Ron Reaugh

cquirke (MVP Win9x) said:
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.
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.



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


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



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


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


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.



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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top