prussdrv_open() fails if filedescriptor=0 is the first available file descriptor in system.

[hzeller]

If all file-descriptors are closed (say, we're running as daemon and have closed all file descriptors), prussdrv_open() fails.

The reason is a flaw in the assumptions in the implementation of prussdrv.c ( https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/app_loader/interface/prussdrv.c ): file-descriptors (prussdrv.mmap_fd and prussdrv.fd[i]) are initialized with zero and considered not opened/invalid when they are zero.

Of course, this assumption fails if all files have been closed before, thus the very first file descriptor in the system is, in fact, zero, so an open("/dev/uio0") returns FD 0. This results in prussdrv_open() to fail.

The whole file has to be changed so that the assumption of 'invalid filedescriptor' is changed to '-1' instead of 0. There are various ways to do that, so I let the maintainers choose what they prefer without suggesting patch for now.

(this was, indeed, a real world problem that surfaced in BeagleG. I've worked around it by re-opening file descriptors https://github.com/hzeller/beagleg/commit/042d1c41767cc382817cb8ce61bbb61aa5e7d274 )

To replicate

Here is a little test-program. With the close(0) call in place, it will fail.

#include <stdio.h>
#include <unistd.h>

#include <prussdrv.h>

int main() {
        // Close file-descriptor 0
        close(0);

        int ret = prussdrv_open(PRU_EVTOUT_0);
        fprintf(stderr, "Return code=%d ", ret);
        if (ret == 0) {
                fprintf(stderr, "SUCCESS\n");
        } else {
                fprintf(stderr, "FAILURE\n");
        }
        return ret;
}

[ghost]

Hi,

I had the same problem on:

root@beaglebone:# uname -or
4.4.30-ti-r64 GNU/Linux
root@beaglebone:# lsb_release -irc
Distributor ID: Debian
Release: 8.6
Codename: jessie

This link helped me to resolve it: https://groups.google.com/forum/#!topic/beagleboard/1rIV-mR8wYw Codename: jessie

[hzeller]

The issued talked about in that thread is about 4.x kernels and the device overlay and PRU interfacing changes that come with it @FedorovIgor.

This bug is about using wrong error sentinel values for file descriptors inside the library, so it is not quite related.

[ghost]

I see, I apologize for not reading carefully your post.