SP2 + Prescott New Detail?

[Ron Reaugh]

A claim has been made that once SP2 has been installed on an 865/875 chipset
mobo+Prescott with a too old microcode version(<7 [<8 ](stepping)) then one
can not simply flash an acceptable microcode version( =>7 [or
=>8 ](stepping))and expect SP2 to work, true??

The claim also is that the only way to run SP2 installed with a too old
version of microcode is to rename update.sys or use SP1's update.sys. About
this configuration some say that, even with a later updated microcode to
the proper level and un-renamed/replaced<g> update.sys, it might not be
fully stable/supported ever, true??

Therefore the overall claim is that if SP2 was installed when the improper
Prescott microcode was present then the ONLY long term fully
'supported/stable' solution is to uninstall SP2 and do it again with the
proper microcode present, true?

If the answers to the above is mostly true then the implication is that
something is irreversibly configured during SP2 install regarding CPU
microcode level. This also implies that there might be a new wrinkle in
SP2 to the HW configuration switch issue beyond the known ones in SP1.

 

[David Candy]

Update.sys need to be disabled during installation only. Then you reenable it after installation.

 

[Ron Reaugh]

Update.sys need to be disabled during installation only. Then you reenable
it after installation.

No, cite a reference.

 

[Ron Reaugh]

A claim has been made that once SP2 has been installed on an 865/875 chipset
mobo+Prescott with a too old microcode version(<7 [<8 ](stepping)) then one
can not simply flash an acceptable microcode version( =>7 [or
=>8 ](stepping))and expect SP2 to work, true??

The claim also is that the only way to run SP2 installed with a too old
version of microcode is to rename update.sys or use SP1's update.sys. About
this configuration some say that, even with a later updated microcode to
the proper level and un-renamed/replaced<g> update.sys, it might not be
fully stable/supported ever, true??

Therefore the overall claim is that if SP2 was installed when the improper
Prescott microcode was present then the ONLY long term fully
'supported/stable' solution is to uninstall SP2 and do it again with the
proper microcode present, true?

If the answers to the above is mostly true then the implication is that
something is irreversibly configured during SP2 install regarding CPU
microcode level. This also implies that there might be a new wrinkle in
SP2 to the HW configuration switch issue beyond the known ones in SP1.

 

[J.]

http://support.microsoft.com/default.aspx?kbid=885626

Update.sys need to be disabled during installation only. Then you reenable
it after installation.

No, cite a reference.

--
----------------------------------------------------------
War on the Pachyderms Terrorists
http://www.counterpunch.org/wilson09012004.html

A claim has been made that once SP2 has been installed on an 865/875 chipset
mobo+Prescott with a too old microcode version(<7 [<8 ](stepping)) then one
can not simply flash an acceptable microcode version( =>7 [or
=>8 ](stepping))and expect SP2 to work, true??

The claim also is that the only way to run SP2 installed with a too old
version of microcode is to rename update.sys or use SP1's update.sys. About
this configuration some say that, even with a later updated microcode to
the proper level and un-renamed/replaced<g> update.sys, it might not be
fully stable/supported ever, true??

Therefore the overall claim is that if SP2 was installed when the
improper
Prescott microcode was present then the ONLY long term fully
'supported/stable' solution is to uninstall SP2 and do it again with the
proper microcode present, true?

If the answers to the above is mostly true then the implication is that
something is irreversibly configured during SP2 install regarding CPU
microcode level. This also implies that there might be a new wrinkle in
SP2 to the HW configuration switch issue beyond the known ones in SP1.

 

[J.]

Please see this for more info:
http://support.microsoft.com/default.aspx?kbid=885626

 

[Ron Reaugh]

Please see this for more info:
http://support.microsoft.com/default.aspx?kbid=885626

Yes, now obviously I've read that several times MORE than you have. Now go
and read it carefully. Then come back and see if you can intelligently
respond to my post.

A claim has been made that once SP2 has been installed on an 865/875
chipset
mobo+Prescott with a too old microcode version(<7 [<8 ](stepping)) then
one
can not simply flash an acceptable microcode version( =>7 [or
=>8 ](stepping))and expect SP2 to work, true??

