Date: Fri, 28 Jul 1995 10:18:09 +0000 () From: Nik Clayton <nik@blueberry.co.uk> To: terry@cs.weber.edu (Terry Lambert) Cc: questions@freebsd.org Subject: Re: Pentiums and cache problems Message-ID: <199507281018.KAA00194@elbereth.blueberry.co.uk> In-Reply-To: <9507271854.AA07822@cs.weber.edu> from "Terry Lambert" at Jul 27, 95 12:54:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > However, with the internal cache on, I still get the occasional reboot,
> > particularly if there is extensive disk activity.
>
> What chipset does the board use?
>
> If Saturn/Neptune/Mercury, what is the chipset manufacture date? If
> prior to Apr 1994, request that they replace the chips with chips
> manufactured from masks produced later than Apr 1994.
I assume you mean the BIOS chipset?
On power up it announces itself as an AMI BIOS (c) 1994, with additions
by TriGem (who manufacture the machine) (c) 1995.
The BIOS name seems to be "Viper"
I've taken the hood off and had a look at the chips.
Two seem to be of interest. One, roughly 1.5cm square has a gold
coloured top and has the text
AMI BIOS
(c) 1993
Pentium CPU
PCA ISA BIOS
288542
on it.
The other is a larger chip, roughly 1.5in square, with the text
OPTi
Viper
82C557
Tawain 951215TE
> The typical problem where disabling the cache fixes the bug is that
> bus mastering DMA transfers to memory by disk controllers do not cause
> the cache contents to be updated or invalidated, and when the "stale"
> data is subsequently accessed, you have problems.
Thanks. I'll pass that on to TriGem. Their response yesterday was that
the OS was failing to pass instructions on the processor fast enough.
I tried to point out that they were talking crap. . .
> The other possibility is faulty electronics on the board itself
> preventing cache notification from operating.
>
> The least likely possibility (but it is still a possibility) is
> that your cache is actually failing, either because they used slower
> than needed parts or because of thermal breakdown from the inside
> the case teperate being too high. Are you running a fan on the
> Pentium itself as well as a fan on the case?
The Pentium has a fan on it (quite a large one in fact).
> Other than that, I can't think of anything serious that could be
> going on (off the top of my head).
For what it's worth, dmesg identifies the processor like so:
CPU: 100-MHz Pentium 815\\100 (Pentium-class CPU)
Origin = "GenuineIntel" Id = 0x525 Stepping=5
Features=0x1bf<FPU,VME,PSE,MCE,CX8,APIC>
real memory = 16384000 (4000 pages)
avail memory = 15007744 (3664 pages)
A thought. Does anyone have (or could they knock one up?) a DOS based
program which would show this bug? If I can demonstrate to TriGem that
the problem occurs on something other than a free OS (no offence
intended to the FreeBSD team, but you can guess their response when I
said I was running a free OS on the machine. . .) then I've probably got
a better chance of getting some action from them.
Failing that, does anyone know of any technical literature (maybe
product updates from Intel or something like that) which document the
fact that this problem exists.
My thanks to those people who've already taken the time to help me out
with this problem.
N
--
--+=[ Nik Clayton System Administration, Blueberry Design Ltd, ]=+--
--+=[ nik@blueberry.co.uk 1/9 Chelsea Harbour Design Centre ]=+--
--+=[ root@blueberry.co.uk London, SW10 0XE. Tel: 0171 351 3313 ]=+--
"It's two o'clock in the morning . . . do you know where your stack pointer is?"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507281018.KAA00194>