Re: [Jackit-devel] Re: Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19

[Florian Schmidt <mista.tapas@gmx.net>]

On Thu, 2 Dec 2004 17:57:56 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> On 02 Dec 2004 10:26:55 -0600
> "Jack O'Quin" <joq@io.com> wrote:
> 
> > 
> > > On Thu, 2 Dec 2004 07:46:20 -0800
> > > Andrew Burgess <aab@cichlid.com> wrote:
> > > > On further thought, I suppose libjack could install a SIGUSR2 handler and
> > > > have that call abort for all the rt client threads. Still no client mods
> > > > needed, only an RT-aware libjack.
> > 
> > Florian Schmidt <mista.tapas@gmx.net> writes:
> > > right. Or instead of aborting jackd might print a debug output (like
> > > "client foo violated RT constraints"). 
> > 
> > Libjack cannot assume the client has no SIGUSR2 handler of its own.
> 
> i see..
> 
> > It would be wonderful to have a reliable mechanism for debugging them.
> 
> I suppose instead of catching the signal the user might just monitor the
> syslog. I'm not sure there's printk's triggered by thisalready , but i'm
> sure if not, ingo might add them. So a trivial patch for jackd would
> probably look like this:
> 
> --- 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);
>  

Well, i do get syslog output with this patch like this:

Dec  2 18:01:11 mango kernel: jack_test:22645 userspace BUG: scheduling in user-atomic context!
Dec  2 18:01:11 mango kernel:  [<c02a38b6>] schedule+0x76/0x130 (8)
Dec  2 18:01:11 mango kernel:  [<c02a44c5>] schedule_timeout+0x85/0xe0 (36)
Dec  2 18:01:11 mango kernel:  [<c016677f>] do_pollfd+0x4f/0x90 (48)
Dec  2 18:01:11 mango kernel:  [<c011ceb0>] process_timeout+0x0/0x10 (8)
Dec  2 18:01:11 mango kernel:  [<c016686a>] do_poll+0xaa/0xd0 (20)
Dec  2 18:01:11 mango kernel:  [<c01669e2>] sys_poll+0x152/0x230 (48)
Dec  2 18:01:11 mango kernel:  [<c0165db0>] __pollwait+0x0/0xd0 (36)
Dec  2 18:01:11 mango kernel:  [<c01025cb>] syscall_call+0x7/0xb (32)

even if the client's process callback is a noop (except for returning
0). Hmm, i must have missed something in jackd's source. i thought
control->process() directly calls the clients process callback..

hmm..