Date: Sun, 04 Jan 2004 23:35:00 -0000 From: Don Lewis <truckman@FreeBSD.org> To: shoesoft@gmx.net Cc: current@FreeBSD.org Subject: Re: page fault panic tracked down (selwakeuppri()) Message-ID: <200401042334.i04NYi7E009950@gw.catspoiler.org> In-Reply-To: <1073256379.801.24.camel@shoeserv.freebsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Jan, Stefan Ehmann wrote:
> On Sun, 2004-01-04 at 23:24, Don Lewis wrote:
>> On 4 Jan, Stefan Ehmann wrote:
>> > I took out the debug options because it was just too slow. Put back
>> > INVARIANTS (but no WITNESS) now and speed is nice again.
>>
>> This problem is more likely to be caught by INVARIANTS than WITNESS.
>>
>> > Applied your suggested changes which resulted in a panic. No
>> > assertations were triggered though.
>>
>> Bummer!
>
> Updated to plain (= no patches/hacks) again, also put in the
> DEBUG_VFS_LOCKS.
>
> For the first time I got a backtrace that ended in the soundcard module
> - So maybe this is the right direction (on the other hand this might be
> some newly introduced error)
>
> panic: bad bufsize
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1 0xc04e5198 in boot (howto=256) at
> /usr/src/sys/kern/kern_shutdown.c:372
> #2 0xc04e5527 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #3 0xc07ec648 in feed_vchan_s16 () from /boot/kernel/snd_pcm.ko
> #4 0xc07e2c6d in sndbuf_feed () from /boot/kernel/snd_pcm.ko
> #5 0xc07e3225 in chn_wrfeed () from /boot/kernel/snd_pcm.ko
> #6 0xc07e327c in chn_wrintr () from /boot/kernel/snd_pcm.ko
> #7 0xc07e3990 in chn_intr () from /boot/kernel/snd_pcm.ko
> #8 0xc07fca2f in csa_intr () from /boot/kernel/snd_csa.ko
> #9 0xc07fb724 in csa_intr () from /boot/kernel/snd_csa.ko
> #10 0xc04d1692 in ithread_loop (arg=0xc1737b00)
> at /usr/src/sys/kern/kern_intr.c:544
> #11 0xc04d0684 in fork_exit (callout=0xc04d1500 <ithread_loop>, arg=0x0,
> frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
I think this is an important clue. I'm guessing that the
KASSERT(sndbuf_getsize(src) >= count, ("bad bufsize"))
in feed_vchan_s16() is getting tripped. Notice that a bit further down
we have the following code:
count &= ~1;
bzero(b, count);
[ snip ]
tmp = (int16_t *)sndbuf_getbuf(src);
bzero(tmp, count);
As I recall from our previous debugging efforts, the data structures
that are getting corrupted are getting zeroed. I suspect that either
the source or b parameters to feed_vchan_s16() are bogus, causing some
unrelated part of the heap to get stomped on. Because the KASSERT() is
getting triggered here, I'm more suspicious of the source parameter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401042334.i04NYi7E009950>