SP2 865/875 Microcode Industry Failure?

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

In article <EK9Yc.266914$OB3.67685@bgtnsc05-news.ops.worldnet.att.net>,
"Ron Reaugh" <rondashreaugh@att.net> wrote:

> A very interesting thing has come up regarding SP2 and the motherboard
> industry in general. An anomaly was detected in the installation of XP SP2
> on Intel 865/875 chipset mobos. After SP2 install most all such mobos from
> most all mfgs would HANG on reboot.
>
> See this post in: microsoft.public.windowsxp.general
>
http://www.google.com/groups?q=+%2 [...] gbl&rnum=1
>
> An MVP there Cari had detected the issue and was pursuing it with MS and
> Intel.
>
> Current Intel CPUs have the ability to have their internal microcode updated
> on the fly(addenda fixed). Apparently that microcode update is done both by
> the mobo's BIOS during POST and during OS init by
> %windir%\system32\drivers\update.sys.
>
> What was determined is that MOST all the major mobo mfgs around are NOT
> keeping their microcode current, at least for 865/875 chipset mobos, even
> with recent BIOS updates! That old CPU microcode(non-existent BIOS
> microcode update apparently in many cases[=0]) was causing SP2 to hang after
> install.
>
> One can view/report that microcode revision level by running Intel's
> Frequency ID utility. The entry to look for is "CPU Revision = n" where n
> >= 0 which is the microcode revision level.
>
> Cari's conclusion as apparently gleaned from MS & Intel was that NO major
> mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel.
> Cari claimed to have tried a broad range of 865 and 875 chipset mobos with
> SP2 and most all failed! She then said that she'd never use anything except
> an Intel mfged mobo again as if after her eureka moment.
>
> Does anyone know more precise details of the overall technology involved
> here and the overall industry competence with respect to CPU microcode
> updates. What is the BIOS supposed to be doing here; is there any
> standard? What does %windir%\system32\drivers\update.sys do exactly?
>
> The implication is that most all of us 865/875 chipset mobo owners (and I
> assume that the issue is MUCH WIDER) have been running with all the CPU
> bugs/addenda UNFIXED!

I don't know why this issue is blown all out of proportion.

It is like the second coming or something.

If an OS is so dependent on microcode being correct, a fairly simple
algorithm and small file of microcode segments would fix it. Microsoft
should consider moving the microcode loader up in their boot sequence,
like before some other kernel files are loaded.

Inside an Asus BIOS, there is a file called cpucode.exe and it will
consist of perhaps 8 or so 2KB microcode segments. Apparently, at least
in some of the older BIOS, there were also a couple of 2KB
"cache segments" in the flash chip as well, and if a new processor
is detected, the microcode segment that loads successfully, is stored
in one of the two cache segments. The BIOS effectively has to
"flash itself", and contains the code to do that. There is actually
a procedure for Award BIOS, where a user can "write" the cache
segment with their own Prescott 2KB code segment, if they want to.
(I have done this on a P2B-S, to get microcode support for a Tualatin.)
The program is called CTMC from CT Heise magazine. In other words,
for the initiated, they can actually prep their BIOS to be "SP2
ready" if they want to, without waiting for Asus (AFAIK works
for Award BIOS, no idea if it works for AMI, as the hook and
methodology of the AMI BIOS could be different).

Asus updates BIOS files on a fairly regular basis. One user here
owns a T2-P Asus small form factor system, and while the Asus
cpusupport page doesn't currently list his system, he claims it
supports Prescott or the advert copy says it supports Prescott.
When I extracted the file of microcode segments for the most
recent version of that BIOS, there were no Prescott family code
segments in the file. So, indeed, in that case, support was
lacking. Other users here who have had "SP2 trouble", aren't
running the latest BIOS, so the solution there is clear.

To keep all these BIOS updated to cover the latest Intel
inprovements, means there will always be a gulf between the
latest released microcode segments and what is available for
download from Asus. I'm sure when a new processor is
released at Intel, it even takes Intel a day or two to update
their BIOS files, so Cari shouldn't be too smug sitting on
an Intel motherboard.

And finally, there is probably a small number of users who
have stuffed Prescott processors in non-Prescott boards,
and whatever happens, is of their own making. If your old
motherboard lists Northwood 0.13u processor support, that is
what you should be buying for it.

Seeing as microcode loading existed in my 440BX based P2B-S
motherboard, I would say the "industry competence" is there.

HTH,
Paul

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

"Ron Reaugh" <rondashreaugh@att.net> wrote in message
news:EK9Yc.266914$OB3.67685@bgtnsc05-news.ops.worldnet.att.net...
> A very interesting thing has come up regarding SP2 and the motherboard
> industry in general. An anomaly was detected in the installation of XP
SP2
> on Intel 865/875 chipset mobos. After SP2 install most all such mobos
from
> most all mfgs would HANG on reboot.

Answered in another group - You cross posting, multi posting, don't have a
life, freak.

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

