Date: Tue, 16 Mar 2004 10:59:04 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: alpha@freebsd.org Subject: Re: Testers Needed!! Message-ID: <200403161059.04115.jhb@FreeBSD.org> In-Reply-To: <20040316065710.GA68934@freebie.xs4all.nl> References: <200403121543.03123.jhb@FreeBSD.org> <20040315231809.GA39847@freebie.xs4all.nl> <20040316065710.GA68934@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 16 March 2004 01:57 am, Wilko Bulte wrote: > > I have the interrupt.c patch now in test. Currently the DS10 is doing a > > plain buildworld, I will move to make -j<big#> next. > > > > How long would the test need to run for a reliable indication of Go/NoGo > > Well... > > c > freebsd.submit.cf > chmod 444 freebsd.submit.cf > > real 240m14.618s > user 131m36.348s > sys 81m19.179s > ds10#lock order reversal > 1st 0xfffffc003efc7960 vm object (vm object) @ vm/swap_pager.c:1313 > 2nd 0xfffffc0000886b20 swap_pager swhash (swap_pager swhash) @ > vm/swap_pager.c: > 1803 > 3rd 0xfffffc003efca9a0 vm object (vm object) @ vm/uma_core.c:886 > Stack backtrace: > db_print_backtrace() at db_print_backtrace+0x18 > backtrace() at backtrace+0x2c > witness_checkorder() at witness_checkorder+0x6c0 > _mtx_lock_flags() at _mtx_lock_flags+0x9c > obj_alloc() at obj_alloc+0x58 > slab_zalloc() at slab_zalloc+0xcc > uma_zone_slab() at uma_zone_slab+0x108 > uma_zalloc_internal() at uma_zalloc_internal+0x5c > 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? -- 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?200403161059.04115.jhb>