[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

* Florian Schmidt <> wrote:

> I don't get any oopses or panics, but i can observer a rather
> interesting behaviour. When i enable the latency traces via
> echo 1 > /proc/sys/kernel/trace_enabled
> my machine starts to make little pauses of ca 3-4 secs. X "hangs" for
> this duration and so does aplay when playing a .wav file. "hangs"
> means that the X display seems to be locked. Interestingly enough all
> keystrokes i entered during the "hang" seem to arrive fine after the
> hang has ended. aplay experiences an xrun.

do you get the same pauses if you do 'dmesg -n 1'? Also, are you using
preempt_thresh or the maximum-searching variant? preempt_thresh can
generate _tons_ of messages with a low threshold, freezing the system in
essence for long periods of time.

but this trace is weird:

> preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
> -------------------------------------------------------
> latency: 1841 us, entries: 4000 (12990) | [VP:1 KP:1 SP:1 HP:1 #CPUS:1]
> -----------------
> | task: aplay/2160, uid:1000 nice:0 policy:0 rt_prio:0
> -----------------
> => started at: __schedule+0x3b/0x5d0 <c02a767b>
> => ended at: finish_task_switch+0x43/0xb0 <c0114ae3>
> =======>
> 00000001 0.000ms (+0.000ms): __schedule (ksoftirqd)
> 00000001 0.000ms (+0.000ms): sched_clock (__schedule)
> 00000002 0.000ms (+0.000ms): deactivate_task (__schedule)
> 00000002 0.000ms (+0.000ms): dequeue_task (deactivate_task)
> 04000002 0.000ms (+0.000ms): __switch_to (__schedule)
> 04000002 0.001ms (+0.000ms): finish_task_switch (__schedule)
> 04000000 0.001ms (+0.000ms): schedule (down_write)
> 04000000 0.001ms (+0.000ms): __schedule (down_write)
> 04000001 0.001ms (+0.000ms): sched_clock (__schedule)
> 04000000 0.001ms (+0.000ms): schedule (down_write)
> 04000000 0.001ms (+0.000ms): __schedule (down_write)
> 04000001 0.002ms (+0.000ms): sched_clock (__schedule)
> 04000000 0.002ms (+0.000ms): schedule (down_write)

this doesnt seem like normal behavior. It seems two tasks are
ping-pong-ing a semaphore but are unable to make any progress. The whole
thing is non-preemptible because this semaphore was taken while in a

(i'd say this is the BKL semaphore - it is quite special in that

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.303 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site