From owner-freebsd-hackers Mon Oct 27 23:14:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA02553 for hackers-outgoing; Mon, 27 Oct 1997 23:14:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA02544 for ; Mon, 27 Oct 1997 23:14:45 -0800 (PST) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z14) with ESMTP id IAA00074; Tue, 28 Oct 1997 08:14:33 +0100 (MET) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id IAA07569; Tue, 28 Oct 1997 08:27:05 +0100 (MET) Message-ID: <19971028082704.21011@gil.physik.rwth-aachen.de> Date: Tue, 28 Oct 1997 08:27:05 +0100 From: Christoph Kukulies To: Mike Smith Cc: Christoph Kukulies , Peter Dufault , freebsd-hackers@freefall.FreeBSD.org Subject: Re: mmap/mlock problem References: <19971027151139.61831@gil.physik.rwth-aachen.de> <199710280209.MAA00972@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199710280209.MAA00972@word.smith.net.au>; from Mike Smith on Tue, Oct 28, 1997 at 12:39:29PM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Oct 28, 1997 at 12:39:29PM +1030, Mike Smith wrote: > [memory-mapped peripheral's space appears to be cached] > > There is a 80186 on the board which communicates > > over some semaphores in the memory region with the outside world. > > You write a command into the location and that location must read > > as 0000 or FFFF if the board is ready or not resp.. Actually it's quite > > weird - I have the source of a DOS program which communicates with > > the board. (This is written for Borlandc/16 bit) > > Does the sample source attempt to invalidate the processor's cache for > the region? What does that mean? The sample source, you mean the vendors 16 bit program? It writes something to e.g. 0xca000 and reads back. If it reads the same value back it has written into it the sample program assumes it is not the semaphore region because reading back from that region would return a 0000 or ffff only (although something different (a command, e.g. 0x0103) is written into it. > > Is it possible that your BIOS is set to consider the address range > occupied by the card as cacheable? I was thinking of that too and checked it. I can find video shadow ram but that's not what is meant by 'cacheable'. I will look into the BIOS settings again for that. The portion of code behaves correctly when executed in the driver but executed in the user process (being root) it behaves differently. (accessing the memory region mapped by the driver). > > mike > -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de