To say that "most all motherboards from most all manufacturers" hang on SP2
installation is absurd. We've installed fifty-three or fifty-four SP2
upgrades on ASUS, ABIT as well as Intel 865 & 875 boards without a single
failure. Why people believe these wild tales is beyond me -- as though
months of beta testing wouldn't have revealed that problem instantly. (We
don't have any Prescott processors, and there may be a problem there on some
machines as I understand it.)

Good wishes to all.

formerprof


"Ron Reaugh" <rondashreaugh@att.net> wrote in message
news:EK9Yc.266914$OB3.67685@bgtnsc05-news.ops.worldnet.att.net...
>A very interesting thing has come up regarding SP2 and the motherboard
> industry in general. An anomaly was detected in the installation of XP
> SP2
> on Intel 865/875 chipset mobos. After SP2 install most all such mobos
> from
> most all mfgs would HANG on reboot.
>
> See this post in: microsoft.public.windowsxp.general
> http://www.google.com/groups?q=+%2 [...] gbl&rnum=1
>
> An MVP there Cari had detected the issue and was pursuing it with MS and
> Intel.
>
> Current Intel CPUs have the ability to have their internal microcode
> updated
> on the fly(addenda fixed). Apparently that microcode update is done both
> by
> the mobo's BIOS during POST and during OS init by
> %windir%\system32\drivers\update.sys.
>
> What was determined is that MOST all the major mobo mfgs around are NOT
> keeping their microcode current, at least for 865/875 chipset mobos,
> even
> with recent BIOS updates! That old CPU microcode(non-existent BIOS
> microcode update apparently in many cases[=0]) was causing SP2 to hang
> after
> install.
>
> One can view/report that microcode revision level by running Intel's
> Frequency ID utility. The entry to look for is "CPU Revision = n" where n
>>= 0 which is the microcode revision level.
>
> Cari's conclusion as apparently gleaned from MS & Intel was that NO major
> mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel.
> Cari claimed to have tried a broad range of 865 and 875 chipset mobos with
> SP2 and most all failed! She then said that she'd never use anything
> except
> an Intel mfged mobo again as if after her eureka moment.
>
> Does anyone know more precise details of the overall technology involved
> here and the overall industry competence with respect to CPU microcode
> updates. What is the BIOS supposed to be doing here; is there any
> standard? What does %windir%\system32\drivers\update.sys do exactly?
>
> The implication is that most all of us 865/875 chipset mobo owners (and I
> assume that the issue is MUCH WIDER) have been running with all the CPU
> bugs/addenda UNFIXED!
>
>
>
>
>
>

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed
CPU Revision = 7. 7 was reported with both the boot floppy version and the
XP version underp XP SP1(one).

I have now flashed BIOS 1017. The build date as shown inside BIOS setup on
the Information Screen 7/24/04.

The Intel Frequency ID app continues to show CPU Revision = 7 using the boot
floppy version of the Intel app AND using the XP version under XP SP1(one).
Yet as cited in the MS XP NG article below, what is supposed to be there is
"at least 8".

Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos then
why isn't 8 here in this recent release Asus BIOS?

The industry failure and/or competence level may be a version issue and not
a there/not there issue. Anyone?

