kern/74432: Yamaha DS-1E produces "kernel: Danger! pcm0:play:2 bufsoft size increasing from 3584 to 3956 after CHANNEL_SETBLOCKSIZE()"

Mark Linimon linimon at lonesome.com
Fri Jul 6 03:00:17 UTC 2007


The following reply was made to PR kern/74432; it has been noted by GNATS.

From: linimon at lonesome.com (Mark Linimon)
To: bug-followup at FreeBSD.org
Cc:  
Subject: Re: kern/74432: Yamaha DS-1E produces "kernel: Danger! pcm0:play:2 bufsoft size increasing from 3584 to 3956 after CHANNEL_SETBLOCKSIZE()"
Date: Thu, 5 Jul 2007 21:58:44 -0500

 ----- Forwarded message from Federico Galvez-Durand Besnard <fico at del.ufrj.br> -----
 
 
 Regarding this issue, Sam Lawrance <lawrance at FreeBSD.org> wrote to me in 
 Oct 2005.
 Unfortunately, I haven't tested Don Lewis' patch yet.
 When Sam's message arrived, I had already moved on to another solution 
 for my problem using OhPhone.
 Everything else worked just fine with PCM in that machine, including Skype.
 I just looked into the pcm/channel.c code in 6.2-p1, the code mentioned 
 in the patch seems to be the same yet. I suppose the problem with this 
 Yamaha DS-1E is still there.
 If I get OhPhone to work again on that machine and reproduce the same 
 error, I may try this patch. It is the only application provoking this 
 problem.
 
 I hope this helps.
 Fico
 
 P.S.: This is the source message I received from Sam Lawrance:
 
 From - Sat Oct  1 09:08:41 2005
 X-Account-Key: account3
 X-UIDL: AKi!!``P"!T$>"!6IH"!
 X-Mozilla-Status: 0011
 X-Mozilla-Status2: 00000000
 Return-Path: <lawrance at FreeBSD.org>
 Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84])
 	by zeus.del.ufrj.br (8.12.9p1/8.12.9) with ESMTP id j914GP7B028171
 	for <fico at del.ufrj.br>; Sat, 1 Oct 2005 01:16:28 -0300 (BRT)
 Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au 
 [61.8.0.86])
 	by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id 
 	j914GHP7023609;
 	Sat, 1 Oct 2005 14:16:17 +1000
 Received: from dirk.no.domain (ppp287C.dyn.pacific.net.au [61.8.40.124])
 	by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id 
 	j914GF8w020745;
 	Sat, 1 Oct 2005 14:16:16 +1000
 Date: Sat, 1 Oct 2005 14:16:55 +1000
 From: Sam Lawrance <lawrance at FreeBSD.org>
 To: Federico Galvez-Durand Besnard <fico at del.ufrj.br>,
   bug-followup at FreeBSD.org
 Subject: Re: ports/74432: ohphone 1.4.1 crashes in 5.3 Stable
 Message-ID: <20051001141655.39235a4d at dirk.no.domain>
 In-Reply-To: <43318241.8080803 at del.ufrj.br>
 References: <200509071346.j87DkdVm091458 at freefall.freebsd.org>
 	<43318241.8080803 at del.ufrj.br>
 X-Mailer: Sylpheed-Claws 1.9.14 (GTK+ 2.6.10; i386-portbld-freebsd6.0)
 Mime-Version: 1.0
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: 7bit
 X-UIDL: AKi!!``P"!T$>"!6IH"!
 
 I asked Don Lewis to have a look, since he added the code that produces
 the warning you are seeing.  This appears to be a kernel issue
 (provoked, but not caused by ohphone).
 
 From: Don Lewis <truckman at FreeBSD.org>
 To: lawrance at FreeBSD.org
 Subject: Re: ports/74432
 Date: Wed, 07 Sep 2005 09:50:34 -0700 (PDT)
 
 On  8 Sep, Sam Lawrance wrote:
 >Wondering if I can ask your opinion.  I notice you added this to
 >src/sys/dev/sound/pcm/channel.c:
 >
 >        /* Decrease the size of bufsoft after decreasing bufhard. */
 >        maxsize = sndbuf_getsize(b);
 >        if (reqblksz * blkcnt > maxsize)
 >                maxsize = reqblksz * blkcnt;
 >        if (maxsize > sndbuf_getsize(bs))
 >                printf("Danger! %s bufsoft size increasing from %d to
 >%d after CHANNEL_SETBLOCKSIZE()\n", c->name, sndbuf_getsize(bs),
 >maxsize); if (sndbuf_getsize(bs) != maxsize || sndbuf_getblksz(bs) !=
 >reqblksz) { ret = sndbuf_remalloc(bs, maxsize/reqblksz, reqblksz);
 >                if (ret)
 >                        goto out1;
 >        }
 >
 >This guy can reproduce that warning:
 >http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/74432
 
 It looks to me like the problem is that the Yamaha hardware only
 supports a fixed block size at any given sample rate, and that the
 application is requesting a larger block size.  I suspect that the
 correct fix is to replace all references to reqblksz in the code you
 cited above with sndbuf_getblksz(bs).  The code before the
 CHANNEL_SETBLOCKSIZE() call should not be modified.
 
 This change should be extensively tested on other hardware and with
 other applications before being committed.
 
 ----- End forwarded message -----


More information about the freebsd-bugs mailing list