From owner-freebsd-current@FreeBSD.ORG  Sun Jan  4 22:58:18 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B90D116A4CE
	for <current@FreeBSD.org>; Sun,  4 Jan 2004 22:58:18 -0800 (PST)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 78A2243D39
	for <current@FreeBSD.org>; Sun,  4 Jan 2004 22:58:17 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i056w97E010527;
	Sun, 4 Jan 2004 22:58:13 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200401050658.i056w97E010527@gw.catspoiler.org>
Date: Sun, 4 Jan 2004 22:58:09 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
To: shoesoft@gmx.net
In-Reply-To: <1073256379.801.24.camel@shoeserv.freebsd>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: current@FreeBSD.org
Subject: Re: page fault panic tracked down (selwakeuppri())
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jan 2004 06:58:18 -0000

On  4 Jan, Stefan Ehmann wrote:

> panic: bad bufsize
> #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1  0xc04e5198 in boot (howto=256) at
> /usr/src/sys/kern/kern_shutdown.c:372
> #2  0xc04e5527 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #3  0xc07ec648 in feed_vchan_s16 () from /boot/kernel/snd_pcm.ko
> #4  0xc07e2c6d in sndbuf_feed () from /boot/kernel/snd_pcm.ko
> #5  0xc07e3225 in chn_wrfeed () from /boot/kernel/snd_pcm.ko
> #6  0xc07e327c in chn_wrintr () from /boot/kernel/snd_pcm.ko
> #7  0xc07e3990 in chn_intr () from /boot/kernel/snd_pcm.ko
> #8  0xc07fca2f in csa_intr () from /boot/kernel/snd_csa.ko
> #9  0xc07fb724 in csa_intr () from /boot/kernel/snd_csa.ko
> #10 0xc04d1692 in ithread_loop (arg=0xc1737b00)
>     at /usr/src/sys/kern/kern_intr.c:544
> #11 0xc04d0684 in fork_exit (callout=0xc04d1500 <ithread_loop>, arg=0x0,
>     frame=0x0) at /usr/src/sys/kern/kern_fork.c:796

Since you mentioned that the panics tend to happen when switching
between songs, I wonder if chn_wrintr() is getting called while the
channel is being closed to flush the sound buffer.  Because the channel
mutex is locked across the call to chn_flush() in dsp_close(), any sound
interrupts that happen during this time will be deferred until after the
channel mutex is released at the end of dsp_close().  There are various
places in the code the re-allocate the buffers and it looks like it
might be possible for the feed_vchan_s16() to use stale buffer pointers,
but it is very difficult to follow this code.

I wonder if the proper fix would be for chn_intr() to bail out if the
CHN_F_RUNNING flag is not set ...