"Ron Reaugh" <rondashreaugh@att.net> wrote in message
news:uqdYc.528526$Gx4.527533@bgtnsc04-news.ops.worldnet.att.net...
>
> "Paul" <nospam@needed.com> wrote in message
> news:nospam-2808042125200001@192.168.1.177...
> > In article <EK9Yc.266914$OB3.67685@bgtnsc05-news.ops.worldnet.att.net>,
> > "Ron Reaugh" <rondashreaugh@att.net> wrote:
> >
> > > A very interesting thing has come up regarding SP2 and the motherboard
> > > industry in general. An anomaly was detected in the installation of
XP
> SP2
> > > on Intel 865/875 chipset mobos.
>
> I FAILED to mention in my opening post that all this is only when using a
> Prescott CPU.
>
> > After SP2 install most all such mobos from
> > > most all mfgs would HANG on reboot.
> > >
> > > See this post in: microsoft.public.windowsxp.general
> > >
> >
>
http://www.google.com/groups?q=+%2 [...] gbl&rnum=1
> > >
> > > An MVP there Cari had detected the issue and was pursuing it with MS
and
> > > Intel.
> > >
> > > Current Intel CPUs have the ability to have their internal microcode
> updated
> > > on the fly(addenda fixed). Apparently that microcode update is done
> both by
> > > the mobo's BIOS during POST and during OS init by
> > > %windir%\system32\drivers\update.sys.
> > >
> > > What was determined is that MOST all the major mobo mfgs around are
NOT
> > > keeping their microcode current, at least for 865/875 chipset mobos,
> even
> > > with recent BIOS updates! That old CPU microcode(non-existent BIOS
> > > microcode update apparently in many cases[=0]) was causing SP2 to hang
> after
> > > install.
> > >
> > > One can view/report that microcode revision level by running Intel's
> > > Frequency ID utility. The entry to look for is "CPU Revision = n"
where
> n
> > > >= 0 which is the microcode revision level.
> > >
> > > Cari's conclusion as apparently gleaned from MS & Intel was that NO
> major
> > > mobo mfg has been keeping their microcode(addenda) current EXCEPT
Intel.
> > > Cari claimed to have tried a broad range of 865 and 875 chipset mobos
> with
> > > SP2 and most all failed! She then said that she'd never use anything
> except
> > > an Intel mfged mobo again as if after her eureka moment.
> > >
> > > Does anyone know more precise details of the overall technology
involved
> > > here and the overall industry competence with respect to CPU microcode
> > > updates. What is the BIOS supposed to be doing here; is there any
> > > standard? What does %windir%\system32\drivers\update.sys do exactly?
> > >
> > > The implication is that most all of us 865/875 chipset mobo owners
(and
> I
> > > assume that the issue is MUCH WIDER) have been running with all the
CPU
> > > bugs/addenda UNFIXED!
> >
> > I don't know why this issue is blown all out of proportion.
>
> It is an issue that is not well known which is why I'm trying to find more
> details and also see what folks know in general.
>
> > It is like the second coming or something.
> >
> > If an OS is so dependent on microcode being correct, a fairly simple
> > algorithm and small file of microcode segments would fix it.
>
> Well then what does this do in XP?
> %windir%\system32\drivers\update.sys
>
> >Microsoft
> > should consider moving the microcode loader up in their boot sequence,
> > like before some other kernel files are loaded.
>
> I got the impression that there was some condition precedent required in
the
> BIOS and that's why %windir%\system32\drivers\update.sys didn't work and
the
> fix was to rename update.sys ??? Please clarify.
>
> > Inside an Asus BIOS, there is a file called cpucode.exe and it will
> > consist of perhaps 8 or so 2KB microcode segments. Apparently, at least
> > in some of the older BIOS, there were also a couple of 2KB
> > "cache segments" in the flash chip as well, and if a new processor
> > is detected, the microcode segment that loads successfully, is stored
> > in one of the two cache segments. The BIOS effectively has to
> > "flash itself", and contains the code to do that. There is actually
> > a procedure for Award BIOS, where a user can "write" the cache
> > segment with their own Prescott 2KB code segment, if they want to.
> > (I have done this on a P2B-S, to get microcode support for a Tualatin.)
> > The program is called CTMC from CT Heise magazine. In other words,
> > for the initiated, they can actually prep their BIOS to be "SP2
> > ready" if they want to, without waiting for Asus (AFAIK works
> > for Award BIOS, no idea if it works for AMI, as the hook and
> > methodology of the AMI BIOS could be different).
> >
> > Asus updates BIOS files on a fairly regular basis. One user here
> > owns a T2-P Asus small form factor system, and while the Asus
> > cpusupport page doesn't currently list his system, he claims it
> > supports Prescott or the advert copy says it supports Prescott.
> > When I extracted the file of microcode segments for the most
> > recent version of that BIOS, there were no Prescott family code
> > segments in the file. So, indeed, in that case, support was
> > lacking. Other users here who have had "SP2 trouble", aren't
> > running the latest BIOS, so the solution there is clear.
> >
> > To keep all these BIOS updated to cover the latest Intel
> > inprovements, means there will always be a gulf between the
> > latest released microcode segments and what is available for
> > download from Asus.
>
> Prescotts were shipping in March.
>
> > I'm sure when a new processor is
> > released at Intel, it even takes Intel a day or two to update
> > their BIOS files, so Cari shouldn't be too smug sitting on
> > an Intel motherboard.
> >
> > And finally, there is probably a small number of users who
> > have stuffed Prescott processors in non-Prescott boards,
> > and whatever happens, is of their own making. If your old
> > motherboard lists Northwood 0.13u processor support, that is
> > what you should be buying for it.
> >
> > Seeing as microcode loading existed in my 440BX based P2B-S
> > motherboard, I would say the "industry competence" is there.
>
> Well, the question is whether the appropriate microcode is getting out in
a
> timely fashion and how users are able to easily know what microcode level
is
> right. It also apparently isn't a one time thing but updates continue to
be
> made available by Intel. It appears that most the major mobo mfgs missed
> this one for the 865/875+Prescott+SP2 release. It wasn't like nobody new
> SP2 was coming in August. There appears to have been a mobo industry
> wide(save Intel) collapse on this issue. There is also some evidence that
> MS did little regarding a headsup to them or its users as this issue was
> reported in June(over 40 days before SP2 RTM).
>
> From your read of the issue how does the rename of
> %windir%\system32\drivers\update.sys
> temporarily fix the issue??
>
>

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

"Paul" <nospam@needed.com> wrote in message
> news:nospam-2908040344340001@192.168.1.177...
[..]
> > Asus does have a quality problem with the BIOS they are releasing -
> > two releases of A7N8X-E BIOS were pulled, I believe due to problems
> > with a module for a particular piece of hardware, and a wild-ass
> > guess is newbie employees are doing builds. This is not the only
> > company I've seen this happen to. I put together an update for a
> > Sun workstation years ago, and found some of the patched applications
> > had been compiled in an insecure manner, a newbie mistake that with
> > the availability of build scripts, is inexcusable.

