xp sp2 download, computer won't boot up now

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\System 32
\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?

You're not alone! You just described the exact same
problem I experienced overnight. I'll let you know if I
find something out.
-----Original Message-----
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\Syste m32
\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?
.

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.
-----Original Message-----
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\Syst em32
\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?
.

.

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
-----Original Message-----
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.
-----Original Message-----
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\Sys tem32
\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?
.

.

.

" wrote:

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
-----Original Message-----
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.
-----Original Message-----
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\Sys tem32
\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?
.

.

.

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.

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.

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

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS\Syst em32
\Drivers\Mup.sys

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/moth...f/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.
--------------- ----- ---- --- -- - - -

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


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

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

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS\Sys tem32
\Drivers\Mup.sys

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/moth...f/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.
--------------- ----- ---- --- -- - - -
.

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?

"cquirke (MVP Win9x)" wrote in message
...
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.

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

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS\Syst em32
\Drivers\Mup.sys

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/moth...f/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.
--------------- ----- ---- --- -- - - -

On Tue, 31 Aug 2004 21:53:00 GMT, "Ron Reaugh"

Why is the temp fix to rename update.sys?

Update.sys is the driver file that locks up when XP SP2 boots on a
system that has Prescott processor running revision 8 or 7.

Just why that happens - i.e. what SP2's larger Update.sys is doing
that older SP1a's Update.sys doesn't do - remains a mystery to me.

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

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

Why is the temp fix to rename update.sys?

Update.sys is the driver file that locks up when XP SP2 boots on a
system that has Prescott processor running revision 8 or 7.

Just why that happens - i.e. what SP2's larger Update.sys is doing
that older SP1a's Update.sys doesn't do - remains a mystery to me.


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

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.

I thought update.sys DID update microcode on CPUs. Nicht wahr?

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

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

That assumes facts NOT in evidence and in fact assumes facts that you
already said you didn't know. 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???

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

Why is the temp fix to rename update.sys?

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

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

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

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.

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

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

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

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

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

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

But FUD swirls around whether Prescott Rev 0 is in fact fit for use.
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.
------------ ----- ---- --- -- - - - -

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

Why is the temp fix to rename update.sys?

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

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

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

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

I say this because I tested as follows:

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What about 8 vs 11?

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

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

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

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

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

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

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

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

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

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

Interesting assertion; I wasn't aware of this.

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

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

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

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

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

"Ron Reaugh" wrote in message news:eCK_c.556789

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

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


"Ron Reaugh" wrote in message
...

"Ron Reaugh" wrote in message news:eCK_c.556789

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

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

"Ron Reaugh" wrote in message
...

"Ron Reaugh" wrote in message news:eCK_c.556789

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