Description of problem: Unable to run the testpmd program using dpdk-18.11.2 testpmd -l 70,72,74,76,78 -w 0000:19:00.5 -- -i --portmask=0x1 --nb-cores=2 --forward-mode=macswap --port-topology=loop EAL: Detected 80 lcore(s) EAL: Detected 2 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Probing VFIO support... EAL: Cannot obtain physical addresses: No such file or directory. Only vfio will function. error allocating rte services array EAL: FATAL: rte_service_init() failed EAL: rte_service_init() failed PANIC in main(): Cannot init EAL 5: [testpmd(_start+0x2e) [0x56436aae6b5e]] 4: [/lib64/libc.so.6(__libc_start_main+0xf3) [0x7f7bde26c873]] 3: [testpmd(+0x4ddf1) [0x56436aae5df1]] 2: [/lib64/librte_eal.so.9(__rte_panic+0xc1) [0x7f7bdf4721e6]] 1: [/lib64/librte_eal.so.9(rte_dump_stack+0x32) [0x7f7bdf47ee32]] Aborted (core dumped) Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. install latest dpdk from red hat Fast Datapath repo 2. run the testpmd program Actual results: core dump Expected results: be able to run the application Additional info:
Hi Sebastian, It seems your application is defaulting to IOVA_PA mode. Can you please check: - You have enough permissions to access physical addresses (i.e: running as root)? - The issue is not reproducible with "--iova-mode va" in the EAL parameters - There is no other dpdk application (including ovs) running in the system. - Does it always fail in the same point? i.e: just after "error allocating rte services array" Thanks.
Let me add more information on the issue. - we are running on an openshift environment with mellanox sriov nic's. - dpdk is running inside a container, build from ubi8, with the dpdk (downstream) package installed on it. - inside the container we are working on a VF from the sriov nic, passed to the container by means of the Sriov CNI - we are using the mlx5_core driver for the nic. We also tried this with a custom build upstream version of dpdk, and it works fine.
It should be a fairly similar issue to bz1785933. I put a scratch build of the 18.11 dpdk package in it, can you have a try? Thanks.
Sebastian, Marcin, Can you confirm this is the same issue than bz1785933? Thanks.
Hi David, Yes, this is the same issue. I was able to run the container without the privileged=true using the scratch build
*** This bug has been marked as a duplicate of bug 1785933 ***
Closed, clearing needinfo