Having once been on the inside of this process, I can
tell you build scripts in many cases are so convoluted
they cause more problems than they prevent.

Rick

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

"Paul" <nospam@needed.com> wrote in message
news:nospam-2908040859390001@192.168.1.177...
> In article <tRgYc.268879$OB3.143525@bgtnsc05-news.ops.worldnet.att.net>,
> "Ron Reaugh" <rondashreaugh@att.net> wrote:
>
> > Paul, thanks.
> >
> > What does %windir%\system32\drivers\update.sys do in XP??
>
> I found a reference here, in the output from "Hijack This"
>
> http://forum.tweakxp.com/forum/for [...] p?TID=7530
>
> Microcode Update Driver: System32\DRIVERS\update.sys (manual start)
>
> The implication is rather interesting. The fact that Cari wants
> update.sys renamed, implies the Microsoft code has been trying
> to load an out of date microcode. I.e. If the BIOS loads a
> recent one, the Microsoft code probably won't overwrite it.
> Otherwise, the update.sys loads its version, and kaboom ?

That's one way to read it. My read was that some minimum version was
required from the BIOS before the MS version could get loaded at all. Is
that plausible?

> Kinda puts a different potential complexion on the issue.

If your assertion is correct rather than my proposition then it certainly
DOES as this issue was reported to MS at least 40 days prior to RTM for SP2.

> If
> update.sys did the right thing, maybe this never would have
> happened ?

That's why I kept asking about update.sys as something didn't seem to fit.

HOWEVER in defense of my proposition it was suggested in the MS XP NG
threads that some 865/875 mobo BIOSs left the Freq. ID showing ZERO(=0)(I
assume meaning no microcode update from the BIOS at all). Apparently even
with =0 SP2 will work/not hang as that is what the fix is: rename
update.sys. The SP1 case I tested shows that XP did not change the BIOS set
=7 microcode value.

So your assertion requires that the MS version is 8 and anything from the
mobo BIOS older causes it to load whereby a equal or greater BIOS version
causes the MS version not to load. AND your assertion also requires that
the MS version is flat out incompatible with SP2.

> I would be very interested to climb inside that
> SP2 update.sys file, to see exactly what lives in there.
> As microcode segments are encrypted, I don't know if there is
> any separate tool you can feed 2KB segments and get ID info.
> Maybe the microcode segments could be compared to known ones
> from Intel ? I don't know if microcode is available for public
> download or not.

I knew there was a bigger issue here. This situation makes it clear that
the backroom boys can no longer keep microcode updates(addenda fixes) in the
closet.

There needs to be overall visibility, reporting and accountability for the
CPU's BIOS version. Users need to get after mobo BIOS mfgs for this
information which needs to become a documented part of every mobo BIOS
release.

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

I run a P4 3.4 GHz Northwood on a P4C800-E DLX MB (Bios version 1016) and
the reported CPU Revision = 17 (I used the Win version of the application).
Is that normal? (looks quite high compared to 7 or 8)

Jan