The claim also is that the only way to run SP2 installed with a too old
version of microcode is to rename update.sys or use SP1's update.sys.
About
this configuration some say that, even with a later updated microcode to
the proper level and un-renamed/replaced<g> update.sys, it might not be
fully stable/supported ever, true??

Therefore the overall claim is that if SP2 was installed when the improper
Prescott microcode was present then the ONLY long term fully
'supported/stable' solution is to uninstall SP2 and do it again with the
proper microcode present, true?

If the answers to the above is mostly true then the implication is that
something is irreversibly configured during SP2 install regarding CPU
microcode level. This also implies that there might be a new wrinkle in
SP2 to the HW configuration switch issue beyond the known ones in SP1.

 

[J.]

The microcode is reloaded each time on boot, it's not "flashed".

If you are running SP2 with the update.sys and it boots, then you are fine,
you had a supported microcode.

If you had to rename update.sys to boot, then you're temporarily running
with unsupported microcode. If you can update your BIOS, then rename
update.sys, you're back to a good state. If not, then you need to wait for
an updated update.sys which will also work.

Please see this for more info:
http://support.microsoft.com/default.aspx?kbid=885626

Yes, now obviously I've read that several times MORE than you have. Now
go
and read it carefully. Then come back and see if you can intelligently
respond to my post.

A claim has been made that once SP2 has been installed on an 865/875
chipset
mobo+Prescott with a too old microcode version(<7 [<8 ](stepping)) then
one
can not simply flash an acceptable microcode version( =>7 [or
=>8 ](stepping))and expect SP2 to work, true??

The claim also is that the only way to run SP2 installed with a too old
version of microcode is to rename update.sys or use SP1's update.sys.
About
this configuration some say that, even with a later updated microcode to
the proper level and un-renamed/replaced<g> update.sys, it might not be
fully stable/supported ever, true??

Therefore the overall claim is that if SP2 was installed when the improper
Prescott microcode was present then the ONLY long term fully
'supported/stable' solution is to uninstall SP2 and do it again with
the
proper microcode present, true?

If the answers to the above is mostly true then the implication is that
something is irreversibly configured during SP2 install regarding CPU
microcode level. This also implies that there might be a new wrinkle in
SP2 to the HW configuration switch issue beyond the known ones in SP1.

 

[Ron Reaugh]

The microcode is reloaded each time on boot, it's not "flashed".

We all knew that.

If you are running SP2 with the update.sys and it boots, then you are fine,
you had a supported microcode.

We all knew that.

If you had to rename update.sys to boot, then you're temporarily running
with unsupported microcode.
Yep.

If you can update your BIOS, then rename
update.sys, you're back to a good state. If not, then you need to wait for
an updated update.sys which will also work.

SP1's update.sys works fine as a temporary workaround. There has been NO
admission that there is any kind of SP2 update.sys fix needed. However it
seems obvious that one is NEEDED but... Are you suggesting that the state
of "unsupported microcode" plus a fixed update.sys is a permanent solution?
Is update.sys also capable of updating Intel CPU microcode?

It sure would be nice if someone would directly answer the questions I posed
in my opening post(yes/no/explanation).

What does update.sys DO??

Please see this for more info:
http://support.microsoft.com/default.aspx?kbid=885626

Yes, now obviously I've read that several times MORE than you have. Now
go
and read it carefully. Then come back and see if you can intelligently
respond to my post.

A claim has been made that once SP2 has been installed on an 865/875
chipset
mobo+Prescott with a too old microcode version(<7 [<8 ](stepping)) then
one
can not simply flash an acceptable microcode version( =>7 [or
=>8 ](stepping))and expect SP2 to work, true??

The claim also is that the only way to run SP2 installed with a too old
version of microcode is to rename update.sys or use SP1's update.sys.
About
this configuration some say that, even with a later updated

microcode
to

the proper level and un-renamed/replaced<g> update.sys, it might not be
fully stable/supported ever, true??

Therefore the overall claim is that if SP2 was installed when the improper
Prescott microcode was present then the ONLY long term fully
'supported/stable' solution is to uninstall SP2 and do it again with
the
proper microcode present, true?

If the answers to the above is mostly true then the implication is that
something is irreversibly configured during SP2 install regarding CPU
microcode level. This also implies that there might be a new

