*BSD News Article 13597


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!spool.mu.edu!uunet!pipex!marble.uknet.ac.uk!uknet!cf-cm!paul
From: paul@isl.cf.ac.uk (Paul)
Newsgroups: comp.os.386bsd.bugs
Subject: Re: PROBLEMS WITH PATCHKIT 0.2.2 - Advice/help needed :-(
Message-ID: <1993Mar29.135244.11215@cm.cf.ac.uk>
Date: 29 Mar 93 13:52:42 GMT
References: <C4BLJ8.GA5@ns1.nodak.edu> <1993Mar26.201921.28420@cs.wisc.edu>
Sender: news@cm.cf.ac.uk (Network News System)
Organization: /usr/local/lib/rn/organisation
Lines: 45

In article <1993Mar26.201921.28420@cs.wisc.edu> jcargill@oka.cs.wisc.edu (Jon Cargille) writes:
>In article <C4BLJ8.GA5@ns1.nodak.edu> tjon@plains.NoDak.edu (Christopher C. Tjon) writes:
>
>>Keep in mind that I was having mysterious reboots and filesystem
>>problems prior to 0.2.2.  I find it difficult to believe that there
>>is anything wrong with my equipment.  It is all brand new and check
>>out on every diagnostic I can find to run on it.  Other os's such as
>>linux and sco 3.2.4 have had no troubles on it at all.
>
>Now *THAT* I find puzzling.  Shouldn't Linux and SCO also have
>problems with a motherboard that doesn't invalidate the cache
>correctly?

This has been puzzling me too. I've got a motherboard with cache
problems and the simplest solution is just to disable external cache. In
fact the performance decrease for me has been slight, I haven't noticed
it in use but a few simple timings show that kernel compiles are about a
minute slower -- I can put up with this to have a stable system.

Anyway, I also would have thought that Linux and SCO would suffer from
these problems but it doesn't appear that they do. I've heard nothing
from Linux users about such problems and I'd have thought there would be
many of them with similar hardware to 386bsd users. Even more perplexing
my dealer actually runs SCO on exactly the same hardware and doesn't see
these problems (I know him quite well so I trust what he says).

It seems that for some reason 386bsd is particularly sensitive to this
particular hardware fault. Thinking about it though, the only way I can
think of getting around this hardware problem would be to invalidate the
cache whenever DMA takes place. Perhaps that's what SCO do though. It
would obviously have a performance hit but on my particular board you
probably wouldn't notice since the cache doesn't cause a significant
performance increase anyway.

Fortunately I believe I've found a fixable problem with my board and I'm
waiting for the manufacturer to confirm this.

Just a few thoughts from a puzzled broken cache user.



-- 
  Paul Richards, University of Wales, College Cardiff

  Internet: paul@isl.cf.ac.uk