"Ron Reaugh" <rondashreaugh@att.net> schreef in bericht
news:rreYc.268221$OB3.147231@bgtnsc05-news.ops.worldnet.att.net...
> I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed
> CPU Revision = 7. 7 was reported with both the boot floppy version and
the
> XP version underp XP SP1(one).
>
> I have now flashed BIOS 1017. The build date as shown inside BIOS setup
on
> the Information Screen 7/24/04.
>
> The Intel Frequency ID app continues to show CPU Revision = 7 using the
boot
> floppy version of the Intel app AND using the XP version under XP
SP1(one).
> Yet as cited in the MS XP NG article below, what is supposed to be there
is
> "at least 8".
>
> Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos
then
> why isn't 8 here in this recent release Asus BIOS?
>
> The industry failure and/or competence level may be a version issue and
not
> a there/not there issue. Anyone?
>
> "Ron Reaugh" <rondashreaugh@att.net> wrote in message
> news:uqdYc.528526$Gx4.527533@bgtnsc04-news.ops.worldnet.att.net...
> >
> > "Paul" <nospam@needed.com> wrote in message
> > news:nospam-2808042125200001@192.168.1.177...
> > > In article
<EK9Yc.266914$OB3.67685@bgtnsc05-news.ops.worldnet.att.net>,
> > > "Ron Reaugh" <rondashreaugh@att.net> wrote:
> > >
> > > > A very interesting thing has come up regarding SP2 and the
motherboard
> > > > industry in general. An anomaly was detected in the installation of
> XP
> > SP2
> > > > on Intel 865/875 chipset mobos.
> >
> > I FAILED to mention in my opening post that all this is only when using
a
> > Prescott CPU.
> >
> > > After SP2 install most all such mobos from
> > > > most all mfgs would HANG on reboot.
> > > >
> > > > See this post in: microsoft.public.windowsxp.general
> > > >
> > >
> >
>
http://www.google.com/groups?q=+%2 [...] gbl&rnum=1
> > > >
> > > > An MVP there Cari had detected the issue and was pursuing it with MS
> and
> > > > Intel.
> > > >
> > > > Current Intel CPUs have the ability to have their internal microcode
> > updated
> > > > on the fly(addenda fixed). Apparently that microcode update is done
> > both by
> > > > the mobo's BIOS during POST and during OS init by
> > > > %windir%\system32\drivers\update.sys.
> > > >
> > > > What was determined is that MOST all the major mobo mfgs around are
> NOT
> > > > keeping their microcode current, at least for 865/875 chipset
mobos,
> > even
> > > > with recent BIOS updates! That old CPU microcode(non-existent BIOS
> > > > microcode update apparently in many cases[=0]) was causing SP2 to
hang
> > after
> > > > install.
> > > >
> > > > One can view/report that microcode revision level by running Intel's
> > > > Frequency ID utility. The entry to look for is "CPU Revision = n"
> where
> > n
> > > > >= 0 which is the microcode revision level.
> > > >
> > > > Cari's conclusion as apparently gleaned from MS & Intel was that NO
> > major
> > > > mobo mfg has been keeping their microcode(addenda) current EXCEPT
> Intel.
> > > > Cari claimed to have tried a broad range of 865 and 875 chipset
mobos
> > with
> > > > SP2 and most all failed! She then said that she'd never use
anything
> > except
> > > > an Intel mfged mobo again as if after her eureka moment.
> > > >
> > > > Does anyone know more precise details of the overall technology
> involved
> > > > here and the overall industry competence with respect to CPU
microcode
> > > > updates. What is the BIOS supposed to be doing here; is there any
> > > > standard? What does %windir%\system32\drivers\update.sys do
exactly?
> > > >
> > > > The implication is that most all of us 865/875 chipset mobo owners
> (and
> > I
> > > > assume that the issue is MUCH WIDER) have been running with all the
> CPU
> > > > bugs/addenda UNFIXED!
> > >
> > > I don't know why this issue is blown all out of proportion.
> >
> > It is an issue that is not well known which is why I'm trying to find
more
> > details and also see what folks know in general.
> >
> > > It is like the second coming or something.
> > >
> > > If an OS is so dependent on microcode being correct, a fairly simple
> > > algorithm and small file of microcode segments would fix it.
> >
> > Well then what does this do in XP?
> > %windir%\system32\drivers\update.sys
> >
> > >Microsoft
> > > should consider moving the microcode loader up in their boot sequence,
> > > like before some other kernel files are loaded.
> >
> > I got the impression that there was some condition precedent required in
> the
> > BIOS and that's why %windir%\system32\drivers\update.sys didn't work and
> the
> > fix was to rename update.sys ??? Please clarify.
> >
> > > Inside an Asus BIOS, there is a file called cpucode.exe and it will
> > > consist of perhaps 8 or so 2KB microcode segments. Apparently, at
least
> > > in some of the older BIOS, there were also a couple of 2KB
> > > "cache segments" in the flash chip as well, and if a new processor
> > > is detected, the microcode segment that loads successfully, is stored
> > > in one of the two cache segments. The BIOS effectively has to
> > > "flash itself", and contains the code to do that. There is actually
> > > a procedure for Award BIOS, where a user can "write" the cache
> > > segment with their own Prescott 2KB code segment, if they want to.
> > > (I have done this on a P2B-S, to get microcode support for a
Tualatin.)
> > > The program is called CTMC from CT Heise magazine. In other words,
> > > for the initiated, they can actually prep their BIOS to be "SP2
> > > ready" if they want to, without waiting for Asus (AFAIK works
> > > for Award BIOS, no idea if it works for AMI, as the hook and
> > > methodology of the AMI BIOS could be different).
> > >
> > > Asus updates BIOS files on a fairly regular basis. One user here
> > > owns a T2-P Asus small form factor system, and while the Asus
> > > cpusupport page doesn't currently list his system, he claims it
> > > supports Prescott or the advert copy says it supports Prescott.
> > > When I extracted the file of microcode segments for the most
> > > recent version of that BIOS, there were no Prescott family code
> > > segments in the file. So, indeed, in that case, support was
> > > lacking. Other users here who have had "SP2 trouble", aren't
> > > running the latest BIOS, so the solution there is clear.
> > >
> > > To keep all these BIOS updated to cover the latest Intel
> > > inprovements, means there will always be a gulf between the
> > > latest released microcode segments and what is available for
> > > download from Asus.
> >
> > Prescotts were shipping in March.
> >
> > > I'm sure when a new processor is
> > > released at Intel, it even takes Intel a day or two to update
> > > their BIOS files, so Cari shouldn't be too smug sitting on
> > > an Intel motherboard.
> > >
> > > And finally, there is probably a small number of users who
> > > have stuffed Prescott processors in non-Prescott boards,
> > > and whatever happens, is of their own making. If your old
> > > motherboard lists Northwood 0.13u processor support, that is
> > > what you should be buying for it.
> > >
> > > Seeing as microcode loading existed in my 440BX based P2B-S
> > > motherboard, I would say the "industry competence" is there.
> >
> > Well, the question is whether the appropriate microcode is getting out
in
> a
> > timely fashion and how users are able to easily know what microcode
level
> is
> > right. It also apparently isn't a one time thing but updates continue
to
> be
> > made available by Intel. It appears that most the major mobo mfgs
missed
> > this one for the 865/875+Prescott+SP2 release. It wasn't like nobody
new
> > SP2 was coming in August. There appears to have been a mobo industry
> > wide(save Intel) collapse on this issue. There is also some evidence
that
> > MS did little regarding a headsup to them or its users as this issue was
> > reported in June(over 40 days before SP2 RTM).
> >
> > From your read of the issue how does the rename of
> > %windir%\system32\drivers\update.sys
> > temporarily fix the issue??
> >
> >
>
>

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

