From: Florian Schmidt <mista.tapas@gmx.net>
To: Ingo Molnar <mingo@elte.hu>
Cc: Rui Nuno Capela <rncbc@rncbc.org>,
linux-kernel@vger.kernel.org, Lee Revell <rlrevell@joe-job.com>,
mark_h_johnson@raytheon.com, "K.R. Foley" <kr@cybsft.com>,
Bill Huey <bhuey@lnxw.com>, Adam Heath <doogie@debian.org>,
Thomas Gleixner <tglx@linutronix.de>,
Michal Schmidt <xschmi00@stud.feec.vutbr.cz>,
Fernando Pablo Lopez-Lezcano <nando@ccrma.stanford.edu>,
Karsten Wiese <annabellesgarden@yahoo.de>,
Gunther Persoons <gunther_persoons@spymac.com>,
emann@mrv.com, Shane Shrybman <shrybman@aei.ca>,
Amit Shah <amit.shah@codito.com>,
Esben Nielsen <simlo@phys.au.dk>, Andrew Morton <akpm@osdl.org>
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19
Date: Thu, 2 Dec 2004 18:44:21 +0100 [thread overview]
Message-ID: <20041202184421.229cf5d5@mango.fruits.de> (raw)
In-Reply-To: <20041202134934.GA32216@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]
On Thu, 2 Dec 2004 14:49:34 +0100
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
>
> > Ok, so if i want to find out whether a client violates the RT
> > constraints for its process callback i would have to add a call to
> > gettimeofday(1,1) at the start of the process callback and
> > gettimeofday(1,0) at the end.
> >
> > Everything which causes a reschedule inbetween will then cause SIGUSR2
> > to be sent to the client for which i could either add a signal handler
> > in the client or just use gdb to get notified of it.
>
> correct. I'd expect there to be a number of less critical reschedules
> happening around startup/shutdown of a client, which one could consider
> a false positive, but there should be no unexpected rescheduling while
> the client is up and running.
Ok,
this simple patch adds the gettimeofday calls around the calling of the
process callback:
--- libjack/client.c.orig 2004-12-02 17:55:04.000000000 +0100
+++ libjack/client.c 2004-12-02 17:56:23.000000000 +0100
@@ -1238,6 +1238,9 @@
if (control->sync_cb)
jack_call_sync_client (client);
+ // enable atomicity check for RP kernels
+ gettimeofday(1,1);
+
if (control->process) {
if (control->process (control->nframes,
control->process_arg)
@@ -1247,7 +1250,10 @@
} else {
control->state = Finished;
}
-
+
+ // disable atomicity check
+ gettimeofday(0,1);
+
if (control->timebase_cb)
jack_call_timebase_master (client);
The results i see are rather interesting though. Even with a noop jack
client (which does nothing but return 0 in the process callback) i get a
syslog report everytime i start the client. Client source attached.
Dec 2 18:39:06 mango kernel: jack_test:22743 userspace BUG: scheduling in user-atomic context!
Dec 2 18:39:06 mango kernel: [<c02a38b6>] schedule+0x76/0x130 (8)
Dec 2 18:39:06 mango kernel: [<c02a44c5>] schedule_timeout+0x85/0xe0 (36)
Dec 2 18:39:06 mango kernel: [<c016677f>] do_pollfd+0x4f/0x90 (48)
Dec 2 18:39:06 mango kernel: [<c011ceb0>] process_timeout+0x0/0x10 (8)
Dec 2 18:39:06 mango kernel: [<c016686a>] do_poll+0xaa/0xd0 (20)
Dec 2 18:39:06 mango kernel: [<c01669e2>] sys_poll+0x152/0x230 (48)
Dec 2 18:39:06 mango kernel: [<c0165db0>] __pollwait+0x0/0xd0 (36)
Dec 2 18:39:06 mango kernel: [<c01025cb>] syscall_call+0x7/0xb (32)
The atomicity check operates on a per task (thread) basis right?
Flo
[-- Attachment #2: jack_test.cc --]
[-- Type: text/x-c++src, Size: 2068 bytes --]
#include <jack/jack.h>
#include <iostream>
#include <sstream>
#include <unistd.h>
jack_client_t *client;
jack_port_t *iport;
jack_port_t *oport;
int wasted_loops = 0;
int sleep_seconds = 1;
int sleep_in_period = 2000;
int counter = 0;
int process(jack_nframes_t frames, void *arg) {
/*
// std::cout << "process callback" << std::endl;
jack_default_audio_sample_t *ibuf;
ibuf = (jack_default_audio_sample_t*)jack_port_get_buffer(iport, frames);
jack_default_audio_sample_t *obuf;
obuf = (jack_default_audio_sample_t*)jack_port_get_buffer(oport, frames);
for (jack_nframes_t frame = 0; frame < frames; frame++) {
for (int i = 0; i < wasted_loops; ++i) {
// do nothing
}
obuf[frame] = ibuf[frame];
}
counter++;
if (counter == sleep_in_period) {
//sleep(sleep_seconds);
}
*/
return 0;
}
int main(int argc, char *argv[]) {
// default = 60 seconds
unsigned int seconds_to_run = 60;
if (argc > 1) {
std::stringstream sec_stream;
sec_stream << argv[1];
sec_stream >> seconds_to_run;
if (argc > 2) {
std::stringstream waste_stream;
waste_stream << argv[2];
waste_stream >> wasted_loops;
std::cout << "wasted loops: " << wasted_loops << std::endl;
}
}
std::cout << "seconds to run: " << seconds_to_run << std::endl;
std::stringstream pid_stream;
pid_stream << getpid();
std::cout << "client_new" << std::endl;
client = jack_client_new(pid_stream.str().c_str());
std::cout << "port_register." << std::endl;
iport = jack_port_register(client, "in", JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput|JackPortIsTerminal, 0);
oport = jack_port_register(client, "out", JACK_DEFAULT_AUDIO_TYPE, JackPortIsTerminal|JackPortIsOutput, 0);
std::cout << "set_process_callback" << std::endl;
jack_set_process_callback(client, process, 0);
std::cout << "activate" << std::endl;
jack_activate(client);
std::cout << "running" << std::endl;
// while(1) {sleep(1);};
sleep(seconds_to_run);
jack_deactivate(client);
jack_client_close(client);
}
next prev parent reply other threads:[~2004-12-02 17:42 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-26 12:12 Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-7 Rui Nuno Capela
2004-11-29 11:05 ` Ingo Molnar
2004-11-29 11:16 ` Ingo Molnar
2004-11-29 11:24 ` Ingo Molnar
2004-11-29 15:42 ` Ingo Molnar
2004-11-29 13:13 ` Rui Nuno Capela
2004-11-29 14:33 ` Ingo Molnar
2004-11-29 15:23 ` Ingo Molnar
2004-11-29 23:16 ` Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-13 Gene Heskett
2004-11-30 1:50 ` K.R. Foley
2004-11-30 3:19 ` Gene Heskett
2004-11-30 4:54 ` Gene Heskett
2004-11-30 15:26 ` K.R. Foley
2004-11-30 16:24 ` Gene Heskett
2004-11-30 16:52 ` Zwane Mwaikambo
2004-12-01 7:16 ` Gene Heskett
2004-11-30 16:57 ` K.R. Foley
2004-11-30 10:29 ` Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-7 Rui Nuno Capela
2004-11-30 13:19 ` Ingo Molnar
2004-11-30 15:39 ` Rui Nuno Capela
2004-11-30 16:42 ` Ingo Molnar
2004-12-01 10:32 ` Ingo Molnar
2004-12-01 11:25 ` Ingo Molnar
2004-12-01 12:49 ` Rui Nuno Capela
2004-12-01 12:47 ` Rui Nuno Capela
2004-12-01 15:40 ` Ingo Molnar
2004-12-01 16:06 ` Ingo Molnar
2004-12-01 16:20 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19 Ingo Molnar
2004-12-01 16:31 ` Ingo Molnar
2004-12-01 18:59 ` Rui Nuno Capela
2004-12-01 21:29 ` Ingo Molnar
2004-12-01 21:30 ` Ingo Molnar
[not found] ` <32788.192.168.1.8.1101938057.squirrel@192.168.1.8>
2004-12-01 21:58 ` Ingo Molnar
2004-12-01 22:04 ` Rui Nuno Capela
2004-12-01 22:09 ` Ingo Molnar
2004-12-01 22:31 ` Rui Nuno Capela
2004-12-02 9:12 ` Rui Nuno Capela
2004-12-02 12:59 ` Rui Nuno Capela
2004-12-02 16:38 ` Fernando Lopez-Lezcano
2004-12-01 22:43 ` Florian Schmidt
2004-12-02 8:40 ` Ingo Molnar
2004-12-02 12:22 ` Florian Schmidt
2004-12-02 12:29 ` Ingo Molnar
2004-12-02 13:06 ` Florian Schmidt
2004-12-02 13:10 ` Ingo Molnar
2004-12-02 13:40 ` Florian Schmidt
2004-12-02 13:49 ` Ingo Molnar
2004-12-02 16:08 ` Florian Schmidt
2004-12-02 17:44 ` Florian Schmidt [this message]
2004-12-02 21:12 ` Florian Schmidt
2004-12-02 13:18 ` Rui Nuno Capela
2004-12-03 1:41 ` Fernando Lopez-Lezcano
2004-12-03 2:23 ` Fernando Lopez-Lezcano
2004-11-30 18:13 ` Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-7 Remi Colinet
2004-11-30 8:15 ` Ingo Molnar
2004-12-01 8:30 ` Eran Mann
2004-12-01 8:53 ` Ingo Molnar
2004-12-01 18:19 ` Adam Heath
-- strict thread matches above, loose matches on Subject: below --
2004-12-02 21:01 [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19 Mark_H_Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041202184421.229cf5d5@mango.fruits.de \
--to=mista.tapas@gmx.net \
--cc=akpm@osdl.org \
--cc=amit.shah@codito.com \
--cc=annabellesgarden@yahoo.de \
--cc=bhuey@lnxw.com \
--cc=doogie@debian.org \
--cc=emann@mrv.com \
--cc=gunther_persoons@spymac.com \
--cc=kr@cybsft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark_h_johnson@raytheon.com \
--cc=mingo@elte.hu \
--cc=nando@ccrma.stanford.edu \
--cc=rlrevell@joe-job.com \
--cc=rncbc@rncbc.org \
--cc=shrybman@aei.ca \
--cc=simlo@phys.au.dk \
--cc=tglx@linutronix.de \
--cc=xschmi00@stud.feec.vutbr.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.