Date: Thu, 15 Jul 1999 10:01:18 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.ORG Subject: Re: panic: zone: entry in free Message-ID: <199907151701.KAA11286@apollo.backplane.com> References: <199907151618.MAA03390@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> I realise that will stop the panic from looking at the source code, but
:> surely it's just covering up the problem and waiting for it to happen
:> later?
:>
:I'm pretty it's caused by the INVARIANTS option, similar incidents have been
:reported many times before. The problem with INVARIANTS is that 1. it alters
:data structures, 2. kernel modules don't know about this option, so you
:have inconsistent kernel and modules. There're three solutions,
:
:1, make INVARIANTS less intrusive. So far only vm_zone code is causing
:problems, I suggest we rename the option to INVARIANTS_ZONE in this part
:of code (the code should be pretty much bug free by now).
:
:2, compile modules with the option. The easiest way is probably add
:-DINVARIANTS in your /etc/make.conf, you have to remember to take it
:out when you remove the option from your config file.
:
:3, do not use INVARIANTS if you don't need it. :)
:
:-lq
This sounds very similar to the DIAGNOSTIC story... I would much
prefer to see INVARIANTS be entirely passive and not fall down
the same well as DIAGNOSTIC did. People may remember how utterly
useless DIAGNOSTIC became due to being overly intrusive.
INVARIANTS should simply assert conditions that it expects to be
true and panic if they aren't.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907151701.KAA11286>