Re: FreeBSD 5.1-R kernel panic

Hi Bosko,

Well I went to go change my /boot/loader.conf options to reflect the
following:

kern.vm.kmem.size="350000"
kern.ipc.nmbclusters="8192"


and enabled "options DDB" in my kernel.

Unfortunately, I ran into a problem on the reboot, the SMP kernel would fail
to load due to some of my /boot/loader.conf changes.... perhaps I
miss-understood something in your instructions... anyhow, this is what was
displayed on the console when I set those above settings in the
/boot/loader.conf... and since I had the debugger running, I did a trace and
included in the paste below... is that the kind of stuff you will want if
the box crashes again as originally mentioned in this thread.


-----------

/boot/kernel/acpi.ko text=0x39b54 data=0x1638+0xf68
syms=[0x4+0x6200+0x4+0x7b62]
2097152K of memory above 4GB ignored
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD 5.1-RELEASE #0: Thu Jul 24 00:19:10 MDT 2003
    root_at_srv2.ashleymadison.com:/usr/obj/usr/src/sys/SMP
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0702000.
Preloaded elf module "/boot/kernel/ipfw.ko" at 0xc07022e4.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0702390.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 2399328136 Hz
CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  Stepping = 7

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA
,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Hyperthreading: 2 logical CPUs
real memory  = 4160225280 (3967 MB)
avail memory = 4045996032 (3858 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
Programming 24 pins in IOAPIC #1
Programming 24 pins in IOAPIC #2
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00050014, at 0xfee00000
 cpu1 (AP):  apic id:  6, version: 0x00050014, at 0xfee00000
 cpu2 (AP):  apic id:  1, version: 0x00050014, at 0xfee00000
 cpu3 (AP):  apic id:  7, version: 0x00050014, at 0xfee00000
 io0 (APIC): apic id:  2, version: 0x00178020, at 0xfec00000
 io1 (APIC): apic id:  3, version: 0x00178020, at 0xfec80000
 io2 (APIC): apic id:  4, version: 0x00178020, at 0xfec80400


Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 00000000
fault virtual address   = 0x8
fault code              = supervisor write, page not present
instruction pointer     = 0x8:0xc034678e
stack pointer           = 0x10:0xc0724d60
frame pointer           = 0x10:0xc0724d80
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at      sf_buf_init+0xce:       movl    %eax,0x8(%ebx,%edx,1)
db> trace
sf_buf_init(0,721000,721c00,721000,0) at sf_buf_init+0xce
mi_startup() at mi_startup+0xb5
begin() at begin+0x2c
db>


-----------

Thanks,
Stephane.

----- 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"