On Sun, Mar 09, 2025 at 12:52:50AM GMT, Kirill A. Korinsky wrote:

> On Sun, 09 Mar 2025 00:26:08 +0100,
> Kirill A. Korinsky <kirill@korins.ky> wrote:
> > 
> > On Sat, 08 Mar 2025 21:31:06 +0100,
> > Marcus Glocker <marcus@nazgul.ch> wrote:
> > > 
> > > I would like to cleanup the queuing in small steps.  Hence, not
> > > removing SIMPLEQ yet.  Would this diff fix your issue when receiving
> > > multiple frames in one transfer?  It looks my devices don't do that
> > > very often, so difficult for me to test.
> > >
> > 
> > I just tested your diff. It's again frozes the system completley, and with
> > added some print I was able to prove that it is again, inside the queue.
> > 
> > It iterates here:
> > 
> > 	while (!SIMPLEQ_EMPTY(&sc->sc_mmap_q))
> > 		SIMPLEQ_REMOVE_HEAD(&sc->sc_mmap_q, q_frames);
> > 
> > and by my printf here I see that the cause that sc_mmap_q contains an
> > element which points to itself as the next one.
> > 
> > I really think that the root cause that ffmpeg / ffplay uses 4-6 buffers
> > when streams from this device, and we have insert and remove from parallel
> > threads to the same queue.
> > 
> > Thuis, if I enable debug, I can reproduce it not each time, and if I
> > increase uvideo_debug, I can't reproduce it at all.
> > 
> > All of this smells like issue from non thread-safe code.
> >
> 
> Ha, I just had frozes the machine with my patch as well from ffplay in X11.

Is this arm64 specific or do you see this also on amd64?