wrinkle
in

SP2 to the HW configuration switch issue beyond the known ones in SP1.

 

[Alex Nichol]

SP1's update.sys works fine as a temporary workaround. There has been NO
admission that there is any kind of SP2 update.sys fix needed. However it
seems obvious that one is NEEDED but... Are you suggesting that the state
of "unsupported microcode" plus a fixed update.sys is a permanent solution?
Is update.sys also capable of updating Intel CPU microcode?

See Chris Quirke's page on this - he has been putting in a lot of work
on it. http://cquirke.mvps.org/sp2intel.htm

What seems to be the position is that the microcode of Prescott is buggy
*unsurprisingly in something so complex), and that intel have provided
means of updating it through a dynamic update. This can be done in the
BIOS POST stage, provided the BIOS is adequately up to date: quite a lot
of BIOSes on early boards are not. Update.sys provides a means of
updating it alternatively as windows boots: the technique appears to
interfere with the installation and initial boot stage with SP2; going
back to the SP1 update.sys (much smaller) which is from before Prescott
so does not try, will get you past. Whether it is better to leave this
one in or put the SP2 one back is unclear - the *best* solution is an
adequate BIOS update, to get the microcode right at the earlier stage


Unfortunately Prescott is so recent that I doubt if any of the SP2 beta
testers was using one - people generally do not do major updates of
hardware in the middle of a beta program

 

[Ron Reaugh]

See Chris Quirke's page on this - he has been putting in a lot of work
on it. http://cquirke.mvps.org/sp2intel.htm

I've been following that and others.

What seems to be the position is that the microcode of Prescott is buggy

What microcode are you talking about? The 'in silicon' microcode or the
encrypted microcode pages loaded by the BIOS of version 7[8] or less?

*unsurprisingly in something so complex), and that intel have provided
means of updating it through a dynamic update.

Exactly. That process and visibility has been kept mostly in the closet.
Therefore there's been no auditability and no assignment of responsibility
of whose job it is to keep that microcode current. Obviously Intel builds
it but then what happens to it after that? The concept of "keeping the
microcode current" has NOT been fully explained/defined.

This can be done in the
BIOS POST stage, provided the BIOS is adequately up to date: quite a lot
of BIOSes on early boards are not.

A huge convolution that needs detailed explanation.

Might I assume that what you meant to say is that a mobo BIOS is capable of
loading a microcode page to a given CPU line(like Prescott) or it isn't? If
it IS then the issue is solved unless you were describing something more
obscure??

Update.sys provides a means of
updating it alternatively

I thought so. You are the first to specifically state that update.sys is a
microcode loader. Please someone confirm his assertion as I'd like a second
source in addition to my hunch.

as windows boots: the technique appears to
interfere with the installation and initial boot stage with SP2; going
back to the SP1 update.sys (much smaller) which is from before Prescott
so does not try, will get you past. Whether it is better to leave this
one in or put the SP2 one back is unclear - the *best* solution is an
adequate BIOS update, to get the microcode right at the earlier stage

So you are also specifically stating that update.sys fails in its attempt to
put new/proper microcode into a Prescott. That means EITHER that there is a
simple bug in update.sys. Thus a quick hotfixed update.sys should be made
available by MS soon. OR this issue has exposed a fundamental weakness in
the strategy of keeping CPU microcode current which a fixed update.sys can't
handle. Which is it?

If the latter then the issue apparently exposes a larger industry problem.
The mobo mfgs have always been assuming that MS was responsible for keeping
the microcode current. That's certainly the way that the mobo industry has
been historically behaving. Historically the mobo mfgs never mention
microcode level nor even the fact of the microcode loading process. It's
always been a CPU line(like Prescott) is supported yes/no and never at what
level of microcode.

Unfortunately Prescott is so recent that I doubt if any of the SP2 beta
testers was using one

Not that new. Prescott started shipping in about March. The Prescott+SP2
issue was described in June under RC2.

- people generally do not do major updates of
hardware in the middle of a beta program

EXCEPT MAYBE THE COMPANY WHO IS RELEASING A MAJOR SP!

 

[Alex Nichol]

A huge convolution that needs detailed explanation.

