From owner-freebsd-hackers  Sun Mar 24 21:17:29 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id VAA19703
          for hackers-outgoing; Sun, 24 Mar 1996 21:17:29 -0800 (PST)
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA19683
          Sun, 24 Mar 1996 21:17:23 -0800 (PST)
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id VAA28302; Sun, 24 Mar 1996 21:16:48 -0800
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199603250516.VAA28302@GndRsh.aac.dev.com>
Subject: Re: Crash advice needed APPENDIX B
To: cau@cc.gatech.edu (Carlos Ugarte)
Date: Sun, 24 Mar 1996 21:16:47 -0800 (PST)
Cc: uhclem@nemesis.lonestar.org, hackers@FreeBSD.ORG, current@FreeBSD.ORG
In-Reply-To: <199603250452.XAA24485@oscar.cc.gatech.edu> from "Carlos Ugarte" at Mar 24, 96 11:52:33 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> 
> > > 7.	It has been suggested that I remove the cache.  I'll just
> > > 	mention that the cache and the board it is plugged-into were
> > > 	both replaced earlier and there was no change in failure rate.
> > > 	Further, this board/cache has no trouble with SCO UNIX,
> > > 	Windows '95 and Windows NT which have all run on it previously
> 
> [snip]
> 
> > Because SCO Unix, Windows 95 and Windows NT are all gross in the way
> > they handled bus master DMA disk controllers, they use a dedicated
> > buffer area that is marked uncacheable just so they can run on the
> > broken cache coherency motherboards.    Can you say totally defeat
> > the purpose of bus master DMA buy having the processor bcopy data
> > around...
> 
> Unfortunately, I've got one of these broken motherboards.  Is
> there a way to make FreeBSD behave the same way?  That is, to
> mark some memory block uncacheable (I guess this would be the
> bounce buffers area)?  I realize this would be counterproductive
> (decreased performance) in most cases, but in my case it might
> help (I am able to use my DMA busmaster car at lower CPU
> speeds, but I'd like to see the results of using a higher clock
> value).

I can only theorize here as I am not that familiar with the current
vm system in FreeBSD but... it should not be that major of a task
to mark the bounce buffer region as uncachable (simply 1 or 2 bits
per PTE in the page tables for this region) and then modify the
bounce buffer code to _always_ bounce the I/O through the buffer.

This would totally defeat bus mastered DMA, but it would infact allow
broken hardware to run.

It is going to take the likes of David Greenman or John Dyson to actually
go implement it, and I would rather see them spend there time working on fixing
critical software bugs that cause even good hardware to crash on occasion
that is effecting _everyone_.

Just my $1.00 worth...

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD