13 Feb
2020
13 Feb
'20
4:02 p.m.
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,
and could only be cleared by a hard reset. Is there a way of mitigating this?
This doesn't seem to happen if the card is being accessed by Alsa.
Running devuan ASCII or Beowulf on intel machine.
Also Rasbian on Pi 4
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
13 Feb
13 Feb
5:36 p.m.
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
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
11:19 p.m.
On 02/13/2020 03:47 PM, Anders Hellquist wrote:
Sometimes ssh'ing in from another box can help
killing jackd of
keyboard/desktop don't respond.
That's my preferred method of dealing with lockups. Of course, you then
need to know which switches to throw once you're on the bad box but
Google can usually help me find the solution.
Best,
dp
14 Feb
14 Feb
2:11 p.m.
On Thu, 13 Feb 2020 16:19:06 -0500
Dave Phillips <dlphillips(a)woh.rr.com> wrote:
On 02/13/2020 03:47 PM, Anders Hellquist wrote:
Thanks for the suggestions everyone.
I was rather hoping there might be some way of getting Jack itself to abort
under these conditions.
I do use an RT kernel on the main machines, and normal input is completely
unresponsive, so trying to get to a terminal or start another session with the
three finger salute is impossible.
I've not thought of trying to ssh from another machine - never even tried that
before for normal operations, so it could be 'interesting' :o
At the moment I'm not inclined to do too much experimenting due to only just
recovering from a recent disaster (power cut in the middle of an upgrade).
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Sometimes ssh'ing in from another box can
help killing jackd of
keyboard/desktop don't respond.
That's my preferred method of dealing with lockups. Of course, you then
need to know which switches to throw once you're on the bad box but
Google can usually help me find the solution.
Best,
dp 
2:21 p.m.
Will Godfrey <willgodfrey(a)musically.me.uk> writes:
On Thu, 13 Feb 2020 16:19:06 -0500
Dave Phillips <dlphillips(a)woh.rr.com> wrote:
I think there are some emergency SysReq key combinations. No idea
whether they need some special enabling. They bypass user space and
might be worth a try for getting a somewhat more regular shutdown.
--
David Kastrup
On 02/13/2020 03:47 PM, Anders Hellquist wrote:
Thanks for the suggestions everyone.
I was rather hoping there might be some way of getting Jack itself to abort
under these conditions.
I do use an RT kernel on the main machines, and normal input is completely
unresponsive, so trying to get to a terminal or start another session with the
three finger salute is impossible. Sometimes ssh'ing in from another box can
help killing jackd of
keyboard/desktop don't respond.
That's my preferred method of dealing with lockups. Of course, you then
need to know which switches to throw once you're on the bad box but
Google can usually help me find the solution.
Best,
dp 
4:19 p.m.
On 14/02/2020 13:21, David Kastrup wrote:
I think there are some emergency SysReq key
combinations. No idea
whether they need some special enabling. They bypass user space and
might be worth a try for getting a somewhat more regular shutdown.
Alt + SysReq + REISUB (aka "Reboot Even If System Utterly Broken")
should reboot the machine.
Best,
Jeremy
4:22 p.m.
On February 14, 2020 2:18:58 PM UTC, Jeremy Jongepier <jeremy(a)autostatic.com>
wrote:
On 14/02/2020 13:21, David Kastrup wrote:
What is SysReq?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I think there are some emergency SysReq key
combinations. No idea
whether they need some special enabling. They bypass user space and
might be worth a try for getting a somewhat more regular shutdown.
Alt + SysReq + REISUB (aka "Reboot Even If System Utterly Broken")
should reboot the machine.
Best,
Jeremy
4:29 p.m.
Goran Mekić <meka(a)tilda.center> writes:
On February 14, 2020 2:18:58 PM UTC, Jeremy Jongepier
<jeremy(a)autostatic.com> wrote:
A key on the usual PC keyboards.
--
David Kastrup
On 14/02/2020 13:21, David Kastrup wrote:
What is SysReq? I think there are some emergency SysReq key
combinations. No idea
whether they need some special enabling. They bypass user space and
might be worth a try for getting a somewhat more regular shutdown.
Alt + SysReq + REISUB (aka "Reboot Even If System Utterly Broken")
should reboot the machine.
Best,
Jeremy 
4:41 p.m.
On 2020-02-14 15:29, David Kastrup wrote:
Goran Mekić <meka(a)tilda.center> writes:
It's also implemented in /proc/sys/kernel.
I have this since quite a few years in a script on my computers if, or
rather when, things goes wrong and I can get in from outside.
echo 1 > /proc/sys/kernel/sysrq
echo r > /proc/sysrq-trigger
echo e > /proc/sysrq-trigger
echo i > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger
--
/bengan
On February 14, 2020 2:18:58 PM UTC, Jeremy
Jongepier <jeremy(a)autostatic.com> wrote:
A key on the usual PC keyboards. On 14/02/2020 13:21, David Kastrup wrote:
What is SysReq? I think there are some emergency SysReq key
combinations. No idea
whether they need some special enabling. They bypass user space and
might be worth a try for getting a somewhat more regular shutdown.
Alt + SysReq + REISUB (aka "Reboot Even If System Utterly Broken")
should reboot the machine.
Best,
Jeremy 
5:05 p.m.
On Fri, Feb 14, 2020 at 8:30 AM David Kastrup <dak(a)gnu.org> wrote:
Goran Mekić <meka(a)tilda.center> writes:
> On February 14, 2020 2:18:58 PM UTC, Jeremy Jongepier <jeremy(a)autostatic.com>
wrote:
>>On 14/02/2020 13:21, David Kastrup wrote:
>>> I think there are some emergency SysReq key combinations. No idea
>>> whether they need some special enabling. They bypass user space and
>>> might be worth a try for getting a somewhat more regular shutdown.
>>
>>Alt + SysReq + REISUB (aka "Reboot Even If System Utterly Broken")
>>should reboot the machine.
>>
>>Best,
>>
>>Jeremy
>
> What is SysReq?
On "traditional" keyboards it is the same key as PrtScn.
-m
5:15 p.m.
On Fri, 14 Feb 2020 09:04:41 -0600
Matt Zagrabelny <mzagrabe(a)d.umn.edu> wrote:
On Fri, Feb 14, 2020 at 8:30 AM David Kastrup
<dak(a)gnu.org> wrote:
Ah! Thanks for that. It had me puzzled too.
Will "traditionalist" :P
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Goran Mekić <meka(a)tilda.center> writes:
> On February 14, 2020 2:18:58 PM UTC, Jeremy Jongepier <jeremy(a)autostatic.com>
wrote:
>>On 14/02/2020 13:21, David Kastrup wrote:
>>> I think there are some emergency SysReq key combinations. No idea
>>> whether they need some special enabling. They bypass user space and
>>> might be worth a try for getting a somewhat more regular shutdown.
>>
>>Alt + SysReq + REISUB (aka "Reboot Even If System Utterly Broken")
>>should reboot the machine.
>>
>>Best,
>>
>>Jeremy
>
> What is SysReq?
On "traditional" keyboards it is the same key as PrtScn.
-m 
4:31 p.m.
On 14/02/20 15:18, Jeremy Jongepier wrote:
On 14/02/2020 13:21, David Kastrup wrote:
On some distributions I think you need to actually enable it. [0]
Also there's a quite authoritative comment about the fact that 'S' and
'U' should not be recommended any more on 'modern' systems [1][2] and
that it should now be 'REIB' (Reboot Even If Broken)
[0] https://wiki.archlinux.org/index.php/Keyboard_shortcuts#Kernel
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[2]
https://wiki.archlinux.org/index.php/Talk:Keyboard_shortcuts#Standard_short…
I think there are some emergency SysReq key
combinations. No idea
whether they need some special enabling. They bypass user space and
might be worth a try for getting a somewhat more regular shutdown.
Alt + SysReq + REISUB (aka "Reboot Even If System Utterly Broken")
should reboot the machine.
17 Feb
17 Feb
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.
1696
days inactive
1700
days old
linux-audio-user@lists.linuxaudio.org
13 comments
11 participants
participants (11)
-
Anders Hellquist -
Bengt Gördén -
Chris Caudle -
Dave Phillips -
David Kastrup -
Fernando Lopez-Lezcano -
Goran Mekić -
Jeremy Jongepier -
Lorenzo Sutton -
Matt Zagrabelny -
Will Godfrey