From owner-freebsd-arm@FreeBSD.ORG Wed Jan 28 14:15:32 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 764301065672 for ; Wed, 28 Jan 2009 14:15:32 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 331808FC22 for ; Wed, 28 Jan 2009 14:15:32 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id n0SEFVYh075472; Wed, 28 Jan 2009 08:15:31 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1233152131; bh=RILcY2Jh+sl5oSVrwEU0fo/hAxcoDuo4Mxpr6th LkyI=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=R4UNHJcECYP cvMMvmUk4rl6ExQeYlCUcVtvpXDb0V/D6Gf031qS3s00ILBjjg2qEM3l+7BcenU5oN3 5b/1oPYCDD3xAVgjqJMRVb1fCWkSDtnSc/vf8XBQ5BMRuRimfYnHh+2IlU92LM1aUno MVZayS+Y9ETDtnu48o9SsfH4YM= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id n0SEFVsG075471; Wed, 28 Jan 2009 08:15:31 -0600 (CST) (envelope-from tinguely) Date: Wed, 28 Jan 2009 08:15:31 -0600 (CST) From: Mark Tinguely Message-Id: <200901281415.n0SEFVsG075471@casselton.net> To: arm@freebsd.org, gjb@semihalf.com, tinguely@casselton.net In-Reply-To: <4980356A.4090403@semihalf.com> Cc: Subject: Re: svn commit: r186730 - in head... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 14:15:32 -0000 > I downloaded your patch and applied it (after a few modification to get rid of compile errors). However, when I boot the board with new code it hangs. The problem is with uma allocator for pv_entries. When there is no more entries available it create new ones. It includes mapping memory into kernel using pmap_qenter. And then recurrence starts, pmap_qenter calls pmap_kenter which tries to allocate pv_entry and so on. > I think that pv_entries for pmap_kenter should be allocated from some special pool to avoid this problem. Or some threshold could be set for uma allocator to force allocation of new pv_entries if number of free entries drops below the threshold, but I am not sure if it is possible without extending uma interface. > > Grzesiek Thank-you for the feedback. I should have anticipated that. If mapping the kernel mappings is the correct thing to do, we may add a map/virtual address entry to the md_page to remember the first mapping and then only manage on the duplicate kernel mapping. The extra check should be less overhead than managing every kernel mapping. --Mark Tinguely