NetBSD Problem Report #52786

From www@NetBSD.org  Mon Dec  4 06:25:24 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-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 C0E187A1A0
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  4 Dec 2017 06:25:24 +0000 (UTC)
Message-Id: <20171204062523.C02D17A1F1@mollari.NetBSD.org>
Date: Mon,  4 Dec 2017 06:25:23 +0000 (UTC)
From: eddie@cottongim.org
Reply-To: eddie@cottongim.org
To: gnats-bugs@NetBSD.org
Subject: Audio not working on SPARCStation20
X-Send-Pr-Version: www-1.0

>Number:         52786
>Category:       port-sparc
>Synopsis:       Audio not working on SPARCStation20
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 04 06:30:00 +0000 2017
>Closed-Date:    Sat Sep 01 05:52:41 +0000 2018
>Last-Modified:  Sat Sep 01 05:52:41 +0000 2018
>Originator:     Eddie Cottongim
>Release:        7.0.1 through 7.1
>Organization:
>Environment:
NetBSD ss20.cottongim.org 8.99.7 NetBSD 8.99.7 (GENERIC) #1: Fri Nov 24 21:53:52 IST 2017  fly@localhost:/home/fly/sparc/sys/arch/sparc/compile/GENERIC sparc
Note this was a "CURRENT" kernel compiled with a fix for port-sparc/5272 to enable ddb to provide some diagnostics.
>Description:
"audioplay sample.au" hangs indefinitely, but can be interrupted by control-C or the kernel debugger. Examination in the debugger shows audioplay in the "dbrifxdt" state.

"cat sample.au > /dev/sound" (or /dev/audio) locks the machine and cannot be recovered by control-C, and the kernel debugger cannot be entered.

Commands were done from the console, with no X11 running.

I have changed sample rates, formats (with audioctl, for example to match the format of the audio file above) etc without any noticeable difference.

Behavior is similar in 7.0.1 and 7.1, though I recall almost any sound command locking the machine in 7.0.1 and stability seems better in "CURRENT" as of about 11/25/17.

I recall at some point hearing some static (not reproducible), so I think the hardware has at least a chance of making some noise.

Other info of interest:

from dmesg:
dbri0: speakerbox detected
dbri0: cs4215 rev E found at offset 8
audio0 at dbri0: full duplex, playback, capture, mmap
dbri0: Virtual format configured - Format SLINEAR, precision 16, channels 2, frequency 48000
dbri0: Latency: 64 milliseconds

audioctl -a
name=CS4215
version=
config=dbri
encodings=slinear_be:16,slinear_le:16*,ulinear_le:16*,ulinear_be:16*,mulaw:8*,alaw:8*
properties=full_duplex,mmap
full_duplex=0
fullduplex=0
blocksize=256
hiwat=256
lowat=192
monitor_gain=0
mode=play
play.rate=8000
play.channels=1
play.precision=8
play.encoding=mulaw
play.gain=124
play.balance=32
play.port=0x0
play.avail_ports=0x0
play.seek=0
play.samples=0
play.eof=0
play.pause=0
play.error=0
play.waiting=0
play.open=1
play.active=0
play.buffer_size=65536
record.rate=8000
record.channels=1
record.precision=8
record.encoding=mulaw
record.gain=0
record.balance=32
record.port=0x2
record.avail_ports=0x3
record.seek=0
record.samples=0
record.eof=0
record.pause=0
record.error=0
record.waiting=0
record.open=0
record.active=0
record.buffer_size=65536
record.errors=0



>How-To-Repeat:
Basic audio commands such as audioplay or "cat" data to the audio devices produce no sound, and the latter hangs the machine.
>Fix:

>Release-Note:

>Audit-Trail:
From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/52786: Audio not working on SPARCStation20
Date: Mon, 4 Dec 2017 12:14:31 -0500

 I'm in SPARC mode right now, I'll deal with this.

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: port-sparc-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: port-sparc/52786: Audio not working on SPARCStation20
Date: Tue, 05 Dec 2017 14:15:16 +1100

 with -current i see similar.  using audio play, at first it
 claims to be spinning in system space:

 load: 0.29  cmd: audioplay 6064 [0xede14bd0/1] 0.01u 12.48s 45% 1016k
 load: 0.71  cmd: audioplay 6064 [0xede14bd0/1] 0.01u 67.82s 95% 1016k
 [ ... ]

 but 0xede14bd0 is a userland address.  at this point i tried to
 login remotely again, and it locked up.  no response on ssh now.

 i was able to drop into ddb, but the audioplay thread has no
 stack trace in the kernel.


 .mrg.

From: Michael <macallan@netbsd.org>
To: 
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-sparc/52786: Audio not working on SPARCStation20
Date: Wed, 6 Dec 2017 17:39:25 -0500

 Hmm, mixerctl -a gives a hard hang here. I tried mpg123 which seems to
 be doing *something* but nothing audible.

