Date: Thu, 18 Mar 2004 20:08:59 +0100
Message-ID: <s5hd67ac6r8.wl@alsa2.suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: andrea@suse.de, mjy@geizhals.at, linux-kernel@vger.kernel.org
Subject: Re: CONFIG_PREEMPT and server workloads
In-Reply-To: <20040318110159.321754d8.akpm@osdl.org>
References: <40591EC1.1060204@geizhals.at>
	<20040318060358.GC29530@dualathlon.random>
	<s5hlllycgz3.wl@alsa2.suse.de>
	<20040318110159.321754d8.akpm@osdl.org>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 13) (Rational FORTRAN) (i386-suse-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1619
Lines: 46

At Thu, 18 Mar 2004 11:01:59 -0800,
Andrew Morton wrote:
> 
> btw, several months ago we discussed the idea of adding a sysctl to the
> ALSA drivers which would cause a dump_stack() to be triggered if the audio
> ISR detected a sound underrun.
> 
> This would be a very useful feature, because it increases the number of
> low-latency developers from O(2) to O(lots).  If some user is complaining
> of underruns we can just ask them to turn on the sysctl and we get a trace
> pointing at the culprit code.
> 
> And believe me, we need the coverage.  There are all sorts of weird code
> paths which were found during the development of the 2.4 low-latency patch.
> i2c drivers, fbdev drivers, all sorts of things which you and I don't
> test.
> 
> I know it's a matter of
> 
> 	if (sysctl_is_set)
> 		dump_stack();
> 
> in snd_pcm_update_hw_ptr_post() somewhere, but my brain burst when working
> out the ALSA sysctl architecture.
> 
> Is this something you could add please?

oh, sorry, maybe i forgot to tell you that it has been already there
:)

	# echo 1 > /proc/asound/card0/pcm0p/xrun_debug

this will show the stacktrace when a buffer overrun/underrun is
detected in the irq handler.  it's not perfect, though.

we can add stacktracing in other nasty places, e.g. when the
unexpected h/w pointer is returned (this is usually because of sloppy
irq handling).


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