<div dir="auto">Sometimes ssh'ing in from another box can help killing jackd of keyboard/desktop don't respond.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020, 16:37 Chris Caudle <<a href="mailto:chris@chriscaudle.org">chris@chriscaudle.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, February 13, 2020 8:02 am, Will Godfrey wrote:<br>
> On running Jack into a USB soundcard, there have been a few occasions<br>
> where the USB lead was snagged and pulled out.<br>
> On each occasion the computer locked up,<br>
<br>
On similar occurrence I have been able to run "killall jackd" and recover.<br>
In your case the entire machine became unresponsive?<br>
<br>
Are you running an RT kernel?  I wonder if with RT and a high enough<br>
priority the jackd process could consume so much processor time that the<br>
system was not usable.  In my case I have a kernel configured with<br>
preempt, but not the full preempt-RT patches.<br>
<br>
The only suggestion I would have is check whether the control-alt-F3 key<br>
combo can switch to a different virtual terminal, perhaps some process in<br>
the desktop environment locked up, but if you can get to a shell again you<br>
could  kill jackd.<br>
<br>
-- <br>
Chris Caudle<br>
_______________________________________________<br>
Linux-audio-user mailing list<br>
<a href="mailto:Linux-audio-user@lists.linuxaudio.org" target="_blank" rel="noreferrer">Linux-audio-user@lists.linuxaudio.org</a><br>
<a href="https://lists.linuxaudio.org/listinfo/linux-audio-user" rel="noreferrer noreferrer" target="_blank">https://lists.linuxaudio.org/listinfo/linux-audio-user</a><br>
</blockquote></div>