Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hello all,
I was trying to run forked-daapd on my DNS-320 (2.00 fw) with running DNS-320&325_linuxDebian_revA_Squeeze_all_en_20110111. Forked-daapd was successfuly installed from package (stable squeeze ver. 0.12) and I was also able to build my own (version 0.19). After installing binary and starting I have got this strange error in log
[2011-10-22 02:40:07] scan: Could not create eventfd: Invalid argument [2011-10-22 02:40:07] main: File scanner thread failed to start
Is there anybody more experienced than me who could help me to solve this out? It seems that something wrong with eventfd. Here is the C code that could help to get better overview.
#ifdef USE_EVENTFD
exit_efd = eventfd(0, EFD_CLOEXEC);
if (exit_efd < 0)
{
DPRINTF(E_FATAL, L_SCAN, "Could not create eventfd: %s\n", strerror(errno));
goto pipe_fail;
}Any help is more than appreciated. Thank you.
Offline
Which kernel do you use?
man eventfd wrote:
The following values may be bitwise ORed in flags to change the behaviour of
eventfd():
EFD_CLOEXEC (since Linux 2.6.27)
Set the close-on-exec (FD_CLOEXEC) flag on the new file descriptor.
See the description of the O_CLOEXEC flag in open(2) for reasons why
this may be useful.
EFD_NONBLOCK (since Linux 2.6.27)
Set the O_NONBLOCK file status flag on the new open file description.
Using this flag saves extra calls to fcntl(2) to achieve the same
result.
EFD_SEMAPHORE (since Linux 2.6.30)
Provide semaphore-like semantics for reads from the new file
descriptor. See below.
In Linux up to version 2.6.26, the flags argument is unused, and must be
specified as zero.
So to use EFD_CLOEXEC you need at least 2.6.27
Offline
Hello, thanks for your quick response.
Mijzelf wrote:
Which kernel do you use?
Linux DLINK320 2.6.22.18 armv5tejl
Mijzelf wrote:
So to use EFD_CLOEXEC you need at least 2.6.27
Is there any way to update it without any serious risks?
Thanks!
Offline
sergej.novosibirsk wrote:
Is there any way to update it without any serious risks?
Depends on your definition of 'serious risks'. Theoretically it's not risky at all, as you can test the new kernel using uBoot commands before flashing it. But if you have to ask it, it probably exceeds your (current) skills.
You could try to exchange EFD_CLOEXEC by zero, possibly it just works. Or build the code without the USE_EVENTFD set. (Maybe ./configure --without-eventfd ?)
Offline