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.
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)
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.
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.
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)
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. 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
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.
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
- don't commit multiple changes at once (e.g. new BIOS + new SP)
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. 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.
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. 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.
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.
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.
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.
--------------- ------- ----- ---- --- -- - - - -
Sucess-proof your business! Tip #37
When given an NDA to sign, post it on your web site