[LAU] Computer lockup

[Fernando Lopez-Lezcano]

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 
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


> 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.
>