NetBSD Problem Report #56059

From www@netbsd.org  Tue Mar 16 12:16:43 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id B22831A9217
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 16 Mar 2021 12:16:43 +0000 (UTC)
Message-Id: <20210316121642.49FB51A9239@mollari.NetBSD.org>
Date: Tue, 16 Mar 2021 12:16:42 +0000 (UTC)
From: rvp@SDF.ORG
Reply-To: rvp@SDF.ORG
To: gnats-bugs@NetBSD.org
Subject: speaker(4): system hangs if tone < 100 Hz (_SC_CLK_TCK) is played
X-Send-Pr-Version: www-1.0

>Number:         56059
>Category:       kern
>Synopsis:       speaker(4): system hangs if tone < 100 Hz (_SC_CLK_TCK) is played
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    isaki
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 16 12:20:00 +0000 2021
>Closed-Date:    Sat Apr 10 04:18:19 +0000 2021
>Last-Modified:  Sat Apr 10 04:18:19 +0000 2021
>Originator:     RVP
>Release:        NetBSD-HEAD/amd64 9.99.81 (built 202103152150Z)
>Organization:
>Environment:
NetBSD-HEAD/amd64 9.99.81 (built 202103152150Z)
>Description:
Play a tone < 100 Hz using /dev/speaker. System hangs.

# echo o0 C > /dev/speaker
# echo n1 > /dev/speaker

These command work:

# echo o1 C > /dev/speaker
# echo n9 > /dev/speaker

The latest 9.1-STABLE also behaves the same.
>How-To-Repeat:
See commands above.
>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->isaki
Responsible-Changed-By: isaki@NetBSD.org
Responsible-Changed-When: Thu, 18 Mar 2021 07:58:27 +0000
Responsible-Changed-Why:
Mine.


From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/56059: speaker(4): system hangs if tone < 100 Hz (_SC_CLK_TCK)
 is played
Date: Thu, 18 Mar 2021 08:07:39 +0000 (UTC)

 What I forgot to mention in the bug report was that this speaker
 is a synthesized device--ie. this is not an old-fashioned PPI PC
 speaker. (As far as I can figure it out, my system--an Asus X202E
 laptop--doesn't have a physical PC speaker at all):

 $ fgrep audio /var/run/dmesg.boot 
 hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
 hdaudio0: interrupting at msi1 vec 0
 hdafg0 at hdaudio0: vendor 1106 product 8446
 audio0 at hdafg0: playback, capture, full duplex, independent
 audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
 audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording
 spkr0 at audio0: PC Speaker (synthesized)
 hdafg1 at hdaudio0: vendor 8086 product 2806
 $

 So, the sound is being synthesized in sys/dev/audio/audiobell.c
 and this is really an audio(4) bug.

 Poking around in the sources a bit led me to wonder if generating
 (small) samples for tones < 100Hz was leading to a buffer underrun
 somewhere. And, it seems this is so: raising the hw.audio0.blk_ms
 value "fixes" the kernel hang for me. A value of 15 ms suffices,
 but, then the generated tones seemed "off tune", so I've raised it to
 the max. it will go to on my HW (8KB -- ~42 secs):

 # sudo sysctl -w hw.audio0.blk_ms=50

 Maybe this will help narrow down what needs to be fixed in the
 code.

 -RVP

From: "Tetsuya Isaki" <isaki@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56059 CVS commit: src/sys/dev/audio
Date: Sat, 20 Mar 2021 04:56:52 +0000

 Module Name:	src
 Committed By:	isaki
 Date:		Sat Mar 20 04:56:52 UTC 2021

 Modified Files:
 	src/sys/dev/audio: audiobell.c

 Log Message:
 Fix and improve the buffer length calculation to avoid zero length
 even if blk_ms is small.
 This fixes PR kern/56059.


 To generate a diff of this commit:
 cvs rdiff -u -r1.3 -r1.4 src/sys/dev/audio/audiobell.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Tetsuya Isaki <isaki@pastel-flower.jp>
To: RVP <rvp@SDF.ORG>
Cc: gnats-bugs@netbsd.org,
	kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/56059: speaker(4): system hangs if tone < 100 Hz (_SC_CLK_TCK) is played
Date: Sat, 20 Mar 2021 14:54:33 +0900

 At Thu, 18 Mar 2021 08:07:39 +0000 (UTC),
 RVP wrote:
 > Poking around in the sources a bit led me to wonder if generating
 > (small) samples for tones < 100Hz was leading to a buffer underrun
 > somewhere. And, it seems this is so: raising the hw.audio0.blk_ms
 > value "fixes" the kernel hang for me. A value of 15 ms suffices,
 > but, then the generated tones seemed "off tune", so I've raised it to
 > the max. it will go to on my HW (8KB -- ~42 secs):

 Thank you.  I've just fixed it.

 A trivial correction for just future reference.
 tones < 100Hz is not related. (98Hz "O0G" worked).
 The buffersize was calculated indirectly from the beep's frequency
 and blk_ms.  I omit the details (since it is complicated), but if
 the resulted size becomes less than 32 bytes, then rounding down it
 by 32 bytes caused zero.

 > Maybe this will help narrow down what needs to be fixed in the
 > code.

 Anyway, thank you for your report!
 ---
 Tetsuya Isaki <isaki@pastel-flower.jp / isaki@NetBSD.org>

State-Changed-From-To: open->needs-pullups
State-Changed-By: isaki@NetBSD.org
State-Changed-When: Sat, 20 Mar 2021 06:00:19 +0000
State-Changed-Why:
Fixed in -current. Needs pullups to -9.


From: RVP <rvp@SDF.ORG>
To: Tetsuya Isaki <isaki@pastel-flower.jp>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org
Subject: Re: kern/56059: speaker(4): system hangs if tone < 100 Hz (_SC_CLK_TCK)
 is played
Date: Sat, 20 Mar 2021 07:34:56 +0000 (UTC)

 On Sat, 20 Mar 2021, Tetsuya Isaki wrote:

 > A trivial correction for just future reference.
 > tones < 100Hz is not related. (98Hz "O0G" worked).
 >

 Yes, I noticed that. But, the next one down F# (93Hz) definitely
 hung the system--I just assumed it was a due to rounding, somewhere.

 > The buffersize was calculated indirectly from the beep's frequency
 > and blk_ms.  I omit the details (since it is complicated), but if
 > the resulted size becomes less than 32 bytes, then rounding down it
 > by 32 bytes caused zero.
 >

 Thanks for that explanation: even abbreviated, it is quite clear.

 I'll try the fix out when the new images get built. Feel free to
 close this PR.

 -RVP

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56059 CVS commit: [netbsd-9] src/sys/dev/audio
Date: Tue, 6 Apr 2021 17:44:29 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Tue Apr  6 17:44:29 UTC 2021

 Modified Files:
 	src/sys/dev/audio [netbsd-9]: audiobell.c

 Log Message:
 Pull up following revision(s) (requested by isaki in ticket #1241):

 	sys/dev/audio/audiobell.c: revision 1.4

 Fix and improve the buffer length calculation to avoid zero length
 even if blk_ms is small.

 This fixes PR kern/56059.


 To generate a diff of this commit:
 cvs rdiff -u -r1.3 -r1.3.2.1 src/sys/dev/audio/audiobell.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: needs-pullups->closed
State-Changed-By: isaki@NetBSD.org
State-Changed-When: Sat, 10 Apr 2021 04:18:19 +0000
State-Changed-Why:
[pullup-9 #1241] was applied.


>Unformatted:

Home	PR Database Search