Might I assume that what you meant to say is that a mobo BIOS is capable of
loading a microcode page to a given CPU line(like Prescott) or it isn't? If
it IS then the issue is solved unless you were describing something more
obscure??

Chris would be better on this than me; but as I understand it the BIOSes
concerned have the ability to patch the microcode, on the fly at power
up, and it needs an adequately updated BIOS to come with adequately
updated patch

And yes - the update.sys does need revising, and I would expect MS and
Intel to be working on that. Meanwhile the work around of having it out
of use during SP2 install serves to get that into place, and my feeling
is that then sticking with the SP1 version is best bet. But I don't
have a Prescott system to try it on - Chris as a system builder
does,and is experimenting

 

[Ron Reaugh]

Chris would be better on this than me; but as I understand it the BIOSes
concerned have the ability to patch the microcode, on the fly at power
up,

That's my understanding.

and it needs an adequately updated BIOS to come with adequately
updated patch

Well, these encrypted microcode pages are included in the BIOS. Lot's of
em...one for each CPU type and stepping that the mobo supports.

And yes - the update.sys does need revising, and I would expect MS and
Intel to be working on that. Meanwhile the work around of having it out
of use during SP2 install serves to get that into place, and my feeling
is that then sticking with the SP1 version is best bet. But I don't
have a Prescott system to try it on - Chris as a system builder
does,and is experimenting

All that agrees with my understanding.

HOWEVER you snipped all the interesting and important points that I'd
brought up. I'll repaste em here:

*unsurprisingly in something so complex), and that intel have provided
means of updating it through a dynamic update.

Exactly. That process and visibility has been kept mostly in the closet.
Therefore there's been no auditability and no assignment of responsibility
of whose job it is to keep that microcode current. Obviously Intel builds
it but then what happens to it after that? The concept of "keeping the
microcode current" has NOT been fully explained/defined.

Update.sys provides a means of
updating it alternatively

I thought so. You are the first to specifically state that update.sys is a
microcode loader. Please someone confirm his assertion as I'd like a second
source in addition to my hunch.

as windows boots: the technique appears to
interfere with the installation and initial boot stage with SP2; going
back to the SP1 update.sys (much smaller) which is from before Prescott
so does not try, will get you past. Whether it is better to leave this
one in or put the SP2 one back is unclear - the *best* solution is an
adequate BIOS update, to get the microcode right at the earlier stage

So you are also specifically stating that update.sys fails in its attempt to
put new/proper microcode into a Prescott. That means EITHER that there is a
simple bug in update.sys. Thus a quick hotfixed update.sys should be made
available by MS soon. OR this issue has exposed a fundamental weakness in
the strategy of keeping CPU microcode current which a fixed update.sys can't
handle. Which is it?

If the latter then the issue apparently exposes a larger industry problem.
The mobo mfgs have always been assuming that MS was responsible for keeping
the microcode current. That's certainly the way that the mobo industry has
been historically behaving. Historically the mobo mfgs never mention
microcode level nor even the fact of the microcode loading process. It's
always been a CPU line(like Prescott) is supported yes/no and never at what
level of microcode.

Unfortunately Prescott is so recent that I doubt if any of the SP2 beta
testers was using one

Not that new. Prescott started shipping in about March. The Prescott+SP2
issue was described in June under RC2.

- people generally do not do major updates of
hardware in the middle of a beta program

EXCEPT MAYBE THE COMPANY WHO IS RELEASING A MAJOR SP!

 

[jt3]

Been interested in this since seeing cryptic remarks about microcode updates
in BIOS updates for my daughter's Dell. You might look at some of the Linux
sites, though you may well be more up on this than I.
http://www.securiteam.com/securityreviews/5FP0M1PDFO.html

Joe

See Chris Quirke's page on this - he has been putting in a lot of work
on it. http://cquirke.mvps.org/sp2intel.htm

I've been following that and others.

What seems to be the position is that the microcode of Prescott is buggy

What microcode are you talking about? The 'in silicon' microcode or the
encrypted microcode pages loaded by the BIOS of version 7[8] or less?

*unsurprisingly in something so complex), and that intel have provided
means of updating it through a dynamic update.