"Jan" <jstaaijNOSPAM@worldonline.nl> wrote in message
news:4133460d$0$62377$5fc3050@dreader2.news.tiscali.nl...
> I run a P4 3.4 GHz Northwood on a P4C800-E DLX MB (Bios version 1016) and
> the reported CPU Revision = 17 (I used the Win version of the
application).
> Is that normal? (looks quite high compared to 7 or 8)

This whole thread is only about Prescott so Northwoods 17 is in a different
arena.

> "Ron Reaugh" <rondashreaugh@att.net> schreef in bericht
> news:rreYc.268221$OB3.147231@bgtnsc05-news.ops.worldnet.att.net...
> > I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed
> > CPU Revision = 7. 7 was reported with both the boot floppy version and
> the
> > XP version underp XP SP1(one).
> >
> > I have now flashed BIOS 1017. The build date as shown inside BIOS setup
> on
> > the Information Screen 7/24/04.
> >
> > The Intel Frequency ID app continues to show CPU Revision = 7 using the
> boot
> > floppy version of the Intel app AND using the XP version under XP
> SP1(one).
> > Yet as cited in the MS XP NG article below, what is supposed to be
there
> is
> > "at least 8".
> >
> > Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos
> then
> > why isn't 8 here in this recent release Asus BIOS?
> >
> > The industry failure and/or competence level may be a version issue and
> not
> > a there/not there issue. Anyone?
> >
> > "Ron Reaugh" <rondashreaugh@att.net> wrote in message
> > news:uqdYc.528526$Gx4.527533@bgtnsc04-news.ops.worldnet.att.net...
> > >
> > > "Paul" <nospam@needed.com> wrote in message
> > > news:nospam-2808042125200001@192.168.1.177...
> > > > In article
> <EK9Yc.266914$OB3.67685@bgtnsc05-news.ops.worldnet.att.net>,
> > > > "Ron Reaugh" <rondashreaugh@att.net> wrote:
> > > >
> > > > > A very interesting thing has come up regarding SP2 and the
> motherboard
> > > > > industry in general. An anomaly was detected in the installation
of
> > XP
> > > SP2
> > > > > on Intel 865/875 chipset mobos.
> > >
> > > I FAILED to mention in my opening post that all this is only when
using
> a
> > > Prescott CPU.
> > >
> > > > After SP2 install most all such mobos from
> > > > > most all mfgs would HANG on reboot.
> > > > >
> > > > > See this post in: microsoft.public.windowsxp.general
> > > > >
> > > >
> > >
> >
>
http://www.google.com/groups?q=+%2 [...] gbl&rnum=1
> > > > >
> > > > > An MVP there Cari had detected the issue and was pursuing it with
MS
> > and
> > > > > Intel.
> > > > >
> > > > > Current Intel CPUs have the ability to have their internal
microcode
> > > updated
> > > > > on the fly(addenda fixed). Apparently that microcode update is
done
> > > both by
> > > > > the mobo's BIOS during POST and during OS init by
> > > > > %windir%\system32\drivers\update.sys.
> > > > >
> > > > > What was determined is that MOST all the major mobo mfgs around
are
> > NOT
> > > > > keeping their microcode current, at least for 865/875 chipset
> mobos,
> > > even
> > > > > with recent BIOS updates! That old CPU microcode(non-existent
BIOS
> > > > > microcode update apparently in many cases[=0]) was causing SP2 to
> hang
> > > after
> > > > > install.
> > > > >
> > > > > One can view/report that microcode revision level by running
Intel's
> > > > > Frequency ID utility. The entry to look for is "CPU Revision = n"
> > where
> > > n
> > > > > >= 0 which is the microcode revision level.
> > > > >
> > > > > Cari's conclusion as apparently gleaned from MS & Intel was that
NO
> > > major
> > > > > mobo mfg has been keeping their microcode(addenda) current EXCEPT
> > Intel.
> > > > > Cari claimed to have tried a broad range of 865 and 875 chipset
> mobos
> > > with
> > > > > SP2 and most all failed! She then said that she'd never use
> anything
> > > except
> > > > > an Intel mfged mobo again as if after her eureka moment.
> > > > >
> > > > > Does anyone know more precise details of the overall technology
> > involved
> > > > > here and the overall industry competence with respect to CPU
> microcode
> > > > > updates. What is the BIOS supposed to be doing here; is there
any
> > > > > standard? What does %windir%\system32\drivers\update.sys do
> exactly?
> > > > >
> > > > > The implication is that most all of us 865/875 chipset mobo owners
> > (and
> > > I
> > > > > assume that the issue is MUCH WIDER) have been running with all
the
> > CPU
> > > > > bugs/addenda UNFIXED!
> > > >
> > > > I don't know why this issue is blown all out of proportion.
> > >
> > > It is an issue that is not well known which is why I'm trying to find
> more
> > > details and also see what folks know in general.
> > >
> > > > It is like the second coming or something.
> > > >
> > > > If an OS is so dependent on microcode being correct, a fairly simple
> > > > algorithm and small file of microcode segments would fix it.
> > >
> > > Well then what does this do in XP?
> > > %windir%\system32\drivers\update.sys
> > >
> > > >Microsoft
> > > > should consider moving the microcode loader up in their boot
sequence,
> > > > like before some other kernel files are loaded.
> > >
> > > I got the impression that there was some condition precedent required
in
> > the
> > > BIOS and that's why %windir%\system32\drivers\update.sys didn't work
and
> > the
> > > fix was to rename update.sys ??? Please clarify.
> > >
> > > > Inside an Asus BIOS, there is a file called cpucode.exe and it will
> > > > consist of perhaps 8 or so 2KB microcode segments. Apparently, at
> least
> > > > in some of the older BIOS, there were also a couple of 2KB
> > > > "cache segments" in the flash chip as well, and if a new processor
> > > > is detected, the microcode segment that loads successfully, is
stored
> > > > in one of the two cache segments. The BIOS effectively has to
> > > > "flash itself", and contains the code to do that. There is actually
> > > > a procedure for Award BIOS, where a user can "write" the cache
> > > > segment with their own Prescott 2KB code segment, if they want to.
> > > > (I have done this on a P2B-S, to get microcode support for a
> Tualatin.)
> > > > The program is called CTMC from CT Heise magazine. In other words,
> > > > for the initiated, they can actually prep their BIOS to be "SP2
> > > > ready" if they want to, without waiting for Asus (AFAIK works
> > > > for Award BIOS, no idea if it works for AMI, as the hook and
> > > > methodology of the AMI BIOS could be different).
> > > >
> > > > Asus updates BIOS files on a fairly regular basis. One user here
> > > > owns a T2-P Asus small form factor system, and while the Asus
> > > > cpusupport page doesn't currently list his system, he claims it
> > > > supports Prescott or the advert copy says it supports Prescott.
> > > > When I extracted the file of microcode segments for the most
> > > > recent version of that BIOS, there were no Prescott family code
> > > > segments in the file. So, indeed, in that case, support was
> > > > lacking. Other users here who have had "SP2 trouble", aren't
> > > > running the latest BIOS, so the solution there is clear.
> > > >
> > > > To keep all these BIOS updated to cover the latest Intel
> > > > inprovements, means there will always be a gulf between the
> > > > latest released microcode segments and what is available for
> > > > download from Asus.
> > >
> > > Prescotts were shipping in March.
> > >
> > > > I'm sure when a new processor is
> > > > released at Intel, it even takes Intel a day or two to update
> > > > their BIOS files, so Cari shouldn't be too smug sitting on
> > > > an Intel motherboard.
> > > >
> > > > And finally, there is probably a small number of users who
> > > > have stuffed Prescott processors in non-Prescott boards,
> > > > and whatever happens, is of their own making. If your old
> > > > motherboard lists Northwood 0.13u processor support, that is
> > > > what you should be buying for it.
> > > >
> > > > Seeing as microcode loading existed in my 440BX based P2B-S
> > > > motherboard, I would say the "industry competence" is there.
> > >
> > > Well, the question is whether the appropriate microcode is getting
out
> in
> > a
> > > timely fashion and how users are able to easily know what microcode
> level
> > is
> > > right. It also apparently isn't a one time thing but updates continue
> to
> > be
> > > made available by Intel. It appears that most the major mobo mfgs
> missed
> > > this one for the 865/875+Prescott+SP2 release. It wasn't like nobody
> new
> > > SP2 was coming in August. There appears to have been a mobo industry
> > > wide(save Intel) collapse on this issue. There is also some evidence
> that
> > > MS did little regarding a headsup to them or its users as this issue
was
> > > reported in June(over 40 days before SP2 RTM).
> > >
> > > From your read of the issue how does the rename of
> > > %windir%\system32\drivers\update.sys
> > > temporarily fix the issue??
> > >
> > >
> >
> >
>
>

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

