Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: audio panic



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 <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>
> 
> 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).

I have not been able to reproduce this yet (I am using the fixed libossaudio;
I will have to try go back to see if I can trigger the crash with the unfixed
version -- I tried to write a small program to reproduce the problem but it
works without fail).

I have been reading the code around the crash a bit, and I have a question:

 https://nxr.netbsd.org/xref/src/sys/dev/audio/audiodef.h#116

 116         u_int           usrbuf_usedhigh;/* high water mark in bytes */

but usrbuf_usedhigh is used as if it is measured in frames?

 https://nxr.netbsd.org/xref/src/sys/dev/audio/audio.c#4501

 4500         count = uimin(count,
 4501             (track->usrbuf_usedhigh - usrbuf->used) / framesize);
 4502         bytes = count * framesize;
 
(and apparently also throughout the rest of the audio.c).

I wonder if this should be:

 4500         count = uimin(count,
 4501             track->usrbuf_usedhigh - usrbuf->used);

I doubt that this is the cause of the panic though. If I may guess:

 https://nxr.netbsd.org/xref/src/sys/dev/audio/audio.c#4521
 https://nxr.netbsd.org/xref/src/sys/dev/audio/audio.c#4525

 4521                 bytes2 = bytes - bytes1;
 4525                 auring_push(usrbuf, bytes2);
 
does not check whether bytes2 is small enough? (The panic happened when
the software was consuming audio at a much lower rate than it asked for.)

Thanks for looking at this!

-- 
Yorick Hardy


Home | Main Index | Thread Index | Old Index