Date: Wed, 28 Jun 95 11:53:44 MDT From: terry@cs.weber.edu (Terry Lambert) To: ahill@netspace.net.au (Anthony Hill) Cc: tom@uniserve.com, jan@bagend.atl.ga.us, hackers@freebsd.org Subject: Re: keyboard locks up 950622-SNAP Message-ID: <9506281753.AA16462@cs.weber.edu> In-Reply-To: <Pine.BSF.3.91.950628181643.10753A-100000@stang.netspace.net.au> from "Anthony Hill" at Jun 28, 95 06:20:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The first try was just installing bin. After printing xxxx blocks > > > on debug window I got Fatal trap 12: page fault while in kernel mode. > > > > Sounds like hardware. Try disabling the cache. > > > What is the problem with FreeBSD and caches - I could not install, and > cannot rebuild a kernel with my cache turned on ! Turning it off is a > pretty easy fix - but I also take a pretty big performance hit. > > What does it mean if your cache is causing these problems ? It means you are running a bus master controller and the writes the controller does to memory using controller-initiated DMA are not causing the cache contents to be updated or invalidated because your cache controller or MMU are broken or incorrectly configured. On the off chance you are running PCI with a non-Triton chipset, it might mean that you have more than two bus mastering devices attempting DMA and pre-Triton chips are too stupid to arbitrate more than two (or more than one for some OPTi chipsets that haven't been fully identified by their owners). If you are running VESA, it might mean that you either have a VESA (VLB) motherboard that doesn't have "master slots" at all, or it may be that you've plugged a disk controller into a non-master slot. Or it may mean that you have a BIOS-enabled cache on a Cyrix or TI processer (based on the Cyrix chip masks) and have Cyrix aware BIOS on your motherboard. It's possible to work around many of these silently, at a performance penalty for non-broken (the majority) hardware, either by specifically flushing the cache using BINVD or by marking DMA pages as non-cacheable and flushing them when the operation is setup. Cyrix processers, you can turn off the cache and not tell anyone (like Linux does) because they don't support the non-cacheable bit correctly. If you have a broken cache, probably the most efficient workaround you can personally hope for is that of marking the pages for the target buffer non-cacheable, setting up and starting the DMA, THEN invalidating the current cache contents. This lets the invalidate be interleaved with the actual I/O operation (a concurrency boost). In many cases, if they are user supplied buffers, it's a good idea to reset the page as cacheable following the completion of the DMA operation. This is an addition of six compares (roughly; it may be less with a different implementation that the one I've considered) per I/O operation, all of which are nothing but overhead on most hardware for a marginal benefit (at best) on your hardware. Bottom line is: turn of you cache and run FreeBSD or run Linux and have it turn off your cache for you. Or don't use bus master DMA (ie: use IDE instead of SCSI), eat the overhead and concurrency hit you take for polled I/O, and leave the cache on. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506281753.AA16462>