Intel Bayfield (ATX 865G); reliable? Prescott too hot?

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

I've been building PCs for a few years now, and since Socket 7 I have
preferred Intel motherboard chipsets (tho generally not Intel mobos).

I recently moved from generic 865G motherboards to using Intel's
Bayfield, which is a full-ATX based on that chipset.

I've found reliability to be more erratic than I'd previously
considered acceptable for motherboards. A couple of outright
failures, but more often it's been general flakiness (e.g. locking up
at temps other sample boards don't lock up, or locking up at
particular points in the MemTest suite).

Also, usually when a processor core is shrunk, the new chips will run
cooler at a given clock speed. Once again, Prescott has defied the
usual expectations; even the modest Celeron 2.4GHz tends to push what
Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
regularly locking up at 42C and others being happy at full temp.

What's been other ppl's mileage on this stuff?


>--------------- ---- --- -- - - - -
I'm baaaack!
>--------------- ---- --- -- - - - -
12 answers Last reply
More about intel bayfield 865g reliable prescott
  1. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Mon, 06 Dec 2004 00:45:44 +0200, "cquirke (MVP Win9x)"
    <cquirkenews@nospam.mvps.org> wrote:

    >I've been building PCs for a few years now, and since Socket 7 I have
    >preferred Intel motherboard chipsets (tho generally not Intel mobos).
    >
    >I recently moved from generic 865G motherboards to using Intel's
    >Bayfield, which is a full-ATX based on that chipset.
    >
    >I've found reliability to be more erratic than I'd previously
    >considered acceptable for motherboards. A couple of outright
    >failures, but more often it's been general flakiness (e.g. locking up
    >at temps other sample boards don't lock up, or locking up at
    >particular points in the MemTest suite).

    Intel's boards aren't really all that different from any other
    company, and not really any more reliable either. I don't know about
    this particular model, but all companies have the odd board that just
    doesn't match up with others.

    >Also, usually when a processor core is shrunk, the new chips will run
    >cooler at a given clock speed. Once again, Prescott has defied the
    >usual expectations;

    You are forgetting that the Prescott is NOT a core shrink at all, but
    rather a major overhaul of the whole chip design. The reason why the
    Prescott consumes more power than the Northwood before it is that
    Intel more than doubled the number of transistors (from ~55M to
    ~125M).

    On a per-transistor basis, Intel's Prescott shows just as much of a
    power consumption drop as previous die shrinks (ie "Willamette" P4 at
    180nm to "Northwood" P4 at 130nm), but when you factor in the large
    increase in transistor count, it's no surprise that the chip consumes
    more power.

    Of course, the question that none of us have been able to answer is
    why in the heck did Intel more than double the transistor count
    without a really noticeable improvement in performance?! But I
    digress..

    > even the modest Celeron 2.4GHz tends to push what
    >Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
    >regularly locking up at 42C and others being happy at full temp.

    I'm not quite sure where "Zone 2" is in this board, but it sounds like
    perhaps your not getting very much airflow through the case? It
    doesn't do much good to remove the heat from your processor if that
    heat isn't subsequently being moved out of the case.

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  2. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Mon, 06 Dec 2004 06:53:10 -0500, Tony Hill
    >On Mon, 06 Dec 2004 00:45:44 +0200, "cquirke (MVP Win9x)"

    >>I've been building PCs for a few years now, and since Socket 7 I have
    >>preferred Intel motherboard chipsets (tho generally not Intel mobos).
    >>I recently moved from generic 865G motherboards to using Intel's
    >>Bayfield, which is a full-ATX based on that chipset.

    >>I've found reliability to be more erratic than I'd previously
    >>considered acceptable for motherboards. A couple of outright
    >>failures, but more often it's been general flakiness

    >Intel's boards aren't really all that different from any other
    >company, and not really any more reliable either.

    What I didn't expect was, *less* reliability. Mobo failures, DoA, or
    turning up as baddie on swap testing were very rare before Bayfield,
    other than the capacitor failures that is.

    >I don't know about this particular model, but all companies have
    >the odd board that just doesn't match up with others.

    This isn't base on one baddie, but a few over several months.

    >>Also, usually when a processor core is shrunk, the new chips will run
    >>cooler at a given clock speed. Once again, Prescott has defied the
    >>usual expectations;

    >You are forgetting that the Prescott is NOT a core shrink at all, but
    >rather a major overhaul of the whole chip design. The reason why the
    >Prescott consumes more power than the Northwood before it is that
    >Intel more than doubled the number of transistors (from ~55M to
    >~125M).

    I know L2 counts a lot for that, but where did the rest go? Usually
    they either simplify at a mild performance hit, and/or add
    functionalities like new SIMD opcodes. Does HT take up so many
    trannies? If so, how does that affect no-HT Celeron? My mileage is
    based on Prescott Celeron, which as slightly faster base speed and L2
    pushed from 128k to 256k and not much else. In fact, deeper pipelines
    are said to lose most of what L2 gains, at current GHz.

    >Of course, the question that none of us have been able to answer is
    >why in the heck did Intel more than double the transistor count
    >without a really noticeable improvement in performance?!

    Law of Diminishing Returns? Moore predicted double the trannies every
    18 months, and it's the extrapolation of others that assume this means
    twice the speed. There's only so much you can do by increasing
    "processing about processing" - so I expect full multi-CPU dies next.

    >> even the modest Celeron 2.4GHz tends to push what
    >>Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
    >>regularly locking up at 42C and others being happy at full temp.

    >I'm not quite sure where "Zone 2" is in this board

    Exactlty - and neither manual nor board map show where these sensors
    are, nor could I find info at Intel's site.

    >perhaps your not getting very much airflow through the case? It
    >doesn't do much good to remove the heat from your processor if that
    >heat isn't subsequently being moved out of the case.

    I had to move from one case design that had PSU vertically in front of
    CPU, which I suspect created a hot pocket at top of case between the
    PSU and CPU assembly. Extra case fans didn't help.

    But even with the larger case design that has horizontal PSU above the
    mobo, I still see heat issues. As a non-overclocker who generally
    uses modest (Celeron) chips with boxed fans that have been fine until
    now, I'm surprised to see these sort of heat problems.


    >--------------- ---- --- -- - - - -
    I'm baaaack!
    >--------------- ---- --- -- - - - -
  3. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"
    <cquirkenews@nospam.mvps.org> wrote:

    >On Mon, 06 Dec 2004 06:53:10 -0500, Tony Hill
    >>On Mon, 06 Dec 2004 00:45:44 +0200, "cquirke (MVP Win9x)"
    >
    >>I don't know about this particular model, but all companies have
    >>the odd board that just doesn't match up with others.
    >
    >This isn't base on one baddie, but a few over several months.

    It may simply be that this model of board is a bad design, not just
    one sample of the board. If the problems are one of design, than that
    is entirely possible.

    >>You are forgetting that the Prescott is NOT a core shrink at all, but
    >>rather a major overhaul of the whole chip design. The reason why the
    >>Prescott consumes more power than the Northwood before it is that
    >>Intel more than doubled the number of transistors (from ~55M to
    >>~125M).
    >
    >I know L2 counts a lot for that, but where did the rest go? Usually
    >they either simplify at a mild performance hit, and/or add
    >functionalities like new SIMD opcodes.

    That's the real question now isn't it.. 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. Others still were
    added for the extra 11 instructions that make up SIMD. A few of them
    are also there for the 64-bit EM64T support (present but disabled on
    most chips).

    In the end though, it still seems like a LOT of extra transistors
    given the nearly non-existent performance gains (an occasional
    performance loses).

    > Does HT take up so many trannies?

    Hyperthreading was implemented in Northwood, and while it was slightly
    changed in Prescott (including the addition of two new instructions),
    it doesn't seem to have improved performance at all.

    > If so, how does that affect no-HT Celeron?

    AFAIK the Celeron uses the exact same core, just with hyperthreading
    disabled.

    > My mileage is
    >based on Prescott Celeron, which as slightly faster base speed and L2
    >pushed from 128k to 256k and not much else. In fact, deeper pipelines
    >are said to lose most of what L2 gains, at current GHz.

    The Prescott-based Celeron D chips are quite a bit faster, clock for
    clock, than the older Northwood-based Celeron chips. The old Celeron
    was SEVERELY data-starved due to the two-fold hit of small cache and
    low bus speed. The Celeron D doubled the L1 data cache, improved the
    trace cache, doubled the L2 cache and bumped up the bus speed. The
    end result was about a 20% improvement in per-clock performance
    relative to the old chip.

    Still, almost none of that improvement came from any changes in the
    processor core itself (though I suppose we should consider L1 cache
    and trace cache as part of the processor core).

    >>Of course, the question that none of us have been able to answer is
    >>why in the heck did Intel more than double the transistor count
    >>without a really noticeable improvement in performance?!
    >
    >Law of Diminishing Returns? Moore predicted double the trannies every
    >18 months, and it's the extrapolation of others that assume this means
    >twice the speed. There's only so much you can do by increasing
    >"processing about processing" - so I expect full multi-CPU dies next.

    As I do, and I'm sure that the diminishing returns is part of it.
    Still, AMD's Athlon64 die has less than twice as many transistors as
    the AthlonXP and it saw a fairly measurable improvement in
    performance. Admittedly that was mostly due to integrating the memory
    controller, but that simply raises the question of "why didn't Intel
    do that?!"... but I suppose that's another discussion that's already
    going on in this newsgroup :>

    >>> even the modest Celeron 2.4GHz tends to push what
    >>>Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
    >>>regularly locking up at 42C and others being happy at full temp.
    >
    >>I'm not quite sure where "Zone 2" is in this board
    >
    >Exactlty - and neither manual nor board map show where these sensors
    >are, nor could I find info at Intel's site.
    >
    >>perhaps your not getting very much airflow through the case? It
    >>doesn't do much good to remove the heat from your processor if that
    >>heat isn't subsequently being moved out of the case.
    >
    >I had to move from one case design that had PSU vertically in front of
    >CPU, which I suspect created a hot pocket at top of case between the
    >PSU and CPU assembly. Extra case fans didn't help.
    >
    >But even with the larger case design that has horizontal PSU above the
    >mobo, I still see heat issues. As a non-overclocker who generally
    >uses modest (Celeron) chips with boxed fans that have been fine until
    >now, I'm surprised to see these sort of heat problems.

    Have you tried updating the BIOS on this board? Just a thought, but I
    know a lot of these thermal sensors are VERY inaccurate and are really
    just taking a wild guess at temperature. Often time a manufacturer
    will have a bug in their temp sensor settings in the BIOS that causes
    incorrect temp readings?

    Along the same lines, do things inside the case (and/or heatsinks)
    seem to be getting physically hot? 47C is pretty warm and should be
    noticeable if the ambient air is that warm. On the other hand, if
    it's just the processor that they are measuring, 47C is rather cool
    and really shouldn't be a problem at all.

    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.

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  4. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Wed, 08 Dec 2004 00:19:58 -0500, Tony Hill
    >On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"

    >It may simply be that this model of board is a bad design, not just
    >one sample of the board. If the problems are one of design, than that
    >is entirely possible.

    Yep, could be - it gets rev'd enough, tho so far the baddies haven't
    all been of one particular -40x rev. Saw another one today; system is
    fine except it locks on POST after reset; after ATX power cycle, POSTs
    fine, etc. Same PSU and other goodies as usual.

    >>>Prescott consumes more power than the Northwood before it
    >>>Intel more than doubled the number of trans (~55M to ~125M).

    >>I know L2 counts a lot for that, but where did the rest go?

    >That's the real question now isn't it.. 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.

    Think XP SP2 vs. Prescott issue, where a Prescott (or P4-EE) left at
    Microcode rev 0 by BIOS cause SP2's Update.sys to lock up.

    ( http://cquirke.mvps.org/sp2intel.htm refers)

    I expect some "slackness" where some stuff is left generalized a la
    programmable logic array, to be comitted via microcode?

    >In the end though, it still seems like a LOT of extra transistors
    >given the nearly non-existent performance gains (an occasional
    >performance loses).

    On "losses", are you referring to the deeper pipelines?

    >> Does HT take up so many trannies?
    >> If so, how does that affect no-HT Celeron?

    >AFAIK the Celeron uses the exact same core, just with hyperthreading
    >disabled.

    Bloody typical - no wonder Intel pushes P4 so hard, it's money for jam

    >AMD's Athlon64 die has less than twice as many transistors as
    >the AthlonXP and it saw a fairly measurable improvement in
    >performance. Admittedly that was mostly due to integrating the memory
    >controller, but that simply raises the question of "why didn't Intel
    >do that?!"... but I suppose that's another discussion that's already
    >going on in this newsgroup :>

    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.

    2) Pins on mobo instead of CPU; if the pins bend, it's the mobo
    vendor's problem, and that may be another Intel mobo chipset sold
    (seeing as Intel won't have to cough that up as warranty fix). 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.

    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..

    >>But even with the larger case design that has horizontal PSU above the
    >>mobo, I still see heat issues. As a non-overclocker who generally
    >>uses modest (Celeron) chips with boxed fans that have been fine until
    >>now, I'm surprised to see these sort of heat problems.

    >Have you tried updating the BIOS on this board? Just a thought, but I
    >know a lot of these thermal sensors are VERY inaccurate and are really
    >just taking a wild guess at temperature. Often time a manufacturer
    >will have a bug in their temp sensor settings in the BIOS that causes
    >incorrect temp readings?

    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.

    >Along the same lines, do things inside the case (and/or heatsinks)
    >seem to be getting physically hot? 47C is pretty warm and should be
    >noticeable if the ambient air is that warm.

    Yes, a hand on the top back of case does feel hot :-)

    >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.

    Which is why I took my impressions here, to see whether I wasn't the
    only one with such issues. It's a certain amount of work to fully
    test and document an issue, and that's more difficult when several
    boards exhibit flakiness that are not a "hangin' offence" but
    nonetheless fall short of even PC Chips expectations.


    >--------------- ----- ---- --- -- - - -
    Dreams are stack dumps of the soul
    >--------------- ----- ---- --- -- - - -
  5. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
    <cquirkenews@nospam.mvps.org> wrote:

    >On Wed, 08 Dec 2004 00:19:58 -0500, Tony Hill
    >>On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"
    >
    >>It may simply be that this model of board is a bad design, not just
    >>one sample of the board. If the problems are one of design, than that
    >>is entirely possible.
    >
    >Yep, could be - it gets rev'd enough, tho so far the baddies haven't
    >all been of one particular -40x rev. Saw another one today; system is
    >fine except it locks on POST after reset; after ATX power cycle, POSTs
    >fine, etc. Same PSU and other goodies as usual.

    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. In this case it seems to be a
    drop in quality. These days I mostly recommend MSI for good quality
    and price, though I've had ok luck with the bargain-basement Chaintech
    board I have now (bought it on a whim because it was dirt-cheap).

    >>That's the real question now isn't it.. 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.
    >
    >Think XP SP2 vs. Prescott issue, where a Prescott (or P4-EE) left at
    >Microcode rev 0 by BIOS cause SP2's Update.sys to lock up.
    >
    >( http://cquirke.mvps.org/sp2intel.htm refers)
    >
    >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.

    >>In the end though, it still seems like a LOT of extra transistors
    >>given the nearly non-existent performance gains (an occasional
    >>performance loses).
    >
    >On "losses", are you referring to the deeper pipelines?

    Yup. There may be some other situations where you could take a
    performance hit, but the longer pipeline is the big one.

    >>> Does HT take up so many trannies?
    >>> If so, how does that affect no-HT Celeron?
    >
    >>AFAIK the Celeron uses the exact same core, just with hyperthreading
    >>disabled.
    >
    >Bloody typical - no wonder Intel pushes P4 so hard, it's money for jam

    Market segmentation. It's the magick behind Intel's profits.

    >>AMD's Athlon64 die has less than twice as many transistors as
    >>the AthlonXP and it saw a fairly measurable improvement in
    >>performance. Admittedly that was mostly due to integrating the memory
    >>controller, but that simply raises the question of "why didn't Intel
    >>do that?!"... but I suppose that's another discussion that's already
    >>going on in this newsgroup :>
    >
    >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.

    Of course, the article linked above with a bit light on tech details,
    and I couldn't really find just what the actual cause of the error
    was.

    >2) Pins on mobo instead of CPU; if the pins bend, it's the mobo
    >vendor's problem, and that may be another Intel mobo chipset sold
    >(seeing as Intel won't have to cough that up as warranty fix). 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.

    >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.

    >>Have you tried updating the BIOS on this board? Just a thought, but I
    >>know a lot of these thermal sensors are VERY inaccurate and are really
    >>just taking a wild guess at temperature. Often time a manufacturer
    >>will have a bug in their temp sensor settings in the BIOS that causes
    >>incorrect temp readings?
    >
    >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.

    >>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.

    >Which is why I took my impressions here, to see whether I wasn't the
    >only one with such issues. It's a certain amount of work to fully
    >test and document an issue, and that's more difficult when several
    >boards exhibit flakiness that are not a "hangin' offence" but
    >nonetheless fall short of even PC Chips expectations.

    Well, I'm afraid I'm out of ideas on this one. I haven't worked with
    the board, so I don't really know any specifics about it.

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  6. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
    <cquirkenews@nospam.mvps.org> wrote:

    >Think XP SP2 vs. Prescott issue, where a Prescott (or P4-EE) left at
    >Microcode rev 0 by BIOS cause SP2's Update.sys to lock up.
    >
    >( http://cquirke.mvps.org/sp2intel.htm refers)

    Thanks for the URL Chris - it's a good start point for SP2 troubles. OT
    for this thread, but have you come across the print server problem with
    SP2, where it exceeds the TCP/IP queue request count and purposely goes
    into heavy delay?

    I have it on a LAN Manager "print server" running Win95 (yeah I know
    but....) - SP2 just seems to go to sleep when a print is attempted or even
    a printer properties attempt. There doesn't seem to be a registry
    paramater - the only "fix" I've seen is a patch to a system file, which is
    a bit too ugly for my liking. Turning off the Firewall mitigates very
    slightly but the count and action seem to be hard coded in.

    Apparently it's breaking print servers from several mfrs but you'd think
    that M$ would not break their own stuff even if it *is* legacy.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
  7. 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)
    >------------ ----- --- -- - - - -
  8. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Fri, 10 Dec 2004 19:35:20 -0500, George Macdonald
    >On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"

    >>( http://cquirke.mvps.org/sp2intel.htm refers)

    >Thanks for the URL Chris - it's a good start point for SP2 troubles. OT
    >for this thread, but have you come across the print server problem with
    >SP2, where it exceeds the TCP/IP queue request count and purposely goes
    >into heavy delay?

    That sounds like the TCP/IP throttling issue; it usually impacts
    peer-to-peer file sharing apps. The intention is to limit the
    effectiveness of malware-infested PCs in spreading out malware.

    It's a controversial measure, as you can imagine; several scenarios
    that genuinely require that traffic are impacted. The fix is to
    revert or patch tcpip.sys (I think); a Google on ...

    XP SP2 TCP/IP throttling

    ....should pick up coverage of this. It does!

    http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#EHAA

    <paste>

    Limited number of simultaneous incomplete outbound TCP connection
    attempts

    Detailed description

    The TCP/IP stack now limits the number of simultaneous incomplete
    outbound TCP connection attempts. After the limit has been reached,
    subsequent connection attempts are put in a queue and will be resolved
    at a fixed rate. Under normal operation, when applications are
    connecting to available hosts at valid IP addresses, no connection
    rate-limiting will occur. When it does occur, a new event, with ID
    4226, appears in the system’s event log.

    Why is this change important? What threats does it help mitigate?

    This change helps to limit the speed at which malicious programs, such
    as viruses and worms, spread to uninfected computers. Malicious
    programs often attempt to reach uninfected computers by opening
    simultaneous connections to random IP addresses. Most of these random
    addresses result in a failed connection, so a burst of such activity
    on a computer is a signal that it may have been infected by a
    malicious program.

    </paste>

    http://www.broadbandreports.com/shownews/56054

    http://www.atrevido.net/blog/default.aspx?date=2004-09-22

    http://forum.osnn.net/archive/index.php/t-39958.html

    >I have it on a LAN Manager "print server" running Win95 (yeah I know
    >but....) - SP2 just seems to go to sleep when a print is attempted or even
    >a printer properties attempt. There doesn't seem to be a registry
    >paramater - the only "fix" I've seen is a patch to a system file, which is
    >a bit too ugly for my liking. Turning off the Firewall mitigates very
    >slightly but the count and action seem to be hard coded in.

    Doesn't sound like it fits? How many PCs on the LAN? Remember there
    are limits on incoming connections for "desktop" Windows:
    - 10: Win95xx, 98xx, NT Workstation, Windows 2000 Pro, WinXP Pro
    - 5: WinME, WinXP Home

    >Apparently it's breaking print servers from several mfrs but you'd think
    >that M$ would not break their own stuff even if it *is* legacy.

    Actually, SP2 does break some previously-advocated strategies, but IMO
    it's a good thing - because those strategies were fundamentally unsafe
    in the first place. When IE4 was trying to cadge market from
    Netscape, MS basically sold our heads on a platter to web devs; now
    that there's anger at just what web devs are allowed to do behind our
    back, SP2 sets about trying to stuff the genie back in the bottle.

    The irony is, Netscape's lack of these risky functionalities is a big
    factor in its comeback. Users like it because it does less (dangerous
    stuff) - tho it has holes of its own, and when stress-tested with
    invalid or exploitative IFrame etc. it's less solid than IE.


    >------------------ ----- ---- --- -- - - - -
    The rights you save may be your own
    >------------------ ----- ---- --- -- - - - -
  9. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sat, 11 Dec 2004 20:51:20 +0200, "cquirke (MVP Win9x)"
    <cquirkenews@nospam.mvps.org> wrote:

    >On Fri, 10 Dec 2004 19:35:20 -0500, George Macdonald
    >>On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
    >
    >>>( http://cquirke.mvps.org/sp2intel.htm refers)
    >
    >>Thanks for the URL Chris - it's a good start point for SP2 troubles. OT
    >>for this thread, but have you come across the print server problem with
    >>SP2, where it exceeds the TCP/IP queue request count and purposely goes
    >>into heavy delay?
    >
    >That sounds like the TCP/IP throttling issue; it usually impacts
    >peer-to-peer file sharing apps. The intention is to limit the
    >effectiveness of malware-infested PCs in spreading out malware.
    >
    >It's a controversial measure, as you can imagine; several scenarios
    >that genuinely require that traffic are impacted. The fix is to
    >revert or patch tcpip.sys (I think); a Google on ...
    >
    >XP SP2 TCP/IP throttling
    >
    >...should pick up coverage of this. It does!
    >
    >http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#EHAA
    >
    ><paste>
    >
    >Limited number of simultaneous incomplete outbound TCP connection
    >attempts
    >
    >Detailed description
    >
    >The TCP/IP stack now limits the number of simultaneous incomplete
    >outbound TCP connection attempts. After the limit has been reached,
    >subsequent connection attempts are put in a queue and will be resolved
    >at a fixed rate. Under normal operation, when applications are
    >connecting to available hosts at valid IP addresses, no connection
    >rate-limiting will occur. When it does occur, a new event, with ID
    >4226, appears in the system’s event log.
    >
    >Why is this change important? What threats does it help mitigate?
    >
    >This change helps to limit the speed at which malicious programs, such
    >as viruses and worms, spread to uninfected computers. Malicious
    >programs often attempt to reach uninfected computers by opening
    >simultaneous connections to random IP addresses. Most of these random
    >addresses result in a failed connection, so a burst of such activity
    >on a computer is a signal that it may have been infected by a
    >malicious program.
    >
    ></paste>
    >
    >http://www.broadbandreports.com/shownews/56054
    >
    >http://www.atrevido.net/blog/default.aspx?date=2004-09-22
    >
    >http://forum.osnn.net/archive/index.php/t-39958.html

    Yeah that's it - it's been discussed in various places but the problem is
    there is no fix! I haven't looked at his details yet because I'm not real
    happy with a 3rd party code patch but http://www.lvllord.de/ has it - only
    thing I've found so far.

    >>I have it on a LAN Manager "print server" running Win95 (yeah I know
    >>but....) - SP2 just seems to go to sleep when a print is attempted or even
    >>a printer properties attempt. There doesn't seem to be a registry
    >>paramater - the only "fix" I've seen is a patch to a system file, which is
    >>a bit too ugly for my liking. Turning off the Firewall mitigates very
    >>slightly but the count and action seem to be hard coded in.
    >
    >Doesn't sound like it fits? How many PCs on the LAN? Remember there
    >are limits on incoming connections for "desktop" Windows:
    > - 10: Win95xx, 98xx, NT Workstation, Windows 2000 Pro, WinXP Pro
    > - 5: WinME, WinXP Home

    What doesn't fit? This is our "downstairs printer" which two people use
    and it's been working fine for years on our LAN, including with WinXP SP1
    as a client. There's something about LAN Manager printing, possibly linked
    to Lexmark's connection method, which causes a burst of TCP/IP packets...
    which hits the limit. M$'s suggestion to "stop the application" is
    asinine... because it's *their* application and there's no way to stop the
    damned thing: right click on the printer icon and the bloody WinXP SP2
    system goes into a coma. It *can't* be stopped... <tap><tap><tap>........

    From what I gather, this is affecting print server boxes from various mfrs
    and is going to require firmware upgrades for them... *if* they are still
    "supported" by said mfr. At least with SP2's DEP, you can turn it off
    selectively or globally; with this you can't even roll back to SP1 on a new
    system.

    >>Apparently it's breaking print servers from several mfrs but you'd think
    >>that M$ would not break their own stuff even if it *is* legacy.
    >
    >Actually, SP2 does break some previously-advocated strategies, but IMO
    >it's a good thing -

    It breaks a lot of things - I've got others like Symantec's Anti-Virus
    Corporate Edition V8.01 causing blue screens on shutdown (remember WinXP is
    not supposed to err, blue-screen). That one seems to be something to do
    with the floppy drive check on shutdown - Symantec promises a fix by end
    January... IFF you have their Gold Insurance. In the meantime you're on
    your own. Oh and apparently scheduled updates of virus signatures is
    broken as well - not something I personally want or recommend anyway.

    As for the LAN Manager printing, M$ claims that "Under normal operation,
    when applications are connecting to available hosts at valid IP addresses,
    no connection rate-limiting will occur." It would be nice if they could
    elaborate on what is a "valid IP address" - apparently intra-domain does
    not count!

    IMO SP2 is the biggest cock-up that's been foisted on the computing
    community to date... only demonstates quite clearly how ill-conceived the
    whole Windows system really is. A U-turn on what is and is not allowed at
    this stage is, quite understandably, causing chaos. Also quite interesting
    that this FU is free, when it's the kind of thing which would have been a
    pay-for upgrade.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
  10. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sat, 18 Dec 2004 17:29:50 +0200, "cquirke (MVP Win9x)"
    <cquirkenews@nospam.mvps.org> wrote:

    >On Mon, 13 Dec 2004 03:04:06 -0500, George Macdonald
    >>On Sun, 12 Dec 2004 21:52:22 +0200, "cquirke (MVP Win9x)"
    >>>On Sun, 12 Dec 2004 02:00:32 -0500, George Macdonald
    >
    >>>>>XP SP2 TCP/IP throttling
    >
    >>>I've heard of swapping out TCPIP.SYS, presumably with a "fixed" or
    >>>older version (e.g. SP1). Dunno if there are settingsware fixes.
    >
    >>What I've read - didn't keep refs - is that there is no registry "tweak"...
    >>hard coded, which is unforgivable in retrospect.
    >
    >In the context of a post-penetration defence, it would have to be
    >hard-coded rather than "Simon Says Let Me Spam" settingsware.

    Firewall and DEP are both fully controllable.<shrug> They must have known
    about this before release -- may even be one of the issues which delayed
    the thing for so long. Just something else for IETF to snigger over if you
    ask me.;-)

    >>It's not really the printer - it's the WinXP client which is bursting
    >>TCP/IP packets, to the server, past its "allotted" limit. A "netstat -no"
    >>shows the "flood" clearly - dunno if it's the "server", which is an old
    >>Pentium w. Win95B, which is just slow or if its the Lexmark connection
    >>scheme which is the basic cause.
    >
    >AFAIK the TCP/IP throttling things doesn't go about the size of
    >traffic, it's about the number of (unsolicited?) connections. If it
    >were an anti-spam equivalent, it would let you send a 10M message, but
    >not a 100k message to 100 different recipients.

    AIUI the throttling I'm talking about is to do with the number of
    oustanding (unacknowledged ?) TCP/IP packets a client is allowed to issue
    before it is forced to go "lazy"... which would seem to indicate an
    assumption that said client is a potential infector. The kind of thing
    this would protect against on a LAN is precisely what happened to us a year
    or so ago with a worm (mydoom or sasser ?) picked up outside the office by
    a laptop.

    >>>No question, there are several incompats and issues; SP2 is
    >>>effectively a new OS subversion, so there's all the pain of an OS
    >>>upgrade. Hassles fall into two categories; where apps are doing risky
    >>>things that SP2 aims to prevent, and other issues.
    >
    >>As a user, there is a certain expectation that on an OS upgrade
    >
    >...and SP2 isn't supposed to be as "deep" as that, which is why it's a
    >nasty shock to find it frets about processor microcode revision...

    As above, it's becoming evident why it took so long to get out and possibly
    the long delays with WinXP-64.

    >>>I haven't heard of that as a generic problem, or even a specific av
    >>>product problem come to that. However, we do see lots of hassles when
    >>>SP2 is installed over active malware, and several malware do clobber
    >>>access to av sites, av updates, or the av app itself.
    >
    >>There was no malware involved apart from SP2 and Symantec.:-)
    >
    >No history of malware? I ask, because the evil that malware does can
    >live after its destruction (many malware defences against av and
    >cleanup tools are settingsware, requiring no ongoing malware presence)

    A fresh install to a just-built system.

    Oh and here's another unfathomable idiocy in SP2: AYK it does not install
    a Java VM. Now if you install Sun's Java plugins for another browser and
    also allow it to add the IE plugin, the M$ VM gets installed and activated
    *BUT* it's the "vulnerable" pre-April '03 VM... so if you turn on Automatic
    Updates it wants to download and install the fixed IE VM. YTF did they not
    put the fixed VM in the installable set?... utter madness?...
    incompetence?... malevolence?.........

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
  11. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sun, 19 Dec 2004 01:28:19 -0500, George Macdonald

    >Oh and here's another unfathomable idiocy in SP2: AYK it does not install
    >a Java VM. Now if you install Sun's Java plugins for another browser and
    >also allow it to add the IE plugin, the M$ VM gets installed and activated

    It does? By what? From what I see, the Sun Java VM is available from
    IE, but there's no MS VM present. And yes; Sun's Java VM has
    exploitable holes, so you have to ensure that's updated too :-p

    >*BUT* it's the "vulnerable" pre-April '03 VM... so if you turn on Automatic
    >Updates it wants to download and install the fixed IE VM. YTF did they not
    >put the fixed VM in the installable set?... utter madness?...
    >incompetence?... malevolence?.........

    Legal constraints, perhaps?

    SP1a differs from SP1 in only one respect; it has the MS VM ripped
    out, as mandated by the judgement from Sun vs. MS. That prohibits MS
    from distributing thier VM, and as you can see, that complicates the
    process of MS "fixing" their VM without "distributing" it.


    >-------------------- ----- ---- --- -- - - - -
    "If I'd known it was harmless, I'd have
    killed it myself" (PKD)
    >-------------------- ----- ---- --- -- - - - -
  12. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sun, 19 Dec 2004 17:27:53 +0200, "cquirke (MVP Win9x)"
    <cquirkenews@nospam.mvps.org> wrote:

    >On Sun, 19 Dec 2004 01:28:19 -0500, George Macdonald
    >
    >>Oh and here's another unfathomable idiocy in SP2: AYK it does not install
    >>a Java VM. Now if you install Sun's Java plugins for another browser and
    >>also allow it to add the IE plugin, the M$ VM gets installed and activated
    >
    >It does? By what? From what I see, the Sun Java VM is available from
    >IE, but there's no MS VM present. And yes; Sun's Java VM has
    >exploitable holes, so you have to ensure that's updated too :-p

    Well I'm not going to retrace my steps but the "Microsoft VM" shows in IE's
    Options/Advanced tab after installing the Sun Java Runtime Environment and
    selecting to apply it to Mozilla and IE - no idea whether it was there
    before or not but according to the "rules" it should not have been...
    certainly now, Windows Update shows that fix 816093 is required:
    http://www.microsoft.com/technet/security/bulletin/MS03-011.mspx

    On further checking it would appear that maybe neither Sun nor M$ was
    responsible for the Microsoft VM getting loaded - no trace of it on the
    WinXP SP2 CD. Musta been somebody else:-)... maybe the nVidia Web-based
    interface to their Network Access Manager? This is a nForce3 chipset mbrd.

    >>*BUT* it's the "vulnerable" pre-April '03 VM... so if you turn on Automatic
    >>Updates it wants to download and install the fixed IE VM. YTF did they not
    >>put the fixed VM in the installable set?... utter madness?...
    >>incompetence?... malevolence?.........
    >
    >Legal constraints, perhaps?

    It would appear so.

    >SP1a differs from SP1 in only one respect; it has the MS VM ripped
    >out, as mandated by the judgement from Sun vs. MS. That prohibits MS
    >from distributing thier VM, and as you can see, that complicates the
    >process of MS "fixing" their VM without "distributing" it.

    Windows Update now says that it wants to download and install the fix - so
    a fix, which is really a replacement distribution is OK?<shrug> The bottom
    line is that 3rd parties are allowed to continue to distribute a flawed M$
    VM without hope of the fixed version getting to them, while M$ will supply
    the fix as an Update. I just find this whole situation farcical.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Ask a new question

Read More

CPUs Intel Motherboards