SP2 865/875 Microcode Industry Failure?

Discussion in 'Abit' started by Ron Reaugh, Aug 29, 2004.

  1. Ron Reaugh

    Ron Reaugh Guest

    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=+"cp...=&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
    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!
     
    Ron Reaugh, Aug 29, 2004
    #1
    1. Advertisements

  2. Ron Reaugh

    Paul Guest

    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
     
    Paul, Aug 29, 2004
    #2
    1. Advertisements

  3. 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...
    --email: icbm: Delray Beach, FL |
    <URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+
     
    Thomas A. Horsley, Aug 29, 2004
    #3
  4. Ron Reaugh

    Noozer Guest

    Answered in another group - You cross posting, multi posting, don't have a
    life, freak.
     
    Noozer, Aug 29, 2004
    #4
  5. Ron Reaugh

    Ron Reaugh Guest

    I FAILED to mention in my opening post that all this is only when using a
    Prescott CPU.
    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.
    Well then what does this do in XP?
    %windir%\system32\drivers\update.sys
    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.
    Prescotts were shipping in March.
    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??
     
    Ron Reaugh, Aug 29, 2004
    #5
  6. Ron Reaugh

    Formerprof Guest

    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


     
    Formerprof, Aug 29, 2004
    #6
  7. Ron Reaugh

    Ron Reaugh Guest

    QUITE RIGHT...but they DO HANG using a Prescott. I FAILED to mention that
    littel detail but have since corrected that error.
     
    Ron Reaugh, Aug 29, 2004
    #7
  8. Ron Reaugh

    Ron Reaugh Guest

    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, Aug 29, 2004
    #8
  9. Ron Reaugh

    Ron Reaugh Guest

    Correction 7/22/04.
     
    Ron Reaugh, Aug 29, 2004
    #9
  10. Ron Reaugh

    Paul Guest

    I have a look at P4C800-E Deluxe 1017 BIOS, and you are correct. The
    microcode for 0F33 is version 7.

    I selected the p4p800s_se 1006se BIOS and for 0F33 the version was 9.

    I think what we are missing here, is what precisely triggers a
    BIOS update. For Asus, when enough crap piles up, or there are
    enough complaints, or the larger OEM customers complain, they
    act. Microcode updates have about the same weight as any other bug
    in the BIOS. If something else is being fixed, then perhaps during
    the build, they throw in the latest microcode files they have on
    hand. Now, imagine an Asus BIOS for a mature board - there are
    few bugs in the queue for the board, which means even though a
    microcode update is pending, the priority of issuing an update
    isn't high enough for that update to get done. Every company
    has priorities, and Asus puts more energy into fixing the egregious
    bugs in brand new motherboards, than it does into fixing the BIOS
    of boards near the tail of their sales curve. (Remember, many
    Asus boards are released with half-finished BIOS - time to market
    is everything, and a late introduction kills the profit for the
    product. Some of the Asus BIOS cannot even read the SPD of the
    memory DIMMs in their first release, and memory timing uses
    conservative values, until they can finish the code.)

    Intel, on the other hand, would probably pride itself on releasing
    a new BIOS for every board it ever made, every time the microcode
    changes. But doing so, entails regression testing all those
    motherboards, at huge expense.

    I guess who you do business with, depends on who provides the things
    people want most. The un-overclockable Intel boards don't attract
    the typical home builder, but for the corporate user depending on
    corporate features, Intel is probably the way to go.

    And, when we talk about competence, within the last day or two, there
    was a guy who flashed up his Asus DLS533 server board to the latest
    BIOS, and noticed his RAID array was no longer detected by the BIOS.
    When I looked at the BIOS, a module was missing from the new BIOS, so
    no code to drive that hardware.

    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.

    To me, this indicates that regression testing of these BIOS is
    slipping, for stuff like this to get through. Putting it all in
    perspective, the microcode situation is just a small part of the
    overall picture.

    Paul
     
    Paul, Aug 29, 2004
    #10
  11. Ron Reaugh

    Ron Reaugh Guest

    Paul, thanks.

    What does %windir%\system32\drivers\update.sys do in XP??

     
    Ron Reaugh, Aug 29, 2004
    #11
  12. Ron Reaugh

    Rick Guest

    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
     
    Rick, Aug 29, 2004
    #12
  13. Ron Reaugh

    Paul Guest

    I found a reference here, in the output from "Hijack This"

    http://forum.tweakxp.com/forum/forum_posts_view.asp?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 ?

    Kinda puts a different potential complexion on the issue. If
    update.sys did the right thing, maybe this never would have
    happened ? 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.

    Paul
     
    Paul, Aug 29, 2004
    #13
  14. Ron Reaugh

    Ron Reaugh Guest

    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?
    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.
    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 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.
     
    Ron Reaugh, Aug 29, 2004
    #14
  15. Ron Reaugh

    Ron Reaugh Guest

    From another thread in this NG is a URL describing some details about this
    issue:
    http://cquirke.mvps.org/sp2intel.htm

    In summary this thread has it mostly correct and the primary outstanding
    questions of this thread are not answered there. That URL is more about how
    to get SP2 workin in spite of this issue.
     
    Ron Reaugh, Aug 29, 2004
    #15
  16. Ron Reaugh

    Winey Guest

    On Sun, 29 Aug 2004 03:43:49 -0400, (Paul) wrote:

    [snip]

    How are you able to look at the BIOS code. Isn't it all real-mode
    assembler?
    [more snipping]
    Not to mention the fact that the board itself often undergoes
    revisions after it is first released.
    [snipping again]
    Again, exactly HOW were you able to look at the BIOS to see the
    missing module?

    time to market, plus the need to cut costs everywhere.
    [lots and lots more snipped]

    --W--
     
    Winey, Aug 30, 2004
    #16
  17. Ron Reaugh

    Ron Reaugh Guest

    There are whole cults of BIOS fiddlers and they have their set of tools.

    What I'm waiting for is a NEW cult of CPU microcode fiddlers and then just
    wait until the spammers and Al Queida get their hands on your CPU
    internals...BIOS code is childs play<G>. Let's start a new NG and a company
    selling CPU microcode nanosnake scanners and popup stopper all in one.

    I wonder how much faster a game would run if you updated the CPU's microcode
    in real time...let's call it "writeable control store" or was that Varian
    circa 1970<G>.
     
    Ron Reaugh, Aug 30, 2004
    #17
  18. Ron Reaugh

    Paul Guest

    I don't understand all the details, but the microcode itself is
    encrypted for this very reason. To make it harder to craft a 2KB
    "bomb" to load into the processor. Judging by the fact that the
    tools I use can list version info, the headers must be in plain
    text. I don't recall where the microcode method is documented,
    but there were some discussions about microcode a while back where
    some of this was discussed.

    As for tools, I use AMIBCP75.exe to open and extract modules
    from AMI BIOS. CTMC from heise.de has a program called splitawd,
    that will chop up an Award BIOS into its modules. The Award modules
    are compressed and LHA decompresses them to executable form. Then,
    a hex editor and searching for text strings inside the module can
    reveal the identity of, say, a RAID BIOS module.

    The CTMC program itself was created to examine the microcode module.
    The /store command of the main program, breaks the microcode
    module up into its 2KB microcode files. The CTMC program also lists
    the vintage info for each microcode file.

    So, either AMIBCP75 and then CTMC, or splitawd, lha -x, CTMC will
    handle AMI or Award BIOS respectively. There are other tools
    like modbin, awardmod, etc., which allow more extensive hacking,
    but without a BIOS Savior and a need for it, I'm not really
    interested in going further than that.

    Paul
     
    Paul, Aug 30, 2004
    #18
  19. Ron Reaugh

    Jan Guest

    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

     
    Jan, Aug 30, 2004
    #19
  20. Ron Reaugh

    ... et al. Guest

    Not on this technical level.
    But one of my favourite complaints in this newsgroup (the *.asus
    one) is that their BIOS updates (for my A7V333 board) come
    *without any* documentation *at all* !! And from what i gather
    that behaviour is nothing exceptional, but rather bussiness as
    usual from motherboard manufacturers. :-(
     
    ... et al., Aug 30, 2004
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.