Exactly. That process and visibility has been kept mostly in the closet.
Therefore there's been no auditability and no assignment of responsibility
of whose job it is to keep that microcode current. Obviously Intel builds
it but then what happens to it after that? The concept of "keeping the
microcode current" has NOT been fully explained/defined.

This can be done in the
BIOS POST stage, provided the BIOS is adequately up to date: quite a lot
of BIOSes on early boards are not.

A huge convolution that needs detailed explanation.

Might I assume that what you meant to say is that a mobo BIOS is capable of
loading a microcode page to a given CPU line(like Prescott) or it isn't? If
it IS then the issue is solved unless you were describing something more
obscure??

Update.sys provides a means of
updating it alternatively

I thought so. You are the first to specifically state that update.sys is a
microcode loader. Please someone confirm his assertion as I'd like a second
source in addition to my hunch.

as windows boots: the technique appears to
interfere with the installation and initial boot stage with SP2; going
back to the SP1 update.sys (much smaller) which is from before Prescott
so does not try, will get you past. Whether it is better to leave this
one in or put the SP2 one back is unclear - the *best* solution is an
adequate BIOS update, to get the microcode right at the earlier stage

So you are also specifically stating that update.sys fails in its attempt to
put new/proper microcode into a Prescott. That means EITHER that there is a
simple bug in update.sys. Thus a quick hotfixed update.sys should be made
available by MS soon. OR this issue has exposed a fundamental weakness in
the strategy of keeping CPU microcode current which a fixed update.sys can't
handle. Which is it?

If the latter then the issue apparently exposes a larger industry problem.
The mobo mfgs have always been assuming that MS was responsible for keeping
the microcode current. That's certainly the way that the mobo industry has
been historically behaving. Historically the mobo mfgs never mention
microcode level nor even the fact of the microcode loading process. It's
always been a CPU line(like Prescott) is supported yes/no and never at what
level of microcode.

Unfortunately Prescott is so recent that I doubt if any of the SP2 beta
testers was using one

Not that new. Prescott started shipping in about March. The Prescott+SP2
issue was described in June under RC2.

- people generally do not do major updates of
hardware in the middle of a beta program

EXCEPT MAYBE THE COMPANY WHO IS RELEASING A MAJOR SP!

Alex Nichol MS MVP (Windows Technologies)
Bournemouth, U.K. (e-mail address removed)8E8L.org (remove the D8 bit)

 

[Ron Reaugh]

Been interested in this since seeing cryptic remarks about microcode updates
in BIOS updates for my daughter's Dell. You might look at some of the Linux
sites, though you may well be more up on this than I.
http://www.securiteam.com/securityreviews/5FP0M1PDFO.html

"those who are interested in microcode hacking....is in no way encrypted as
it is in Intel microcode updates......The ability to fundamentally alter
instruction decoding and execution on AMD K8 processors is sure to interest
hardware hackers everywhere."

<VBG>

http://www.eetimes.com/news/97/963news/hole.html
good but 1997


What does XP's update.sys do exactly?

Joe
been

NO

admission that there is any kind of SP2 update.sys fix needed.

However
it

seems obvious that one is NEEDED but... Are you suggesting that

the
state

of "unsupported microcode" plus a fixed update.sys is a permanent solution?
Is update.sys also capable of updating Intel CPU microcode?

See Chris Quirke's page on this - he has been putting in a lot of work
on it. http://cquirke.mvps.org/sp2intel.htm

I've been following that and others.

What seems to be the position is that the microcode of Prescott is

buggy

What microcode are you talking about? The 'in silicon' microcode or the
encrypted microcode pages loaded by the BIOS of version 7[8] or less?

*unsurprisingly in something so complex), and that intel have provided
means of updating it through a dynamic update.

Exactly. That process and visibility has been kept mostly in the closet.
Therefore there's been no auditability and no assignment of responsibility
of whose job it is to keep that microcode current. Obviously Intel builds
it but then what happens to it after that? The concept of "keeping the
microcode current" has NOT been fully explained/defined.

This can be done in the
BIOS POST stage, provided the BIOS is adequately up to date: quite a lot
of BIOSes on early boards are not.

A huge convolution that needs detailed explanation.

Might I assume that what you meant to say is that a mobo BIOS is capable of
loading a microcode page to a given CPU line(like Prescott) or it isn't? If
it IS then the issue is solved unless you were describing something more
obscure??

