Date: Mon, 21 Apr 1997 15:43:50 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: perlsta@fang.cs.sunyit.edu (Alfred Perlstein) Cc: hans@brandinnovators.com, dwhite@resnet.uoregon.edu, hackers@freebsd.org Subject: Re: Apparent bug in /dev/spkr driver (fwd) Message-ID: <199704210613.PAA08016@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.95.970417115214.11465A-100000@fang.cs.sunyit.edu> from Alfred Perlstein at "Apr 17, 97 11:56:35 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704210613.PAA08016>