From owner-freebsd-current Wed Nov 12 12:19:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05309 for current-outgoing; Wed, 12 Nov 1997 12:19:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05301 for ; Wed, 12 Nov 1997 12:19:26 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id NAA22026; Wed, 12 Nov 1997 13:19:15 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd021997; Wed Nov 12 13:19:06 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA07092; Wed, 12 Nov 1997 13:19:04 -0700 (MST) From: Terry Lambert Message-Id: <199711122019.NAA07092@usr09.primenet.com> Subject: Re: make world time???/ To: handy@sag.space.lockheed.com (Brian N. Handy) Date: Wed, 12 Nov 1997 20:19:03 +0000 (GMT) Cc: roberto@keltia.freenix.fr, current@FreeBSD.ORG In-Reply-To: from "Brian N. Handy" at Nov 12, 97 09:49:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Throw away this. You don't need bounce buffers. > > This is probably the one thing that has never made any sense to me, in > spite of the fabulous missives people have written on it. (And I have > saved a few along the way...this is my own failing.) When do I need this? > Can this be explained in dirt-simple terms we, the unwashed masses, will > follow? (And as an example you can discuss Pentiums with boatloads of > memory. :-) You need bounce buffers to "bounce" request buffers from above 16M to below 16M when you are using a bus mastering controller on an ISA bus (since the ISA bus can only address the lower 16M of memory). If you make a request, and the buffer for the request is above 16M, then the controller will only be able to latch 24 bits of its address on the bus. If the driver doesn't catch the "request out of range", then on completion, the request will stomp some area equal to the buffer address & 0x00ffffff. This would be bad. You may also need to explicitly enable bounce buffers for systems which fail to comply with the standards they pretend to; specifically, there are a number of EISA chipsets (the HiNT chipset is the most notorious) that say they are EISA, but can only address 24 bits of memory from a bus master device. There has been at least one VLB chipset that has been claimed to have this problem. So, if you ave a "Pentium with boatloads of memory", but you plugged in your ISA Adaptec 1542 controller because you spent all your money on memory and can't afford an NCR/SymBIOS controller for the $45 or so they go for if you sop around, then you could experience the problem. Technically, it's possible to auto-detect these cards and defective chipsets by making a request using a buffer just above 16M, with a corresponding hole in low memory. Here's how the test works: 1) Allocate a buffer in low memory at some offset "x". 2) Allocate a buffer in high memory at 16M + x 3) Allocate a compare buffer somewhere. 4) Schedule a bus mastering DMA read into the low memory buffer; wait for it to complete 5) Copy the low memory buffer contents to the compare buffer 6) XOR some non-zero pattern into the low memory buffer 7) Copy the low memory buffer contents to the high memory buffer 8) Schedule a bus mastering DMA read into the low memory buffer; wait for it to complete 9) Compare the compare buffer contents against the low memory and high memory buffer contents. 10) If the compare buffer contents matches the low memory buffer contents, set the "USEBOUNCEBUFFERS" flag on the controller. This code hasn't been implemented, mostly because it applies to either antique or broken hardware (some would argue that ISA is broken -- like me -- so that it *only* applies to broken hardware. 8-)). Plus there's the benefit that it gets to confuse innocent victims about 4 times a month... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.