Re: FreeBSD 5.1-R kernel panic

From: Stephane Raimbault (segr_at_hotmail.com)
Date: 07/24/03

  • Next message: Stephane Raimbault: "Re: FreeBSD 5.1-R kernel panic" 
    To: <current@freebsd.org>
Date: Thu, 24 Jul 2003 03:17:06 -0600

    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@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@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@technokratis.com * bmilekic@FreeBSD.org
    > TECHNOkRATIS Consulting Services * http://www.technokratis.com/
    > _______________________________________________
    > freebsd-current@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-current
    > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Stephane Raimbault: "Re: FreeBSD 5.1-R kernel panic"

    Relevant Pages