linux-kernel - Re: 2.6.19-rc6-rt8: alsa xruns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061129195144.GA8676@elte.hu>
Date:	Wed, 29 Nov 2006 20:51:44 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Fernando Lopez-Lezcano <nando@...ma.Stanford.EDU>
Cc:	"Linux-Kernel," <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.19-rc6-rt8: alsa xruns

* Fernando Lopez-Lezcano <nando@...ma.Stanford.EDU> wrote:

> > ok, i reproduced something similar on one of my boxes and it turned 
> > out to be a tracer bug. I've uploaded -rt10, could you try it? (The 
> > xruns will likely remain, but at least the tracer should be more 
> > usable now to find out the reason for the xruns.)
> 
> I'm testing -rt10 right now (your binary rpm). Looks like the number 
> and length of the xruns went down, at least for now. All below 2mSec - 
> jack is running 128x2 @ 48000Hz. I'll let it run for a while and 
> report the traces (I have a script that collects all traces above 
> 60us, but not all xruns trigger a trace).

ok.

How do you gather the traces, are you using manual control of tracing 
via prctl(0,1) / prctl(0,0) - or the built-in wakeup tracing method? The 
wakeup tracing method will detect fundamental problems in -rt 
scheduling, but other types of delays can be better debugged via 
explicit tracing. [jackd used to have the gettimeofday(0,1)/(0,0) hack - 
this API hack has been replaced by prctl(0,1)/(0,0) to start/stop 
tracing] Take a look at linux/scripts/trace-it.c on how to set up 
manually triggered tracing. [if you do that then all you need to do is 
to start/stop the trace - the kernel will do a maximum search and will 
record the longest delay between start/stop calls.]

Also, can you see the xruns/latencies with latencytest too? (That one 
might be easier to reproduce for me.)

Also, my experience is that if there's a short succession of latencies 
after each other, then it's usually the first trace that makes most 
sense to analyze - the others might just be 'followup' or 'secondary' 
delays caused by the tracing/printing overhead of the first trace. So 
generally i concentrate on the first trace. But if the traces are 
reasonably apart then each of them makes sense - and sometimes one trace 
is more informative than another.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/