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) _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 - 16:40:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:40 UTC