On Sun, 29 Aug 2004 05:53:08 GMT, "Ron Reaugh" <rondashreaugh@att.net>
wrote:

>> "Formerprof" wrote
>> > To say that "most all motherboards from most all manufacturers" hang on
>> > SP2 installation is absurd.
>>
>> QUITE RIGHT...but they DO HANG using a Prescott. I FAILED to mention that
>> littel detail but have since corrected that error.

Good discussion, folks, so it's
SP2 + Prescott = hang, unless on an intel mobo.

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

In article <8tj8k0dlada1mdkc55t9n3gdjtnmhuarv9@4ax.com>,
brian.brunner@verizon.verizon.net wrote:

> On Sun, 29 Aug 2004 05:53:08 GMT, "Ron Reaugh" <rondashreaugh@att.net>
> wrote:
>
> >> "Formerprof" wrote
> >> > To say that "most all motherboards from most all manufacturers" hang on
> >> > SP2 installation is absurd.
> >>
> >> QUITE RIGHT...but they DO HANG using a Prescott. I FAILED to mention that
> >> littel detail but have since corrected that error.
>
> Good discussion, folks, so it's
> SP2 + Prescott = hang, unless on an intel mobo.

No, it is considered on a case by case basis, and the Intel
Frequency ID utility shows the version of microcode being used.
Based on the version being a particular one, with the Prescott,
that is how you decide to install of not. If some kind person
will examine your mobo maker's BIOS microcode files for you,
they can even tell you which minimum BIOS is required to be
flash upgraded to the motherboard, to make it "SP2 Prescott"
ready. For example, some Asus 875/865 BIOS are more than
ready, and others are not - microcode updates are not issued
separately, but new microcode is bundled with bug fixes to the
BIOS, and that is why they are late in coming on some boards.

