Date: Wed, 17 Mar 2004 11:22:31 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: alpha@freebsd.org Subject: Re: Testers Needed!! Message-ID: <200403171122.31121.jhb@FreeBSD.org> In-Reply-To: <20040317072801.GA75715@freebie.xs4all.nl> References: <200403121543.03123.jhb@FreeBSD.org> <20040316164849.GA71626@freebie.xs4all.nl> <20040317072801.GA75715@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > > uma_zalloc_arg() at uma_zalloc_arg+0x418 > > > > swp_pager_meta_build() at swp_pager_meta_build+0x148 > > > > swap_pager_putpages() at swap_pager_putpages+0x380 > > > > default_pager_putpages() at default_pager_putpages+0x1c > > > > vm_pageout_flush() at vm_pageout_flush+0x1e0 > > > > panic: pmap_emulate_reference(0xfffffc001fdc0290, 0x1606f8000, 1, 0): > > > > pa 0x0 not > > > > managed > > > > at line 2573 in file ../../../alpha/alpha/pmap.c > > > > cpuid = 0; > > > > panic > > > > Stopped at Debugger+0x38: zapnot v0,#0xf,v0 <v0=0x0> > > > > db> > > > > db> > > > > > > > > This was running a make -j32 > > > > > > This has been reported recently on the list w/o preemption, so I don't > > > think preemption is the problem here. The specific problem I saw with > > > preemption on the past only happened on SMP and was a hard hang. The > > > DS20 I was using never lasted more than a day doing a loop of > > > buildworld -j 32 or so. In fact, I don't think it even finished a -j > > > 32 buildworld but I could be wrong (it's been a while). UP never had > > > problems, it is really the SMP case that my extra changes address and > > > that needs testing. This bug (pmap one) also needs fixing, but I don't > > > think it is preemption related and I'm not sure what the bug is, though > > > it appears maybe that you got a read fault on a page that was just > > > swapped out perhaps? > > > > Could be. The system has 1GB of RAM, dunno about the swap. I'll set the > > -j somewhat lower to see if it continus to run with less load. > > I went back to really high load testing (I've seen spikes of load > avg of 80+ :) and this is the last conserver appears to have caught: > > lock order reversal^M > 1st 0xfffffc001dba10a0 vm object (vm object) @ vm/swap_pager.c:1313^M > 2nd 0xfffffc0000886b20 swap_pager swhash (swap_pager swhash) @ > vm/swap_pager.c: > 1803^M > 3rd 0xfffffc003efca9a0 vm object (vm object) @ vm/uma_core.c:886^M > Stack backtrace:^M > db_print_backtrace() at db_print_backtrace+0x18^M > 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? -- 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?200403171122.31121.jhb>