[lng-odp] [Bug 3611] ODP linux generic fails on AArch64 in non-ABI-compat mode
https://bugs.linaro.org/show_bug.cgi?id=3611 Maxim Uvarov changed: What|Removed |Added CC||maxim.kuvyr...@linaro.org --- Comment #5 from Maxim Uvarov --- On connect we figured out that it's clang issue and placed workaround patch here: https://projects.linaro.org/projects/ODP/issues/ODP-661 Waiting some confirmation from tool chain team. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [lng-odp] Bug 3657
Yes, it is.
The error is the same. I did replied that the only difference I see is with
Ubuntu version and different minor version of mellanox driver.
On Wed, Mar 28, 2018, 07:29 Bill Fischofer
wrote:
> Thanks for the update. Sounds like you're already using DPDK 17.11?
> What about Mellanox driver level? Is the failure the same as you
> originally reported?
>
> From the reported error:
>
> pktio/dpdk.c:1538:dpdk_start():Queue setup failed: err=-12, port=0
> odp_l2fwd.c:1671:main():Error: unable to start 0
>
> This is a DPDK PMD driver error reported by rte_eth_rx_queue_setup().
> In the Mellanox PMD (drivers/net/mlx5/mlx5_rxq.c) this is the
> mlx5_rx_queue_setup() routine. The relevant code seems to be this:
>
> if (rxq != NULL) {
> DEBUG("%p: reusing already allocated queue index %u (%p)",
> (void *)dev, idx, (void *)rxq);
> if (priv->started) {
> priv_unlock(priv);
> return -EEXIST;
> }
> (*priv->rxqs)[idx] = NULL;
> rxq_cleanup(rxq_ctrl);
> /* Resize if rxq size is changed. */
> if (rxq_ctrl->rxq.elts_n != log2above(desc)) {
> rxq_ctrl = rte_realloc(rxq_ctrl,
> sizeof(*rxq_ctrl) +
> (desc + desc_pad) *
> sizeof(struct rte_mbuf
> *),
> RTE_CACHE_LINE_SIZE);
> if (!rxq_ctrl) {
> ERROR("%p: unable to reallocate queue index %u",
> (void *)dev, idx);
> priv_unlock(priv);
> return -ENOMEM;
>}
> }
> } else {
> rxq_ctrl = rte_calloc_socket("RXQ", 1, sizeof(*rxq_ctrl) +
> (desc + desc_pad) *
> sizeof(struct
> rte_mbuf *),
> 0, socket);
> if (rxq_ctrl == NULL) {
> ERROR("%p: unable to allocate queue index %u",
>(void *)dev, idx);
>priv_unlock(priv);
> return -ENOMEM;
> }
> }
>
> The reported -12 error code is -ENOMEM so I'd say the issue is some
> sort of memory allocation failure.
>
>
> On Wed, Mar 28, 2018 at 8:43 AM, gyanesh patra
> wrote:
> > Hi Bill,
> > I tried with Matias' suggestions but without success.
> >
> > P Gyanesh Kumar Patra
> >
> > On Mon, Mar 26, 2018 at 4:16 PM, Bill Fischofer <
> bill.fischo...@linaro.org>
> > wrote:
> >>
> >> Hi Gyanesh,
> >>
> >> Have you had a chance to look at
> >> https://bugs.linaro.org/show_bug.cgi?id=3657 and see if Matias'
> suggestions
> >> are helpful to you?
> >>
> >> Thanks,
> >>
> >> Regards,
> >> Bill
> >
> >
>
[lng-odp] [Bug 3690] New: fdserver process interferes with signal handling
https://bugs.linaro.org/show_bug.cgi?id=3690
Bug ID: 3690
Summary: fdserver process interferes with signal handling
Product: OpenDataPlane - linux- generic reference
Version: master
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: Shared Memory
Assignee: christophe.mil...@linaro.org
Reporter: janne.pelto...@nokia.com
CC: lng-odp@lists.linaro.org
Target Milestone: ---
The SHM implementation forks a child process that will stay in the same process
group as the parent and will thus receive the signals sent to the group.
One situation where this happens is when an ODP application is run in a shell
and ctrl-C is pressed. An application may set a signal handler to handle ctrl-C
presses in some controlled way, but now there are two problems caused by the
fdserver:
1) The signal handler set by the application runs also in the context of the
fdserver process. The handler may misbehave because the environment in the
fdserver process can be different than in the application controlled processes.
2) Even if the signal handler runs correctly in the fdserver process context,
the main loop of fdserver is not prepared to have its accept() call interrupted
by a signal, causing fdserver to exit.
I bumped into this when wondering about annoying error messages that I got when
stopping the fpm example application of OFP. Problem 1) caused the signal
handler to segfault and if that is fixed in fpm (by doing less in the handler)
then problem 2) would still cause the same error messages.
I am not sure what the right fix would be. Maybe fdserver should do setsid() to
detach itself from the parent's process group, or maybe not because then it
could not output its error messages to the terminal anymore. Or maybe it should
just mask a bunch a signals.
I think fdserver should at least handle EINTR errors so that an application
like fpm can try to handle the rest. This would suffice (some indentation fixes
included):
diff --git a/platform/linux-generic/_fdserver.c
b/platform/linux-generic/_fdserver.c
index 065736f0..af9ca4a0 100644
--- a/platform/linux-generic/_fdserver.c
+++ b/platform/linux-generic/_fdserver.c
@@ -559,8 +559,11 @@ static void wait_requests(int sock)
addr_sz = sizeof(remote);
c_socket = accept(sock, (struct sockaddr *)&remote, &addr_sz);
if (c_socket == -1) {
- ODP_ERR("wait_requests: %s\n",
strerror(errno));
- return;
+ if (errno == EINTR)
+ continue;
+
+ ODP_ERR("wait_requests: %s\n", strerror(errno));
+ return;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: [lng-odp] Bug 3657
Thanks for the update. Sounds like you're already using DPDK 17.11?
What about Mellanox driver level? Is the failure the same as you
originally reported?
>From the reported error:
pktio/dpdk.c:1538:dpdk_start():Queue setup failed: err=-12, port=0
odp_l2fwd.c:1671:main():Error: unable to start 0
This is a DPDK PMD driver error reported by rte_eth_rx_queue_setup().
In the Mellanox PMD (drivers/net/mlx5/mlx5_rxq.c) this is the
mlx5_rx_queue_setup() routine. The relevant code seems to be this:
if (rxq != NULL) {
DEBUG("%p: reusing already allocated queue index %u (%p)",
(void *)dev, idx, (void *)rxq);
if (priv->started) {
priv_unlock(priv);
return -EEXIST;
}
(*priv->rxqs)[idx] = NULL;
rxq_cleanup(rxq_ctrl);
/* Resize if rxq size is changed. */
if (rxq_ctrl->rxq.elts_n != log2above(desc)) {
rxq_ctrl = rte_realloc(rxq_ctrl,
sizeof(*rxq_ctrl) +
(desc + desc_pad) *
sizeof(struct rte_mbuf *),
RTE_CACHE_LINE_SIZE);
if (!rxq_ctrl) {
ERROR("%p: unable to reallocate queue index %u",
(void *)dev, idx);
priv_unlock(priv);
return -ENOMEM;
}
}
} else {
rxq_ctrl = rte_calloc_socket("RXQ", 1, sizeof(*rxq_ctrl) +
(desc + desc_pad) *
sizeof(struct rte_mbuf *),
0, socket);
if (rxq_ctrl == NULL) {
ERROR("%p: unable to allocate queue index %u",
(void *)dev, idx);
priv_unlock(priv);
return -ENOMEM;
}
}
The reported -12 error code is -ENOMEM so I'd say the issue is some
sort of memory allocation failure.
On Wed, Mar 28, 2018 at 8:43 AM, gyanesh patra wrote:
> Hi Bill,
> I tried with Matias' suggestions but without success.
>
> P Gyanesh Kumar Patra
>
> On Mon, Mar 26, 2018 at 4:16 PM, Bill Fischofer
> wrote:
>>
>> Hi Gyanesh,
>>
>> Have you had a chance to look at
>> https://bugs.linaro.org/show_bug.cgi?id=3657 and see if Matias' suggestions
>> are helpful to you?
>>
>> Thanks,
>>
>> Regards,
>> Bill
>
>
Re: [lng-odp] Bug 3657
Hi Bill, I tried with Matias' suggestions but without success. P Gyanesh Kumar Patra On Mon, Mar 26, 2018 at 4:16 PM, Bill Fischofer wrote: > Hi Gyanesh, > > Have you had a chance to look at https://bugs.linaro.org/ > show_bug.cgi?id=3657 and see if Matias' suggestions are helpful to you? > > Thanks, > > Regards, > Bill >
