Re: xp sp2 download, computer won't boot up now
From: Ron Reaugh (rondashreaugh_at_att.net)
Date: 09/09/04
- Next message: itsme: "AOL"
- Previous message: Ted Zieglar aka Rocky: "Re: tss.exe error?"
- In reply to: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Next in thread: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Reply: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 09 Sep 2004 04:01:47 GMT
"cquirke (MVP Win9x)" <cquirkenews@nospam.mvps.org> wrote in message
news:th4vj0dup06kk8r0gben68c346hgalb7u0@4ax.com...
> 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).
That sounds like a bug meaning that we should see a hotfixed update.sys
soon.
> >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.
Please supply more detail. What way does it seem to work in your testing?
> >> 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,
OK, so now your are saying that update.sys IS a microcode loader?
> 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
YES! Now can anyone report that update.sys ever changes the 'CPU revision
=' for a Prescott or any other CPU type? If the BIOS has the required 7[8]
level then what does update.sys leave it as?
> ...whereas I get same rev if SP2's Update.sys is in effect or not.
That seems to follow the reports that I've seen.
> 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...
And that process is broken for the Prescott.
> SP2 Update.sys sees rev <7, dies trying to push rev 8
Obviously a bug in update.sys's code or in the update.sys concept.
> SP2 Update.sys sees rev 7, pushes rev 8 OK
Has that ever been observed.
> SP2 Update.sys sees rev 8+, does nothing
Some have reported an 11 or B for very recent BIOSs so we got Prescott XP
SP2 running on various microcode levels?
> >> 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".
YES, who is minding that store?
> >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;
Of course.
> 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.
Well, the issue was whether update.sys ever pushes anything into a
Northwood that's detectable by 'Frequency ID'.
> >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.
YES, who is minding that store.
> 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.
HMMM is right.
> >> 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.
Where are the hackers when we need em(they're probably all off breakin the
encryption<g>)<G>?
> >> 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?
Not relevant. It doesn't hang during boot.
> >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?
What is clear is the SP2 RTM did NOT need a hard boot hang on Intel's latest
CPU.
There's gotta be more to this story.
> >> 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?
And a favorite is NOT their own mobos? I don't think so. I'm lookin at
something more like no one has been watching this store. Some mobo mfg got
an 8 level from the Intel's OEM CPU group and included it in a BIOS because
they had it. Behind the curtain and no responsibility and no checks and
balances may be the problem.
> 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.
The microcode distribution process has never been documented AFAIK.
> >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)
And how overall CPU microcode fits into that is a damn good question.
> >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).
Curious the number of Prescott systems that ran SP1 just fine while 'Freq
ID' showed = 0(no microcode).
> 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?
But IF that 7/8 declaration of finality means anything important then what
does todays 11/B mean? Why did they even bother to even build 11/B if 7/8
was sufficient?
> >> 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.
Let's see, if I were the manager of the SP2 testing group..then should I be
expecting early termination....Prescott+SP2 should have been a hipri June
test of RC2 INHOUSE! Same thing for the Intel mobo test group and RC2..who
is lookin for a job<g>?
There's gotta be more to this story!
> >> >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.
How many lines of code to check CPU type and stepping? More likely
something else OR just more microcode pages.
- Next message: itsme: "AOL"
- Previous message: Ted Zieglar aka Rocky: "Re: tss.exe error?"
- In reply to: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Next in thread: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Reply: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
