From owner-freebsd-current@FreeBSD.ORG Mon Dec 15 10:59:20 2003 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 C291F16A4CE; Mon, 15 Dec 2003 10:59:20 -0800 (PST) Received: from hak.cnd.mcgill.ca (hak.cnd.mcgill.ca [132.216.11.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4269743D3C; Mon, 15 Dec 2003 10:59:12 -0800 (PST) (envelope-from mat@hak.cnd.mcgill.ca) Received: from hak.cnd.mcgill.ca (localhost [127.0.0.1]) by hak.cnd.mcgill.ca (8.12.9/8.12.8) with ESMTP id hBFIuD15069342; Mon, 15 Dec 2003 13:56:13 -0500 (EST) (envelope-from mat@hak.cnd.mcgill.ca) Received: (from mat@localhost) by hak.cnd.mcgill.ca (8.12.9/8.12.8/Submit) id hBFIu6Uu069341; Mon, 15 Dec 2003 13:56:06 -0500 (EST) Date: Mon, 15 Dec 2003 13:56:06 -0500 From: Mathew Kanner To: Munehiro Matsuda Message-ID: <20031215185606.GA63202@cnd.mcgill.ca> References: <200312151501.hBFF1Abp088978@fledge.watson.org> <3FDDD7AE.7040801@bis.midco.net> <20031216.013254.74722020.haro@h4.dion.ne.jp> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20031216.013254.74722020.haro@h4.dion.ne.jp> User-Agent: Mutt/1.4.1i Organization: I speak for myself, operating in Montreal, CANADA X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hak.cnd.mcgill.ca cc: re@freebsd.org cc: pmes@bis.midco.net cc: current@freebsd.org Subject: Re: 5.2-RELEASE TODO 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: Mon, 15 Dec 2003 18:59:20 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Dec 15, Munehiro Matsuda wrote: > From: Peter Schultz > Date: Mon, 15 Dec 2003 09:47:58 -0600 > ::Robert Watson wrote: > ::> Testing focuses for 5.2-RELEASE > ::> > ::> +---------------------------------------------------------------------------+ > ::> | Issue | Status |Responsible| Description | > ::> |--------------+-------------+-----------+----------------------------------| > ::> | | | |The PCM audio framework and device| > ::> | | | |drivers have been locked and free | > ::> |PCM locking | | |of Giant for quite a while, but | > ::> |and |Needs testing|-- |LOR problems persist along with | > ::> |performance | | |reports of poor audio performance | > ::> |issues | | |under load. These problems are | > ::> | | | |believed to have been corrected, | > ::> | | | |but more testing is desired. | > ::> |--------------+-------------+-----------+----------------------------------| > :: > > ::This longstanding problem has now been fixed as far as I'm concerned. > ::Xmms hasn't played mp3s without a hicup for me on -CURRENT since at > ::least a year, if not two or more. It's been so long I can't recall. > :: > ::I'm testing with a soundblaster live! value card: > ::pcm0: port 0xef20-0xef3f irq 17 at device 17.0 on pci0 > ::pcm0: > :: > ::I'm running a -CURRENT SMP kernel on a Tyan S1832DL w/dual PII 350s. I > ::only assume it's working with 5.2 RC1. > :: > ::Pete... > > Hi, > > I still get LOR with my sound card and some hicup under disk load, with > today's 5.2-CURRENT. It's a UP system with following sound card. > > pcm0: port 0xfcac-0xfcaf,0xfc00-0xfc3f mem 0xfecf0000-0xfecf7fff irq 9 at device 9.0 on pci0 > pcm0: > > Also, here's hand written LOR message: > > lock order reversal > 1st 0xc3405440 pcm0 (sound softc) @ dev/sound/pci/ds1.c:734 > 2nd 0xc3405080 pcm0:play:0 (pcm play channel) @ dev/sound/pcm/channel.c:480 > Stack backtrace: > .... > witness_lock(c3405080,0,c07a8705,1e0,c33f7300) at witness_lock+0x672 > _mtx_lock_flags(c3405080,0,c07a8705,1e0,0) at _mtx_lock_flags+0xba > chn_intr(c33f7300,104,4,4,c3405240) at chn_intr+0x2f > ds_intr(c340b4000,0,c07b3baa,21f,c334c1c4) at ds_intr+0xf5 > ithread_loop(c1856900,d03a7d48,c07b3a24,311,3473635f) at ithread_loop+0x192 > fork_exit(c059da00,c1856900,d03a7d48) at fork_exit+0xb4 > fork_trampoline() at fork_trampoline+0x8 Hello, This LOR is mostly harmless. Please try the attached patch the avoid it. Since this bug isn't critical, I won't commit it to 5.2 unless instructed otherwise by the -re team. Thanks, --Mat -- Having your book made into a movie is like having your ox made into a bouillon cube. - Bill Neely --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ds1.patch" Index: ds1.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sound/pci/ds1.c,v retrieving revision 1.36 diff -u -r1.36 ds1.c --- ds1.c 2 Sep 2003 17:30:37 -0000 1.36 +++ ds1.c 15 Dec 2003 18:49:02 -0000 @@ -729,8 +729,15 @@ ds_intr(void *p) { struct sc_info *sc = (struct sc_info *)p; - u_int32_t i, x; + int i, pch, rch; + /* + * In this particular scenerio, sc->lock only protects + * against hardware access. Other immutables, like the lock itself and + * the pointers to the pcm channel structure can be accessed safely without + * the lock. + */ + pch = rch = 0; snd_mtxlock(sc->lock); i = ds_rd(sc, YDSXGR_STATUS, 4); if (i & 0x00008000) @@ -739,25 +746,26 @@ ds_wr(sc, YDSXGR_STATUS, i & 0x80008000, 4); sc->currbank = ds_rd(sc, YDSXGR_CTRLSELECT, 4) & 0x00000001; - x = 0; - for (i = 0; i < DS1_CHANS; i++) { - if (sc->pch[i].run) { - x = 1; - chn_intr(sc->pch[i].channel); - } - } - for (i = 0; i < 2; i++) { - if (sc->rch[i].run) { - x = 1; - chn_intr(sc->rch[i].channel); - } - } + for (i = 0; i < DS1_CHANS; i++) + if (sc->pch[i].run) + pch |= 1<rch[i].run) + rch |= 1<lock); + + for (i = 0; ipch[i].channel); + + for (i = 0; i<2; i++) + if ( rch & (1<rch[i].channel); } /* -------------------------------------------------------------------- */ --uAKRQypu60I7Lcqm--