Re: Serial port blues
- From: Johannes Stezenbach <js@xxxxxxxxxxx>
- Date: Sun, 21 Jan 2007 15:04:21 +0100
On Sun, Jan 21, 2007 at 08:05:57AM +0100, Willy Tarreau wrote:
On Sun, Jan 21, 2007 at 12:54:56AM -0500, Theodore Tso wrote:
On Sat, Jan 20, 2007 at 06:36:44PM +0100, Willy Tarreau wrote:
Now he must be careful about avoiding busy loops in the rest of the
program, or he will have to use the reset button.
An easy way of dealing with this is to have an sshd running
an alternative port running at a nice high priority (say, prio 95 or
so). That way, if you screw up, you can always login remotely and
kill the offending program.
There is also a RT Watchdog program which can be found on
rt.wiki.kernel.org which can be used to recover from runaway real-time
processes without needing to hit the reset button.
Thanks for those hints, I've been used to play with the reset button,
at least it has forced me to double check my code before running it :-)
I think SysRq-N sets all processes with RT-priority to non-RT.
Johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Serial port blues
- From: Joe Barr
- Re: Serial port blues
- From: Willy Tarreau
- Re: Serial port blues
- From: Theodore Tso
- Re: Serial port blues
- From: Willy Tarreau
- Serial port blues
- Prev by Date: Re: How to use an usb interface than is claimed by HID?
- Next by Date: SATA exceptions triggered by XFS (since 2.6.18)
- Previous by thread: Re: Serial port blues
- Next by thread: Re: Serial port blues
- Index(es):