From owner-freebsd-stable Sun Nov 17 19:35: 4 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA02837B401 for ; Sun, 17 Nov 2002 19:35:02 -0800 (PST) Received: from hub.org (hub.org [64.49.215.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A94343E4A for ; Sun, 17 Nov 2002 19:35:02 -0800 (PST) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [64.49.215.141]) by hub.org (Postfix) with ESMTP id 7DAA78A2D96 for ; Sun, 17 Nov 2002 23:34:55 -0400 (AST) Date: Sun, 17 Nov 2002 23:34:55 -0400 (AST) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Subject: Re: -STABLE was stable for long time In-Reply-To: <20021118031634.GA755@laurel.tmseck.homedns.org> Message-ID: <20021117232943.C23359-100000@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 18 Nov 2002, Thomas Seck wrote: > Test programs that bevave like your users - spawning lots of processes > and the like? I am not a developer - are there some "load simulating" > suites available? If so, I could give them a try regularly on various > i386 machines at work. If not, could we talk some of the core developers > into developing a test suite? The problem, again, is that once you get into the real life scenario, you are dealing with 100+1 different programs that are not only putting a load on the server, but are interacting with it ... Basically, the 'test suite' is guys like myself that are willing to take the risk and run -STABLE ... the mechanism that needs to be put into place, though, is for getting those bugs addressed so that they don't repeat ... > I am talking with my system administrator hat on. My production servers > did not run into troubles with -RELEASE so far. My -STABLE machines at > home did not, too. Maybe I am just lucky... But I agree with you that > having some dedicated testing boxes would be a "good thing"(tm). 10hrs after I downgraded to RELENG_4_7, the server crashed ... in the VM subsystem, from what I can tell: (kgdb) where #0 0xc959b256 in ?? () #1 0xc013ec50 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:223 #2 0xc013f375 in panic (fmt=0xc02111f9 "%s") at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc01e4f15 in trap_fatal (frame=0xf46e4e18, eva=4048397648) at /usr/src/sys/i386/i386/trap.c:974 #4 0xc01e4b81 in trap_pfault (frame=0xf46e4e18, usermode=0, eva=4048397648) at /usr/src/sys/i386/i386/trap.c:867 #5 0xc01e46db in trap (frame={tf_fs = 24, tf_es = -194117616, tf_ds = -1071972336, tf_edi = 0, tf_esi = -158666368, tf_ebp = -194097564, tf_isp = -194097596, tf_ebx = -247896864, tf_edx = -246569648, tf_ecx = 16777217, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071953732, tf_cs = 8, tf_eflags = 66118, tf_esp = -193136816, tf_ss = -160643136}) at /usr/src/sys/i386/i386/trap.c:466 #6 0xc01b48bc in vm_object_deallocate (object=0xf13964e0) at /usr/src/sys/vm/vm_object.c:386 #7 0xc01b1c03 in vm_map_entry_delete (map=0xf66cc7c0, entry=0xf47cf750) at /usr/src/sys/vm/vm_map.c:1829 #8 0xc01b1d85 in vm_map_delete (map=0xf66cc7c0, start=0, end=3217031168) at /usr/src/sys/vm/vm_map.c:1932 #9 0xc01b1e12 in vm_map_remove (map=0xf66cc7c0, start=0, end=3217031168) at /usr/src/sys/vm/vm_map.c:1957 #10 0xc0137248 in exit1 (p=0xf47be6c0, rv=0) at /usr/src/sys/kern/kern_exit.c:217 #11 0xc0137018 in exit1 (p=0xf47be6c0, rv=-878618816) at /usr/src/sys/kern/kern_exit.c:103 #12 0xc01e5251 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1, tf_ebp = -1077937844, tf_isp = -194097196, tf_ebx = 672716588, tf_edx = 672716000, tf_ecx = -1077937460, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 672397204, tf_cs = 31, tf_eflags = 647, tf_esp = -1077937888, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175 #13 0xc01d297b in Xint0x80_syscall () cannot read proc at 0 (kgdb) 20hrs later, that same server, with the same kernel, is still purring along ... and it might be another 20 days before it crashes again ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message