|
From: Ralf J. <po...@ra...> - 2014-03-31 19:38:03
|
Hi,
> So..
> 1. Yup
> 2. It's not a module, but build into the kernel, so yes (I guess that
> shouldn't be a problem)
> 3. No /dev/dsp or mixer. OSS is removed, alsa emulation is disabled
I don't know about built-in cuse, but I agree it shouldn't be a problem.
Though maybe it's worth a try...
>
> So here's strace output..
>
[...]
Comparing this to the output on my machine doesn't show any significant
difference until
> fuse: fuse_remove_signal_handlers: unknown session
> futex(0x7fff8fe59940, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN
Weird enough, that error is after the print... but I have a very similar
call to futex() and it's succeeding (and it's the last thing happening,
actually).
Also, your output shows exactly the same behaviour that I observe when
calling osspd with osspd already running. In the absence of a better
theory, this looks to me as if something already took these major/minor
numbers. You don't happen to have SOUND_OSS_CORE_PRECLAIM enabled in the
kernel?
I had the same problem on Debian when I had "oss-compat" installed, so I
added the following to /etc/modprobe.d/osspd.conf:
blacklist snd-pcm-oss
blacklist snd-mixer-oss
blacklist snd-seq-oss
I suppose there's nothing in any logfiles?
In particular, I get the following in dmesg when the major/minor numbers
are already claimed:
CUSE: failed to register chrdev region
Did you use other fuse applications successfully? (I don't know any
other cuse application or I would ask about that.)
= Some more ideas in case none of the above applies =
The communication with fuse is not really visible in the strace though,
that seems to work through magic mmaps - and it looks like it's failing
somewhere there.
Could you insert something like
if (rc) {
log_msg(OSSP_LOG_CRIT, "fuse_session_loop_mt returned %d", rc);
}
after "rc = fuse_session_loop_mt(se);" in cuse_worker in osspd.c?
It may also be interesting to learn more about what's actually happening
in osspd (I hoped to see that with strace, but that did not work out).
Maybe ltrace is more informative? The last resort would be to step
through this with gdb.
Disclaimer: I'm guessing here as much as you are, and it's not like I
know how to use cuse or fuse - I'm just the Debian package maintainer.
Kind regards
Ralf
|