Date: Sat, 05 May 2007 15:40:52 -0700 From: Eric Anholt <eric@anholt.net> To: David G Lawrence <dg@dglawrence.com> Cc: current@FreeBSD.org Subject: Re: swap_pager_swap_init panic Message-ID: <1178404852.54075.47.camel@vonnegut> In-Reply-To: <20070505033659.GB2462@tnn.dglawrence.com> References: <1178329243.54075.34.camel@vonnegut> <20070505033659.GB2462@tnn.dglawrence.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Fri, 2007-05-04 at 20:36 -0700, David G Lawrence wrote: > > I've got an SMP netbooting test machine, which panics on startup almost > > 100% of the time with the issue that has been reported since 2006-12-02 > > at least: > > db> where > > Tracing pid 40 tid 100040 td 0xffffff003b9e24c0 > > kdb_enter() at kdb_enter+0x2f > > panic() at panic+0x291 > > swap_pager_swap_init() at swap_pager_swap_init+0x20c > > I had the same problem with one of my SMP machines. It's a curious problem > since I can take the same hard drive over to a slightly different SMP machine > and not see the panic. It appears to be a race of some kind in the VM system > initialization, right after the second CPU is started. > Try this patch out and let me know if it fixes it for you... > > > Index: uma_core.c > =================================================================== > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > retrieving revision 1.119.2.19 > diff -c -r1.119.2.19 uma_core.c > *** uma_core.c 11 Feb 2007 03:31:19 -0000 1.119.2.19 > --- uma_core.c 1 Mar 2007 06:52:26 -0000 > *************** > *** 1615,1621 **** > #endif > args.name = "UMA Zones"; > args.size = sizeof(struct uma_zone) + > ! (sizeof(struct uma_cache) * (mp_maxid + 1)); > args.ctor = zone_ctor; > args.dtor = zone_dtor; > args.uminit = zero_init; > --- 1615,1621 ---- > #endif > args.name = "UMA Zones"; > args.size = sizeof(struct uma_zone) + > ! (sizeof(struct uma_cache) * (mp_maxid + 33)); > args.ctor = zone_ctor; > args.dtor = zone_dtor; > args.uminit = zero_init; > > Note that I don't claim this is a proper fix - it is just a work-around > that works for me. I've got the machine busy doing something else right now. What's this patch supposed to do? The panic clearly looks like a race to me -- the swapper's got the keg's recurse flag bumped (that printf in the backtrace I think was the one just after taking the recurse flag back down), and pagedaemon is checking for recursion on using the keg, and failing. -- Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGPQf0HUdvYGzw6vcRAnNdAJ9lhfuF0i69uUs+GaMNiIluVSdiLACgjAdo 4qnG/b93p3QCU2kBFTvWeng= =yodg -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1178404852.54075.47.camel>