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