From owner-freebsd-threads@FreeBSD.ORG Wed Nov 19 13:24:48 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C31816A4CE for ; Wed, 19 Nov 2003 13:24:48 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED72443FBD for ; Wed, 19 Nov 2003 13:24:45 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hAJLOj1G026771; Wed, 19 Nov 2003 16:24:45 -0500 (EST) Date: Wed, 19 Nov 2003 16:24:45 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1069273626.93981.10.camel@blue.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Losing pages from a mmap in threaded app vs. non-threaded X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2003 21:24:48 -0000 On Wed, 19 Nov 2003, Sean McNeil wrote: > Hello all, > > I have an interesting problem. I've ported a device driver to FreeBSD > from Linux and all works just fine with the non-threaded application. > When I use threads, the first 8 pages of the map get removed from the > process vmspace. > > A trick is used to mmap different memory pools of the driver. There are > 3 of them and an offset is given to mmap to identify which one: > > 0x10000000 > 0x20000000 > 0x40000000 > > The buffer I see losing the first 8 pages is the one mmap'd with > > 0x40000000 > > I haven't looked into the other mmaps, as the above one is the most > important. mmap is called correctly and each page is returned > appropriately. Again, this works without threads. > > Is there some mmap region that threads uses that is conflicting with my > choice? Is there any known issue with mmap and threads? This problem > happens with libc_r.so, libkse.so, and libthr.so. > > The work I'm doing is split into driver/application and turnaround is > high to get the application people to recompile with different values > (in progress), so I thought asking here might answer my question sooner > than experimentation. > > All comments/replies are greatly appreciated, > Sean The thread libraries use mmap to map kern.usrstack as thread stacks and guard pages. I don't know how this would affect your driver. -- Dan Eischen