On Thu, Jul 15, 1999 at 12:08:07AM -0400, Luoqi Chen wrote:
I've been getting this panic when I've installed new kernels the last
couple of times. The panic is occuring when I have freshly booted the
system with a new kernel and logged on for the first time. It appears
to occur at the
: 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
On Thu, Jul 15, 1999 at 12:18:42PM -0400, Luoqi Chen wrote:
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
On Thu, Jul 15, 1999 at 10:01:18AM -0700, Matthew Dillon wrote:
: 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
On Thu, 15 Jul 1999 21:18:03 +0100, Dominic Mitchell wrote:
This of course begs the question, under what circumstances *should* one
use INVARIANTS?
This has been explained to me before as "when you have the time and
inclination to look into any problems that this might cause or
highlight."
On Thursday, 15 July 1999 at 0:08:07 -0400, Luoqi Chen wrote:
I've been getting this panic when I've installed new kernels the last
couple of times. The panic is occuring when I have freshly booted the
system with a new kernel and logged on for the first time. It appears
to occur at the
I've been getting this panic when I've installed new kernels the last
couple of times. The panic is occuring when I have freshly booted the
system with a new kernel and logged on for the first time. It appears
to occur at the point at which I start fetchmail in my profile, FWIW.
BTW: My home
I've been getting this panic when I've installed new kernels the last
couple of times. The panic is occuring when I have freshly booted the
system with a new kernel and logged on for the first time. It appears
to occur at the point at which I start fetchmail in my profile, FWIW.
Get rid
I seem to be able to repeat this panic, every time I make a certain change
to a file and save it out this happens. It's a NFS mounted file from my i386
box to my alpha, both running pretty much current. It's the alpha that
panics.
Stopped at Debugger..ng+0x24: ldq ra,0(sp)
What's your memory configuration and what's your kernel configuration?
df
dmesg
cat /usr/src/sys/i386/conf/YOURKERNELCONFIG
In general, the more information you include in the email, the easier
it is on the list.
-Matt
On Wed, 10 Mar 1999, Chuck Robey wrote:
You know, guys, for programmers, wanting immediate panics on stuff like
this is great, but there isn't one user in a thousand that wants this.
If you make this kinda stuff default on a version *other than* current
(current being by definition, for
On Wed, 10 Mar 1999, Matthew Dillon wrote:
: :
: :This means that invariants need to add relatively little overhead.
: :
: :Peter
:
: which they do.
:
:You know, guys, for programmers, wanting immediate panics on stuff like
:this is great, but there isn't one user in a thousand
Chuck Robey wrote:
That's completely true, but nearly all users simply couldn't care less.
They don't see the long view, they only see what's happening right now.
With that I will agree... :)
It's the reason that your attitude is totally correct healthy for a
developer ... but the only
Karl Pielorz wrote:
It's the reason that your attitude is totally correct healthy for a
developer ... but the only thing that most users will see is the fact
that FreeBSD panics more often. They won't even bother to make of note
of why a panic occurred, all they will ever note is that
On Thu, 11 Mar 1999, Chuck Robey wrote:
On Wed, 10 Mar 1999, Matthew Dillon wrote:
: :
: :This means that invariants need to add relatively little overhead.
: :
: :Peter
:
: which they do.
:
:You know, guys, for programmers, wanting immediate panics on stuff like
Matthew Dillon dil...@apollo.backplane.com writes:
I would disagree with that. Invariants are for people who want
their data to be as safe as possible and don't mind eating a little
cpu doing extra sanity checks in the kernel. It is something I would
almost certainly enable
Uh, no. Invariants are for developers who want to make sure their code
is correct. There is no reason why an end user would want to build a
kernel with invariants enabled. Invariants will *not* increase data
safety. If they have any effect at all (i.e. if they actually catch a
bug), the
On Wed, 10 Mar 1999 sth...@nethelp.no wrote:
Uh, no. Invariants are for developers who want to make sure their code
is correct. There is no reason why an end user would want to build a
kernel with invariants enabled. Invariants will *not* increase data
safety. If they have any effect at
On Wed, 10 Mar 1999 11:48:57 -0500 (EST), Dan Swartzendruber
dru...@kersur.net said:
I have to concur. I've never understood the don't worry be happy
point of view on this issue.
Do you always compile and install all your programs with debugging
symbols?
-GAWollman
--
Garrett A. Wollman
sth...@nethelp.no writes:
Uh, no. Invariants are for developers who want to make sure their code
is correct. There is no reason why an end user would want to build a
kernel with invariants enabled. Invariants will *not* increase data
safety. If they have any effect at all (i.e. if they
On Wed, 10 Mar 1999, Garrett Wollman wrote:
On Wed, 10 Mar 1999 11:48:57 -0500 (EST), Dan Swartzendruber
dru...@kersur.net said:
I have to concur. I've never understood the don't worry be happy
point of view on this issue.
Do you always compile and install all your programs with
On Wed, 10 Mar 1999, Garrett Wollman wrote:
On Wed, 10 Mar 1999 11:48:57 -0500 (EST), Dan Swartzendruber
dru...@kersur.net said:
I have to concur. I've never understood the don't worry be happy
point of view on this issue.
Do you always compile and install all your programs with
On Wed, 10 Mar 1999 12:03:00 -0500 (EST), Dan Swartzendruber
dru...@kersur.net said:
No, but I didn't think that was what we were talking about. I thought
we were talking about assertions.
We were talking about invariants, which document the conditions which
nearby code expect and/or cause.
:We were talking about invariants, which document the conditions which
:nearby code expect and/or cause. To actually check these conditions
:in a production system is a waste of CPU power; their function is to
:define for the developers precisely what the expected outcome of a
:particular
:No, it is not - not in the general case, and not in the long term. I
:was trying to point out that there may be extreme cases where an
:otherwise harmless bug would cause a panic with invariants enabled.
:
:Matt claimed that invariants increase data safety, which I find
:difficult to understand.
:Uh, no. Invariants are for developers who want to make sure their code
:is correct. There is no reason why an end user would want to build a
:kernel with invariants enabled. Invariants will *not* increase data
:safety. If they have any effect at all (i.e. if they actually catch a
:bug), the
You two are basically discussing overspecifying source code vs
normal source code. It doesn't really matter much if the
overspecifying consists of merging the TeX sources for a book or
by adding invariants as part of design verification. The discussion
itself has about as much merit as our
I don't use DIAGNOSTIC because it's overly intrusive and cause cause
panics or create bugs where none exist.
At least that was true in 2.2.x. I remember trying to use it at BEST.
The result was continually crashing machines due to bugs in the diagnostic
code ( such as
In message 199903101944.laa57...@apollo.backplane.com, Matthew Dillon writes:
I don't use DIAGNOSTIC because it's overly intrusive and cause cause
panics or create bugs where none exist.
Then it should be fixed.
Personally, I would be happier if DIAGNOSTIC were ripped out entirely
Brian Feldman wrote:
On Wed, 10 Mar 1999, Garrett Wollman wrote:
On Wed, 10 Mar 1999 11:48:57 -0500 (EST), Dan Swartzendruber
dru...@kersur.net said:
I have to concur. I've never understood the don't worry be happy
point of view on this issue.
Do you always compile and
I don't use DIAGNOSTIC because it's overly intrusive and cause cause
panics or create bugs where none exist.
Then it should be fixed. I think DIAGNOSTIC is *supposed* to do
everything you're arguing for and to scream for its removal in one
breath and then call for a mechanism which
On Wed, 10 Mar 1999 sth...@nethelp.no wrote:
Uh, no. Invariants are for developers who want to make sure their code
is correct. There is no reason why an end user would want to build a
kernel with invariants enabled. Invariants will *not* increase data
safety. If they have any effect at
Matthew Dillon dil...@apollo.backplane.com wrote:
there are simply not enough sanity checks being made in the kernel.
There is a trade off between the amount of sanity checking and
performance. We need to make sure that any sanity checking we add
doesn't make the system unusably slow or
:
:Therefore, my preference is to turn invariants on on all my production
:kernels as well as my development kernels.
:
:This means that invariants need to add relatively little overhead.
:
:Peter
which they do.
-Matt
On Wed, 10 Mar 1999, Matthew Dillon wrote:
:
:Therefore, my preference is to turn invariants on on all my production
:kernels as well as my development kernels.
:
:This means that invariants need to add relatively little overhead.
:
:Peter
which they do.
You know,
: :
: :This means that invariants need to add relatively little overhead.
: :
: :Peter
:
: which they do.
:
:You know, guys, for programmers, wanting immediate panics on stuff like
:this is great, but there isn't one user in a thousand that wants this.
:If you make this kinda stuff
: :
: :This means that invariants need to add relatively little overhead.
: :
: :Peter
:
: which they do.
:
:You know, guys, for programmers, wanting immediate panics on stuff like
:this is great, but there isn't one user in a thousand that wants this.
:If you make this kinda
There are many potential problems with SMP kernels. Many of the inline
functions in machine/cpufunc.h depend on SMP. We've already pessimised
the usual (non-SMP) case by uninlining a few too many spl-related
functions.
So you think it would be bad to have zalloc and zfree as non-inline
Eivind Eklund eiv...@freebsd.org writes:
That is, INVARIANTS in kernel incompatible with dynamic loading.
Somehow this strikes me as a Bad Thing...
It _is_ a bad thing. I've been pondering what to do with the
intrusive invariant checks - make them dependent on
INTRUSIVE_INVARIANTS,
Assar Westerlund writes:
I think that the goal should be to make KLDs work with all kinds of
kernels.
I've been thinking about this too...
Certainly, for each kernel config option FOO we could have a symbol
in the kernel that a KLD could examine:
static const u_char kernlel_option_FOO =
I think that the goal should be to make KLDs work with all kinds of
kernels. And the only place where this seems to be a problem is with
zalloc and zfree. So it seems to me that one of the following could
be done to solve it:
a. make zalloc and zfree non-inline
b. call zalloci and zfreei in
Bruce Evans b...@zeta.org.au writes:
I think that the goal should be to make KLDs work with all kinds of
kernels. And the only place where this seems to be a problem is with
zalloc and zfree. So it seems to me that one of the following could
be done to solve it:
a. make zalloc and zfree
:Jos Backus wrote:
:
: That is, INVARIANTS in kernel incompatible with dynamic loading.
:
: Somehow this strikes me as a Bad Thing...
:
:Invariants is not for the production minded. It is for those who
:work with things likely to get broken. Say, for instance, -current.
::-)
:
:--
:Daniel C.
If you thought you could follow the code around a bit and work out why
it's happening, that would be very helpful...
This occurs almost immediately after copying a file to an msdos fs. I can
provide more info if that is deemed useful.
FreeBSD jos.mp-c.com 4.0-CURRENT FreeBSD 4.0-CURRENT
On Tue, Feb 23, 1999 at 12:09:03PM +0300, Dmitrij Tejblum wrote:
You could add -DINVARIANTS to CFLAGS in sys/module/msdosfs/Makefile.
OK, did that, no more panics. Thanks!
Dima
Cheers,
--
Jos Backus _/ _/_/_/Reliability means never
On Tue, Feb 23, 1999 at 02:41:14AM +0300, Dmitrij Tejblum wrote:
Jos Backus wrote:
This occurs almost immediately after copying a file to an msdos fs. I can
provide more info if that is deemed useful.
I suspect your kernel compiled with INVARIANTS,
Yes, and with INVARIANTS_SUPPORT as well
Jos Backus wrote:
On Tue, Feb 23, 1999 at 02:41:14AM +0300, Dmitrij Tejblum wrote:
Jos Backus wrote:
This occurs almost immediately after copying a file to an msdos fs. I can
provide more info if that is deemed useful.
I suspect your kernel compiled with INVARIANTS,
Yes, and with
On Tue, Feb 23, 1999 at 12:09:03PM +0300, Dmitrij Tejblum wrote:
Inline functions in vm/vm_zone.h depend on INVARIANTS. These functions
used in msdosfs and in other parts of the kernel.
OK, I see.
How does one add INVARIANTS support to modules?
You could add -DINVARIANTS to CFLAGS in
On Tue, Feb 23, 1999 at 10:59:39AM +0100, Jos Backus wrote:
On Tue, Feb 23, 1999 at 12:09:03PM +0300, Dmitrij Tejblum wrote:
Inline functions in vm/vm_zone.h depend on INVARIANTS. These functions
used in msdosfs and in other parts of the kernel.
OK, I see.
How does one add INVARIANTS
On Tue, Feb 23, 1999 at 04:16:26PM +0100, Eivind Eklund wrote:
Somehow this strikes me as a Bad Thing...
It _is_ a bad thing. I've been pondering what to do with the
intrusive invariant checks - make them dependent on
INTRUSIVE_INVARIANTS, perhaps?
Depends on how dangerous these invariant
On Tue, Feb 23, 1999 at 05:08:57PM +0100, Jos Backus wrote:
On Tue, Feb 23, 1999 at 04:16:26PM +0100, Eivind Eklund wrote:
Somehow this strikes me as a Bad Thing...
It _is_ a bad thing. I've been pondering what to do with the
intrusive invariant checks - make them dependent on
In message 19990223191857.h10...@bitbox.follo.net, Eivind Eklund writes:
A couple of the invariants we have modify the
behaviour to make it possible to check for things, and this should be
separate from the ones that doesn't modify the behaviour beyond adding
checks.
That sounds more like
Jos Backus wrote:
That is, INVARIANTS in kernel incompatible with dynamic loading.
Somehow this strikes me as a Bad Thing...
Invariants is not for the production minded. It is for those who
work with things likely to get broken. Say, for instance, -current.
:-)
--
Daniel C. Sobral
:In message 19990223191857.h10...@bitbox.follo.net, Eivind Eklund writes:
:
:A couple of the invariants we have modify the
:behaviour to make it possible to check for things, and this should be
:separate from the ones that doesn't modify the behaviour beyond adding
:checks.
:
:That sounds more
This occurs almost immediately after copying a file to an msdos fs. I can
provide more info if that is deemed useful.
FreeBSD jos.mp-c.com 4.0-CURRENT FreeBSD 4.0-CURRENT #3: Sat Feb 20 19:31:56
CET 1999 j...@jos.mp-c.com:/usr/src/sys/compile/JOS i386
Thanks,
--
Jos Backus
Jos Backus wrote:
This occurs almost immediately after copying a file to an msdos fs. I can
provide more info if that is deemed useful.
I suspect your kernel compiled with INVARIANTS, you load msdosfs module
dynamically, and the module isn't compiled with INVARIANTS. If so,
don't do that. If
56 matches
Mail list logo