So, Intel doesn't have the market cornered :-) In fact, I bet
even Microsoft could fix this, if SP2 wasn't so "bug free". It
is my belief that an improved update.sys file could fix this,
and this is a NIMBY (not in my back yard) problem. I'll believe
that, until someone tells me exactly what SP2 update.sys is using
for its own microcode patches.

Paul

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

"Paul" <nospam@needed.com> wrote in message
news:nospam-1209041352100001@192.168.1.177...
> In article <8tj8k0dlada1mdkc55t9n3gdjtnmhuarv9@4ax.com>,
> brian.brunner@verizon.verizon.net wrote:
>
> > On Sun, 29 Aug 2004 05:53:08 GMT, "Ron Reaugh" <rondashreaugh@att.net>
> > wrote:
> >
> > >> "Formerprof" wrote
> > >> > To say that "most all motherboards from most all manufacturers"
hang on
> > >> > SP2 installation is absurd.
> > >>
> > >> QUITE RIGHT...but they DO HANG using a Prescott. I FAILED to mention
that
> > >> littel detail but have since corrected that error.
> >
> > Good discussion, folks, so it's
> > SP2 + Prescott = hang, unless on an intel mobo.
>
> No, it is considered on a case by case basis, and the Intel
> Frequency ID utility shows the version of microcode being used.
> Based on the version being a particular one, with the Prescott,
> that is how you decide to install of not. If some kind person
> will examine your mobo maker's BIOS microcode files for you,
> they can even tell you which minimum BIOS is required to be
> flash upgraded to the motherboard, to make it "SP2 Prescott"
> ready. For example, some Asus 875/865 BIOS are more than
> ready, and others are not - microcode updates are not issued
> separately, but new microcode is bundled with bug fixes to the
> BIOS, and that is why they are late in coming on some boards.
>
> So, Intel doesn't have the market cornered :-) In fact, I bet
> even Microsoft could fix this, if SP2 wasn't so "bug free". It
> is my belief that an improved update.sys file could fix this,
> and this is a NIMBY (not in my back yard) problem. I'll believe
> that, until someone tells me exactly what SP2 update.sys is using
> for its own microcode patches.

There is an ongoing question as to whether update.sys is in fact a microcode
loader. No one has been able to show that a system before and after
update.sys ever shows a different "CPU revision =" from Intel's Freq ID.
Some have been looking including on Northwoods.

What exactly happened here with this whole deal remains a deepening mystery.

Archived from groups: alt.comp.periphs.mainboard.asus,alt.comp.periphs.mainboard.abit (More info?)

"Brian Brunner" <brian.brunner@verizon.verizon.net> wrote in message
news:8tj8k0dlada1mdkc55t9n3gdjtnmhuarv9@4ax.com...
> On Sun, 29 Aug 2004 05:53:08 GMT, "Ron Reaugh" <rondashreaugh@att.net>
> wrote:
>
> >> "Formerprof" wrote
> >> > To say that "most all motherboards from most all manufacturers" hang
on
> >> > SP2 installation is absurd.
> >>
> >> QUITE RIGHT...but they DO HANG using a Prescott. I FAILED to mention
that
> >> littel detail but have since corrected that error.
>
> Good discussion, folks, so it's
> SP2 + Prescott = hang, unless on an intel mobo.

No, not that simple. There's an Aug 6 answer and a now answer. Neither
was exclusively "Intel is ok". The correct microcode version is the only
thing that makes it ok short of the workaround for now anyway..


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

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