From owner-freebsd-alpha@FreeBSD.ORG Wed Mar 17 15:04:37 2004 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2331D16A4F6 for ; Wed, 17 Mar 2004 15:04:37 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4FEE43D2D for ; Wed, 17 Mar 2004 15:04:36 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 16668 invoked from network); 17 Mar 2004 23:04:36 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 17 Mar 2004 23:04:36 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i2HN4W28073163; Wed, 17 Mar 2004 18:04:32 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Wilko Bulte Date: Wed, 17 Mar 2004 18:06:01 -0500 User-Agent: KMail/1.6 References: <200403121543.03123.jhb@FreeBSD.org> <200403171122.31121.jhb@FreeBSD.org> <20040317224324.GA80099@freebie.xs4all.nl> In-Reply-To: <20040317224324.GA80099@freebie.xs4all.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403171806.01271.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: alpha@FreeBSD.org Subject: Re: Testers Needed!! X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 23:04:37 -0000 On Wednesday 17 March 2004 05:43 pm, Wilko Bulte wrote: > On Wed, Mar 17, 2004 at 11:22:31AM -0500, John Baldwin wrote: > > On Wednesday 17 March 2004 02:28 am, Wilko Bulte wrote: > > > On Tue, Mar 16, 2004 at 05:48:49PM +0100, Wilko Bulte wrote: > > > > On Tue, Mar 16, 2004 at 10:59:04AM -0500, John Baldwin wrote: > > > > > On Tuesday 16 March 2004 01:57 am, Wilko Bulte wrote: > > > > > > backtrace() at backtrace+0x2c^M > > > witness_checkorder() at witness_checkorder+0x6c0^M > > > _mtx_lock_flags() at _mtx_lock_flags+0x9c^M > > > obj_alloc() at obj_alloc+0x58^M > > > slab_zalloc() at slab_zalloc+0xcc^M > > > uma_zone_slab() at uma_zone_slab+0x108^M > > > uma_zalloc_internal() at uma_zalloc_internal+0x5c^M > > > uma_zalloc_arg() at uma_zalloc_arg+0x418^M > > > swp_pager_meta_build() at swp_pager_meta_build+0x148^M > > > swap_pager_putpages() at swap_pager_putpages+0x380^M > > > default_pager_putpages() at default_pager_putpages+0x1c^M > > > vm_pageout_flush() at vm_pageout_flush+0x1e0^M > > > _end() at 0xfffffc003fade020^M > > > prologue botch: displacement 16^M > > > panic: > > > > > > Machine seems to have locked up solid, I cannot get back to the > > > console, does not react to a break. It does respond to ping's however. > > > > Hmm, well, that LOR is a known bogus one. It seems that ddb panic'd > > trying to do the backtrace though (tracing off of _end is usually a bad > > sign). Can you reproduce any of these problems if you test under load > > w/o the preemption patch? > > With the patch still in I just got: > > db> trace > Debugger() at Debugger+0x38 > __panic() at __panic+0x228 > sleepq_timeout() at sleepq_timeout+0x10c > softclock() at softclock+0x228 > ithread_loop() at ithread_loop+0x1a4 > fork_exit() at fork_exit+0x100 > exception_return() at exception_return > --- root of call graph --- > db> > > Sofar I seem to have a set of different footprints. Heh, that wouldn't happen to have been the bogus assertion I fixed recently would it? RCS file: /usr/cvs/src/sys/kern/subr_sleepqueue.c,v ---------------------------- revision 1.4 date: 2004/03/16 18:56:22; author: jhb; state: Exp; lines: +1 -1 Remove a bogus assertion and readd it in a more correct location. A thread might be enqueued on a sleep queue but not be asleep when the timeout fires if it is blocked on a lock trying to check for pending signals before going to sleep. In the case of fixing up the TDF_TIMEOUT race, however, the thread must be marked asleep. Reported by: kan (the bogus one) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org