Hi Vipin, 

These crashes are specific to the testpmd primary and testpmd secondary application. 
Please check https://patches.dpdk.org/project/dpdk/patch/20250804113322.53650-1-14pwcse1224@uetpeshawar.edu.pk/
The details are provided over there. 

Regards, 
Khadem

On Mon, Aug 11, 2025 at 3:19 PM Varghese, Vipin <Vipin.Varghese@amd.com> wrote:
[Public]

Snipped

> > Since somehow the email are split it is difficult to see the indexing
> >
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > Hi Stephen,
> > >
> > > Many thanks for diving deeper into the issue and sharing the insights.
> > >
> > > I agree. given that the primary tears down all the devices on exit,
> > > the secondary is left with dangling pointers and inconsistent state.
> >
> > Secondary if PMD should not be attempting to cleanup (especially for ethdev_ptr
> shared from primary) I agree to that.
> > But should not be covered in library or PMD. While cleanup for other
> > needs to be done properly
> >
> >  Without a mechanism to notify or synchronize that teardown,
> >
> > You already have health check added in the code for identify if primay is still alive
> or not..
> > There used to be MP thread spawned which actually piggy back the
> > communication. Is this broken? Can you please point to git
>
> There is no easy way to handle the case where primary crashes; leaving
> secondary process with pointers to dead data.

Thank you for sharing, but as shared the other threads (this topic has 3), the reason for the patch is because once the primary is dead it causes secondary to crash (segment fault).

As shared in earlier email at least till 22.11 LTS and 23.03 (as it was my last testing with multi-process) I did not encounter these.

@Khadem Ullah can you please share which version of DPDK you are noticing this failure?


--
Engr. Khadem Ullah,
Software Engineer,
Dreambig Semiconductor Inc
https://dreambigsemi.com/