*BSD News Article 13732


Return to BSD News archive

Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!news.byu.edu!ns.novell.com!gateway.univel.com!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: PROBLEMS WITH PATCHKIT 0.2.2 - Advice/help needed :-(
Message-ID: <1993Mar30.212516.20745@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <C4BLJ8.GA5@ns1.nodak.edu> <1993Mar26.201921.28420@cs.wisc.edu> <1993Mar29.135244.11215@cm.cf.ac.uk>
Date: Tue, 30 Mar 93 21:25:16 GMT
Lines: 76

In article <1993Mar29.135244.11215@cm.cf.ac.uk> paul@isl.cf.ac.uk (Paul) writes:
>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.

This is not the only potential cause (or resoloution) of the problem; as
I have stated in a previous posting on the subject, there are broken
caches and there is broken code.

Currently the code can have problems even on "good" caches because the
pages used in DMA's are not marked "non-cachable".

The other soloution which was suggested to me (that I didn't repeat) by
Leonard N. Zubkoff was to use WBINVD to force a writeback; this is very,
very expensive, but would fix broken caches as well as making fixing the
VM system unncessary (I would prefer that it be necessary).  Note that
broken caches can also be fixed by lobotomizing them.

I would say thet 97-99% of all caches would work fine if the pages weren't
allowed to be cached through normal means.  The broken caches are definite
exceptions to the rule.

I suspect that something dealing with split memory (guaranteeing allocation
in the first 16M) and the cachable bit (guaranteeing no caching of DMA
target memory) has occurred or will occur in 0.2.  I'm not personally
going to tackle this unless I end up brick-walling it somewhere else
(like in shared library code), and it becomes convenient to do it for
other reasons.

Anyone who wants to tackle the problem given this start is welcome to do
so, but they should realize that whatever they do will be obsoleted in 0.2
(best case) or have to be redone (worst case) as a result of the VM changes
I keep hearing generalities about.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------