Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Aug 2002 00:39:48 +0100
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Carolyn Longfoot <c_longfoot@hotmail.com>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: panic: vm_page insert: already inserted?????
Message-ID:  <20020816233948.GA16764@happy-idiot-talk.infracaninophi>
In-Reply-To: <F87Tk1ozO0A2i0Wxc4d0001003d@hotmail.com>
References:  <F87Tk1ozO0A2i0Wxc4d0001003d@hotmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 16, 2002 at 02:40:48PM -0400, Carolyn Longfoot wrote:
> What is that panic caused by and how do I fix it? I'm on 4.6 RELEASE and a 
> dual CPU box, with a SMP kernel (of course).
> 
> The exact error is:
> panic: vm_page_insert: already inserted
> mp_lock = 01000001; cpuid = 1; lapic.id = 01000000
> boot() called on cpu#1

That's pretty drastic: the system is losing track of memory pages.
The cause could be hardware --- either a fault, or some chip set not
properly supported --- or software --- kernel bugs or some flaw in the
way you've configured your SMP kernel.

Do you see the same effect if you run the generic kernel? It's only
single processor, I know, but it should run OK on just about any
machine.  If the generic kernel panics in the same way, you've
probably got duff hardware.

What level of optimization did you use to build your kernel?  Setting
COPTFLAGS to anything higher than '-O -pipe' can lead you into a world
of hurt.

Failing that, it's time to generate a problem report.  In order to do
that effectively, and give the developers something they can work
with, you'll have to do a bit of work.  Chapter 16 of the Developers'
Handbook describes what you need to do in detail
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html)
but to summarize the steps are as follows:

    i) Compile a kernel with debug symbols.  Uncomment the line:

        makeoptions    DEBUG=-g

       in your kernel config file, and build and install a new kernel.

       Nb. this will generate loadable kernel modules with debug
       symbols which will take up more space to install on your root
       partition.  The installed /kernel will not contain the debug
       symbols --- assuming that you build via

        make KERNCONF=FOO buildkernel 

       you'll find the kernel image with the debug symbols in:

        /usr/obj/usr/src/sys/FOO/kernel.debug

       Seeing as you're doing some kernel building anyhow, you could
       try updating to the latest 4-STABLE or 4.6.2-RELEASE system at
       this point --- it's possible someone has already fixed the
       problem you're seeing.

   ii) Set up "/var/crash" to save a core dump of your system when it
       crashes.  You need to have a swap area at least 64K bigger than
       the amount of RAM in your system, plus a partition with plenty
       of free space that you can save the core images to.
       Traditionally /var/crash has been used, but the /var partition
       isn't usually big enough nowadays.  Here's how to set your
       system up to save core images to /home/crash:

        mkdir -p /home/crash
        chown root:wheel /home/crash
	chmod 750 /home/crash
	echo 2048 > /home/crash/minfree                     [1]
        echo 'dumpdev="/dev/ad0s1b"' >> /etc/rc.conf        [2]   
        echo 'dumpdir="/home/crash"' >> /etc/rc.conf
        shutdown -r now

       [1] See savecore(8): don't save a core image if it would leave
       less than this number of kilobytes free space on the partition.

       [2] Substitute whatever you use as a swap partition, or an
       otherwise completely unused disk slice of appropriate size.

  iii) Wait for a panic to happen.  You should see the system dumping
       core to your swap partition, and then during the following
       reboot, you should see a message about saving the core image to
       /home/crash.

       Now you can generate a traceback in gdb(1):

        cd /usr/obj/usr/src/sys/FOO
        gdb -k -e /home/crash/kernel.0 kernel.debug /home/crash/vmcore.0
          where

   iv) Finally you should submit a bug report via send-pr(1):

        send-pr -P > /tmp/bug-report
        vi /tmp/bug-report
        send-pr -f /tmp/bug-report

       Fill in the fields in the template bug report appropriately,
       giving as much useful information as you can.  See
       http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/index.html
       for guidance on how to do that.  It's a good idea to include a
       copy of your kernel configuration and a copy of
       /var/run/dmesg.boot as well as the stack trace you just
       generated.

Someone should get back to you fairly soon, probably with a few
supplemental questions, and eventually some sort of resolution to the
problem.

> This seems to happen every couple hours and only when I was at the console 
> did I catch the error because <ANNOYED>this error is not logged 
> anywhere</ANNOYED> and I went crazy looking through the logs to find out 
> what's going on.

Well, what's happening to your system is kind of like it's having it's
brains blown out.  Not much chance for it to produce any dying
words...

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
Tel: +44 1628 476614                                  Marlow
Fax: +44 0870 0522645                                 Bucks., SL7 1TH UK

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020816233948.GA16764>