Re: panic: zone: entry in free
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 point at which I start fetchmail in my profile, FWIW. Get rid of INVARIANTS in your config file. 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? -- 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
: 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
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, 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, 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 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
panic: zone: entry in free
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 directory is mounted over nfsv3,udp from a Solaris2.6 server with amd. I've tried getting rid of amd and it makes no difference. At the moment, I'm having to use a kernel from June 8th, to be able to login... Here's the traceback from ddb: Debugger(0xc01d545b) at Debugger+0x37 panic(0xc01e5339, 0xc6aa6df4, 0xc0152af8, 0x1, 0) at panic+0x74 zerror(0x1, 0, 0xc6aa6f80, 0x, 0xc0f3b300) at zerror+0x3f namei(0xc6aa6eec, 0, 0xc6aa6f80, 0x, 0xc6aa6e30) at namei+0xac vn_open(0xc6aa6eec, 0x3, 0, 0xc6558680, 0xc01f572c) at vn_open+0x1eb open(0xc6558680, 0xc6aa6f80, 0x, 0, 0x) at open+0xbb syscall(0x2f, 0x2f, 0x2f, 0x, 0) at syscall+0x182 Xint0x80_syscall() at Xint0x80_syscall+0x26 Does this lot mean anything to anybody? Unfortunately, I can't seem to get a crash dump out of the thing. I've tried doing both "panic" and "continue" from within ddb, and it looks as though the dump is being written to disk, but when it comes back up, nothing. Here's the config file for the kernel that's crashing on me: # # VOODOO --- Dom's workstation. A HP Vectra VL. # # $Id: VOODOO,v 1.22 1999/07/13 06:23:14 dom Exp $ # machine "i386" cpu "I686_CPU" ident VOODOO maxusers32 # Build a debug kernel. makeoptions DEBUG="-g" options DDB # Kernel debugger. options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options "NO_F00F_HACK" options FFS #Berkeley Fast Filesystem options FFS_ROOT options INET#InterNETworking options INVARIANTS options INVARIANT_SUPPORT options KTRACE #kernel tracing options SOFTUPDATES options SYSVMSG options SYSVSEM options SYSVSHM options UCONSOLE#Allow users to grab the console options USER_LDT#Wine. controller isa0at nexus? controller pci0at nexus? controller fdc0at isa? port "IO_FD1" irq 6 drq 2 diskfd0 at fdc0 drive 0 ## controller wdc0at isa? port "IO_WD1" irq 14 ## disk wd0 at wdc0 drive 0 flags 0xa0ff ## controller wdc1at isa? port "IO_WD2" irq 15 ## device wcd0#IDE CD-ROM # Soren's new atapi stuff... controller ata0 device atadisk0 device atapicd0 # syscons is the default console driver, resembling an SCO console controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? irq 12 device vga0at isa? port ? conflicts device sc0 at isa? # Mandatory, don't remove device npx0at nexus? port IO_NPX irq 13 device apm0at nexus? disable flags 0x31 device sio0at isa? port "IO_COM1" flags 0x10 irq 4 device sio1at isa? port "IO_COM2" irq 3 device xl0 # Parallel port bus. controller ppbus0 device lpt0at ppbus? device plip0 at ppbus? device ppc0at isa? port? irq 7 pseudo-device loop pseudo-device ether pseudo-device pty 32 pseudo-device bpf 2 pseudo-device snp 2 #Snoop on ttys pseudo-device splash And here's the dmesg for the successful kernel that I'm running which is pretty much the same but with a couple more filesystems compiled into it instead of modules. Please let me know if there's any more information I can provide to help with tracking this down... Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #18: Tue Jun 8 05:00:06 BST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/VOODOO Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II (299.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping=4 Features=0x80f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 67108864 (65536K bytes) avail memory = 62611456 (61144K bytes) Preloaded elf kernel "kernel.goodnfs" at 0xc028c000. Preloaded elf module "if_tun.ko" at 0xc028c0a4. Pentium Pro MTRR support enabled, default memory type is uncacheable npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 Correcting Natoma config for non-SMP Correcting Natoma config for
Re: panic: zone: entry in free
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. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: zone: entry not free
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) 0xfe00059e7bc0 ra=0xfc4185d8,sp=0xfe00059e7bc0 db t Debugger..ng() at Debugger..ng+0x24 panic..ng() at panic..ng+0xf0 zerror..ng() at zerror..ng+0x6c namei..ng() at namei..ng+0x140 stat..ng() at stat..ng+0x44 syscall..ng() at syscall..ng+0x1dc XentSys() at XentSys+0x50 (null)() at 0x120009e38 No debugger on the alpha at the moment (but I'm working on that) and I probably won't be able to do anything for another 24 hours if you need more info. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 Matthew Dillon dil...@backplane.com : :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) :0xfe00059e7bc0 ra=0xfc4185d8,sp=0xfe00059e7bc0 :db t :Debugger..ng() at Debugger..ng+0x24 :panic..ng() at panic..ng+0xf0 :zerror..ng() at zerror..ng+0x6c :namei..ng() at namei..ng+0x140 :stat..ng() at stat..ng+0x44 :syscall..ng() at syscall..ng+0x1dc :XentSys() at XentSys+0x50 :(null)() at 0x120009e38 :... :Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 programmers/developers only) then you're going to hear bloody murder, and you guys will be doing vast damage to FreeBSD's reputation. Hmm. Well think of it this way. What happens when the kernel doesn't panic but manages to accidentally wipe out your file system without warning? or perhaps just loose some of the more important data on the HDD? What kind of reaction do you expect then? Users don't want panics, and they don't care why, they just want things to work. True enough, but at what cost? - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 that wants this. :If you make this kinda stuff default on a version *other than* current :(current being by definition, for programmers/developers only) then :you're going to hear bloody murder, and you guys will be doing vast :damage to FreeBSD's reputation. : :Users don't want panics, and they don't care why, they just want things No no no... you are missing the whole point. *IF* we put these kinds of checks in by default, the result is a few more panics in the near term, but *NO* panics in the medium and long term. 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. 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 a panic *did* occur. A developer will be helped hugely by your attitude, which is why it would be *very* healthy for current to do what you want. All the folks running current would serve as a better set of guinea pigs ... we're all developers, I don't think any of us would complain ... but never get the idea that a user is going to be happy to get a panic; no matter how much time you spend explaining why it's a good thing, they'll only remember that FreeBSD paniced on them. Alex Zepeda wrote: Hmm. Well think of it this way. What happens when the kernel doesn't panic but manages to accidentally wipe out your file system without warning? or perhaps just loose some of the more important data on the HDD? What kind of reaction do you expect then? Seeing as we're talking about failures that, most of the time, the user never sees the results of, users won't say a single thing ... if they're box *doesn't* panic, they'll be happy. If it panics more often, they'll notice that, and they won't bother asking why, they'll just switch to Linux (and quickly). They aren't signing on to be FreeBSD beta-testers, you know ... at least, believe me, THEY know that. On top of all that, the ordinary user won't even bother to report the fact that your panic happened (or why), while they're removing FreeBSD. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free - Default of state of Invariants
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 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 a panic *did* occur. Why not make the default 'OFF' for non -current, and just tell the users it's there? I know quite a few FreeBSD users, and out of the bunch I reckon ~3 of them would turn it on, and be happy - the other 9 or so would leave it off, and still be happy... -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free - Default of state of Invariants
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 a panic *did* occur. Why not make the default 'OFF' for non -current, and just tell the users it's there? I know quite a few FreeBSD users, and out of the bunch I reckon ~3 of them would turn it on, and be happy - the other 9 or so would leave it off, and still be happy... Like it has been done since... middle january? This thread is entering the twilight zone... -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org FreeBSD is Yoda, Linux is Luke Skywalker. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 :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 programmers/developers only) then :you're going to hear bloody murder, and you guys will be doing vast :damage to FreeBSD's reputation. : :Users don't want panics, and they don't care why, they just want things No no no... you are missing the whole point. *IF* we put these kinds of checks in by default, the result is a few more panics in the near term, but *NO* panics in the medium and long term. 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. 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 a panic *did* occur. it most likely will crash anyway. A developer will be helped hugely by your attitude, which is why it would be *very* healthy for current to do what you want. All the folks running current would serve as a better set of guinea pigs ... we're all developers, I don't think any of us would complain ... but never get the idea that a user is going to be happy to get a panic; no matter how much time you spend explaining why it's a good thing, they'll only remember that FreeBSD paniced on them. it most likely will crash/reboot/freeze anyway. Alex Zepeda wrote: Hmm. Well think of it this way. What happens when the kernel doesn't panic but manages to accidentally wipe out your file system without warning? or perhaps just loose some of the more important data on the HDD? What kind of reaction do you expect then? Seeing as we're talking about failures that, most of the time, the user never sees the results of, users won't say a single thing ... if they're box *doesn't* panic, they'll be happy. If it panics more often, they'll notice that, and they won't bother asking why, they'll just switch to Linux (and quickly). They aren't signing on to be FreeBSD beta-testers, you know ... at least, believe me, THEY know that. On top of all that, the ordinary user won't even bother to report the fact that your panic happened (or why), while they're removing FreeBSD. Perhaps if a panic printed a small line on how to report the problem that could be considered an improvement, if that could then also be disabled with 'options NO_CONTACT_INFO_ON_PANIC'. 'Please Transcribe this down and email it to b...@freebsd.org someone will get back to you as soon as possible, don't bother if you are overclocking' :) or perhaps a url to explain what not to report... It actually sounds like a good idea, this isn't NT, FreeBSD shouldn't 'just go boom' I want to see where the hell it did, so i can look at it and contact someone who can look at it. Someone at work asked me what's so awesome about freebsd, I babbled on for about half an hour then i showed him something he didn't belive at first: http://www.freebsd.org/cgi/query-pr.cgi?pr=8732 'dude, yeah i found a bug, they got back to within the hour and fixed it' 'really? how much was the tech support call?' 'oh, i just emailed them.' 'wow.' :) Happy users? Happy core team? yes, it's possible even when you get a panic. thanks, you guys make computers usable. -Alfred +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 in a production kernel. 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 result is a panic (whereas with a kernel without invariants, the bug might actually go unnoticed). You must be thinking of the FAILSAFE option. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 result is a panic (whereas with a kernel without invariants, the bug might actually go unnoticed). So for the end user it's better to have the bug go unnoticed than to get a kernel panic and notice the bug? Please tell me I'm misunder- standing something here. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 all (i.e. if they actually catch a bug), the result is a panic (whereas with a kernel without invariants, the bug might actually go unnoticed). So for the end user it's better to have the bug go unnoticed than to get a kernel panic and notice the bug? Please tell me I'm misunder- standing something here. I have to concur. I've never understood the don't worry be happy point of view on this issue. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 actually catch a bug), the result is a panic (whereas with a kernel without invariants, the bug might actually go unnoticed). So for the end user it's better to have the bug go unnoticed than to get a kernel panic and notice the bug? Please tell me I'm misunder- standing something here. 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. The only possible value an end user could derive from a kernel with invariants is a backtrace to attach to a send-pr. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 debugging symbols? No, but I didn't think that was what we were talking about. I thought we were talking about assertions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 debugging symbols? This is the DEVELOPMENT branch of the FreeBSD project, and you know that. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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. 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 operation is, so that new bugs are not introduced when code is modified. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: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 operation is, so that new bugs are not introduced when code :is modified. : :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same I would not characterize the use of invariants in production kernels as being a waste of cpu power... I'm sure there are many people who are more interested in data integrity then in performance. The use of inviariants can conceivably catch a problem early that might otherwise corrupt the system later. On the otherhand, the speeddaemons might not want either the invariants or the standard sanity checks, in which case they do not turn on invariant support and they do turn on MAX_PERF ( which gets rid of most of the standard sanity checks ). -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: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. : :DES There is no such thing as a harmless bug. If it's a bug, it needs to be fixed. Many 'harmless bugs' which are noted in source code come back to bite you later when some other programmer adds new code that uses a function in a legal but never-before-tested way. It is my considered opinion that one of the reasons why it has taken FreeBSD years to work out and fix serious bugs in the kernel is that there are simply not enough sanity checks being made in the kernel. The VM system is especially fragile in this regard, but most of the rest of the system has the same problem. For example, trying to block on a lockmgr lock inside an interrupt should result in an instantanious panic. But it doesn't. I can recall at least a dozen bugs that took months to locate because that sort of sanity check is not being made. It is *NOT* 'harmless', even if the occassional hit doesn't fry the system. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: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 result is a panic (whereas with a kernel without invariants, :the bug might actually go unnoticed). : :You must be thinking of the FAILSAFE option. : :DES :-- :Dag-Erling Smorgrav - d...@flood.ping.uio.no I would rather the system panic then corrupt a filesystem. Invariants are most useful to developers, but just because a developer's testing doesn't hit any invariants doesn't mean that the invariant won't get hit after the developer commits his code. I think what you are missing here is the fact that allowing bugs to go unnoticed draws out the debugging process. If we had more KASSERT's in the kernel 3 years ago, we would not still have a buggy kernel today. Sweeping bugs under the rug this way does not help anyone. It goes without saying that users catch almost as many bugs as developers, they simply can't fix them. When the a production kernel does not perform extra sanity checks, a bug can remain undetected for years. Therefore, my preference is to turn invariants on on all my production kernels as well as my development kernels. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 recent style(9) discussions, split infinitives included or not: It is pointless. We already have one option in the kernel for increased sanity checks, it's called DIAGNOSTIC and it is legal to add (even substantial) amounts of extra code under that option, as long as there is a sensible reason. Several of my kernels run with DIAGNOSTIC defined, and debug symbols and basic-block profiling to boot. And yes, I do find bugs that way. And no, I would hate to spend 50% of my performance on those options in production. Considering that I think a sensible approach here would be to define a global macro called INVARIANT(condition, text) as follows: #ifdef DIAGNOSTIC #define INVARIANT(condition, text) if (condition) ; else panic(text) #else #define INVARIANT(condition, text) do ; while (0) #endif In a suitably global kernel include file. Can everybody live with that as a compromise ? -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 diagnostics that were using a blocking malloc() inside an interrupt ). Personally, I would be happier if DIAGNOSTIC were ripped out entirely and replaced with something less intrusive. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 and replaced with something less intrusive. I wouldn't. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 install all your programs with debugging symbols? This is the DEVELOPMENT branch of the FreeBSD project, and you know that. Which would get back to my original (contested) statement: you shouldn't use INVARIANTS unless you are running blah, blah, blah, say, for example, -current. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org FreeBSD is Yoda, Linux is Luke Skywalker. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 does exactly what it was *supposed* to do in the next doesn't exactly advance the credibility of the argument, knowwhutahmean? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 all (i.e. if they actually catch a bug), the result is a panic (whereas with a kernel without invariants, the bug might actually go unnoticed). So for the end user it's better to have the bug go unnoticed than to get a kernel panic and notice the bug? Please tell me I'm misunder- standing something here. # Halt the system (panic) on discovering an unexpected kernel # inconsistency, in an attempt to prevent data corruption. Disabled # by default on production releases because of increased CPU load and that # these states should never happen. Good on -CURRENT. # # Bugs: Does not stop on other kinds of failures (hardware, etc) # # options FAILSTOP Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 adversely impact interrupt response. It's up the the relevant developers to make sure that a `reasonable' level of sanity checking is done. And later It goes without saying that users catch almost as many bugs as developers, Possibly more - there are more of them and they are likely to be stressing the system in unexpected (to the developer) ways. 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 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: :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 Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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, 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 programmers/developers only) then you're going to hear bloody murder, and you guys will be doing vast damage to FreeBSD's reputation. Users don't want panics, and they don't care why, they just want things to work. Your reasons are great, and totally irrelevant, unless I misunderstood you and you meant to restrict it to current only. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: : : :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 default on a version *other than* current :(current being by definition, for programmers/developers only) then :you're going to hear bloody murder, and you guys will be doing vast :damage to FreeBSD's reputation. : :Users don't want panics, and they don't care why, they just want things No no no... you are missing the whole point. *IF* we put these kinds of checks in by default, the result is a few more panics in the near term, but *NO* panics in the medium and long term. In otherwords, by putting the checks in now, the kernel gets debugged much more quickly --- to the point where a year down the line we no longer get kernel panics at all. If you are worried about FreeBSD's reputation, just think where we would be now if we had done this 3 years ago! When you push something under the rug, all you do is draw out the complaints into multiple years. This can't be ( and hasn't been ) good for our reputation. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: : : :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 default on a version *other than* current :(current being by definition, for programmers/developers only) then :you're going to hear bloody murder, and you guys will be doing vast :damage to FreeBSD's reputation. : :Users don't want panics, and they don't care why, they just want things No no no... you are missing the whole point. *IF* we put these kinds of checks in by default, the result is a few more panics in the near term, but *NO* panics in the medium and long term. In otherwords, by putting the checks in now, the kernel gets debugged much more quickly --- to the point where a year down the line we no longer get kernel panics at all. Also, try commenting out a panic line in a known bug, and watch how quickly the kernel crashes anyway, in the same situation. Most of the time, the panic is dumping out (some) debugging information before crashing all over itself. Just taking out the diagnostic message is really just making crashes more obscure. If the error were recoverable, normally the system recovers from it. If it's not, it panic's and dies. Take out the panic, and all you've got left is a 'die', which probably will lead people on a wild goose chase as to where that section of memory really got trashed. Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 functions? That would mean that KLDs would be different depending on the options used to build the kernel and that KLDs would need some way of figuring out the these options. How should that be done? By installing opt_global.h after building the kernel? I think global options should be avoided if possible. When they can't be avoided, KLDs should probably extern versions of some functions that are normally static inline, and whatever else it takes for them to be to be independent of kernel options. The kernel proper must provide the uninlined versions (compiled with its options). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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, perhaps? That would still make some KLDs incompatible with INTRUSIVE_INVARIANTS, but that is probably the best we can do. 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 code that can end up in KLDs c. call zalloci and zfreei everywhere where it's not performance-critical /assar To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 = 1;
But what to do about KLD's that want to link against kernel symbols
that may or may not exist? For example, some KLD's that present
interfaces would like to know if BPF is in the kernel, and if so
to support it .. but this means linking with bpfattach(), etc..
Would it be possible to permit 'partial' linking of a KLD, so that
the following code would work no matter what kernel was used?
int
xyz_attach()
{
...
if (kernlel_option_BPF 0)
bpf_attach(..); /* bpf_attach only gets resolved if it exists
* in the kernel; otherwise, it remains NULL but
* that's OK because in that case we don't call it
*/
...
}
Maybe this would require something like this in the KLD..
MODULE_BREAKABLE_LINKS(xyz) { bpfattach, bpf_mtap };
A fair bit of hackery, but probably worth it...
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 code that can end up in KLDs c. call zalloci and zfreei everywhere where it's not performance-critical 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. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 non-inline b. call zalloci and zfreei in code that can end up in KLDs c. call zalloci and zfreei everywhere where it's not performance-critical 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 functions? That would mean that KLDs would be different depending on the options used to build the kernel and that KLDs would need some way of figuring out the these options. How should that be done? By installing opt_global.h after building the kernel? /assar To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: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 (8-DCS) 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 in a production kernel. DIAGNOSTIC, on the otherhand, is something I would only enable in an extreme test environment. :d...@newsguy.com :d...@freebsd.org -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 #3: Sat Feb 20 19:31:56 CET 1999 j...@jos.mp-c.com:/usr/src/sys/compile/JOS i386 Thanks, -- Jos Backus _/ _/_/_/Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 as per Matt's instructions. you load msdosfs module dynamically, and the module isn't compiled with INVARIANTS. This is after a successful world and subsequent kernel build. If so, don't do that. I'm not aware that I do, really. jos:/usr/src/sys/modules/msdos# grep INVARIANTS * jos:/usr/src/sys/modules/msdos# jos:/usr/src/sys/msdosfs# grep INVARIANTS * jos:/usr/src/sys/msdosfs# How does one add INVARIANTS support to modules? If not, please provide more info. I'm not sure what I'm doing wrong. If I'm not, I will, of course. Just tell me what you want to know. Thanks, -- Jos Backus _/ _/_/_/Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 INVARIANTS_SUPPORT as well as per Matt's instructions. you load msdosfs module dynamically, and the module isn't compiled with INVARIANTS. This is after a successful world and subsequent kernel build. If so, don't do that. I'm not aware that I do, really. jos:/usr/src/sys/modules/msdos# grep INVARIANTS * jos:/usr/src/sys/modules/msdos# jos:/usr/src/sys/msdosfs# grep INVARIANTS * jos:/usr/src/sys/msdosfs# Inline functions in vm/vm_zone.h depend on INVARIANTS. These functions used in msdosfs and in other parts of the kernel. How does one add INVARIANTS support to modules? You could add -DINVARIANTS to CFLAGS in sys/module/msdosfs/Makefile. You better just link msdosfs statically, or remove INVARIANTS from your kernel. That is, INVARIANTS in kernel incompatible with dynamic loading. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 sys/module/msdosfs/Makefile. You better just link msdosfs statically, or remove INVARIANTS from your kernel. I'll try this tonight, thanks. That is, INVARIANTS in kernel incompatible with dynamic loading. Somehow this strikes me as a Bad Thing... Cheers, -- Jos Backus _/ _/_/_/Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 support to modules? You could add -DINVARIANTS to CFLAGS in sys/module/msdosfs/Makefile. You better just link msdosfs statically, or remove INVARIANTS from your kernel. I'll try this tonight, thanks. 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, perhaps? That would still make some KLDs incompatible with INTRUSIVE_INVARIANTS, but that is probably the best we can do. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 violations are, I would think. Iow, do they justify a panic()? That would still make some KLDs incompatible with INTRUSIVE_INVARIANTS, but that is probably the best we can do. At least that way the non-intrusive ones can be left in (and still be useful). Cheers, -- Jos Backus _/ _/_/_/Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 INTRUSIVE_INVARIANTS, perhaps? Depends on how dangerous these invariant violations are, I would think. Iow, do they justify a panic()? IMO, any invariant violation justifies a panic(). Otherwise, people would not pay heed to them. Invariant violations are pretty serious. However, my opinion is also that invariant checks should be non-intrusive - ie, they should not change the normal code path, only add extra checks. 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. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 DIAGNOSTIC kind of material, doesn't it ? -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
: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 DIAGNOSTIC kind of material, doesn't it ? : :-- :Poul-Henning Kamp FreeBSD coreteam member :p...@freebsd.org Real hackers run -current on their laptop. It sure does. DIAGNOSTIC is historically intrusive. INVARIANTS should definitely *not* be intrusive. Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
panic: zone: entry not free
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 _/ _/_/_/Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
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 not, please provide more info. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
