Re: panic upon kldunload snd_ich (lor # 159)

From: Ben Kaduk <minimarmot_at_gmail.com>
Date: Tue, 13 Sep 2005 03:37:21 +0000
On 9/13/05, Ben Kaduk <minimarmot_at_gmail.com> wrote:
> 
> 
> 
> On 9/12/05, Alexander Leidinger <Alexander_at_leidinger.net> wrote:
> > 
> > On Mon, 12 Sep 2005 04:04:48 +0000
> > Ben Kaduk <minimarmot_at_gmail.com> wrote:
> > 
> > > Booting to single user and issuing:
> > > # kldload snd_ich
> > > # kldunload snd_ich 
> > >
> > > are sufficient to trigger the panic on my system. I know that 
> > Alexander
> > > Leidinger has recently committed some bits to current in the sound 
> > code, but
> > > it is unclear if it will fix my panic; I'm currently cvsup-ing and 
> > building 
> > > world to find out.
> > >
> > > The machine in question is:
> > >
> > > bash-2.05b$ uname -a
> > > FreeBSD prolepsis.math.uiuc.edu <http://prolepsis.math.uiuc.edu> <http://prolepsis.math.uiuc.edu
> > >
> > > 7.0-CURRENTFreeBSD
> > > 7.0-CURRENT #9: Thu Aug 25 06:22:00 UTC 2005
> > > kaduk_at_prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS
> > > i386
> > 
> > You should update to a -current which has: 
> > ---snip---
> > $FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.96 2005/09/12 18:33:33 
> > netchild Exp $
> > $FreeBSD: src/sys/dev/sound/pcm/dsp.c,v 1.84 2005/09/12 18:33:33 
> > netchild Exp $
> > ---snip---
> > 
> > If it still panics we need to get a backtrace (please have a look at 
> > the kernel-debugging chapter in the handbook; taking a backtrace isn't
> > hard).
> > 
> > Bye,
> > Alexander.
> > 
> > --
> > 0 and 1. Now what could be so hard about that?
> > 
> > http://www.Leidinger.net Alexander _at_ Leidinger.net<http://Leidinger.net>
> > GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
> > 
> 
> I upgraded to todays current, with 
> $FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.96 2005/09/12 18:33:33 
> netchild Exp $ and
> $FreeBSD: src/sys/dev/sound/pcm/dsp.c,v 1.84 2005/09/12 18:33:33 netchild 
> Exp $,
> and the panic still occurs, even in single-user. I can dump without 
> complaints, but since my /var is only 256 M, I have been manually running 
> savecore in single user, saving cores in /usr/crash (perhaps I should try 
> with hw.physmem=200M); this latest core seems to have problems:
> prolepsis# kgdb /usr/obj/usr/src/sys/PROLEPSIS/kernel.debug 
> /usr/crash/vmcore.0
> results in a (infinite) loop of:
> kgdb: kvm_read: invalid address (0xf0)
> 
> so this could be tough to debug. I will try to get an automatic dump on 
> /var, and if that fails, set up a serial console and leave the machine in 
> the debugger.
> 
> Ben Kaduk
> 
> 

Bad news: the dump on /var, though it seems to complete successfully, 
exhibits the same looping behaviour of the bigger dump, namely:
kgdb: kvm_read: invalid address (0xf0)

Also, I seem to be incompotent at reading documentation, in that I have yet 
to get a working serial console.
I tried both booting with a serial console and switching to gdb over serial 
console from ddb. In both cases I have a null-modem cable connecting sio0 on 
the problem box (prolepsis) to sio0 on an older 5.3-beta3 box (pleonasm).
To try to boot from a serial console, I dropped to the loader prompt on 
prolepsis (the box that panics), and tried "boot -h". This did not seem to 
have any affect, as console output was still directed to the video console, 
even after the system hit multiuser. I also tried dropping to the loader and 
typing "set console=comconsole", which resulted in a (infinite) wait on 
prolepsis. I then tried various "tip" commands on pleonasm, such as "tip 
/dev/cuaa0" and "tip com1", the latter of which was the only one which 
seemed to have any affect, namely that the terminal on pleonasm printed out 
"connected" and then ceased to respond to anything at all, and nothing 
happened on prolepsis, either.

I also tried to enter the debugger on prolepsis and then switch to gdb over 
serial console, along the lines of:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html
I panic()ed prolepsis, then ran "kgdb -r /dev/cuaa0 kernel.debug" on 
pleonasm, where kernel.debug was copied from prolepsis. This seemed to 
connect, but typing "gdb" at the debugger prompt on prolepsis resulted in an 
error along the lines of "gdb remote protocol is not active now", which 
presumably means that I need to set a flag on the serial port, but I don't 
know where or what.

In summary, I am unclear on how to use tip to access a serial console, and 
on serial port flags for console use.

I hope someone can point out my errors, so I can get a useable stack trace.

Thanks

Ben Kaduk
Received on Tue Sep 13 2005 - 01:37:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:43 UTC