On Fri, 2006-03-03 at 18:32 +0100, Guennadi Liakhovetski wrote:
> On Thu, 2 Mar 2006, Lee Revell wrote:
> 
> > On Fri, 2006-03-03 at 00:13 +0100, Guennadi Liakhovetski wrote:
> > > On Thu, 2 Mar 2006, Lee Revell wrote:
> > > 
> > > > Try enabling latency tracing in the kernel config and see what you get
> > > > in /proc/latency_trace.
> > 
> > That's for user triggered latency tracing, you want the standard kernel
> > latency tracer:
> > 
> > echo 1 > /proc/sys/kernel/trace_enabled
> > echo 0 > /proc/sys/kernel/preempt_max_latency
> 
> Aha, that was the key:-)
> 
> > Then try nice -n -20 arecord ..., once you get some underruns:
> > 
> > cat /proc/latency_trace
> 
> Ok, there's "nothing" there - nothing near the xrun value I've just got:
> 
> overrun!!! (at least 35.525 ms long)
> 
> and in /proc/latency_trace
> 
> preemption latency trace v1.1.5 on 2.6.15.4-rt16
> --------------------------------------------------------------------
>  latency: 64 us, #36/36, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
>     -----------------
>     | task: softirq-timer/0-3 (uid:0 nice:0 policy:1 rt_prio:1)
>     -----------------
> 
>                  _------=> CPU#            
>                 / _-----=> irqs-off        
>                | / _----=> need-resched    
>                || / _---=> hardirq/softirq 
>                ||| / _--=> preempt-depth   
>                |||| /                      
>                |||||     delay             
>    cmd     pid ||||| time  |   caller      
>       \   /    |||||   \   |   /           
>  pdflush-104   0D.h3    0us : __trace_start_sched_wakeup (try_to_wake_up)
>  pdflush-104   0D.h3    1us : __trace_start_sched_wakeup <<...>-3> (62 0)
>  pdflush-104   0Dnh2    1us : try_to_wake_up <<...>-3> (62 74)
>  pdflush-104   0Dnh2    1us : check_raw_flags (try_to_wake_up)
>  pdflush-104   0Dnh1    2us : preempt_schedule (try_to_wake_up)
>  pdflush-104   0Dnh1    2us : wake_up_process (wakeup_softirqd)
>  pdflush-104   0Dnh1    3us : check_raw_flags (raise_softirq)
>  pdflush-104   0Dnh1    3us : rcu_pending (update_process_times)
>  pdflush-104   0Dnh1    3us : scheduler_tick (update_process_times)
>  pdflush-104   0Dnh1    3us : sched_clock (scheduler_tick)
>  pdflush-104   0Dnh2    4us : task_timeslice (scheduler_tick)
>  pdflush-104   0Dnh1    5us : preempt_schedule (scheduler_tick)
>  pdflush-104   0Dnh1    5us : softlockup_tick (update_process_times)
>  pdflush-104   0Dnh2    6us : note_interrupt (__do_IRQ)
>  pdflush-104   0Dnh2    6us : enable_8259A_irq (__do_IRQ)
>  pdflush-104   0Dnh3    8us : check_raw_flags (enable_8259A_irq)
>  pdflush-104   0Dnh2    8us : preempt_schedule (enable_8259A_irq)
>  pdflush-104   0Dnh1    8us : preempt_schedule (__do_IRQ)
>  pdflush-104   0Dnh1    9us : irq_exit (do_IRQ)
>  pdflush-104   0Dn.1    9us+< (608)
>  pdflush-104   0.n..   41us : preempt_schedule (_mmx_memcpy)
>  pdflush-104   0Dn..   41us : __schedule (preempt_schedule)
>  pdflush-104   0Dn..   41us : profile_hit (__schedule)
>  pdflush-104   0Dn.1   42us : sched_clock (__schedule)
>  pdflush-104   0D..2   42us+: trace_array (__schedule)
>  pdflush-104   0D..2   47us : trace_array <<...>-3> (62 62)
>  pdflush-104   0D..2   48us : trace_array <pdflush-104> (74 78)
>  pdflush-104   0D..2   49us : trace_array <<...>-2984> (76 78)
>  pdflush-104   0D..2   50us+: trace_array (__schedule)
>    <...>-3     0D..2   59us : __switch_to (__schedule)
>    <...>-3     0D..2   60us : __schedule <pdflush-104> (74 62)
>    <...>-3     0...1   61us : trace_stop_sched_switched (__schedule)
>    <...>-3     0D..2   62us : trace_stop_sched_switched <<...>-3> (62 0)
>    <...>-3     0D..2   63us : trace_stop_sched_switched (__schedule)
> 
> 
> vim:ft=help
> 
> Then I tried switching lapic again on, then removing "nmi_watchdog=2", and 
> even "acpi=off" - nothing helps. No more ideas... What now? Can we do some 
> smart arecord profiling?...

So the scheduler is OK.  Try it with the standard kernel.

You may need to go back through previous kernel version to identify
exactly when it broke.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Reply via email to