Update.sys provides a means of
updating it alternatively

I thought so. You are the first to specifically state that update.sys

is

a
microcode loader. Please someone confirm his assertion as I'd like a second
source in addition to my hunch.


So you are also specifically stating that update.sys fails in its

attempt

to
put new/proper microcode into a Prescott. That means EITHER that there

is

a
simple bug in update.sys. Thus a quick hotfixed update.sys should be made
available by MS soon. OR this issue has exposed a fundamental weakness in
the strategy of keeping CPU microcode current which a fixed update.sys can't
handle. Which is it?

If the latter then the issue apparently exposes a larger industry problem.
The mobo mfgs have always been assuming that MS was responsible for keeping
the microcode current. That's certainly the way that the mobo industry has
been historically behaving. Historically the mobo mfgs never mention
microcode level nor even the fact of the microcode loading process. It's
always been a CPU line(like Prescott) is supported yes/no and never at what
level of microcode.


Not that new. Prescott started shipping in about March. The Prescott+SP2
issue was described in June under RC2.


EXCEPT MAYBE THE COMPANY WHO IS RELEASING A MAJOR SP!

 

[jt3]

Sorry, don't know, can only infer from the threads the hackers have
provided, but it rather looks like it checks your BIOS revision, but the
obvious problem of rebooting if it were to try to update it??

Good luck, and I'll be interested in anything you find out...
Joe

Been interested in this since seeing cryptic remarks about microcode updates
in BIOS updates for my daughter's Dell. You might look at some of the Linux
sites, though you may well be more up on this than I.
http://www.securiteam.com/securityreviews/5FP0M1PDFO.html

"those who are interested in microcode hacking....is in no way encrypted as
it is in Intel microcode updates......The ability to fundamentally alter
instruction decoding and execution on AMD K8 processors is sure to interest
hardware hackers everywhere."

<VBG>

http://www.eetimes.com/news/97/963news/hole.html
good but 1997


What does XP's update.sys do exactly?

Joe

Ron Reaugh wrote:


SP1's update.sys works fine as a temporary workaround. There has

been

NO
admission that there is any kind of SP2 update.sys fix needed. However
it
seems obvious that one is NEEDED but... Are you suggesting that the
state
of "unsupported microcode" plus a fixed update.sys is a permanent
solution?
Is update.sys also capable of updating Intel CPU microcode?

See Chris Quirke's page on this - he has been putting in a lot of work
on it. http://cquirke.mvps.org/sp2intel.htm

I've been following that and others.

What seems to be the position is that the microcode of Prescott is buggy

What microcode are you talking about? The 'in silicon' microcode or the
encrypted microcode pages loaded by the BIOS of version 7[8] or less?

*unsurprisingly in something so complex), and that intel have provided
means of updating it through a dynamic update.

Exactly. That process and visibility has been kept mostly in the closet.
Therefore there's been no auditability and no assignment of responsibility
of whose job it is to keep that microcode current. Obviously Intel builds
it but then what happens to it after that? The concept of "keeping the
microcode current" has NOT been fully explained/defined.

This can be done in the
BIOS POST stage, provided the BIOS is adequately up to date: quite a lot
of BIOSes on early boards are not.

A huge convolution that needs detailed explanation.

Might I assume that what you meant to say is that a mobo BIOS is

capable
of

loading a microcode page to a given CPU line(like Prescott) or it

isn't?
If

it IS then the issue is solved unless you were describing something more
obscure??

Update.sys provides a means of
updating it alternatively

I thought so. You are the first to specifically state that update.sys

is

a
microcode loader. Please someone confirm his assertion as I'd like a second
source in addition to my hunch.

as windows boots: the technique appears to
interfere with the installation and initial boot stage with SP2; going
back to the SP1 update.sys (much smaller) which is from before Prescott
so does not try, will get you past. Whether it is better to leave this
one in or put the SP2 one back is unclear - the *best* solution is an
adequate BIOS update, to get the microcode right at the earlier stage

So you are also specifically stating that update.sys fails in its

attempt

to
put new/proper microcode into a Prescott. That means EITHER that

there

is

weakness

in industry
has