Date: Wed, 17 Mar 2004 18:06:01 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: alpha@FreeBSD.org Subject: Re: Testers Needed!! Message-ID: <200403171806.01271.jhb@FreeBSD.org> In-Reply-To: <20040317224324.GA80099@freebie.xs4all.nl> References: <200403121543.03123.jhb@FreeBSD.org> <200403171122.31121.jhb@FreeBSD.org> <20040317224324.GA80099@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403171806.01271.jhb>