17 Feb
2020
17 Feb
'20
9:18 p.m.
On 2/13/20 7:36 AM, Chris Caudle wrote:
On Thu, February 13, 2020 8:02 am, Will Godfrey
wrote:
I have seen this myself. Nasty.
This is running a "normal" kernel but with threadirqs enabled and high
priority for the irq thread that hosts the USB audio interface.
If I am fast and realize my mistake soon (usually pulling the plug on
the interface and forgetting I have jack running) I can usually killall
jackd, and if that does not work killall -9 jackd. If I wait for too
long the machine becomes very very laggy and finally stops dead in a
short time. Nothing seems to be able to revive it save for a forced
power cycle.
A while back there was a thread that mentioned this - jack, when
confronted with the loss of an interface, should probably switch to the
dummy driver temporarily, and switch back if the interface is online
again. But then again, somebody has to code this :-)
-- Fernando
On running Jack into a USB soundcard, there have
been a few occasions
where the USB lead was snagged and pulled out.
On each occasion the computer locked up,
On similar occurrence I have been able to run "killall jackd" and recover.
In your case the entire machine became unresponsive? Are you running an RT kernel? I wonder if with RT and
a high enough
priority the jackd process could consume so much processor time that the
system was not usable. In my case I have a kernel configured with
preempt, but not the full preempt-RT patches.
The only suggestion I would have is check whether the control-alt-F3 key
combo can switch to a different virtual terminal, perhaps some process in
the desktop environment locked up, but if you can get to a shell again you
could kill jackd.