zfs/vm panic: vm_object_page_collect_flush failed
Hi, I've been building KDE on a new -CURRENT system with ZFS and hit a panic - vm_object_page_collect_flush failed (more info is at http://www.cran.org.uk/~brucec/freebsd/zfs_vm_panic.txt). #9 0x802a6190 in panic (fmt=Variable fmt is not available. ) at /usr/src/head/sys/kern/kern_shutdown.c:574 #10 0x8043744e in vm_object_page_clean (object=Variable object is not available. ) at /usr/src/head/sys/vm/vm_object.c:823 #11 0x804376f6 in vm_object_terminate (object=0xff011a96d5e8) at /usr/src/head/sys/vm/vm_object.c:691 #12 0x804446d8 in vnode_destroy_vobject (vp=0xff00bd2acb40) at /usr/src/head/sys/vm/vnode_pager.c:167 #13 0x80a56252 in zfs_freebsd_reclaim (ap=Variable ap is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4836 #14 0x803396e5 in vgonel (vp=0xff00bd2acb40) at vnode_if.h:830 #15 0x80339a4c in vrecycle (vp=0xff00bd2acb40, td=Variable td is not available. ) at /usr/src/head/sys/kern/vfs_subr.c:2517 #16 0x80a3149a in zfs_zinactive (zp=0xff0096d06dc0) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1066 #17 0x80a55c96 in zfs_inactive (vp=0xff00bd2acb40, cr=Variable cr is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4059 #18 0x80a55e3a in zfs_freebsd_inactive (ap=Variable ap is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4792 #19 0x80338e92 in vinactive (vp=0xff00bd2acb40, td=0xff019871b450) at vnode_if.h:807 #20 0x8033c961 in vputx (vp=0xff00bd2acb40, func=1) at /usr/src/head/sys/kern/vfs_subr.c:2238 #21 0x80438dd7 in vm_object_deallocate (object=0xff011a96d5e8) at /usr/src/head/sys/vm/vm_object.c:447 #22 0x8042f68c in vm_map_entry_deallocate (entry=0xff00bd6054b0, system_map=0) at /usr/src/head/sys/vm/vm_map.c:2622 #23 0x8042f6c2 in vm_map_process_deferred () at /usr/src/head/sys/vm/vm_map.c:466 #24 0x80430d2f in vm_map_remove (map=0xff0093adac40, start=Variable start is not available. ) at /usr/src/head/sys/vm/vm_map.c:2793 #25 0x80434057 in vmspace_exit (td=0xff019871b450) at /usr/src/head/sys/vm/vm_map.c:333 #26 0x8027bea6 in exit1 (td=0xff019871b450, rv=0) at /usr/src/head/sys/kern/kern_exit.c:299 #27 0x8027c9ee in sys_exit (td=Variable td is not available. ) at /usr/src/head/sys/kern/kern_exit.c:109 #28 0x802e699a in syscallenter (td=0xff019871b450, sa=0xff81b832eba0) at /usr/src/head/sys/kern/subr_trap.c:318 #29 0x8046323c in syscall (frame=0xff81b832ec40) at /usr/src/head/sys/amd64/amd64/trap.c:938 #30 0x8044dd42 in Xfast_syscall () at /usr/src/head/sys/amd64/amd64/exception.S:381 #31 0x0008006e567c in ?? () -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: zfs/vm panic: vm_object_page_collect_flush failed
On Sat, Nov 20, 2010 at 02:48:15PM +, Bruce Cran wrote: Hi, I've been building KDE on a new -CURRENT system with ZFS and hit a panic - vm_object_page_collect_flush failed (more info is at http://www.cran.org.uk/~brucec/freebsd/zfs_vm_panic.txt). #9 0x802a6190 in panic (fmt=Variable fmt is not available. ) at /usr/src/head/sys/kern/kern_shutdown.c:574 #10 0x8043744e in vm_object_page_clean (object=Variable object is not available. ) at /usr/src/head/sys/vm/vm_object.c:823 #11 0x804376f6 in vm_object_terminate (object=0xff011a96d5e8) at /usr/src/head/sys/vm/vm_object.c:691 #12 0x804446d8 in vnode_destroy_vobject (vp=0xff00bd2acb40) at /usr/src/head/sys/vm/vnode_pager.c:167 #13 0x80a56252 in zfs_freebsd_reclaim (ap=Variable ap is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4836 #14 0x803396e5 in vgonel (vp=0xff00bd2acb40) at vnode_if.h:830 #15 0x80339a4c in vrecycle (vp=0xff00bd2acb40, td=Variable td is not available. ) at /usr/src/head/sys/kern/vfs_subr.c:2517 #16 0x80a3149a in zfs_zinactive (zp=0xff0096d06dc0) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1066 #17 0x80a55c96 in zfs_inactive (vp=0xff00bd2acb40, cr=Variable cr is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4059 #18 0x80a55e3a in zfs_freebsd_inactive (ap=Variable ap is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4792 #19 0x80338e92 in vinactive (vp=0xff00bd2acb40, td=0xff019871b450) at vnode_if.h:807 #20 0x8033c961 in vputx (vp=0xff00bd2acb40, func=1) at /usr/src/head/sys/kern/vfs_subr.c:2238 #21 0x80438dd7 in vm_object_deallocate (object=0xff011a96d5e8) at /usr/src/head/sys/vm/vm_object.c:447 #22 0x8042f68c in vm_map_entry_deallocate (entry=0xff00bd6054b0, system_map=0) at /usr/src/head/sys/vm/vm_map.c:2622 #23 0x8042f6c2 in vm_map_process_deferred () at /usr/src/head/sys/vm/vm_map.c:466 #24 0x80430d2f in vm_map_remove (map=0xff0093adac40, start=Variable start is not available. ) at /usr/src/head/sys/vm/vm_map.c:2793 #25 0x80434057 in vmspace_exit (td=0xff019871b450) at /usr/src/head/sys/vm/vm_map.c:333 #26 0x8027bea6 in exit1 (td=0xff019871b450, rv=0) at /usr/src/head/sys/kern/kern_exit.c:299 #27 0x8027c9ee in sys_exit (td=Variable td is not available. ) at /usr/src/head/sys/kern/kern_exit.c:109 #28 0x802e699a in syscallenter (td=0xff019871b450, sa=0xff81b832eba0) at /usr/src/head/sys/kern/subr_trap.c:318 #29 0x8046323c in syscall (frame=0xff81b832ec40) at /usr/src/head/sys/amd64/amd64/trap.c:938 #30 0x8044dd42 in Xfast_syscall () at /usr/src/head/sys/amd64/amd64/exception.S:381 #31 0x0008006e567c in ?? () Remove the KASSERT() at vm/vm_object.c:823. It is invalid, I will commit the fix later today. pgpHyWkXAXToo.pgp Description: PGP signature
vm panic
panic: lockmgr: locking against myself Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 dbtrace Debugger(c0381630,c03e4ee0,c037fd14,da447c28,1) at Debugger+0x54 panic(c037fd14,0,c037fc88,eb,1fb) at panic+0xab lockmgr(c138e85c,2,0,c3c150e0,c3c1514) at lockmgr+0x512 _vm_map_lock_read(c138e280,c039bc27,896,238d3c,527) at _vm_map_lock_read+0x5a vm_map_check_protection(c138e80,826400,826500,2,c03b1980) at vm_map_check_protection+0x31 useracc(8264fc4,8,2,1,c038b1f) at useracc+0x7d nanosleep(c3c150e0,da447d10,c039f3e,407,2) at nonosleep+0x53 syscall(bfbf002f,804002f,826002f,bfbffbe0,804a420) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x280b0853, esp = 0x8264fb8, ebp = 0x8264fd4 At the time, I am running ksetest, a kse based threaded program. Is the vm still not safe to run threaded program? David Xu ¡Iì¹» ®Þ±éݨ¥¶Ý¢jçH:+éì¹» ®Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
Re: vm panic
Apparently, On Thu, Jan 23, 2003 at 11:45:13AM +0800, David Xu said words to the effect of; panic: lockmgr: locking against myself Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 dbtrace Debugger(c0381630,c03e4ee0,c037fd14,da447c28,1) at Debugger+0x54 panic(c037fd14,0,c037fc88,eb,1fb) at panic+0xab lockmgr(c138e85c,2,0,c3c150e0,c3c1514) at lockmgr+0x512 _vm_map_lock_read(c138e280,c039bc27,896,238d3c,527) at _vm_map_lock_read+0x5a vm_map_check_protection(c138e80,826400,826500,2,c03b1980) at vm_map_check_protection+0x31 useracc(8264fc4,8,2,1,c038b1f) at useracc+0x7d nanosleep(c3c150e0,da447d10,c039f3e,407,2) at nonosleep+0x53 syscall(bfbf002f,804002f,826002f,bfbffbe0,804a420) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x280b0853, esp = 0x8264fb8, ebp = 0x8264fd4 At the time, I am running ksetest, a kse based threaded program. Is the vm still not safe to run threaded program? David Xu Don't know if this is the problem or not but the lockmgr code uses the pid as the lock cookie, so it can't distinguish 2 threads from the same process acquiring a lock. I noticed that netbsd has fixed this for lwps. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
What kind of value do you use for N? It looks like lately the makefiles are too aggressive when using -j, so you end up with N * N * 2 processes running simultaneously. On my -current box with 128M RAM, I used -j13 for a long time, but that runs out of swap nowadays, so I'm using -j4 which does work. My machine is a PentiumMMX/200 x 2 SMP. I'm slowly working down from -j13, and I'm now at -j5 with the same panic. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
Matthew N. Dodd wrote: On Sat, 17 Aug 2002, Mark Murray wrote: If I do a make -jN world build on my dual MMX/200 box, I usually end up in tears (well, a panic anyway). This is completely reproducible, and the panic always happens in swapout_procs while vmdaemon is running. Anyone else getting this? I'm amazed you've got a dual Pentium running -CURRENT at all. both of mine haven't worked with SMP kernels for months. (dual P54C and dual P55C). Wierd, I have it running just peachy on a dual P3 900 box Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
On Mon, 19 Aug 2002, Jason wrote: Wierd, I have it running just peachy on a dual P3 900 box It runs mostly okay on my dual P3/600, although for the last couple of months it has a tendency to panic with a bdwrite: buffer is not busy on average 2-3 times a day (per approx 15 hour run) Such is the price of staying on the bleeding edge, I suppose. :) Chris. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
On Mon, 19 Aug 2002, Jason wrote: Wierd, I have it running just peachy on a dual P3 900 box Just so nobody else replies to this with something similar we're talking about PENTIUMS. Not the P3, P2, Alpha or anything else. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
Matthew N. Dodd wrote: On Mon, 19 Aug 2002, Jason wrote: Wierd, I have it running just peachy on a dual P3 900 box Just so nobody else replies to this with something similar we're talking about PENTIUMS. Not the P3, P2, Alpha or anything else. Yes. My ASUS Dual P90 machine has the same problem. I just thought it was the MP Spec compliance level of the BIOS, and gave up running -current. I guess it's not just me. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
On Mon, 19 Aug 2002, Terry Lambert wrote: Yes. My ASUS Dual P90 machine has the same problem. I just thought it was the MP Spec compliance level of the BIOS, and gave up running -current. I guess it's not just me. 8-(. Its likely that we've got the same motherboard. Mine is a PCI/E-P54NP4 running 133s clocked at 120. I've also got a Tyan S1564D running a pair of 166MMX CPUs. It doesn't seem to be related to drivers or to the compiler. I haven't yet ruled out other parts of the toolchain. My last good build was 1 March 2002. Checking out a tree even as far back as mid-Feb doesn't yeild a good kernel though. I'm at a loss. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
On Sat, 17 Aug 2002, Mark Murray wrote: If I do a make -jN world build on my dual MMX/200 box, I usually end up in tears (well, a panic anyway). This is completely reproducible, and the panic always happens in swapout_procs while vmdaemon is running. Anyone else getting this? I'm amazed you've got a dual Pentium running -CURRENT at all. both of mine haven't worked with SMP kernels for months. (dual P54C and dual P55C). -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
Date: Sun, 18 Aug 2002 20:44:52 -0400 (EDT) From: Matthew N. Dodd [EMAIL PROTECTED] On Sat, 17 Aug 2002, Mark Murray wrote: If I do a make -jN world build on my dual MMX/200 box, I usually end up in tears (well, a panic anyway). This is completely reproducible, and the panic always happens in swapout_procs while vmdaemon is running. Anyone else getting this? I'm not. I'm amazed you've got a dual Pentium running -CURRENT at all. I'm not. both of mine haven't worked with SMP kernels for months. (dual P54C and dual P55C). freebeast(5.0-C)[2] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Sun Aug 18 09:16:14 PDT 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Sun Aug 18 09:16:14 PDT 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST Preloaded elf kernel /boot/kernel/kernel at 0xc0496000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04960a8. Calibrating clock(s) ... TSC clock: 876474687 Hz, i8254 clock: 1193294 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon/Celeron (876.40-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,MMX,FXSR,SSE real memory = 536805376 (524224K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x004c - 0x1ffe7fff, 531791872 bytes (129832 pages) avail memory = 515960832 (503868K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00faf20 bios32: Entry = 0xfb390 (c00fb390) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb3c0 pnpbios: Found PnP BIOS data at 0xc00fbde0 pnpbios: Entry = f:be10 Rev = 1.0 Other BIOS signatures found: null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x8060 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30911106) Using $PIR table, 8 entries at 0xc00fde30 More info available on request; I didn't want to spam the list too much (this time). Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
I'm amazed you've got a dual Pentium running -CURRENT at all. both of mine haven't worked with SMP kernels for months. (dual P54C and dual P55C). I am running SMP CURRENT kernel on 4-Alpha processors . No problems for a lot of months. Yuri. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
In the last episode (Aug 18), David Wolfskill said: From: Matthew N. Dodd [EMAIL PROTECTED] I'm amazed you've got a dual Pentium running -CURRENT at all. I'm not. both of mine haven't worked with SMP kernels for months. (dual P54C and dual P55C). freebeast(5.0-C)[2] uname -a CPU: Pentium III/Pentium III Xeon/Celeron (876.40-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE A Pentium III is not a Pentium, by a long shot. Or is it the other way around. :) P54C is your classic 586 Pentium. P55C is a Pentium/MMX. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VM panic
Hi all If I do a make -jN world build on my dual MMX/200 box, I usually end up in tears (well, a panic anyway). This is completely reproducible, and the panic always happens in swapout_procs while vmdaemon is running. Anyone else getting this? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VM panic
If I do a make -jN world build on my dual MMX/200 box, I usually end up in tears (well, a panic anyway). This is completely reproducible, and the panic always happens in swapout_procs while vmdaemon is running. Anyone else getting this? What kind of value do you use for N? It looks like lately the makefiles are too aggressive when using -j, so you end up with N * N * 2 processes running simultaneously. On my -current box with 128M RAM, I used -j13 for a long time, but that runs out of swap nowadays, so I'm using -j4 which does work. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
woo hoo! vm panic!
panic: vm_page_insert: already inserted syncing disks... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
It looks like you guys got it! What is currently checked in (by Assar)
is working fine! :-)
M
:--=-=-=
:
:Matt Dillon [EMAIL PROTECTED] writes:
: Well, yes... that's essentially what I suggested. You didn't say
: anything about removing the externalized inlines, which is what you
: do in your patch. Looks like a fine patch to me.
:
:Except it didn't work. Now here's a patch that survived building a
:kernel and modules. ok?
:
:/assar
lets see.. ok, I'm going to read the patch carefully this time..
This isn't quite what I had in mind. You are still making an API
change... you are now calling zalloci() from zalloc() for non-SMP boxes.
There is no need to do that.
Instead what I would recommend is making zalloc() and zfree() real
procedures, putting them in vm_zone.c, and removing their inlines from
vm_zone.h. i.e. not have *ANY* inlines at all in vm_zone.h
Then as real procedures in vm_zone.c these functions can have the
#ifdef SMP / related code left intact.
-Matt
:
:--=-=-=
:Content-Disposition: attachment; filename=zalloc-diff
:
:Index: vm_zone.c
:===
:RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
:retrieving revision 1.35
:diff -u -w -r1.35 vm_zone.c
:--- vm_zone.c2000/12/13 10:01:00 1.35
:+++ vm_zone.c2000/12/27 00:59:14
:@@ -32,6 +32,59 @@
:
: static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
:
:+#define ZONE_ERROR_INVALID 0
:+#define ZONE_ERROR_NOTFREE 1
:+#define ZONE_ERROR_ALREADYFREE 2
:+
:+#define ZONE_ROUNDING 32
:+
:+#define ZENTRY_FREE 0x12342378
:+/*
:+ * void *zalloc(vm_zone_t zone) --
:+ * Returns an item from a specified zone.
:+ *
:+ * void zfree(vm_zone_t zone, void *item) --
:+ * Frees an item back to a specified zone.
:+ */
:+static __inline__ void *
:+_zalloc(vm_zone_t z)
:+{
:+void *item;
:+
:+#ifdef INVARIANTS
:+if (z == 0)
:+zerror(ZONE_ERROR_INVALID);
:+#endif
:+
:+if (z-zfreecnt = z-zfreemin)
:+return _zget(z);
:+
:+item = z-zitems;
:+z-zitems = ((void **) item)[0];
:+#ifdef INVARIANTS
:+if (((void **) item)[1] != (void *) ZENTRY_FREE)
:+zerror(ZONE_ERROR_NOTFREE);
:+((void **) item)[1] = 0;
:+#endif
:+
:+z-zfreecnt--;
:+z-znalloc++;
:+return item;
:+}
:+
:+static __inline__ void
:+_zfree(vm_zone_t z, void *item)
:+{
:+((void **) item)[0] = z-zitems;
:+#ifdef INVARIANTS
:+if (((void **) item)[1] == (void *) ZENTRY_FREE)
:+zerror(ZONE_ERROR_ALREADYFREE);
:+((void **) item)[1] = (void *) ZENTRY_FREE;
:+#endif
:+z-zitems = item;
:+z-zfreecnt++;
:+}
:+
: /*
: * This file comprises a very simple zone allocator. This is used
: * in lieu of the malloc allocator, where needed or more optimal.
:Index: vm_zone.h
:===
:RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
:retrieving revision 1.13
:diff -u -w -r1.13 vm_zone.h
:--- vm_zone.h1999/08/28 00:52:44 1.13
:+++ vm_zone.h2000/12/27 00:59:14
:@@ -43,7 +43,6 @@
: struct vm_zone *znext; /* list of zones for sysctl */
: } *vm_zone_t;
:
:-
: voidzerror __P((int)) __dead2;
: vm_zone_t zinit __P((char *name, int size, int nentries, int flags,
:int zalloc));
:@@ -57,77 +56,16 @@
:int nitems));
: void * _zget __P((vm_zone_t z));
:
:-#define ZONE_ERROR_INVALID 0
:-#define ZONE_ERROR_NOTFREE 1
:-#define ZONE_ERROR_ALREADYFREE 2
:-
:-#define ZONE_ROUNDING 32
:-
:-#define ZENTRY_FREE 0x12342378
:-/*
:- * void *zalloc(vm_zone_t zone) --
:- * Returns an item from a specified zone.
:- *
:- * void zfree(vm_zone_t zone, void *item) --
:- * Frees an item back to a specified zone.
:- */
:-static __inline__ void *
:-_zalloc(vm_zone_t z)
:-{
:-void *item;
:-
:-#ifdef INVARIANTS
:-if (z == 0)
:-zerror(ZONE_ERROR_INVALID);
:-#endif
:-
:-if (z-zfreecnt = z-zfreemin)
:-return _zget(z);
:-
:-item = z-zitems;
:-z-zitems = ((void **) item)[0];
:-#ifdef INVARIANTS
:-if (((void **) item)[1] != (void *) ZENTRY_FREE)
:-zerror(ZONE_ERROR_NOTFREE);
:-((void **) item)[1] = 0;
:-#endif
:-
:-z-zfreecnt--;
:-z-znalloc++;
:-return item;
:-}
:-
:-static __inline__ void
:-_zfree(vm_zone_t z, void *item)
:-{
:-((void **) item)[0] = z-zitems;
:-#ifdef INVARIANTS
:-if (((void **) item)[1] == (void *) ZENTRY_FREE)
:-zerror(ZONE_ERROR_ALREADYFREE);
:-((void **) item)[1] = (void *) ZENTRY_FREE;
:-#endif
:-z-zitems = item;
:-z-zfreecnt++;
:-}
:-
: static __inline__ void *
: zalloc(vm_zone_t z)
: {
:-#if defined(SMP)
:
Re: NFS/VM panic in current with INVARIANTS
: :It looks like you guys got it! What is currently checked in (by Assar) :is working fine! :-) : :M Excellent news! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS/VM panic in current with INVARIANTS
Hi Matt I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. The panic() is "freeing free entry", and the traceback (minus most of the numbers) is: panic zerror zfreei NDFREE nfsrv_lookup nfs_nfsd nfssvc syscall(2f, 2f, 2f, 1, 0) xint0x80 NFS activity (not mounting) triggers it. The panic happens on the server box, which is a dual-cpu i386 class running an SMP kernel. What else do you need? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
:Hi Matt
:
:I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS
:set. I suppose I could "fix" this by taking out INVARIANTS, but it
:seems to make more sense to try to get it fixed.
:
:The panic() is "freeing free entry", and the traceback (minus most
:of the numbers) is:
:
:panic
:zerror
:zfreei
:NDFREE
:nfsrv_lookup
:nfs_nfsd
:nfssvc
:syscall(2f, 2f, 2f, 1, 0)
:xint0x80
:
:NFS activity (not mounting) triggers it. The panic happens on the
:server box, which is a dual-cpu i386 class running an SMP kernel.
:
:What else do you need?
:
:M
:--
:Mark Murray
:Warning: this .sig is umop ap!sdn
It could be real, but it's impossible for me to tell because
whoever wrote the INVARIANTS code for _zfree() wrote completely
and utterly illegal code.
static __inline__ void
_zfree(vm_zone_t z, void *item)
{
((void **) item)[0] = z-zitems;
#ifdef INVARIANTS
if (((void **) item)[1] == (void *) ZENTRY_FREE)
zerror(ZONE_ERROR_ALREADYFREE);
((void **) item)[1] = (void *) ZENTRY_FREE;
#endif
z-zitems = item;
z-zfreecnt++;
}
For all we know, item[1] might contain ZENTRY_FREE normally! This
type of invariant code check is just asking for it.
I don't see anything specifically wrong with nfs's use of NDFREE. It's
sophisticated enough that there certainly could be an issue there.
In order to tell for sure, the _zfree() code needs to have a little more
sophistication. When it finds a ZENTRY_FREE, that's only a hint... it
really needs to also iterate through the items list to see if the
structure is in fact already on the freelist. Please try the below
(completely untested!!) patch and see if you still get the panic.
-Matt
Index: vm_zone.h
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
retrieving revision 1.13
diff -u -r1.13 vm_zone.h
--- vm_zone.h 1999/08/28 00:52:44 1.13
+++ vm_zone.h 2000/12/26 18:39:07
@@ -102,8 +102,14 @@
{
((void **) item)[0] = z-zitems;
#ifdef INVARIANTS
- if (((void **) item)[1] == (void *) ZENTRY_FREE)
- zerror(ZONE_ERROR_ALREADYFREE);
+ if (((void **) item)[1] == (void *) ZENTRY_FREE) {
+ void *scan;
+
+ for (scan = z-zitems; scan; scan = ((void **)scan)[0]) {
+ if (scan == item)
+ zerror(ZONE_ERROR_ALREADYFREE);
+ }
+ }
((void **) item)[1] = (void *) ZENTRY_FREE;
#endif
z-zitems = item;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
On Tue, Dec 26, 2000 at 02:00:54PM +0200, Mark Murray wrote: I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. Do you have NFS compiled in to the kernel? I've had trouble using INVARIANTS in the kernel and NFS as a module many times - it always panics in the zone allocation stuff. (Either you always need to compile modules with the same INVARIENTS options as the kernel, or we need to fix INVARIENTS so it doesn't change the expected behaviour of anything in the kernel) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
:Do you have NFS compiled in to the kernel? I've had trouble using :INVARIANTS in the kernel and NFS as a module many times - it always :panics in the zone allocation stuff. : :(Either you always need to compile modules with the same INVARIENTS :options as the kernel, or we need to fix INVARIENTS so it doesn't :change the expected behaviour of anything in the kernel) : : David. zalloc/zfree have inlined components. Mixing INVARIENTS is virtually guarenteed to crash the NDFREE code because the expected magic numbers will not be there. I sure hope this turns out to be Mark's problem. I have a feeling that the issue may go deeper. There is conditional code in the zalloc/zfree inlines for SMP vs non-SMP. This will break modules in an SMP system worse then the INVARIENTS will. I mean *seriously* break... massive corruption and the like can occur. I think the only real solution is to rip out the externally visible zalloc/zfree inlines and replace them with real routines. I will happily do this, those inlines have always been an eyesore to me and the performance benefit is minimal at best. That will solve the SMP and INVARIENTS mixing problem (at least for zalloc/zfree). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
Matt Dillon [EMAIL PROTECTED] writes: I think the only real solution is to rip out the externally visible zalloc/zfree inlines and replace them with real routines. I will happily do this, those inlines have always been an eyesore to me and the performance benefit is minimal at best. That will solve the SMP and INVARIENTS mixing problem (at least for zalloc/zfree). Just make them always call zalloci() and zfreei(). /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
: :Matt Dillon [EMAIL PROTECTED] writes: : I think the only real solution is to rip out the externally visible : zalloc/zfree inlines and replace them with real routines. I will happily : do this, those inlines have always been an eyesore to me and the : performance benefit is minimal at best. That will solve the SMP and : INVARIENTS mixing problem (at least for zalloc/zfree). : :Just make them always call zalloci() and zfreei(). : :/assar I don't think that's good enough. At the moment the API for non-interrupt operation is zalloc() and zfree(), and zalloci() and zfreei() are supposed to be called from interrupts.If we intend to keep both families (zalloc() and zalloci()), then both families have to work properly. If we intend to remove one family (i.e. remove the zalloc() family), then we have to physically remove the calls from the codebase to prevent anyone from accidently calling them from an SMP build. We can't just go do an end-run around the established API as a hack around the problem. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
Matt Dillon [EMAIL PROTECTED] writes:
We can't just go do an end-run around the established API as a
hack around the problem.
I fail too se how my suggestion would change the API at all, but in
case I was unclear, diffs are below.
/assar
Index: vm_zone.c
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
retrieving revision 1.35
diff -u -w -r1.35 vm_zone.c
--- vm_zone.c 2000/12/13 10:01:00 1.35
+++ vm_zone.c 2000/12/27 00:13:44
@@ -32,6 +32,81 @@
static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
+#include machine/lock.h
+
+struct vm_zone {
+ struct simplelock zlock;/* lock for data structure */
+ void*zitems;/* linked list of items */
+ int zfreecnt; /* free entries */
+ int zfreemin; /* minimum number of free entries */
+ int znalloc;/* number of allocations */
+ vm_offset_t zkva; /* Base kva of zone */
+ int zpagecount; /* Total # of allocated pages */
+ int zpagemax; /* Max address space */
+ int zmax; /* Max number of entries allocated */
+ int ztotal; /* Total entries allocated now */
+ int zsize; /* size of each entry */
+ int zalloc; /* hint for # of pages to alloc */
+ int zflags; /* flags for zone */
+ int zallocflag; /* flag for allocation */
+ struct vm_object *zobj; /* object to hold zone */
+ char*zname; /* name for diags */
+ struct vm_zone *znext; /* list of zones for sysctl */
+};
+
+#define ZONE_ERROR_INVALID 0
+#define ZONE_ERROR_NOTFREE 1
+#define ZONE_ERROR_ALREADYFREE 2
+
+#define ZONE_ROUNDING 32
+
+#define ZENTRY_FREE0x12342378
+/*
+ * void *zalloc(vm_zone_t zone) --
+ * Returns an item from a specified zone.
+ *
+ * void zfree(vm_zone_t zone, void *item) --
+ * Frees an item back to a specified zone.
+ */
+static __inline__ void *
+_zalloc(vm_zone_t z)
+{
+ void *item;
+
+#ifdef INVARIANTS
+ if (z == 0)
+ zerror(ZONE_ERROR_INVALID);
+#endif
+
+ if (z-zfreecnt = z-zfreemin)
+ return _zget(z);
+
+ item = z-zitems;
+ z-zitems = ((void **) item)[0];
+#ifdef INVARIANTS
+ if (((void **) item)[1] != (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_NOTFREE);
+ ((void **) item)[1] = 0;
+#endif
+
+ z-zfreecnt--;
+ z-znalloc++;
+ return item;
+}
+
+static __inline__ void
+_zfree(vm_zone_t z, void *item)
+{
+ ((void **) item)[0] = z-zitems;
+#ifdef INVARIANTS
+ if (((void **) item)[1] == (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_ALREADYFREE);
+ ((void **) item)[1] = (void *) ZENTRY_FREE;
+#endif
+ z-zitems = item;
+ z-zfreecnt++;
+}
+
/*
* This file comprises a very simple zone allocator. This is used
* in lieu of the malloc allocator, where needed or more optimal.
Index: vm_zone.h
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
retrieving revision 1.13
diff -u -w -r1.13 vm_zone.h
--- vm_zone.h 1999/08/28 00:52:44 1.13
+++ vm_zone.h 2000/12/27 00:13:44
@@ -21,29 +21,9 @@
#define ZONE_INTERRUPT 1 /* Use this if you need to allocate at int time */
#define ZONE_BOOT 16/* This is an internal flag used by zbootinit */
-#include machine/lock.h
+struct vm_zone;
+typedef struct vm_zone *vm_zone_t;
-typedef struct vm_zone {
- struct simplelock zlock;/* lock for data structure */
- void*zitems;/* linked list of items */
- int zfreecnt; /* free entries */
- int zfreemin; /* minimum number of free entries */
- int znalloc;/* number of allocations */
- vm_offset_t zkva; /* Base kva of zone */
- int zpagecount; /* Total # of allocated pages */
- int zpagemax; /* Max address space */
- int zmax; /* Max number of entries allocated */
- int ztotal; /* Total entries allocated now */
- int zsize; /* size of each entry */
- int zalloc; /* hint for # of pages to alloc */
- int zflags; /* flags for zone */
- int zallocflag; /* flag for allocation */
- struct vm_object *zobj; /* object to hold zone */
- char*zname; /* name for diags */
- struct vm_zone *znext; /* list of zones for sysctl */
-} *vm_zone_t;
-
-
void zerror __P((int)) __dead2;
vm_zone_t zinit __P((char *name, int size, int nentries,
Re: NFS/VM panic in current with INVARIANTS
:Matt Dillon [EMAIL PROTECTED] writes: : We can't just go do an end-run around the established API as a : hack around the problem. : :I fail too se how my suggestion would change the API at all, but in :case I was unclear, diffs are below. : :/assar : Well, yes... that's essentially what I suggested. You didn't say anything about removing the externalized inlines, which is what you do in your patch. Looks like a fine patch to me. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
Matt Dillon [EMAIL PROTECTED] writes:
Well, yes... that's essentially what I suggested. You didn't say
anything about removing the externalized inlines, which is what you
do in your patch. Looks like a fine patch to me.
Except it didn't work. Now here's a patch that survived building a
kernel and modules. ok?
/assar
Index: vm_zone.c
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
retrieving revision 1.35
diff -u -w -r1.35 vm_zone.c
--- vm_zone.c 2000/12/13 10:01:00 1.35
+++ vm_zone.c 2000/12/27 00:59:14
@@ -32,6 +32,59 @@
static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
+#define ZONE_ERROR_INVALID 0
+#define ZONE_ERROR_NOTFREE 1
+#define ZONE_ERROR_ALREADYFREE 2
+
+#define ZONE_ROUNDING 32
+
+#define ZENTRY_FREE0x12342378
+/*
+ * void *zalloc(vm_zone_t zone) --
+ * Returns an item from a specified zone.
+ *
+ * void zfree(vm_zone_t zone, void *item) --
+ * Frees an item back to a specified zone.
+ */
+static __inline__ void *
+_zalloc(vm_zone_t z)
+{
+ void *item;
+
+#ifdef INVARIANTS
+ if (z == 0)
+ zerror(ZONE_ERROR_INVALID);
+#endif
+
+ if (z-zfreecnt = z-zfreemin)
+ return _zget(z);
+
+ item = z-zitems;
+ z-zitems = ((void **) item)[0];
+#ifdef INVARIANTS
+ if (((void **) item)[1] != (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_NOTFREE);
+ ((void **) item)[1] = 0;
+#endif
+
+ z-zfreecnt--;
+ z-znalloc++;
+ return item;
+}
+
+static __inline__ void
+_zfree(vm_zone_t z, void *item)
+{
+ ((void **) item)[0] = z-zitems;
+#ifdef INVARIANTS
+ if (((void **) item)[1] == (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_ALREADYFREE);
+ ((void **) item)[1] = (void *) ZENTRY_FREE;
+#endif
+ z-zitems = item;
+ z-zfreecnt++;
+}
+
/*
* This file comprises a very simple zone allocator. This is used
* in lieu of the malloc allocator, where needed or more optimal.
Index: vm_zone.h
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
retrieving revision 1.13
diff -u -w -r1.13 vm_zone.h
--- vm_zone.h 1999/08/28 00:52:44 1.13
+++ vm_zone.h 2000/12/27 00:59:14
@@ -43,7 +43,6 @@
struct vm_zone *znext; /* list of zones for sysctl */
} *vm_zone_t;
-
void zerror __P((int)) __dead2;
vm_zone_t zinit __P((char *name, int size, int nentries, int flags,
int zalloc));
@@ -57,77 +56,16 @@
int nitems));
void * _zget __P((vm_zone_t z));
-#define ZONE_ERROR_INVALID 0
-#define ZONE_ERROR_NOTFREE 1
-#define ZONE_ERROR_ALREADYFREE 2
-
-#define ZONE_ROUNDING 32
-
-#define ZENTRY_FREE0x12342378
-/*
- * void *zalloc(vm_zone_t zone) --
- * Returns an item from a specified zone.
- *
- * void zfree(vm_zone_t zone, void *item) --
- * Frees an item back to a specified zone.
- */
-static __inline__ void *
-_zalloc(vm_zone_t z)
-{
- void *item;
-
-#ifdef INVARIANTS
- if (z == 0)
- zerror(ZONE_ERROR_INVALID);
-#endif
-
- if (z-zfreecnt = z-zfreemin)
- return _zget(z);
-
- item = z-zitems;
- z-zitems = ((void **) item)[0];
-#ifdef INVARIANTS
- if (((void **) item)[1] != (void *) ZENTRY_FREE)
- zerror(ZONE_ERROR_NOTFREE);
- ((void **) item)[1] = 0;
-#endif
-
- z-zfreecnt--;
- z-znalloc++;
- return item;
-}
-
-static __inline__ void
-_zfree(vm_zone_t z, void *item)
-{
- ((void **) item)[0] = z-zitems;
-#ifdef INVARIANTS
- if (((void **) item)[1] == (void *) ZENTRY_FREE)
- zerror(ZONE_ERROR_ALREADYFREE);
- ((void **) item)[1] = (void *) ZENTRY_FREE;
-#endif
- z-zitems = item;
- z-zfreecnt++;
-}
-
static __inline__ void *
zalloc(vm_zone_t z)
{
-#if defined(SMP)
return zalloci(z);
-#else
- return _zalloc(z);
-#endif
}
static __inline__ void
zfree(vm_zone_t z, void *item)
{
-#ifdef SMP
zfreei(z, item);
-#else
- _zfree(z, item);
-#endif
}
-#endif
+#endif /* _SYS_ZONE_H */
Re: NFS/VM panic in current with INVARIANTS
:--=-=-=
:
:Matt Dillon [EMAIL PROTECTED] writes:
: Well, yes... that's essentially what I suggested. You didn't say
: anything about removing the externalized inlines, which is what you
: do in your patch. Looks like a fine patch to me.
:
:Except it didn't work. Now here's a patch that survived building a
:kernel and modules. ok?
:
:/assar
lets see.. ok, I'm going to read the patch carefully this time..
This isn't quite what I had in mind. You are still making an API
change... you are now calling zalloci() from zalloc() for non-SMP boxes.
There is no need to do that.
Instead what I would recommend is making zalloc() and zfree() real
procedures, putting them in vm_zone.c, and removing their inlines from
vm_zone.h. i.e. not have *ANY* inlines at all in vm_zone.h
Then as real procedures in vm_zone.c these functions can have the
#ifdef SMP / related code left intact.
-Matt
:
:--=-=-=
:Content-Disposition: attachment; filename=zalloc-diff
:
:Index: vm_zone.c
:===
:RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
:retrieving revision 1.35
:diff -u -w -r1.35 vm_zone.c
:--- vm_zone.c 2000/12/13 10:01:00 1.35
:+++ vm_zone.c 2000/12/27 00:59:14
:@@ -32,6 +32,59 @@
:
: static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
:
:+#define ZONE_ERROR_INVALID 0
:+#define ZONE_ERROR_NOTFREE 1
:+#define ZONE_ERROR_ALREADYFREE 2
:+
:+#define ZONE_ROUNDING 32
:+
:+#define ZENTRY_FREE 0x12342378
:+/*
:+ * void *zalloc(vm_zone_t zone) --
:+ *Returns an item from a specified zone.
:+ *
:+ * void zfree(vm_zone_t zone, void *item) --
:+ * Frees an item back to a specified zone.
:+ */
:+static __inline__ void *
:+_zalloc(vm_zone_t z)
:+{
:+ void *item;
:+
:+#ifdef INVARIANTS
:+ if (z == 0)
:+ zerror(ZONE_ERROR_INVALID);
:+#endif
:+
:+ if (z-zfreecnt = z-zfreemin)
:+ return _zget(z);
:+
:+ item = z-zitems;
:+ z-zitems = ((void **) item)[0];
:+#ifdef INVARIANTS
:+ if (((void **) item)[1] != (void *) ZENTRY_FREE)
:+ zerror(ZONE_ERROR_NOTFREE);
:+ ((void **) item)[1] = 0;
:+#endif
:+
:+ z-zfreecnt--;
:+ z-znalloc++;
:+ return item;
:+}
:+
:+static __inline__ void
:+_zfree(vm_zone_t z, void *item)
:+{
:+ ((void **) item)[0] = z-zitems;
:+#ifdef INVARIANTS
:+ if (((void **) item)[1] == (void *) ZENTRY_FREE)
:+ zerror(ZONE_ERROR_ALREADYFREE);
:+ ((void **) item)[1] = (void *) ZENTRY_FREE;
:+#endif
:+ z-zitems = item;
:+ z-zfreecnt++;
:+}
:+
: /*
: * This file comprises a very simple zone allocator. This is used
: * in lieu of the malloc allocator, where needed or more optimal.
:Index: vm_zone.h
:===
:RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
:retrieving revision 1.13
:diff -u -w -r1.13 vm_zone.h
:--- vm_zone.h 1999/08/28 00:52:44 1.13
:+++ vm_zone.h 2000/12/27 00:59:14
:@@ -43,7 +43,6 @@
: struct vm_zone *znext; /* list of zones for sysctl */
: } *vm_zone_t;
:
:-
: void zerror __P((int)) __dead2;
: vm_zone_t zinit __P((char *name, int size, int nentries, int flags,
: int zalloc));
:@@ -57,77 +56,16 @@
: int nitems));
: void *_zget __P((vm_zone_t z));
:
:-#define ZONE_ERROR_INVALID 0
:-#define ZONE_ERROR_NOTFREE 1
:-#define ZONE_ERROR_ALREADYFREE 2
:-
:-#define ZONE_ROUNDING 32
:-
:-#define ZENTRY_FREE 0x12342378
:-/*
:- * void *zalloc(vm_zone_t zone) --
:- *Returns an item from a specified zone.
:- *
:- * void zfree(vm_zone_t zone, void *item) --
:- * Frees an item back to a specified zone.
:- */
:-static __inline__ void *
:-_zalloc(vm_zone_t z)
:-{
:- void *item;
:-
:-#ifdef INVARIANTS
:- if (z == 0)
:- zerror(ZONE_ERROR_INVALID);
:-#endif
:-
:- if (z-zfreecnt = z-zfreemin)
:- return _zget(z);
:-
:- item = z-zitems;
:- z-zitems = ((void **) item)[0];
:-#ifdef INVARIANTS
:- if (((void **) item)[1] != (void *) ZENTRY_FREE)
:- zerror(ZONE_ERROR_NOTFREE);
:- ((void **) item)[1] = 0;
:-#endif
:-
:- z-zfreecnt--;
:- z-znalloc++;
:- return item;
:-}
:-
:-static __inline__ void
:-_zfree(vm_zone_t z, void *item)
:-{
:- ((void **) item)[0] = z-zitems;
:-#ifdef INVARIANTS
:- if (((void **) item)[1] == (void *) ZENTRY_FREE)
:- zerror(ZONE_ERROR_ALREADYFREE);
:- ((void **) item)[1] = (void *) ZENTRY_FREE;
:-#endif
:- z-zitems = item;
:- z-zfreecnt++;
:-}
:-
: static __inline__ void *
: zalloc(vm_zone_t z)
: {
:-#if defined(SMP)
: return zalloci(z);
:-#else
:- return _zalloc(z);
:-#endif
: }
:
: static __inline__ void
: zfree(vm_zone_t z, void *item)
: {
:-#ifdef SMP
: zfreei(z, item);
:-#else
:- _zfree(z, item);
:-#endif
:
Re: NFS/VM panic in current with INVARIANTS
On Tue, Dec 26, 2000 at 02:00:54PM +0200, Mark Murray wrote: I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. Do you have NFS compiled in to the kernel? I've had trouble using INVARIANTS in the kernel and NFS as a module many times - it always panics in the zone allocation stuff. No I don't. Hmmm... (Either you always need to compile modules with the same INVARIENTS options as the kernel, or we need to fix INVARIENTS so it doesn't change the expected behaviour of anything in the kernel) OK. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
