Re: swap_pager_swap_init panic

From: Eric Anderson <anderson_at_freebsd.org>
Date: Wed, 16 May 2007 07:24:31 -0500
On 05/05/07 17:40, Eric Anholt wrote:
> 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.
> 


Anything more come of this?  I'm seeing this too.  AMD64, recent 
-CURRENT, SMP, Core 2 Duo, NFS booting.


Eric
Received on Wed May 16 2007 - 10:24:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:10 UTC