From owner-freebsd-current Mon Mar 11 03:47:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA03124 for current-outgoing; Mon, 11 Mar 1996 03:47:35 -0800 (PST) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA03119 for ; Mon, 11 Mar 1996 03:47:31 -0800 (PST) Received: by Sisyphos id AA20705 (5.67b/IDA-1.5 for current@freebsd.org); Mon, 11 Mar 1996 12:46:36 +0100 Message-Id: <199603111146.AA20705@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 11 Mar 1996 12:46:35 +0100 In-Reply-To: Terry Lambert "Re: AMD doesn't like SNAP! (panic: unwire: page not in pmap)" (Mar 10, 12:21) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Terry Lambert Subject: Re: AMD doesn't like SNAP! (panic: unwire: page not in pmap) Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mar 10, 12:21, Terry Lambert wrote: } Before, when I suggested that a DMA be triggered as part of a probe } process on a per controller basis to determine if bounce buffers } were necessary, I neglected the non-working cache case. The cache } cases need to be considered at the same time because they need to } trigger similar controller/memory events in order to be detectable. } } When a bus master DMA occurs, there is supposed to be a cache } notification, and the L1 and L2 cache lines are supposed to be } invalidated or written back for the memory range in which the DMA } took place. Just for the record: The NCR driver does such a test, and it has detected hardware problems on a few occasions ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se