From owner-freebsd-current@FreeBSD.ORG Thu Jan 29 07:55:46 2004 Return-Path: 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 29AB716A4CE; Thu, 29 Jan 2004 07:55:46 -0800 (PST) Received: from lakemtao05.cox.net (lakemtao05.cox.net [68.1.17.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70E7E43D55; Thu, 29 Jan 2004 07:55:44 -0800 (PST) (envelope-from emoe@cox.net) Received: from emoe ([68.97.44.169]) by lakemtao05.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20040129155540.XOJQ29834.lakemtao05.cox.net@emoe>; Thu, 29 Jan 2004 10:55:40 -0500 From: "Erik Moe" To: "Don Lewis" Date: Thu, 29 Jan 2004 09:55:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200401290714.i0T7EY7E085897@gw.catspoiler.org> cc: freebsd-current@FreeBSD.org cc: jhb@FreeBSD.org Subject: RE: 5.2-RELEASE panic in turnstile_wait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 15:55:46 -0000 How long has this been an issue? Was this a problem in 5.1-RELEASE as well, because I had a few mysterious panics in 5.1 where it look like there was memory corruption. Erik > -----Original Message----- > From: Don Lewis [mailto:truckman@FreeBSD.org] > Sent: Thursday, January 29, 2004 1:15 AM > To: emoe@cox.net > Cc: jhb@FreeBSD.org; freebsd-current@FreeBSD.org > Subject: Re: 5.2-RELEASE panic in turnstile_wait > > > On 29 Jan, Erik Moe wrote: > > My loader.conf looks like this... > > > > hw.pci.allow_unsupported_io_range="1" > > hw.ata.atapi_dma="1" > > > > hw.snd.pcm0.vchans=4 > > hw.snd.maxautovchans=4 > > There is a potential buffer overflow in the vchan code that can bzero() > unrelated objects in the kernel heap, like the mutex that you found, and > cause hard to track down system panics. The buffer overflow can be > triggered by certain combinations of sound hardware and software. > > The 5.2-RELEASE errata list contains the following note: > > (9 Jan 2004) The use of multiple vchans (virtual audio channels with > dynamic mixing in software) in the pcm(4) driver has been known to cause > some instability. > > > I finally came up with a fix for this problem that worked and checked it > into the -CURRENT source within the last 24 hours. I'd recommend either > disabling vchans or upgrading to -CURRENT, though you might be able to > retrofit the contents of src/sys/dev/sound/pcm/ and rebuild your kernel. > >