From owner-freebsd-hackers Sun Apr 20 23:14:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA18183 for hackers-outgoing; Sun, 20 Apr 1997 23:14:45 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA18177 for ; Sun, 20 Apr 1997 23:14:41 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id PAA08016; Mon, 21 Apr 1997 15:43:51 +0930 (CST) From: Michael Smith Message-Id: <199704210613.PAA08016@genesis.atrad.adelaide.edu.au> Subject: Re: Apparent bug in /dev/spkr driver (fwd) In-Reply-To: from Alfred Perlstein at "Apr 17, 97 11:56:35 am" To: perlsta@fang.cs.sunyit.edu (Alfred Perlstein) Date: Mon, 21 Apr 1997 15:43:50 +0930 (CST) Cc: hans@brandinnovators.com, dwhite@resnet.uoregon.edu, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm just looking at this... Alfred Perlstein stands accused of saying: > > Maybe this helps... > > > > In the speaker driver it does: > > > > n = uio->uio_resid; > > cp = spkr_inbuf->b_un.b_addr; > > if (!(error = uiomove(cp, n, uio))) > > playstring(cp, n); > > > > According to a discussion I had with Bruce Evans because of a > > similar problem in a home grown driver, it seems that uiomove() > > can sleep and that therefore another uiomove() may mess up the > > driver's buffers. The speaker driver should lock its buffer before > > doing the uiomove(). Actually, many drivers do not lock their private > > I/O buffers before uiomove()-ing. Hope this helps a bit. The driver claims to only permit a single opener, which as Bruce has pointed out before is pointless as fd's are duplicated across forks. Still, unless there is room for two callers to hop in at the same time, there shouldn't actually be any trouble. Can someone post the sequence of events that leads to 'death' on the part of the driver? > innner loop that you posted? or should i just leave it to the experts? i > would really like to help though. Some testing and so forth will be handy. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[