Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cyric CPU's




Mark J. Dulcey wrote in a message to Mike Bilow:

 MJD> 1.  The report about Windows NT is true.  The released
 MJD> version of NT 4.0  does it automatically, so you take a
 MJD> performance hit.

I don't have any direct information about Windows NT relative to the 6x86 other
than what I have already posted.  However, there is no way to change the
secondary cache from write-back mode to write-through mode in a way independent
of the particular motherboard and chipset, so I doubt that NT does so.  If
anything, NT would have to take the same general approach that the OS/2 "device
driver" that "fixes" the 6x86 problem does, which is to periodically execute an
invalidation instruction on the CPU.

 MJD> 2.  Cyrix is still working on the problem.  They're trying
 MJD> to create a  software patch.  Meanwhile, they have said they
 MJD> will replace the CPU of  anyone who asks with a newer, fixed
 MJD> version.  (They saw what happened to  Intel, after all.)

The problem will not ever be fixed.  The problem is the motherboard, not the
CPU.  What is being corrupted is the secondary cache on the motherboard, not
the primary cache inside the CPU.  The reason the Pentium works and the 6x86
does not is because the Pentium is actually slower on the cache control lines,
and the clock derivation would have to be changed to fix it.

 MJD> 3.  There is no evidence that the problem that Microsoft
 MJD> claims to have found has any effect on Linux.

The problem is operating system independent.  It will affect any 32-bit
operating system which has a sufficiently fast I/O subsystem.  OS/2 and Linux
are both definitely known to be affected.  NT 3.51 is not affected only because
its I/O subsystem is so pathetically slow, but NT 4.0 apparently is fast enough
to join the club.
 
-- Mike






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org