[dpdk-dev] [PATCH] test: fix hang on FreeBSD
Radu Nicolau
radu.nicolau at intel.com
Mon May 21 15:33:16 CEST 2018
- Previous message: [dpdk-dev] [PATCH] test: fix hang on FreeBSD
- Next message: [dpdk-dev] [PATCH] net/liquidio:fix Unable to update lio_dev->linfo.link var When I was using VPP +dpdk-18.02+liqudio CN23xx, I encountered such a bug. When VPP called dpdk_device_start to initialize DPDK liqudio drive, I found that initialization failed. The reason for the failure is that VF MTU > PF MTU, but PF MTU has been modified to 9600 (> VF MTU). Finally, I am location that DPDK liqudio drive cannot get the correct PF driver to liqudio network card. It is due to the fact that when VPP calls dpdk_device_start to initialize DPDK liqudio drive, this time, lio_dev->linfo. Link var already exists in the old value, not empty. Cause lio_dev - > linfo. Link. Link_status64 != 0 statement is set up, and the link info is stopped directly to liqudio card, resulting in no get accurate pf mtu. I did a test model to reproduce the bug, which is to add rte_eth_dev_set_mtu(portid, vf_mtu) to the rte_eth_dev_start function when using dpdk-18.02+liqudio CN23xx+l2fwd. You need to make sure that 1500 < vf_mtu < pf_mtu will be available. At this time, you will have net_liovf[04:00.3]ERROR: lio_dev_mtu_set() VF MTU should be >= 68 and <= 1500. Such a mistake.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On 5/21/2018 2:28 PM, Burakov, Anatoly wrote:
> On 21-May-18 12:35 PM, Radu Nicolau wrote:
>> Fixes: af75078fece3 ("first public release")
>> Cc: stable at dpdk.org
>>
>> Signed-off-by: Radu Nicolau <radu.nicolau at intel.com>
>> ---
>> test/test/test_debug.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/test/test/test_debug.c b/test/test/test_debug.c
>> index faf2cf5..56fadce 100644
>> --- a/test/test/test_debug.c
>> +++ b/test/test/test_debug.c
>> @@ -34,7 +34,8 @@ test_panic(void)
>> printf("Fork Failed\n");
>> return -1;
>> }
>> - wait(&status);
>> + sleep(1);
>> + waitpid(pid, &status, WNOHANG);
>> if(status == 0){
>> printf("Child process terminated normally!\n");
>> return -1;
>>
>
> I'd be curious to see which specific problem you are addressing as
> well. FreeBSD hanging on abort is a known issue, and a workaround is
> already available:
>
> http://dpdk.org/dev/patchwork/patch/40256/
>
> FreeBSD doesn't really "hang" here, it just spends a
> looooooooooooooong time doing the core dump because FreeBSD, unlike
> Linux, doesn't ignore hugepage and zero-page anonymous memory for core
> dumps, resulting in it trying to dump the entire 128 gigabytes of VA
> space that we preallocate.
>
> Setting resource limits will address the immediate issue, a more
> complete fix (some memory subsystem refactor) will be coming for 18.08.
>
So it seems my "fix" only hides the issue and doesn't actually fix
anything - so I will remove it from patchwork
- Previous message: [dpdk-dev] [PATCH] test: fix hang on FreeBSD
- Next message: [dpdk-dev] [PATCH] net/liquidio:fix Unable to update lio_dev->linfo.link var When I was using VPP +dpdk-18.02+liqudio CN23xx, I encountered such a bug. When VPP called dpdk_device_start to initialize DPDK liqudio drive, I found that initialization failed. The reason for the failure is that VF MTU > PF MTU, but PF MTU has been modified to 9600 (> VF MTU). Finally, I am location that DPDK liqudio drive cannot get the correct PF driver to liqudio network card. It is due to the fact that when VPP calls dpdk_device_start to initialize DPDK liqudio drive, this time, lio_dev->linfo. Link var already exists in the old value, not empty. Cause lio_dev - > linfo. Link. Link_status64 != 0 statement is set up, and the link info is stopped directly to liqudio card, resulting in no get accurate pf mtu. I did a test model to reproduce the bug, which is to add rte_eth_dev_set_mtu(portid, vf_mtu) to the rte_eth_dev_start function when using dpdk-18.02+liqudio CN23xx+l2fwd. You need to make sure that 1500 < vf_mtu < pf_mtu will be available. At this time, you will have net_liovf[04:00.3]ERROR: lio_dev_mtu_set() VF MTU should be >= 68 and <= 1500. Such a mistake.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the dev
mailing list