Re: FreeBSD 5.1-R kernel panic

Well, I had compiled "options DDB" into the kernel and today the kernel
panic'd... here is what I got.  I ran the following in the db> prompt.
"trace", "show reg", "ps".  Let me know if this is the kind of information
you need, and if there is anything else I need to provide... can I
re-compile the kernel without the "options DDB" now, or should I provide the
same info next time in panic's to confirm it's the same problem?

Thanks,
Stephane.

I've attached the file debug.txt which contains the panic info.  Let me know
if you need it in a different format.

Thanks again,
Stephane Raimbault.


----- Original Message ----- 
From: "Bosko Milekic" <bmilekic_at_technokratis.com>
Newsgroups: mailing.freebsd.current
Sent: Wednesday, July 23, 2003 10:14
Subject: Re: FreeBSD 5.1-R kernel panic


>
> On Wed, Jul 23, 2003 at 09:56:32AM -0600, Stephane Raimbault wrote:
> > Hi Bosko,
> >
> > Looking at netstat -m, the value I'd probably be interested in is the
> > following:
> >
> > 3% of cluster map consumed
> >
> > knowing that the Maximum possible is 25600 I can deduce that ~768 are
being
> > used?  Is that correct.  I'm not much of a programmer, but I did
recognize
> > the printf(); statements from a C class I didn't do well in half a
decade
> > ago... as you can tell, I'm not much of a programmer :).  If it's not
the 3%
> > I should be paying attention too... then let me know :)
>
>   Look at the "in pool" values for all the pcpu and GEN caches and add
>   them up.  Do this for clusters (since there are fewer).  Compare to
>   the "Maximum Possible" value.  With a machine that goes into
>   spike-load periods, you may want to have the Maximum Possible stay
>   about 4-6 times what you have as your average "in pool" value
>   (remember to sum the "in pool" values for the pcpu and GEN caches).
>
>   The 3% is not what you think it is.  It's the percentage of the
>   allocated wired-down memory that is NOT in any of the caches but is
>   allocated and circulating in the system.  If you have a high number of
>   cached items but the percentage is relatively low for most of the
>   time, it's a sign that you were probably in a heavy-usage scenario
>   some time ago, but that your current usage is relatively low.
>
> > As for using the option DDB in my kernel, I do have one question.  I do
have
> > remote console access that I use to go into single user mode on the box
> > remotely.  I'm suspecting I could use the debugger mode over the
> > comconsole... I just want to make sure there is some kind of reboot
command
> > from the debugger so that I can tell the box to reboot once I've
captured
> > the stack trace?  If so, I'll enable the DDB tonight and get you the
info as
> > soon as I can.
>
>   Yes, you can do DDB over serial console.  Take a look at the handbook
>   for more information on using DDB.  If you have the space in /var and
>   enough swap, you may want to try getting a crashdump so that you can
>   reboot and use GDB to debug.  Again, take a look at the handbook.
>
> > thanks again,
> > Stephane.
>
> -- 
> Bosko Milekic  *  bmilekic_at_technokratis.com  *  bmilekic_at_FreeBSD.org
> TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003