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. Robert N M Watson > > Aug 3 16:19:17 workstation kernel: lock order reversal > Aug 3 16:19:17 workstation kernel: 1st 0xc097ab20 UMA lock (UMA lock) _at_ > /usr/src/sys/vm/uma_core.c:1491 > Aug 3 16:19:17 workstation kernel: 2nd 0xc1060144 system map (system map) _at_ > /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" >Received on Thu Aug 04 2005 - 08:19:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:40 UTC