13 Feb
2020
13 Feb
'20
10:47 p.m.
Sometimes ssh'ing in from another box can help killing jackd of
keyboard/desktop don't respond.
On Thu, Feb 13, 2020, 16:37 Chris Caudle <chris(a)chriscaudle.org> wrote:
On Thu, February 13, 2020 8:02 am, Will Godfrey
wrote:
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.
--
Chris Caudle
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user