Re: xp sp2 download, computer won't boot up now
From: cquirke (MVP Win9x) (cquirkenews_at_nospam.mvps.org)
Date: 09/08/04
- Next message: cquirke (MVP Win9x): "Re: sp2 is a certified killer"
- Previous message: Randy: "Windows Update not loading fully - doesn't work"
- In reply to: Ron Reaugh: "Re: xp sp2 download, computer won't boot up now"
- Next in thread: Ron Reaugh: "Re: xp sp2 download, computer won't boot up now"
- Reply: Ron Reaugh: "Re: xp sp2 download, computer won't boot up now"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 09 Sep 2004 01:53:37 +0200
On Sun, 05 Sep 2004 20:24:42 GMT, "Ron Reaugh" <rondashreaugh@att.net>
>"cquirke (MVP Win9x)" <cquirkenews@nospam.mvps.org> wrote in message
>> On Sun, 05 Sep 2004 00:23:02 GMT, "Ron Reaugh"
>> >I was under the impression that update.sys loads microcode
>> >into processors. Is that true?
>> I don't think it pushes microcode to the processor; more likely it
>> tests to see if the required microcode revision level is present.
>And does a hard hang if it's NOT...hmmm?
It hard-hangs if Prescott is insufficiently rev'd (by BIOS).
>I think some of the wording in the original Cari threads
>described update.sys as a microcode loader.
That may be, but it doesn't seem to work that way, if the results of
my testing are anything to go by.
>> I say this because I tested as follows:
>> Old BIOS, Rev 0 CPU, SP1a, SP1a Update.sys - OK
>> Old BIOS, Rev 0 CPU, SP2, SP2 Update.sys - Fail
>Please define "Fail"...You mean boot hang?
Yes, I mean the stereotypical hard lock that applies to normal, last
good, safe and safe command bootups, and that is cleared by disabling
L1 and L2 cache in CMOS setup.
>> Old BIOS, Rev 0 CPU, SP2, SP1a Update.sys - OK
>> New BIOS, Rev 11 CPU, SP2, SP1a Update.sys - OK
>> New BIOS, Rev 11 CPU, SP2, SP2 Update.sys - OK
>> If it were Update.sys and not BIOS that rev'd up CPU, I'd expect:
>Suspect assumptions. Both might do microcode updates. I fail to see what
>the following list is or proposes beyond the list above.
Only if Update.sys and BIOS rev'd to exactly the same revision level,
would you see that mileage. Let's say Update.sys rev'd to 8, and BIOS
rev'd to 7, you'd get this...
New BIOS, no SP2 Update.sys in effect = rev 7
New BIOS, SP2 Update.sys in effect = rev 8
...whereas I get same rev if SP2's Update.sys is in effect or not.
Mind you, that could imply Update.sys looks for a lower threshold rev
and pushes that only if the existing level is lower, e.g...
SP2 Update.sys sees rev <7, dies trying to push rev 8
SP2 Update.sys sees rev 7, pushes rev 8 OK
SP2 Update.sys sees rev 8+, does nothing
>> Old BIOS, Rev 0 CPU, SP1a, SP1a Update.sys - OK
>> Old BIOS, Rev 0 CPU, SP2, SP2 Update.sys - Fail
>> Old BIOS, Rev 0 CPU, SP2, SP1a Update.sys - OK
>> New BIOS, Rev 0 CPU, SP2, SP1a Update.sys - OK
>> New BIOS, Rev 11 CPU, SP2, SP2 Update.sys - OK
>A nice little embarrassing side question: From what deficiency does one's
>system suffer by having CPU revision = 8 microcode versus the obviously
>superior<g> CPU revision = 11 microcode??? Both 'work' with SP2.
No idea. Until now, I've never had to care about the gory details of
Intel's bugfixes as pushed by BIOS on Intel's behalf - but now I'm
beginning to wonder how many of those "needs newwer BIOS" posts were
really "needs newer CPU bugfixes".
>What really needs to be done in SP1 and/or SP2 is test some known cases for
>say Northwood using the Intel boot version of the Frequency ID utility vs
>Win version and see if CPU revision = value is ever different.
Hmm... Northwood steppings and revs aren't the same as Prescott; each
time the higher cog changes, all lower cogs cease to relate to
previous values. For example, if the family number isn't the same,
comparing steppings is meaningless, etc.
>It also would be realy neat if there was some nice list somewhere of ALL the
>different microcode versions for each CPU stepping and what exactly the
>difference of each is.
Exactly. I can't find that at Intel, though that's the obvious place
to expect to find it - and Intel's usually good at that stuff,
Collins' complaints notwithstanding.
I can get good .pdf coverage of BIOS revisions for Intel's Bayfield
mobos, and which mobo batch numbers ship with which BIOS, and the BIOS
update details do say "apply newest CPU updates" or some such.
I can find good .pdf coverage of CPU errata on a per-stepping basis.
What I cannot find, is what errata are fixed by which microcode
revision patch, and which microcode revision patch is pushed by which
version of Intel's BIOS for the Bayfield mobos.
In fact, there's very little to suggest that BIOS pushing of microcode
revisions is happening. It's all "pay no attention to the man behind
the curtain", and then when SP2 catches them out, it's spun as "those
OEMs aren't supporting our processor properly". Hmm.
>> But the CPU rev went into effect as soon as I used the new BIOS,
>Well, yeah that's what happens with microcode in BIOS as it gets into the
>CPU during POST.
Yep.
>> even while still using the smaller Update.sys from SP1a.
>
>I wonder what 'bigger' job SP2's update.sys has to do?
Me2. It's all binary, so I can't tell if it's slabs of microcode to
be pushed, or extra raw programming logic.
>> I read some stuff on microcode updates that suggests at least some of
>> these have to be done early in POST, i.e. before RAM check.
>"some of these" What are "these"? Is a reword: 'some microcode updates
>might need to be done very early on in POST before RAM check'?
Yes; sorry to be vague on source, but it was arb links that Google
found - may have been forum posts of Linux project notes.
>> ... rev'ing CPU would blow out the CPU's context and make
>> it difficult, if not impossible, to resume protected mode processing,
>> return from function calls, retain register and MMX state, whatever.
>I'll bet it's tractable or at least it may have always been thought to be
>tractable until this came up<G>.
Heh heh... the man behind the curtain gets his revenge!
>> But FUD swirls around whether Prescott Rev 0 is in fact fit for use.
>It runs SP2 and does NOT blue screen all over the place. Now define "fit
>for use" beyond that.
Have you tested every aspect of SP2?
>Especially the apparent MS decision that non-bootability was
>preferrable to allowing arrival at that unfit for use state.
I don't think that was a design decision at all - I suspect this is
yer genuine "oops, code doesn't behave as expected" bug.
>I used the word 'decision' advisedly as the issue was known in June.
That's interesting; in which case, the decision may have been to leave
it like that. The question is, does the system really need whatever
Update.sys is doing, or not?
>> Intel's spin is that Prescott should receive appropriate microcode
>> updates from BIOS, otherwise should be considered unfit for use.
>What about 8 vs 11?
Quite!
>Interestingly apparently even some of Intel's own 865/875 mobo's didn't get
>the 8 level microcode until 11:59:59PM if not 12:01:00 AM.
Yes, I've watched that, and drew similar conclusions. Bought 2 x
Bayfields this week, and both are hitherto-unseen -409 batch, and in
boxes too (unusual for this particular distie). Stock purge?
>Given that then how did the others have a chance yet apparently
>some 8 microcode was in some 3rd party mobos pre Aug 1.
Well. that's the thing. Does Intel play favorites? Are OEMs expected
to visit Intel's fine print section on a regular basis, just in case
there's some earth-shattering news being mumbled there?
>There's more to this story and I'm VERY curious. Why else do you think I'm
>stalking the threads on this issue<g>?
Yep, I'm interested too.
>There is one school of thought that the mobo mfgs' job is DONE microcode
>wise once they EVER deliver ANY version of "production level microcode" for
>a given CPU+stepping. Once that's done then any further CPU errata is the
>responsibility of the OS and that's what update.sys does.
That makes sense in a way: The OS must run on the system, period. If
the OS "needs" something on the system, then it must not only supply
that change, but also make the change purely within the scope of the
OS (so it doesn't break system compat with other OSs with other needs)
>We need a precise definition of "production level microcode" which again is
>phraseology apparently from Intel used/quoted in Cari's early posts.
I interpret that to mean the baseline rev that was documented to be
required for proper Prescott support. But Prescott probably "grew up
in public", given that mobo dev has to parallel CPU dev a la the beta
blues. Mobos made months before Prescott release may be based on
earlier documentation with a lower (or no) microcode baseline.
It could also be interpreted to mean that earlier microcode revs were
never released, i.e. the first production rev was 7 or 8 (the
baselines required, possibly why MS dev'd on these).
In which case, Intel's spin is implying OEMs are using earlier revs
that weren't supposed to get out of the lab, like 1 thru 6. While in
reality, it looks as if BIOSs simply aren't aware of the need to push
microcode at all; they ASSume the CPU actually works as-is. Imagine!
Key questions: When did Intel declare Prescott documentation to be
final (i.e. "take these stone tablets down from the mount, and be
fruitful and multiply") and was the "needs mcode 7/8" part of that
spec, or later? If later, how much later? Released how, and to whom?
>> With this FUD in mind, I chose to echo the party line that running SP2
>> with SP1a's Update.sys should not be seen as a definitive solution,
>> and that the real solution is a BIOS that revs Prescott properly.
>That assume facts not in evidence not the least of which is our lack of a
>full understanding of what exactly update.sys actually does.
Yep; that's what I mean by FUD.
>If one follows all the early Cari posts and forum threads that led to a
>different forum thread that DID describe RC2 + Prescott boot hang in mid
>June.
>Now let's see...there was some thread I saw recently where somebody was
>claiming that some high percentage of recently shipped systems likely
>included 865/875+Prescott....must have been some wacko<g> or the fact that
>the issue was detected back in RC2 is OBVIOUS.
I'd have asserted that (i.e. that many recent systems would have
shipped with Prescott on those chipsets, at a time when it was thought
that only those chipsets were affected).
But I only hit the problem (and started a-hollerin') very soon after
RTM. I never tested any of the betas or RCs.
>> >What's update.sys's job???
>> That's a very good question ... My guess is it may be what
>> determines what processor is present, and thus which code pathways can
>> be used by the OS (e.g. SIMD3? SIMD2? SIMD1? 3DNow!? etc.)
>How does that 'guess' fit with the name update.sys and 'bigger' ?
Extra programming logic to test for SIMD3 support, etc.
>--------------- ----- ---- --- -- - - -
Dreams are stack dumps of the soul
>--------------- ----- ---- --- -- - - -
- Next message: cquirke (MVP Win9x): "Re: sp2 is a certified killer"
- Previous message: Randy: "Windows Update not loading fully - doesn't work"
- In reply to: Ron Reaugh: "Re: xp sp2 download, computer won't boot up now"
- Next in thread: Ron Reaugh: "Re: xp sp2 download, computer won't boot up now"
- Reply: Ron Reaugh: "Re: xp sp2 download, computer won't boot up now"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
