DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Rick LaMont <lamont@dotcsw.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Segmentation fault in rte_eal_hugepage_attach
Date: Wed, 17 Dec 2014 09:35:33 +0000	[thread overview]
Message-ID: <20141217093533.GA12400@bricha3-MOBL3> (raw)
In-Reply-To: <20141217041236.GB15643@www6.g1.pair.com>

On Tue, Dec 16, 2014 at 11:12:36PM -0500, Rick LaMont wrote:
> My DPDK application works fine when it's the primary process but crashes
> whenever --proc-type=secondary. The segmentation fault occurs in this call
> to mmap() within rte_eal_hugepage_attach():
> 
>         /*
>          * fdzero is mmapped to get a contiguous block of virtual
>          * addresses of the appropriate memseg size.
>          * use mmap to get identical addresses as the primary process.
>          */
>         base_addr = mmap(mcfg->memseg[s].addr, mcfg->memseg[s].len,
>                  PROT_READ, MAP_PRIVATE | MAP_FIXED, fd_zero, 0);
> 
> I've confirmed that addr and len match the values in rte_eal_hugepage_init()
> of the primary process (1 gigabyte). The target platform is a 32-bit embedded
> system running a Yocto distribution. I've confirmed that other applications
> such as mp_simple work as both primary and secondary on the same platform.
> The problem only occurs with a larger application to which I'm adding DPDK
> capabilities.
> 
> Any advice on how to troubleshoot this? I've been looking at it for a week
> already and am running out of ideas for things to test.
> 
> Thanks,
> 
> 
> Rick LaMont          | The storm that I thought would blow over
> Dot C Software, Inc. | Clouds the light of the love that I found

Hi,

getting multi-process support working on 32-bits is a lot more difficult than
with 64-bit due to the reduced addresss space range available. 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/<pid>/maps file for the secondary process to see what is
using the address range and if it's something you can do something about.
2) If you do find a free 1G range inside the secondary process address space, you
can try hinting that address to the primary process to see if it can map the
memory there, allowing the secondary process to duplicate. [See "base-virtaddr"
EAL option]

Regards,
/Bruce

  reply	other threads:[~2014-12-17  9:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-17  4:12 Rick LaMont
2014-12-17  9:35 ` Bruce Richardson [this message]
2014-12-18  3:54   ` Rick LaMont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141217093533.GA12400@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=lamont@dotcsw.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).