FreeBSD 5.1-R kernel panic
Stephane Raimbault
segr at hotmail.com
Thu Jul 24 02:17:19 PDT 2003
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"
More information about the freebsd-current
mailing list