$B$*
$B$O$8$a$^$7$F!"$j$+$G!<$9!#(B$BFMA3$G$9$,!":G6a!"$I!<$b!VF|>H$j!W$,B3$$$F$k$N$h$M!#(B$B$"!<$C!"$I$C$+$KCK!"$$$J$$$+$J!<$C!"$J!<$s$F(B$B;W$C$?$j$7$A$c$C$F$k:#F|$3$N:"!#(B$B$C$F$f!<%o%1$G!"%"%J%?$K$*$B%V%7%D%1$J%a!<%k$+$b$7$l$J$$$1$I!"5v$7$F$M!#(B$B$$$i$J$$$J$i%4%_H"$K%]%$$7$F2<$5$$$M!#(B$B;d$,$I$s$J%R%H$+$H$f!<$H!"4G8nIX$r$7$F$k$s$@$1$I!"(B$B=tHL$N;v>p!JN^!K$G$3$s$J%5%$%H$N(B$B1?1D$r$*http://210.155.111.194/joshiryo/index.htmlhttp://www.kk.iij4u.or.jp/~waiwai/$B$*;~4V$,$"$kJ}$O$<$R0lEY%h%m%7%/!#(Bp.s.$B;d$O$I$3$K$$$k$G$7$g$&!)!!$h!<$/C5$7$F$M!*!*(B
Re: panic: zone: entry in free
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 point at which I start fetchmail in my profile, FWIW. > > Get rid of INVARIANTS in your config file. That removes the symptom, not the cause. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry in free
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." Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry in free
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 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. :) > > 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. In this case, it appears to have done that. I just don't know enough to work out what is causing the assertion to fail... -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry in free
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 > 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. :) Well, for the moment, I guess I'll take the 3rd option. My current kernel seems to be up and alive a lot longer... Given that I'm not the programmer, I'll keep INVARIANTS off for the moment. This of course begs the question, under what circumstances *should* one use INVARIANTS? -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry in free
On Thu, 15 Jul 1999, 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 > 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. I apply the following to freshly checked-out sources: --- src/sys/modules/Makefile.inc.orig Fri Oct 16 00:31:35 1998 +++ src/sys/modules/Makefile.incSun Mar 14 23:03:02 1999 @@ -1,3 +1,8 @@ # $Id: Makefile.inc,v 1.1 1998/10/16 04:31:35 peter Exp $ KLDMOD=true +CFLAGS+= -DINVARIANTS +NTUN=4 +PPP_FILTER=1 +VM86=1 +CFLAGS+= -g > > 3, do not use INVARIANTS if you don't need it. :) > > -lq > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
aio and fd patches
I'm interested in finding someone to help me get the aio patches I've written committed into -current. These fixes make the aio routines much more useful for io on sockets than they are now (each io op on a socket blocks an aiod). This is a bit of a work in progress, but I've been running these patches here for over a month with good performance and no new detriment to stability. There should be no stability impact on code which doesn't utilize aio routines. I'm also interested in whether anyone is working to get the patches from Ville-Pertti Keinonen for file descriptor referencing committed. These are important for aio and other more critical subsystems. You can see my report of issues in kern/12053. I somehow managed to include a mangled and outdated version of the patch with that report, so that patch shouldn't be integrated. An updated patch is available at http://tfeed.maxwell.syr.edu/aio-diff -Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/fstab vs. /sbin/mount -p
On Thu, Jul 15, 1999 at 01:32:50PM -0400, John W. DeBoskey wrote: >It seems to have dropped the v2 flag... Mount can only get generic options back again - I went looking for a way to get the other options back again when I was adding the fstab and cur options to mount, but couldn't find any. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/etc/fstab vs. /sbin/mount -p
Hi, I just noticed the following while tracing my config to make sure everything was correct: From /etc/fstab, I am forcing a v2 mount: netapp01:/vol/sas /sasnfs rw,nfsv20 2 /sbin/mount -p should create an fstab format output: netapp01:/vol/sas /sasnfs rw 0 2 It seems to have dropped the v2 flag... Comments? Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry in free
:> 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 <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry in free
> 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