From: matthew green <mrg@eterna.com.au>
To: port-sparc-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Cc: 
Subject: re: port-sparc/52786: Audio not working on SPARCStation20
Date: Thu, 07 Dec 2017 12:48:21 +1100

 BTW, i tested this with -current, -8, -7 and -6 and they're
 all broken.  ouch.


 .mrg.

From: Michael <macallan@netbsd.org>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-sparc/52786: Audio not working on SPARCStation20
Date: Thu, 7 Dec 2017 10:55:23 -0500

 Hmm, last commit to dbri.c is from 2013 - I *thought* I used it a
 little more recently. Guess I didn't.

From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/52786: Audio not working on SPARCStation20
Date: Thu, 7 Dec 2017 11:02:35 -0600 (CST)

 On Thu, 7 Dec 2017, Michael <macallan@netbsd.org> wrote:

 > Hmm, last commit to dbri.c is from 2013 - I *thought* I used it a
 > little more recently. Guess I didn't.

 While poking at DBRI stuff, perhaps PR port-sparc/34046 could get some
 attention as well?

 While not in service at present, the SS10 system is more accessible for
 testing than other SPARC systems I have.  (Digging out one of my
 SUNW,speakerbox units is unlikely at this time, though.)

 If I could safely get an SS20 down from the high shelf where it has
 been stored, I could try slipping the MAGMA card into it for comparison.
 That is unlikely to be possible for several weeks, though.

 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

From: matthew green <mrg@eterna.com.au>
To: port-sparc-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Cc: 
Subject: re: port-sparc/52786: Audio not working on SPARCStation20
Date: Fri, 08 Dec 2017 06:58:27 +1100

 we broke this with the audiomp merge.  it triggers LOCKDEBUG.

 callers of dbri_command_send() are inconsistent about whether
 the interrupt lock is taken or not.  i've got a fix coming.

From: Michael <macallan@netbsd.org>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-sparc/52786: Audio not working on SPARCStation20
Date: Thu, 7 Dec 2017 17:36:21 -0500

 >  we broke this with the audiomp merge.  it triggers LOCKDEBUG.

 Might explain why I didn't hit it - the sparcbook's got only one CPU
 and SMP kernels were too unstable to do much on the SS20.

 >  callers of dbri_command_send() are inconsistent about whether
 >  the interrupt lock is taken or not.  i've got a fix coming.

 Nice!

From: matthew green <mrg@eterna.com.au>
To: Michael <macallan@netbsd.org>
Cc: gnats-bugs@NetBSD.org
Subject: re: port-sparc/52786: Audio not working on SPARCStation20
Date: Fri, 08 Dec 2017 18:54:56 +1100

 Michael writes:
 > >  we broke this with the audiomp merge.  it triggers LOCKDEBUG.
 > 
 > Might explain why I didn't hit it - the sparcbook's got only one CPU
 > and SMP kernels were too unstable to do much on the SS20.
 > 
 > >  callers of dbri_command_send() are inconsistent about whether
 > >  the interrupt lock is taken or not.  i've got a fix coming.

 i've commited my fixes, which makes audio not hang the
 system or the proceess, but doesn't make audio work yet.

 so, progress but no success yet.


 .mrg.

From: "Michael Lorenz" <macallan@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52786 CVS commit: src/sys/dev
Date: Thu, 21 Dec 2017 21:56:29 +0000

 Module Name:	src
 Committed By:	macallan
 Date:		Thu Dec 21 21:56:29 UTC 2017

 Modified Files:
 	src/sys/dev/ic: cs4215reg.h
 	src/sys/dev/sbus: dbri.c dbrivar.h

 Log Message:
 overhaul the dbri driver and make it work again in the New Order Of Things
 - fix switching between control and data mode
 - make sure interrupts can happen in control mode
 - implement audioif.commit_settings()
 - switch to control mode only if needed - for changes in sample rate or format
   but not for things like volume control
 should fix PR 52786


 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.5 src/sys/dev/ic/cs4215reg.h
 cvs rdiff -u -r1.36 -r1.37 src/sys/dev/sbus/dbri.c
 cvs rdiff -u -r1.14 -r1.15 src/sys/dev/sbus/dbrivar.h

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

From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/52786: Audio not working on SPARCStation20
Date: Tue, 26 Dec 2017 03:48:56 -0500

 >  > Might explain why I didn't hit it - the sparcbook's got only one CPU
 >  > and SMP kernels were too unstable to do much on the SS20.
 >  >   
 >  > >  callers of dbri_command_send() are inconsistent about whether
 >  > >  the interrupt lock is taken or not.  i've got a fix coming.  
 >  
 >  i've commited my fixes, which makes audio not hang the
 >  system or the proceess, but doesn't make audio work yet.

 I found out why I didn't hit this bug on the SPARCbook.
 The problem is that switching the codec from data mode to control mode
 never really worked - we were missing a reset of the CHI, to make it
 forget the pipe setup for data mode and accept the new setup for
 control mode. That's why enabling control mode works the first time
 ( when the chip is cold ) but not after that, when we've been in data
 mode at least once.
 Unlike the SS20, the SPARCbook can control power to a few devices,
 including the dbri. The driver will keep the dbri powered down until
 someone open()s the attached audio device, so every time we actually
 program parameters the chip will come up out of cold, control mode will
 work once etc., at least as long as the userland program will only set
 parameters once and then just keep playing audio.
 I'll request pullup to 8.0 as soon as someone other than me confirms
 that things work now.

