Subject: Re: [linux-audio-dev] Lowlatency rpm problem
From: David Olofson (david_AT_gardena.net)
Date: Wed Oct 11 2000 - 14:54:41 EEST
On Thu, 05 Oct 2000, Benno Senoner wrote:
> On Thu, 05 Oct 2000, miriam rainsford wrote:
> >
> > Hi all,
> >
> > I've been trying Benno's kernel rpms with Ingo's low latency patches... at the moment I'm running 2.2.17-1LL for i686,
> > on a Mandrake system (as you'd all know it is in theory Red Hat based so it
> >should work...). Its all working beautifully - very nice indeed! - except now
> >my system won't power down from linux. Just wondering if anyone else has had
> >that problem and if there is a fix for it?
> >
> >
> >Miriam.
>
>
> Hi Miriam,
> you are right power down does not work , because I intentionally disabled apm
> (power managment) support when compiling the RPM.
> This because on some motherboards, the APM interrups cause high latency peaks.
>
> But I don't think that it is a high price to pay, being forced to press the
> power button when powering down your box, in return of 5msec latencies ....
Mmm... I have the halt script shut down my UPS instead, so I actually
don't *want* the computer to power off - if it does,
>
>
> PS: I had a few crashes using the 2.2.17 RPM on my box, but I am not 100% sure
> it it was due to my app (EVO) deadlocking in an infinite loop (and since it runs
> SCHED_FIFO, it never releases the CPU thus your box will freeze)
Maybe it's time someone hacked up a simple watchdog daemon? Unless
someone's already working on it, I'll give it a shot as soon as I get
back to running lowlatency kernels.
Hmmm... I might actually do this at work, as I'm just about to set up
a "fault tolerant" embeded test system, based on Linux/RTAI +
lowlatency. (It's basically supposed to crash badly, as we're chasing
what we think is a hardware problem. I'd like the system to stay up
and gather as much information as possible, and keeping SCED_FIFO
threads from freezing the system is one measure to avoid Stupid
Frozen Screens and the like.)
Quick'n'dirty version, with limited security:
* Watchdog runs as daemon at highest possible SCHED_FIFO prio.
* Watchdog also has a SCHED_FIFO thread at lowest prio, which is
occasionally queried in order to guarantee that non RT threads have
a chance to run in a heavily loaded system. (Checking the process
info from the kernel might be enough, though...)
* Applications use library with IPC code to talk to the watchdog.
* Applications are supposed to run as non-root.
* API provides:
- int wd_set_signal(pid_t pid, int signum)
Tell the watchdog what signal to send to the
specified thread if it should cause CPU overload.
- int wd_set_signal_timeout(pid_t pid, int maxslot)
Tell the watchdog how long (in ms) the specified
thread may stay runnable before it gets the signal
set by wd_set_signal().
After the signal is sent, the watchdog resets the
timer for the thread, and goes back to monitoring.
If a thread should keep running, it will receive a
signal every <maxslot> ms, until it gets off the
CPU, or is killed by the watchdog.
- int wd_set_kill_timeout(pid_t pid, int maxslot)
If the specified thread stays runnable for more than
<maxslot> ms, the watchdog will brutally kill it.
There is a global limit here that only root can
change. (That is, unless the admin allows non-root
users to write the config file! :-)
- int wd_set_scheduler(pid_t pid, int policy, int priority)
Sets the scheduling policy and priority of a thread.
The priority for SCHED_FIFO should (probably) be
encoded in a way that makes it easier for RT
applications to cooperate, rather than trying to
keep each other from the CPU...
Of course, the watchdog prevents clients from setting
higher priorities than it's using itself.
- Some basic info functions to allow applications to get some
idea of what the current RT environment is, and what's
currently going on. (Other RT threads etc.)
Suggestions?
One thing that worries me is this; How to find out if a thread is
deadlocked, or if it's just running/sleeping with very short
intervals, without a kernel hack? Do the existing APIs provide
reliable info in such cases? (I don't want to rely on the threads
reporting to the daemon in any explicit way! Not reliable.)
Preferably, this should be done without any kernel hacks, extra
modules or other special requirements.
(Please, CC to do_AT_reologica.se, as that address isn't subscribed to
these lists.)
This archive was generated by hypermail 2b28 : Wed Oct 11 2000 - 16:10:05 EEST