v4l2src: device or resource busy

[IgalKroyter]

hi,

I am trying to restart a pipeline after it was GST_STATE_NULL and
unreferenced. Though after rebuilding the pipeline and trying to start it
the following message is displayed: *"libv4l2: error setting pixformat:
Device or resource busy"*. I guess it is the v4l2src component, as if once I
initialise it, the relevant HW resource is occupied and cannot be release
although the v4l2src component is dereferenced.

Any suggestions? Am I correct?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lun. 9 sept. 2019 14 h 41, IgalKroyter <[hidden email]> a écrit :

hi,

I am trying to restart a pipeline after it was GST_STATE_NULL and
unreferenced. Though after rebuilding the pipeline and trying to start it
the following message is displayed: *"libv4l2: error setting pixformat:
Device or resource busy"*. I guess it is the v4l2src component, as if once I
initialise it, the relevant HW resource is occupied and cannot be release
although the v4l2src component is dereferenced.

Any suggestions? Am I correct?

A buffer leak could leak could lead to this. Note that on newer kernel this restriction has been lifted, a driver can now be detached from its buffers and support for this has been added in v4l2src (not released yet).

--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Pascal Jacquemart]

Yes I have seen this one as well

You can run fuser -v /dev/video0

It should tell you if the file descriptor is still open or more likely
in case of leaky buffers that the device have been closed but the
device is still mapped.

I think you should terminate the pipeline by sending an EOS event on
the v4l2src element and makes sure it propagates. Then set state to
NULL and unref everything.

This should work even on older kernels.
I am running on CentOS kernel 3.16 and it is fine.


On Mon, 9 Sep 2019 13:36:58 -0500 (CDT)
IgalKroyter <[hidden email]> wrote:

> hi,
>
> I am trying to restart a pipeline after it was GST_STATE_NULL and
> unreferenced. Though after rebuilding the pipeline and trying to
> start it the following message is displayed: *"libv4l2: error setting
> pixformat: Device or resource busy"*. I guess it is the v4l2src
> component, as if once I initialise it, the relevant HW resource is
> occupied and cannot be release although the v4l2src component is
> dereferenced.
>
> Any suggestions? Am I correct?
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[IgalKroyter]

*Nicolas,* hi,

The version I'm using is quite firmed (1.8.3) into the environment I'm using
so I cannot upgrade it. Is there a way to debug these leaks? as I do not
touch these buffers AFAIK.
The only leak that can think of the is the leaky field in queue I utilize.

*Pascal, * hi,
I have found with the fuser that the /dev/videoX is utilized by the
application and was not released, although I have sent an eos to both the
piepline and the v4l2src element. I do receive an eos on the bus callback,
so I guess it was propagated, wasn't it?
Any suggestions?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mar. 10 sept. 2019 08 h 10, IgalKroyter <[hidden email]> a écrit :

*Nicolas,* hi,

The version I'm using is quite firmed (1.8.3) into the environment I'm using
so I cannot upgrade it. Is there a way to debug these leaks? as I do not
touch these buffers AFAIK.

*Pascal, * hi,
I have found with the fuser that the /dev/videoX is utilized by the
application and was not released, although I have sent an eos to both the
piepline and the v4l2src element. I do receive an eos on the bus callback,
so I guess it was propagated, wasn't it?
Any suggestions?

It's harder to debug on older version. But there will be related memory leak, so maybe try using valgrind. You'll need to find the gst.supp from the common/ repository, for this you need to find the Rev that was used by your version (clone that tag, and look at the git submodule). That's best I can give as my memory does not go as far as 1.8 (that's 4 major releases in the past, so at least 4 years).

--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[kochmmi1]

Hi,
I am experiencig the same issue, i guess. Have you reached some solution?
Thanks
Michal



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mercredi 24 mars 2021 à 06:29 -0500, kochmmi1 a écrit :
> Hi,
> I am experiencig the same issue, i guess. Have you reached some solution?
> Thanks
> Michal

This report was against GStreamer 1.8, which is very ancient. My recommendation
is to use newer kernel and newer GStreamer, as the memory handling has been
improved, allowing to detach buffers from the driver, hence avoiding these EBUSY
errors.

>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[przemek_g]

Hi guys,

Has there been a follow up on this / conclusion?

I am experiencing the same on:
GStreamer 1.20.5
Linux kernel 6.1.5-xilinx-v2023.1

Regards,
Przemek Gajos