Closed catkira closed 7 months ago
@pcercuei can you quick fix this an cherry-pick the fix into pcercuei/fix-mmap
? <3
It's not broken - it's just that you have IIOD running on your board, that already has the buffer's file descriptor opened. As you can read from the commit message, there is a valid reason for it.
There might be a better solution, but it's far from an easy fix, and I'm in vacation until the 8th ;)
hmmm ok, it would be good if both could work at the same time like before. I will kill iiod after reboot until a better solution is found.
I have only BR2_PACKAGE_LIBIIO_IIOD_USBD
enabled, this causes iiod to be started by the S23udc init.d script
I can stop by running S23udc stop
but after that I still get the same error when trying to create a buffer.
oh I found it, I need to kill avahi-daemon as well. This is super inconvenient.
you shouldn't need to kill avahi...
when you do a S23udc stop
, do you get any errors?
If you edit the script so it is : start-stop-daemon -K -p /var/run/iiod.pid
(remove) the -q
(quiet) and 2>/dev/null
what output do you get?
Thanks
@rgetz yes, the avahi thing was a mistake on my side, I was confused because S23udc started iiod which was not obvious for me
It seems like with the new buffer logic it is not even possible to two different iio contexts open inside an application or on two different applications. That's quite a big limitation, I don't know exactly what made this change necessary, but the way it was before was much more convenient for my use cases.
everytime a context is created, it opens the buffer of every iio device that is available in that context and therefore blocks it for all other contexts that are opened after it. Thats super unintuitive and very limiting.
it was probably done for the new event feature, can't this be implemented without breaking multi context support?
commit aba77ca961414bde29c9856ae3f6797bc6eab9c0 causes
iio_device_create_buffer()
to returnDevice or resource busy (16)
when I run it on local.