Re: xp sp2 download, computer won't boot up now
From: Ron Reaugh (rondashreaugh_at_att.net)
Date: 09/12/04
- Next message: chris: "unstallable program"
- Previous message: JimWaeħ: "Re: pagefile stuck at 1535 Mb won't set."
- In reply to: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 12 Sep 2004 02:54:35 GMT
"cquirke (MVP Win9x)" <cquirkenews@nospam.mvps.org> wrote in message
news:q1u6k01k1d98hqk04ftngfb2740tlq1khr@4ax.com...
> On Thu, 09 Sep 2004 04:01:47 GMT, "Ron Reaugh" <rondashreaugh@att.net>
> >"cquirke (MVP Win9x)" <cquirkenews@nospam.mvps.org> wrote in message
> >> 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"
>
> >> >> >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
>
> All very well, but unless that update.sys gets slipstreamed into SP2
> before SP2 is installed, it won't avoid the apparently system-killing
> result; an OS that can't boot in any way at all.
Right but that would address the claim by MS/Intel that after the workaround
running with no or SP1's update.sys could lead to instabilities.
Someone I think from HP/Compaq land has already claimed that MS has agreed
to a SP2a by 10/1.
> >> 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'd guess one of two possibilities:
>
> 1) Push mcode to Prescott
>
> In this simple scenario, Update.sys pushes a set rev to Prescott. If
> this were the case, you'd expect all SP2 Prescott stats to show the
> same rev, which would differ from that pushed by BIOS alone (i.e. when
> using no Update.sys, or SP1a's Update.sys)
Exactly.
> My testing points away from this, and tonight I'll pin that down
> further - I'm building 2 PCs with Bayfield 865G mobos (-409, June 2004
> BIOS) by Intel, and the Celerons are stepping C0 and D0. Pre-SP2
> testing shows these are C0, rev B and D0, rev E respectively.
>
> If this scenario were true, however, then you'd have to posit a cause
> of the crash that only applies with earlier mcode revs; presumably on
> the basis of an Intel erratum later mcode revs fix.
>
> 2) Test for mcode level, patch if not OK
>
> Is Prescott?
> - Is stepping 2 or 3 (C0)?
> - Yes; is mcode rev 7 or better?
> - Yes -> do nothing
> - No -> patch to rev 7 (hard lock)
> - Is stepping 4 (D0)?
> - Yes; is mcode rev 8 or better?
> - Yes -> do nothing
> - No -> patch to rev 8 (hard lock)
>
> That could be any generic bug in the mcode updating process, e.g.
> overlooking issues that arise when reving CPU microcode while CPU is
> in Protected Mode, or has to preserve registers or internal state
> flags, or has to maintain stack sanity, whatever.
>
> 3) Test CPU etc. but no mcode rev at all
>
> This is what I suspect is the case; that Update.sys doesn't push mcode
> rev at all, but is sensitive to mcode rev for one reason or another -
> again, most likely due to an Intel erratum that laster mcode fixes.
>
> The testing Update.sys does might involve L1/L2 cache awareness,
> looking for level of SIMD support, that sort of thing.
>
> >> 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?
>
> No; I'm speculating that if it were an mcode loader, what would have
> to apply for the test results that I see. I don't know if Update.sys
> is a mcode pusher or not, that's what my testing aims to find out.
Very eager to hear your conclusions.
> >> 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?
>
> Watch this space, for C0 rev B and D0 rev E
>
> Also, not sure if Prescott defends newer mcode against attempts to
> push a lower mcode. If it does, then SP2's attempt to push rev 7 to
> rev E will simply bounce off - and that would mean a generic failure
> in the rev update process could apply (in that only when an
> under-rev'd Prescott facilitates an update attempt, does it fail)
>
> >> I wonder how many of those "needs newwer BIOS" posts were
> >> really "needs newer CPU bugfixes".
>
> >YES, who is minding that store?
>
> Well, Intel's a powerful company and as a mobo OEM, you have to do
> whatever it takes to keep them happy. A motherboard that has an Intel
> CPU socket is useless without Intel CPUs (banking on VIA's cut-down
> alternative CPU is not a viable strategy).
>
> So it would not surprise me to find Intel has everyone lined up to
> deliver CPU mcode fixes on their behalf.
Then there needs to be some visibility to the community such that we can see
who is doing it right and not. There needs to be for each BIOS version a
list of microcode included.
> Check out how the most
> recent CPU "socket" passes the problem of bent CPU pins from Intel to
> the mobo vendor, even tho swapping mobo has a far more devastating
> impact on an OS installation than a CPU swap. That's a cynical,
> self-serving "f^%$ the user" change if ever I saw one.
>
> There's a story behind this, but it may be impossible to evaluate.
>
> >Well, the issue was whether update.sys ever pushes anything into a
> >Northwood that's detectable by 'Frequency ID'.
>
> Ah, yes - a nice large body of PCs to test and gather data from
>
> >> >> 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.
>
> It's extremely relevant if you are to assert that preventing the boot
> hang is all you need to test, when it comes to running XP SP2 (or XP
> in general) on Prescott that's insufficiently rev'd.
>
> If you told me today your Prescott rev 0 was solid on SP2, then
> mentioned next week that your newest games all crash, I'd wonder
> whether DirectX 9c's newest features were breaking on Pcott 0.
>
> >> Well. that's the thing. Does Intel play favorites?
>
> >And a favorite is NOT their own mobos?
>
> Well, YMMV with Intel's own Bayfields, depending on what -40x level
> they are. That determines BIOS version, among other things (i.e. an
> old -40x may not be same as a later -40x just because you did a BIOS
> catch-up). This week's Bayfields are -409, with June 2004 BIOS; if
> that is the "required" BIOS, then the date of that BIOS suggests it's
> just about impossible for anyone else to keep up.
>
> >Curious the number of Prescott systems that ran SP1 just fine while 'Freq
> >ID' showed = 0(no microcode).
>
> Quite - and posters who blame the user for SP2 installation failures
> should consider that. There's no way a happy SP0/1 on rev 0 could
> predict the need to update BIOS before installing SP2.
>
> Suggesting that we should automatically revise BIOS before any SP is a
> really bad idea, for two reasons:
> - a failed BIOS update can be catastrophic
I disagree totally. Before this issue for several years now the rule of
thumb has always been to flash the latest BIOS just like nay other DD or SW
update. Failed BIOS updates are a vastly overblown risk. In any case
"catastrophic"..just no.
> - don't commit multiple changes at once (e.g. new BIOS + new SP)
Unless they appear simultaneously in which case one should take the hint.
If not simultaneously then by my rule one would have already flashed the new
BIOS.
> That's why I get angry with those who assert "there's nothing wrong
> with SP2, it's just lame users who don't maintain thier PCs properly".
>
> >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?
>
> You're asking a larger Q here, and that is; how are CPU errata managed
> throughout the industry.
That's been the primary question I've been asking from the beginning.
> Generally these days it's only compiler, OS
> and maybe decvice driver writers who get close enough to the CPU to
> trip over the timing details etc. that these errata involve.
>
> That's aside from errata that apply below the digital layer of
> abstraction, i.e. analog-level issues about how far away the nearest
> charge-pump capacitor can be, etc. Those errata are significant to
> hardware developers rather than coders.
That is likely all true for the details of the microcode BUT not true for
the knowledge on a revision number.
> So I imagine what happens is that hware makers and low-level coders
> would be in Intel's information loop, probably subject to NDA, and
> they would build workarounds for these errata into thier products.
>
> In fact, this in itself can cause problems, if a revision fixes a bug
> in a way that breaks the workaround for that bug. This is a familiar
> toe-stubber that predates Prescott by a decade or few.
>
> Fixing errata may be required for future clock speeds. For example,
> let's say Pin 78 is documented to slew within 1.5 ms but actually
> takes 1.7 ms.
ns, I assume you mean.
> At 3GHz, that may fall within limits, but at 4.5GHz it
> may not - so by the time Intel makes 4.5GHz cores, you'd hope they'd
> have the fix built into the current stepping.
>
> If it wasn't built into that stepping (say, because the flaw was
> discovered too late) then the fix could be pushed as a mcode rev.
>
> >> 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>?
>
> Let's say testers did a lot of "does it crash the PC?" testing during
> the alpha and beta phases, then assumed those battles were sorted and
> concentrated on app testing for the rest of the beta. And as you
> know, Prescott shipped from June, quite late in the beta.
No, I got my Prescott 2.8s in April(Mar?) retail!
> Unless you were aware that SP2 changes the way low-level OS code works
> to the point of tripping over hware details, would you re-test the
> "does it crash the PC?" stuff on what appears to be just a newer point
> revision of a familiar CPU? In-house testers intimate with the
> development and source code might, but "outside" testers may not.
Not buying that overall.
> >> >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.
>
> I dunno, how many tests are there to do? Are there big lookup tables
> of test data involved? Is the test code written quickly in some
> language that creates code that is unlikely to crash, but bloated?
>
> I could easily see the code getting that bloated, even if not much was
> added, if they simply chose not to compact the code when they compiled
> it for some reason or another. It's hard to draw conclusions here.
- Next message: chris: "unstallable program"
- Previous message: JimWaeħ: "Re: pagefile stuck at 1535 Mb won't set."
- In reply to: cquirke (MVP Win9x): "Re: xp sp2 download, computer won't boot up now"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
