18 Apr
2015
18 Apr
'15
7:39 p.m.
Hi *!
I've come across a mysterious problem - since a few days ago (openSUSE
Tumbleweed is a rolling release), JACK hangs during startup. If you
start it with QJackCtl, it will kill it after a while, but if you start
it from the console and strace it, you can see it hangs waiting for a futex:
[...]
sched_get_priority_min(SCHED_FIFO) = 1
sched_get_priority_max(SCHED_FIFO) = 99
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f9e76cfe000
mprotect(0x7f9e76cfe000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f9e774fdfb0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f9e774fe9d0, tls=0x7f9e774fe700,
child_tidptr=0x7f9e774fe9d0) = 4627
sched_setscheduler(4627, SCHED_FIFO, { 1 }) = 0
futex(0x7f9e774fed18, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f9e7ba87000, 227354) = 0
futex(0x7f9e776ff078, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f9e774fe9d0, FUTEX_WAIT, 4627, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
futex(0x7f9e774fe9d0, FUTEX_WAIT, 4627, NULL
and hangs forever after.
It seems to be after acquiring SCHED_FIFO, but just to be sure I
verified that I'm still in group audio, and we still have
@audio - rtprio 95
@audio - memlock 3000000
in /etc/security/limits.conf.
The problem started at the same time kernel 3.19.3 came out for
Tumbleweed, but downgrading to older kernels in the 3.19 series or as
far back as 3.17 doesn't restore jack functionality. So it must be
something in userspace.
Other people have seen this [1] and solved it with the nuclear option,
i.e. downgrading to 13.2, which means a massive userspace rollback.
I wonder if someone could offer some advice as to where else to look...
I did the usual checkup regarding double installs, and I'm positive my
jackd installation is clean. The guys in [1] have used the package, and
I've tried both the package and a clean jack1 and jack2 build from
scratch, with all other libs cleared by hand and ldd relations checked.
Any inspiration welcome,
Jörn
[1]
https://forums.opensuse.org/showthread.php/506613-after-update-Tumbleweed-I…
(not a very insightful discussion)
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
18 Apr
18 Apr
8:33 p.m.
On Sat, 18 Apr 2015 19:39:53 +0200, Jörn Nettingsmeier wrote:
The problem started at the same time kernel 3.19.3 came
out for
Tumbleweed, but downgrading to older kernels in the 3.19 series or as
far back as 3.17 doesn't restore jack functionality. So it must be
something in userspace.
Hi Jörn,
there definitively also is an issue with this kernel.
[rocketmouse@archlinux ~]$ uname -rm
3.19.3-3-ARCH x86_64
[rocketmouse@archlinux ~]$ aconnect -i
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
I only use linux-rt, but an user of this kernel noticed it and started a
thread here:
https://lists.archlinux.org/pipermail/arch-general/2015-April/038789.html
There isn't such an issue with
[rocketmouse@archlinux ~]$ pacman -Q linux-rt linux-rt-lts
linux-rt 3.18.9_rt5-2
linux-rt-lts 3.10.61_rt65-1
on my machine. Using those kernels, aconnect shows all devices listed
by amidi.
It might be unrelated to this particular jack issue, however, it's
worth mentioning it.
Regards,
Ralf
20 Apr
20 Apr
12:30 p.m.
On 04/18/2015 08:33 PM, Ralf Mardorf wrote:
On Sat, 18 Apr 2015 19:39:53 +0200, Jörn Nettingsmeier
wrote:
Curious coincidence: a few weeks before LAC2015, I tried to connect a
BCF2000 to the LAC streaming box, and even though lsusb showed the
device, ALSA did not catch it, ever. This box ran Manjaro, which, IIUC,
is a derivative of Arch.
I'm not sure any of this is actually related to the JACK issue, but yes,
something is fishy about 3.19 :)
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
The problem started at the same time kernel
3.19.3 came out for
Tumbleweed, but downgrading to older kernels in the 3.19 series or as
far back as 3.17 doesn't restore jack functionality. So it must be
something in userspace.
Hi Jörn,
there definitively also is an issue with this kernel.
[rocketmouse@archlinux ~]$ uname -rm
3.19.3-3-ARCH x86_64
[rocketmouse@archlinux ~]$ aconnect -i
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
[rocketmouse@archlinux ~]$ amidi -l
Dir Device Name
IO hw:0,0 HDSPMx579bcc MIDI 1
IO hw:1,0 TerraTec EWX24/96 MIDI
IO hw:2,0 TerraTec EWX24/96 MIDI
I only use linux-rt, but an user of this kernel noticed it and started a
thread here:
https://lists.archlinux.org/pipermail/arch-general/2015-April/038789.html 
4:50 p.m.
On Mon, Apr 20, 2015 at 12:29:58PM +0200, Jörn Nettingsmeier wrote:
Curious coincidence: a few weeks before LAC2015, I
tried to connect a
BCF2000 to the LAC streaming box, and even though lsusb showed the device,
ALSA did not catch it, ever. This box ran Manjaro, which, IIUC, is a
derivative of Arch.
I'm not sure any of this is actually related to the JACK issue, but yes,
something is fishy about 3.19 :)
This one is – perhaps not exclusively – an Arch issue, one has to
manually load snd_seq_midi until it is resolved. It reportedly started
with 3.19.2, I myself ran into it with 3.19.3.
https://bugs.archlinux.org/task/44286
1:48 p.m.
On 04/18/2015 07:39 PM, Jörn Nettingsmeier wrote:
Hi *!
I've come across a mysterious problem - since a few days ago (openSUSE
Tumbleweed is a rolling release), JACK hangs during startup. If you
start it with QJackCtl, it will kill it after a while, but if you start
it from the console and strace it, you can see it hangs waiting for a
futex:
[...]
sched_get_priority_min(SCHED_FIFO) = 1
sched_get_priority_max(SCHED_FIFO) = 99
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f9e76cfe000
mprotect(0x7f9e76cfe000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f9e774fdfb0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f9e774fe9d0, tls=0x7f9e774fe700,
child_tidptr=0x7f9e774fe9d0) = 4627
sched_setscheduler(4627, SCHED_FIFO, { 1 }) = 0
futex(0x7f9e774fed18, FUTEX_WAKE_PRIVATE, 1) = 1
munmap(0x7f9e7ba87000, 227354) = 0
futex(0x7f9e776ff078, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f9e774fe9d0, FUTEX_WAIT, 4627, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
futex(0x7f9e774fe9d0, FUTEX_WAIT, 4627, NULL
and hangs forever after.
It seems to be after acquiring SCHED_FIFO, but just to be sure I
verified that I'm still in group audio, and we still have
@audio - rtprio 95
@audio - memlock 3000000
in /etc/security/limits.conf.
The problem started at the same time kernel 3.19.3 came out for
Tumbleweed, but downgrading to older kernels in the 3.19 series or as
far back as 3.17 doesn't restore jack functionality. So it must be
something in userspace.
new piece of information:
JACK2 (built from current source) fails.
JACK1 (also built from current source) appears to work. weird...
3580
days inactive
3582
days old
linux-audio-user@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Adler -
Jörn Nettingsmeier -
Ralf Mardorf