Kernel spewing errors/warnings on 7.0-CURRENT

Alan Cox alc at cs.rice.edu
Thu Aug 4 18:40:52 GMT 2005


On Thu, Aug 04, 2005 at 11:21:33AM +0100, Robert Watson wrote:
> On Thu, 4 Aug 2005, R. Tyler Ballance wrote:
> 
> >After restarting my FreeBSD-CURRENT workstation, shortly after I logged 
> >in, and shortly before bg_fsck had completely (power outage last night) 
> >I got the following set of messages spewed to ttyv0 :
> 
> This is a non-fatal warning of a lock order issue between UMA and the VM 
> system.  I.e., you don't need to worry per se, but we do need to fix the 
> source of the problem.  I haven't had a chance to investigate what commit 
> started the recent spate of these, but I'm guessing a new lock is either 
> acquired in the vm_pageout code, or in the vm_map code, and UMA sits in 
> the middle.  This is part of the cyclic dependency between UMA an VM. 
> UMA is acquiring its lock so it can safely walk and drain the zone list 
> without zones disappearing, etc.

Off the top my head, I can't think of any recent locking changes
that could have this effect.  That aside, the lock order below is the
one that I would describe as correct, or at least expected.  Can you
hardwire this ordering into witness and see where it is being
violated.  I hypothesize that it is startup_alloc().

Regards,
Alan

> >
> >Aug  3 16:19:17 workstation kernel: lock order reversal
> >Aug  3 16:19:17 workstation kernel: 1st 0xc097ab20 UMA lock (UMA lock) @ 
> >/usr/src/sys/vm/uma_core.c:1491
> >Aug  3 16:19:17 workstation kernel: 2nd 0xc1060144 system map (system map) 
> >@ /usr/src/sys/vm/vm_map.c:2317
> >Aug  3 16:19:17 workstation kernel: KDB: stack backtrace:
> >Aug  3 16:19:17 workstation kernel: kdb_backtrace 
> >(0,ffffffff,c092fc38,c092fd78,c08ba624) at kdb_backtrace+0x29
> >Aug  3 16:19:17 workstation kernel: witness_checkorder 
> >(c1060144,9,c0870d80,90d) at witness_checkorder+0x564
> >Aug  3 16:19:17 workstation kernel: 
> >_mtx_lock_flags(c1060144,0,c0870d80,90d) at _mtx_lock_flags+0x5b
> >Aug  3 16:19:17 workstation kernel: _vm_map_lock(c10600c0,c0870d80,90d) at 
> >_vm_map_lock+0x26
> >Aug  3 16:19:17 workstation kernel: vm_map_remove 
> >(c10600c0,c1d0a000,c1d0b000,d56ecc08,c077e4e1) at vm_map_remove+0x1f
> >Aug  3 16:19:17 workstation kernel: kmem_free 
> >(c10600c0,c1d0a000,1000,d56ecc38,c077de8e) at kmem_free+0x25
> >Aug  3 16:19:17 workstation kernel: page_free(c1d0a000,1000,2) at 
> >page_free+0x29
> >Aug  3 16:19:17 workstation kernel: zone_drain(c104a960) at 
> >zone_drain+0x26a
> >Aug  3 16:19:17 workstation kernel: zone_foreach 
> >(c077dc24,d56eccec,c078fcaf,c1a3d900,d56ecc74) at zone_foreach+0x37
> >Aug  3 16:19:17 workstation kernel: uma_reclaim 
> >(c1a3d900,d56ecc74,0,c0926260,d56ecc80) at uma_reclaim+0x12
> >Aug  3 16:19:17 workstation kernel: vm_pageout_scan 
> >(0,c097af80,0,c087226d,5c3) at vm_pageout_scan+0x103
> >Aug  3 16:19:17 workstation kernel: vm_pageout(0,d56ecd38,0,c0790a68,0) at 
> >vm_pageout+0x2c3
> >Aug  3 16:19:17 workstation kernel: fork_exit(c0790a68,0,d56ecd38) at 
> >fork_exit+0xa0
> >Aug  3 16:19:17 workstation kernel: fork_trampoline() at 
> >fork_trampoline+0x8
> >Aug  3 16:19:17 workstation kernel: --- trap 0x1, eip = 0, esp = 
> >0xd56ecd6c, ebp = 0 ---
> >
> >
> >FreeBSD workstation.local 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 16 
> >15:09:18 CDT 2005     root at workstation.local:/usr/obj/usr/src/sys/GENERIC 
> >i386
> >
> >*****************************
> >
> >This didn't cause the kernel to panic or anything, I just figured the 
> >kernel debugger output might be helpful to somebody here...
> >
> >The same lock order reversal happened the last time I did a clean reboot, 
> >and this time after a hard restart.
> >
> >dmesg output is here if needed: http://agentdero.com/~tyler/ 
> >dmesg.workstation.txt
> >
> >Is this nothing to worry about? Or is something going slightly wrong?
> >
> >Cheers,
> >
> >-R. Tyler Ballance
> >
> >_______________________________________________
> >freebsd-current at freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> >


More information about the freebsd-current mailing list