From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www6.g1.pair.com (www6.g1.pair.com [66.39.3.166]) by dpdk.org (Postfix) with ESMTP id 057442A9 for ; Thu, 18 Dec 2014 04:54:23 +0100 (CET) Received: by www6.g1.pair.com (Postfix, from userid 8138) id 4A58317054; Wed, 17 Dec 2014 22:54:22 -0500 (EST) Date: Wed, 17 Dec 2014 22:54:22 -0500 From: Rick LaMont To: Bruce Richardson Message-ID: <20141218035422.GA1105@www6.g1.pair.com> References: <20141217041236.GB15643@www6.g1.pair.com> <20141217093533.GA12400@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141217093533.GA12400@bricha3-MOBL3> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Segmentation fault in rte_eal_hugepage_attach X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 03:54:23 -0000 > The most likely cause of failure in mapping the memory is that the range > requested is already used by another memory mapping in the processes address > space. Two possible paths to look at this: > 1) examine the /proc//maps file for the secondary process Brilliant advice, Bruce! This was indeed the cause. The secondary process had some shared libraries mapped right in the middle of the viable 1G range. The most expedient workaround was to link the primary process against those same shared libraries, as you advised Etai here: http://www.dpdk.info/ml/archives/dev/2014-April/001829.html Perhaps not the most sustainable solution... Thank you very much, Rick LaMont | After forty years of toil Dot C Software, Inc. | He just up and walked away