Re: TESTERS WANTED: audio drivers

[Andreas Müller <mailinglists%andreas-mueller.com@localhost>]

Hi Matthew,

matthew green <mrg <at> eterna.com.au> writes:

> 
> 
> hi folks.
> 
> we've just merged the SMP audio code to -current, and there are
> several older audio drivers that have not been tested.  we are
> looking for testers for these drivers:
> 
>       pxaacu(4)
> 
> which appears to be available on both GUMSTIX/LUBBOCK for evbarm
> and also hpcmarm NETBOOKPRO.

I'm about to port NetBSD to a new evbarm flavor (TrizepsIV SoM with ConXS
baseboard from Keith&Koep [1]). Before anyone asks: the port is not really
useful right now, because some devices like the ethernet controller are not
working at the moment.

I will try to use this board as a low-power networked MP3 player. The pxaacu
driver compiles fine, however I've got a kernel panic when I try to write data
to /dev/audio. I don't know whether this is related to the changes mentioned
above or it's just me doing some stupid stuff. Here is an excerpt of what I get
on the console:

# cat /dev/random > /dev/audio
Mutex error: mutex_vector_enter: locking against myself

lock address : 0x00000000c1304260
current cpu  :                  0
current lwp  : 0x00000000c143d800
owner field  : 0x00000000c143d800 wait/spin:                0/0

panic: lock error
Stopped in pid 99.1 (sh) at     netbsd:cpu_Debugger+0x4:        bx      r14
db> t
netbsd:vpanic+0xc
        scp=0xc036c6a0 rlv=0xc036c934 (netbsd:printf_nolog)
        rsp=0xc770fafc rfp=0xc770fb10
        r7=0xc043f528
netbsd:panic+0x10
        scp=0xc036c91c rlv=0xc0365368 (netbsd:lockdebug_abort+0x38)
        rsp=0xc770fb24 rfp=0xc770fb4c
netbsd:lockdebug_abort+0xc
        scp=0xc036533c rlv=0xc02a0a78 (netbsd:mutex_enter+0x1d0)
        rsp=0xc770fb50 rfp=0xc770fb78
        r7=0xc143d800 r6=0xc0537ff8
        r5=0xc143d800 r4=0xc1304260
netbsd:mutex_enter+0xc
        scp=0xc02a08b4 rlv=0xc0331f6c (netbsd:acu_codec_write+0x3c)
        rsp=0xc770fb7c rfp=0xc770fb9c
        r10=0x00000002 r8=0xc1304260
        r7=0x00000ff0 r6=0x0000000b r5=0x00000026 r4=0xc13041e8
netbsd:acu_codec_write+0xc
        scp=0xc0331f3c rlv=0xc02007fc (netbsd:ac97_write+0x54)
        rsp=0xc770fba0 rfp=0xc770fbbc
        r8=0x00000000 r7=0x00000ff0
        r6=0x00000026 r5=0x0000000b r4=0xc137d000
netbsd:ac97_write+0xc
        scp=0xc02007b4 rlv=0xc0200d84 (netbsd:ac97_restore_shadow+0x154)
        rsp=0xc770fbc0 rfp=0xc770fbf0
        r6=0xc13041f4 r5=0x0000c300
        r4=0xc137d000
netbsd:ac97_restore_shadow+0xc
        scp=0xc0200c3c rlv=0xc0331a60 (netbsd:acu_open+0xcc)
        rsp=0xc770fbf4 rfp=0xc770fc10
        r10=0x00000002 r8=0x00000000
        r7=0xc13041ec r6=0xc13041f4 r5=0x00001388 r4=0xc13041e8
netbsd:acu_open+0xc
        scp=0xc03319a0 rlv=0xc020b1f8 (netbsd:audio_open+0x88)
        rsp=0xc770fc14 rfp=0xc770fcc8
        r7=0xc0518d18 r6=0x00002480
        r5=0x00000402 r4=0xc132e000
[...]

Do you have any hint for me?

At the moment, I'm using NetBSD kernel 6.99.3, with sources updated today
(2012-02-20) from CVS.

Regards,
Andreas

[1] 
<http://www.keith-koep.com/produkte/xscale-arm-embedded/trizeps4-pxa270.html>