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

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

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

Complicating the issue even more is the way all kinds of stuff you
probably don't want often gets stuffed into new versions of BIOSen
(I've seen people report their Promise Raid drives disappeared
when they updated BIOS to a new version). Just more proof that
microcode updates belong in the kernel, not the BIOS...
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
email: Tom.Horsley@worldnet.att.net icbm: Delray Beach, FL |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+

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

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

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

"Formerprof" <formerprof@yahoo.com> wrote in message
news:10j2prp9t5lkbd4@corp.supernews.com...
> 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.

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

"Ron Reaugh" <rondashreaugh@att.net> wrote in message
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.

Correction 7/22/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 [...] m=5&as_min
y=2004&as_maxd=28&as_maxm=8&as_maxy=2004&selm=eAqpSwjiEHA.2664%40TK2MSFTNGP1
1.phx.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 ha