panic: vm_page insert: already inserted?????

[Carolyn Longfoot]

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

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.

Any ideas anybody?

Cheers,
Caro

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com


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

[Matthew Seaman]

Post by Carolyn Longfoot
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).
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.

Post by Carolyn Longfoot
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

[Carolyn Longfoot]

On Saturday I updated to RELENG_4 (Stable) and the system has been fine
since then, while before it crashed after a few hours. I'll never know what
but something in 4.5 RELEASE sucked mud.

Cheers,
Caro

Post by Matthew Seaman
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.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


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