From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52786 CVS commit: [netbsd-8] src/sys/dev
Date: Sat, 13 Jan 2018 05:40:25 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Sat Jan 13 05:40:25 UTC 2018

 Modified Files:
 	src/sys/dev/ic [netbsd-8]: cs4215reg.h
 	src/sys/dev/sbus [netbsd-8]: dbri.c dbrivar.h

 Log Message:
 Pull up following revision(s) (requested by macallan in ticket #476):
 	sys/dev/sbus/dbrivar.h: revision 1.15
 	sys/dev/ic/cs4215reg.h: revision 1.5
 	sys/dev/sbus/dbri.c: revision 1.37
 overhaul the dbri driver and make it work again in the New Order Of Things
 - fix switching between control and data mode
 - make sure interrupts can happen in control mode
 - implement audioif.commit_settings()
 - switch to control mode only if needed - for changes in sample rate or format
   but not for things like volume control
 should fix PR 52786


 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.4.80.1 src/sys/dev/ic/cs4215reg.h
 cvs rdiff -u -r1.35 -r1.35.22.1 src/sys/dev/sbus/dbri.c
 cvs rdiff -u -r1.13 -r1.13.42.1 src/sys/dev/sbus/dbrivar.h

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

State-Changed-From-To: open->pending-pullups
State-Changed-By: macallan@NetBSD.org
State-Changed-When: Sun, 14 Jan 2018 06:09:57 +0000
State-Changed-Why:
fixed in -current, pullup-8 tickets 476 and 499


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52786 CVS commit: [netbsd-7] src/sys/dev
Date: Wed, 21 Mar 2018 12:04:35 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Mar 21 12:04:35 UTC 2018

 Modified Files:
 	src/sys/dev/ic [netbsd-7]: cs4215reg.h
 	src/sys/dev/sbus [netbsd-7]: dbri.c dbrivar.h

 Log Message:
 Pull up following revision(s) (requested by mrg in ticket #1586):
 	sys/dev/sbus/dbrivar.h: revision 1.14
 	sys/dev/sbus/dbrivar.h: revision 1.15
 	sys/dev/ic/cs4215reg.h: revision 1.5
 	sys/dev/sbus/dbri.c: revision 1.36
 	sys/dev/sbus/dbri.c: revision 1.37
 	sys/dev/sbus/dbri.c: revision 1.38

 fix audiomp bugs:
 - switch from tsleep/wakeup to condvar
 - fix locking in a bunch of places.  there were several locking
   against myself issues.
 also:
 - don't let dbri_process_interrupt_buffer() loop more than once
   over the array of intrs.

 this fixes hangs when using audio on ss20 in -current, but does
 not make audio work.  it eventually times out with eg:
 dbri0: switching to control mode timed out (0 f6)
 and may leave a sample in the audio buffer repeating.

 overhaul the dbri driver and make it work again in the New Order Of Things
 - fix switching between control and data mode
 - make sure interrupts can happen in control mode
 - implement audioif.commit_settings()
 - switch to control mode only if needed - for changes in sample rate or format
   but not for things like volume control
 should fix PR 52786

 fix several KASSERT()s and locking in a few places.

 fixes DIAGNOSTIC kernels and still plays.


 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.4.62.1 src/sys/dev/ic/cs4215reg.h
 cvs rdiff -u -r1.35 -r1.35.4.1 src/sys/dev/sbus/dbri.c
 cvs rdiff -u -r1.13 -r1.13.24.1 src/sys/dev/sbus/dbrivar.h

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

State-Changed-From-To: pending-pullups->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 19 Jun 2018 01:02:14 +0000
State-Changed-Why:
This got fixed & even pulled up to netbsd-7 and netbsd-8. Does it work for you, too?


From: Eddie Cottongim <eddie_cottongim@cox.net>
To: gnats-bugs@gnats.netbsd.org
Cc: 
Subject: Re: port-sparc/52786
Date: Fri, 31 Aug 2018 18:15:11 -0400

 I tried this on the same SPARCStation 20 with:  NetBSD 8.0 (GENERIC.MP) 
 and it appears to be fixed.

 I used audioplay to play a few different .wav and .au files.

 If any other testing combinations are needed, please let me know. Thanks 
 for looking into this.


State-Changed-From-To: feedback->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Sat, 01 Sep 2018 05:52:41 +0000
State-Changed-Why:
Confirmed fixed, thanks for the PR!


>Unformatted:

Home	PR Database Search