Dear Tetsuya, On 2019-11-04, Yorick Hardy wrote: > Dear Tetsuya, > > On 2019-11-02, Tetsuya Isaki wrote: > > At Sat, 26 Oct 2019 18:27:36 +0200, > > Yorick Hardy wrote: > > > [ 166.145911] panic: kernel diagnostic assertion "ring->used + n <= > > > ring->capacity" failed: file "/usr/src/local/sys/dev/audio/audiodef.h", > > > line 406 called from audio_track_record:4518: ring->used=32256 n=32256 > > > ring->capacity=61440 > > > [ 166.145911] cpu3: Begin traceback... > > > [ 166.145911] vpanic() at netbsd:vpanic+0x178 > > > [ 166.145911] kern_assert() at netbsd:kern_assert+0x48 > > > [ 166.155927] audioread() at netbsd:audioread+0xb87 > > > > Can you reproduce this? > > > > Thanks, > > --- > > Tetsuya Isaki <is...@pastel-flower.jp / is...@netbsd.org> > > I should be able to try get it to happen again tomorrow (I managed > to trigger the panic on my work computer only so far). The offending > command is: > > ffplay4 -hide_banner -showmode waves -f oss /dev/audio > > (to test the microphone). I think ffmpeg was reading audio much > slower that the driver was providing it (because of the recording > rate mismatch in our oss which you have kindly fixed).
My attempts at reproducing this with audioio did not work. But reverting the libossaudio fixes makes it reproducible with ffplay4 (this is again because ffplay4 reads the audio at 8000Hz instead of 48000Hz). I have a crash dump if that will help (custom kernel): Crash version 9.99.17, image version 9.99.17. System panicked: trap Backtrace from time of crash is available. db> crash> bt _KERNEL_OPT_NAGR() at 0 ?() at ffffb0013f650000 vpanic() at vpanic+0x181 snprintf() at snprintf startlwp() at startlwp calltrap() at calltrap+0x11 dofileread() at dofileread+0x8f sys_read() at sys_read+0x49 syscall() at syscall+0x1d8 --- syscall (number 3) --- 79d6aac42b7a: Kind regards, -- Yorick Hardy