Archived from groups: alt.comp.periphs.mainboard.asus (
More info?)
"Winey" <NOSPAMME@no-one-here.com> wrote in message
news:8n45k01jiladpiqoqpaauoi851hjl2hhfs@4ax.com...
> On Fri, 10 Sep 2004 19:56:20 GMT, "Ron Reaugh" <rondashreaugh@att.net>
> wrote:
>
> >
> >"Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
> >news:4142039A.8000304@neo.rr.com...
> >> The issue is that many motherboards don't have the proper Intel
> >> microcode for Prescott CPUs -- either because owners hadn't kept up
with
> >> new BIOS' (the "if it aint' broke don't fix it" philosophy, but in this
> >> case it burned them),
> >
> >That philosophy with respect to mobo BIOSs was defunct 4 years ago.
>
> Why? What has changed since 2000 to justify that statement?
BIOSs work now. BIOS flashing works now. The first thing anybody is gonna
want one to do when a problem comes up is flash the latest BIOS. The myth
that one should only flash if there's something specific stated in the new
BIOS that one needs is pure bull. A large percentage of what's new in a new
BIOS version is NOT documented....a good example of that is new microcode
which has never been documented by any mobo mfg AFAIK. Don't wait for the
problem...preempt.
> If
> anything, some people had to do an update because of Y2K issues. That
> was then.
>
>
> >
> >> or even because the motherboard makers themselves
> >> had their heads up their ass (as of the release date for SP2, the
> >> necessary update had not been released at all for maybe half of recent
> >> motherboards, including a number of Asus models -- not withstanding
that
> >> this has been coming for 8 months, and there was no excuse for what
> >> happened).
> >
> >There is significant evidence that the mobo mfgs have NO culpability in
this
> >issue. There is significant evidence that it was internal MS and/or
Intel
> >bungling.
>
> That's a plausible statement, especially for MS. Can you back it up
> with specific examples or other proof?
Intel didn't have the fixed BIOSs out for some of their mobos until after
RTM and there are other suspicions like the issue was known in June
but......
In addition no one will state or may even know exactly what the previously
existing standard was for mobo mfgs as far as microcode level goes. There
appears to have been no one minding that store. One theory is that
update.sys is responsible for putting the proper microcode in for XP but
something broke that process with SP2.
> >> The obvious solution, of course, it to install the latest BIOS on any
> >> motherboard that will take a Prescott (I'd argue, even if a Prescott is
> >> not currently installed).
> >
> >Always flash the latest BIOS...just because.
>
> ... because ...
Obviously because more recent is betteer just like any device driver or SW
update.
There's nothing sacrosanct about a BIOS....one keeps it current just like
any other code.
> Say you flash your wife's system. Yeah, the BIOS was "behind" and in
> fact the whole system is a bit behind by today's state of the art.
> Now, because of some leeeetle detail, your wife's system stops working
> and she can't get email, check on web sites, or do her
> brought-home-from-the-office work.
Flash the old version back. HOWEVER that kind of thinking is what happened
back in 1997 and not now.
> Now what do you say to her? "But honey, Ron Reaugh told me to always
> flash the BIOS to the latest version." For her likely response, look
> up Lysistrata.
Clueless.
>
http://www.google.com/search?sourceid=navclient&ie=UTF-8&q=Lysistrata
> >
> >> But that won't help if the latest bios from the motherboard maker still
> >> doesn't include the proper production microcode from Intel.
> >>
> >> The incompatability with the beta Intel microcode present in many
> >> production BIOS'
> >
> >There's no indication that mobo mfgs had a beta microcode; some had NO
> >Prescott microcode which worked just great in SP1 and W2K3. Many of
Intel's
>
> There are a lot of motherboard makers, and you believe you can assert
> that ALL of them are blameless in this situation?
Especially where most all appear to be in the same boat including INTEL!
> Pick a
> compatibility issue, any issue, and the newsgroups are full of
> complaints about compatibility problems.
HUH!
> >own mobos didn't get the right SP2 BIOS until shortly after RTM. The
BIOS
> >issue was known in June.
> >
> >> is with a module called "Update.sys" in Windows.
> >> Initially people were replacing the SP2 Update.SYS with the one from
> >> SP1, but it apparently turns out that it's enough not to have ANY
> >> update.sys at all, so at least in most cases, you can just rename it to
> >> Update.sav, and then put it back to Update.sys later, after the BIOS
> >> problem is resolved. The problem is, if the incompatability is
present,
> >> the system won't boot, so you need to use the recovery console, which
> >> most people dont' know about (if the drive is FAT32 you can boot from a
> >> DOS floppy or CD, but if it's NTFS, as it usually is, that won't help).
> >
> >There's another workaround. Turn off L1 & L2 cache in BIOS setup and the
> >system will run DOG SLOW. But good enough until you rename update.sys
then
> >reenable L1 & L2 and be happy.
>
> Glad I don't have to do this drill.
> >
> >> There is a writeup on this in the MS knowledgebase. The real "fault"
> >> goes to the Motherboard makers who had their heads up their asses since
> >> January, and to users who don't update their BIOS'.
> >
> >That assertion is OFF and there is NOT the slightest evidence it's true.
>
> Let's hear it from other people in this group. Do you truly trust
> your motherboard mfg to always provide 100% perfect support?
Clueless.
740d.11590$w%6.10664@newsread1.news.pas.earthlink.net...
Facebook
Twitter
Instagram