[LAU] Computer lockup
nando at ccrma.Stanford.EDU
Mon Feb 17 20:18:34 CET 2020
On 2/13/20 7:36 AM, Chris Caudle 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?
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
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 :-)
> 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.
More information about the Linux-audio-user