Archived from groups: comp.sys.ibm.pc.hardware.chips (
More info?)
On Fri, 10 Dec 2004 01:05:13 -0500, Tony Hill
>On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
>>On Wed, 08 Dec 2004 00:19:58 -0500, Tony Hill
>>>On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"
>The basic thing I would take away from this is just to avoid Intel
>motherboards. I've never been much of a fan, more expensive but
>without any improvement in quality.
That was my take, too; I used to prefer generic motherboards based on
Intel chipsets. What changed was a rash of capacitor failures across
a wide range of generic motherboards (Gigabyte, Jetway, DFI), plus
that Intel-branded motherboards dropped into the same price range as
the generics, plus their BIOS became less ideosyncratic.
>>>The extra L2 cache counts for about 30-35M transistors (6
>>>transistors per bit, 9 bits per bit due to ECC and 512KBytes
>>>+ some redundancy). Others are just used for testing and
>>>not actually enabled for normal use.
>>Aha! Think software that's more bloated but more reliable because
>>it's agregated from hi-level blocks, and think post-manufacturing
>>bugfixing CPUs via microcode pushed by BIOS or OS.
>>I expect some "slackness" where some stuff is left generalized a la
>>programmable logic array, to be comitted via microcode?
>To a certain extent yes, though the same is true for older P4's and
>the PIIIs before it.
I'm thinking that the trend is increasing, perhaps. A bit like the
way MS Office bloated up between '95 and '2000.
>>Intel's been a bit sly in shoving their problems onto other ppl, e.g.
>>1) BIOS to maintain and push microcode update revs - how many
>>"required BIOS updates" are actually CPU hotfixes? As it is, the
>>"blame" for SP2 vs. Prescott has been dumped on motherboard and BIOS
>>vendors, whereas a date check on Intel's own mobo Prescott readiness
>>(esp. when in-channel stock versions are also checked) is interesting.
>Hmm.. I hadn't seen that one before. It does seem like the sort of
>thing that really should have been fixed by the motherboard vendors
>with a BIOS update, after all revision 0 is REALLY early on in the
>development process and they had probably updated it before the chips
>ever shipped. This would be more an issue with people upgrading older
>motherboards to new processors without first updating their BIOS,
>which is always hit-and-miss.
It's more a matter of motherboard vendors trying to ship
Prescott-ready motherboards before Prescott itself was ready, perhaps.
We've seen this before; remember how some P55C-ready mobos would
wobble the clock speed on iP55C-233, because Intel changed the
electrical behavior of the 200/233MHz jumper? AFAICR what was pull-up
became pull-down, so if the mobo elecronic logic was same as iP54C,
the actual logic (voltage) level was left floating.
The question is: How soon/late did Intel finalize the microcode
revision level(s), and how effectively were these requirements
communicated to motherboard vendors?
One way to see into that, is to look at Intel's own mobo and BIOS revs
in Bayfield, and compare that to what was in the distributor's stock
at the time that Prescott started shipping here. I fed those details
to MS at the time of the SP2 vs. Prescott crisis, but can't remember
them now offhand - but I remember that even after Prescott was
standard, I'd still get served a Prescott-unready mobo rev at times.
>Of course, the article linked above with a bit light on tech details
I wrote it more in terms of the OS perspective, rather than the
hardware perspective. Not a lot more detail came to light in my
dealings with MS on this; I approached MS, Intel and (in my case)
Jetway, and only MS really fed back any tech detail.
In fact, most of the detail is conjectured from observation :-(
If you do a search at Intel's site for "microcode", e.g. if you wanted
to know what each microcode rev actually fixed, etc. you hit nothing -
it's like the whole process doesn't exist. You get great .pdf on
their own BIOS revs, and processor steppings, and mobo revs too (which
is distinct from BIOS) but nil below the stepping level of detail.
>and I couldn't really find just what the actual cause of the error
>was.
You can pin it down to Update.sys, which is larger in SP2 than SP1 and
(since I wrote that article early in the saga) which is now confirmed
to push microcode to the processor.
Speculation to why this is necessary, is that SP2 includes DirectX 9c,
which in turn has new floating-point pixel shading stuff. My guess is
that this uses (if available) the new SIMD, which has to be
microcode-rev'd up to work properly. This is the only reason I can
think of, why a Service Pack should care about processor rev.
The reason DirectX 9c is in what is ostensibly a security-orientated
SP2, is likely connected to MS's support policy for "old" versions,
which is geared to SP levels and release dates. I suspect it suits
them to push the latest version of subsystems such as WMP, IE, DirectX
etc. into each SP so that old versions of these can drop off the
support and patching maintenance map.
Speculation as to why Update.sys should lock up, starts from whether
it revs a processor that doesn't need rev (I seem to recall it does
not). If not, then all you need to look for are reasons why the
microcode update should lock the PC - and I'd suspect some sort of
processor state reset that loses context, and thus makes further
processing impossible. I read on a Linux-orientated site that some
microcode revs shouldn't be pushed after POST, for this reason.
You're more hooked into hardware (I dropped out of here until I needed
to come back to ask this question; I've been more involved in OS and
anti-malware stuff lately) so if you can find detail, I'd love to
know. I'm not much of a web maintainer (once I write a page, I seldom
go back to revise it) but if what detail there is is wrong, I'll fix.
>>2) Pins on mobo instead of CPU; if the pins bend, it's the mobo
>>vendor's problem. Too bad the user's impact from mobo swap
>>(OS PnP, activation etc.) is way higher than if it was just the
>>CPU that needed replacement.
>Fortunately this has turned out to be pretty much a non-issue. It
>seems like this might actually be less likely to end up with bent pins
>on the motherboard than on the processor.
I really, really hope so. As it is, I see plenty of old Socket 7 etc.
mobos where the plastic hooks for the HS/fan clips broke off.
>>In this sense, I'd think of the current overload effect that can
>>happen when today's mobos meet tomorrow's RAM densities. If that
>>fries the memory controller, Intel would rather have that as the
>>motherboard vendor's problem rather than a CPU warranty swap..
>Hmm.. I think you might be digging a bit too hard for conspiracy
>theories on this one, I don't think I've ever heard of memory
>densities overloading a memory controller.
No, but what does happen is that certain combinations of motherboard
and RAM don't work due to such issues, and that goes back to i820 etc.
It's easier for Intel to say "you need a better mobo" than "our
processor can't do that". Then again, Intel is heading into
Centrino-style CPU/chipset integration; if the current approach (big
dies with more trannies) is to hold, something has to be found for all
those trannies to do. Else making CPUs could get easy enough for
general chip makers (e.g.. nVidia et al) to climb in.
>>>Have you tried updating the BIOS on this board? Just a thought
>>Interesting; I haven't rolled those dice, but note the newer board
>>revs (up to -409, -405 being the Prescott-ready threshold) with
>>Prescott are running just as hot. Prescott Celeron may run 10C higher
>>than "old" Celeron, e.g. 57C rather than 47C, and Zone 2 is often only
>>5-10C behind. So; 47C, 37C is fine, but while 57C may be OK for
>>processor, 47C is less OK for Zone 2. I've seen Zone 2 crack 50C.
>The fact that the chips run hotter doesn't seem all that unusual,
>though it does seem pretty hot for the ambient air around the chip to
>be so hot. Normally with decent airflow you can keep the inside of a
>case pretty cool without much difficulties.
I haven't seen stock processors cooking up like this since PII-300
maxed out the .35u range, and even then, the rest of the box didn't
cook up. Then again, case makers hadn't tried so hard to regain the
smalller pre-ATX size by crowding the PSU deeper into the box.
>>>You might want to contact Intel tech support on this one. Chances are
>>>that if you have experienced this on a few boards than hundreds of
>>>other people have as well. Intel may have a solution to this already.
>>I've found it difficult to find an Intel support socket to plug such
>>formless questions into. I had an Intel marketing droid do a
>>touch-base (as in "feel free to email me if any queries") but a
>>synopsis of these concerns brought no response.
>Sadly this seems to be pretty much the norm these days. Unfortunately
>customers (in general) just are not willing to pay for support, so any
>company that tries to offer decent support either has to drop such
>notions or goes out of business.
I think tech-level support is a cost-effective way for vendors to
tackle this; effectively helps them to pass the buck <g> At one time,
Intel was better at this than MS, but their program became more and
more "small print taketh away", plus they shifted from Q&A at meetings
to no-feedback marketing push, that I lost interest.
MS still does little to communicate directly with small-volume techs
such as myself, though I think what's available on their web site is
way better, but in my case the MVP thing's been very good. In fact,
better comms with techs and builders is one of the things I've pushed
for, where the program has offered the chance to do so.
I've always liked AMD but mistrusted the motherboard chipsets I'd be
forced to build with (SiS, VIA). Noting that AMD's motherboard
chipsets usually use VIA for half the work. Has anything improved
there? What's nVidia's nForce track record been like so far?
>------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
>------------ ----- --- -- - - - -
Facebook
Twitter
Instagram