Re: port-sparc/55876: sparc tests hang at lib/libossaudio/t_ossaudio

[nia <nia%NetBSD.org@localhost>]

The following reply was made to PR port-sparc/55876; it has been noted by GNATS.

From: nia <nia%NetBSD.org@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: port-sparc/55876: sparc tests hang at lib/libossaudio/t_ossaudio
Date: Mon, 14 Dec 2020 10:40:17 +0000

 On Mon, Dec 14, 2020 at 11:15:13AM +0100, Martin Husemann wrote:
 > t_ossaudio (1/1): 4 test cases
 >     oss_dsp_caps: [0.526702s] Passed.
 >     oss_dsp_init: [0.432928s] Failed: ioctl failed
 >     oss_dsp_trigger_read: [0.323718s] Passed.
 >     oss_dsp_trigger_write: [0.322947s] Passed.
 > [1.733396s]
 > 
 > Failed test cases:
 >     t_ossaudio:oss_dsp_init
 > 
 > Summary for 1 test programs:
 >     3 passed test cases.
 >     1 failed test cases.
 >     0 expected failed test cases.
 >     0 skipped test cases.
 > 
 > 
 > The latter ist not very informative, ktrace says:
 > 
 >   2038   2038 t_ossaudio CALL  ioctl(3,AUDIO_SETINFO,0xe7fff188)
 >   2038   2038 t_ossaudio GIO   fd 3 wrote 136 bytes
 >        "\0\0\M-;\M^@\0\0\0\^B\0\0\0 \0\0\0\^F\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
 >         \0\^B\M-P\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\M-;\M^@\0\0\0\
 >         \^B\0\0\0 \0\0\0\^F\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\
 >         \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-p\0\0\0\0\^C\0\0\0\^B\0\0\
 >         \0\0\0\0\0\^E"
 >   2038   2038 t_ossaudio RET   ioctl -1 errno 22 Invalid argument
 > 
 > 
 > The hardware is:
 > 
 > audiocs0 at ebus0 bar 14 offset 0x200000 line 3: CS4231A
 > audio0 at audiocs0: playback, capture, full duplex
 > audio0: slinear_be:16 -> slinear_le:16 2ch 48000Hz, blk 7680 bytes (40ms) for playback
 > audio0: slinear_be:16 <- slinear_le:16 2ch 48000Hz, blk 7680 bytes (40ms) for recording
 > 
 > 
 > So I would claim this is a QEMU bug.
 > 
 > Martin
 
 Might be a NetBSD bug if the driver on the actual machines is different
 from the driver used by QEMU.
 
 The last failing test case is the only surprising one. What line of the
 test case is it failing on?