From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>,
"Xu, HuilongX" <huilongx.xu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Cao, Waterman" <waterman.cao@intel.com>,
"Chen, WeichunX" <weichunx.chen@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [dpdk-dev] mutli process C/S model example init failed on xen dom0 with dpdk-16.07 rc2 package
Date: Mon, 18 Jul 2016 12:33:17 +0100 [thread overview]
Message-ID: <c2ff674c-8249-af55-a3c8-aa07001a7604@intel.com> (raw)
In-Reply-To: <5784D4DF.6070204@6wind.com>
Hi,
On 12/07/2016 12:30, Olivier MATZ wrote:
> Hi Huilong,
>
>
> On 07/12/2016 11:22 AM, Xu, HuilongX wrote:
>> Hi all,
>>
>> I run mutli procee C/S model example failed on xen dom0. Does anyone
>> give me some suggest how to debug it?
>>
>> Thanks a lot
>>
>> test environment:
>>
>> OS&kernel: 3.17.4-301.fc21.x86_64
>>
>> Gcc version: gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC)
>>
>> Package :dpdk.16.07-rc1.tar.gz
>>
>> Target: x86_64-native-linuxapp-gcc
>>
>> Compile switch: enable CONFIG_RTE_LIBRTE_XEN_DOM0
>>
>> Xen version:4.4.1
>>
>> Test cmdline and result:
>>
>> /examples/multi_process/client_server_mp/mp_server/mp_server/x86_64-native-linuxapp-gcc/mp_server
>>
>> -c f -n 4 --xen-dom0 -- -p 0x3 -n 2
>> EAL: Detected 72 lcore(s)
>> EAL: Probing VFIO support...
>> PMD: bnxt_rte_pmd_init() called for (null)
>> EAL: PCI device 0000:01:00.0 on NUMA socket 0
>> EAL: probe driver: 8086:1521 rte_igb_pmd
>> EAL: PCI device 0000:01:00.1 on NUMA socket 0
>> EAL: probe driver: 8086:1521 rte_igb_pmd
>> EAL: PCI device 0000:04:00.0 on NUMA socket 0
>> EAL: probe driver: 8086:10fb rte_ixgbe_pmd
>> EAL: PCI device 0000:04:00.1 on NUMA socket 0
>> EAL: probe driver: 8086:10fb rte_ixgbe_pmd
>> Creating mbuf pool 'MProc_pktmbuf_pool' [6144 mbufs] ...
>> Port 0 init ... Segmentation fault (core dumped)
>>
>
> I reproduced the issue on my platform. In my case, the crash occurs in
> rx_queue_setup():
>
> /* Free memory prior to re-allocation if needed. */
> if (dev->data->rx_queues[queue_idx] != NULL) {
> => em_rx_queue_release(dev->data->rx_queues[queue_idx]);
> dev->data->rx_queues[queue_idx] = NULL;
> }
>
> I don't this we should go in that area for the first rx queue
> initialization. I suspect it could be related to this commit:
> http://dpdk.org/browse/dpdk/commit/?id=ea0bddbd14e68f
>
> I think we cannot expect that memory is initialized at 0 when using
> Xen dom0. If I add the following (dirty) patch, I don't see a crash
> anymore:
I don't have a Xen system available right now, but I'm not sure I follow
here.
Are you saying that when we allocate pages/hugepages from Xen they are
not zeroed?
>
> --- a/lib/librte_eal/common/eal_common_memzone.c
> +++ b/lib/librte_eal/common/eal_common_memzone.c
> @@ -258,6 +258,8 @@ memzone_reserve_aligned_thread_unsafe(const char
> *name, size_t len,
> mz->flags = 0;
> mz->memseg_id = elem->ms -
> rte_eal_get_configuration()->mem_config->memseg;
>
> + memset(mz->addr, 0, mz->len);
> +
> return mz;
> }
>
The commit you are referring to does not touch the memzone reserve APIs,
only changes zmalloc and related APIs.
> --- a/lib/librte_eal/common/rte_malloc.c
> +++ b/lib/librte_eal/common/rte_malloc.c
> @@ -123,7 +123,13 @@ rte_malloc(const char *type, size_t size,
> unsigned align)
> void *
> rte_zmalloc_socket(const char *type, size_t size, unsigned align, int
> socket)
> {
> - return rte_malloc_socket(type, size, align, socket);
> + void *x = rte_malloc_socket(type, size, align, socket);
> +
> + if (x == NULL)
> + return NULL;
> +
> + memset(x, 0, size);
> + return x;
> }
>
> /*
>
>
> Sergio, could you have a look at it?
>
> Regards,
> Olivier
next prev parent reply other threads:[~2016-07-18 11:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 9:22 Xu, HuilongX
2016-07-12 11:30 ` Olivier MATZ
2016-07-18 11:33 ` Sergio Gonzalez Monroy [this message]
2016-07-18 11:49 ` Olivier Matz
2016-07-18 13:15 ` Sergio Gonzalez Monroy
2016-07-18 13:34 ` Thomas Monjalon
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=c2ff674c-8249-af55-a3c8-aa07001a7604@intel.com \
--to=sergio.gonzalez.monroy@intel.com \
--cc=dev@dpdk.org \
--cc=huilongx.xu@intel.com \
--cc=olivier.matz@6wind.com \
--cc=thomas.monjalon@6wind.com \
--cc=waterman.cao@intel.com \
--cc=weichunx.chen@intel.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).