Robert Watson wrote this message on Thu, Jan 26, 2006 at 10:21 +0000: > On Wed, 25 Jan 2006, John-Mark Gurney wrote: > > >Ok, just ran across a new LOR when trying to unload a module: > >lock order reversal: (sleepable after non-sleepable) > >1st 0xc106c708 mt_zone (UMA zone) _at_ vm/uma_core.c:2448 > >2nd 0xc3934044 user map (user map) _at_ vm/vm_map.c:2993 > > This isn't a lock order reversal, it's a page fault. However, you get a > report of a lock order reversal when the page fault handler grabs locks. > Ideally, this wouldn't be the case. > > To do anything useful, it would be helpful to have the line number in > uma_zfree_arg() and uma_zfree_internal(), and also to know what you were > kld unloading -- probably, it's a bug in the kld, which has torn down the > UMA zone before calling free on a member of the zone. Line numbers: (gdb) list *uma_zfree_internal+0xd0 0xc060ecc4 is in uma_zfree_internal (../../../vm/uma_core.c:2468). 2468 if (slab->us_freecount+1 == keg->uk_ipers) { (gdb) list *uma_zfree_arg+0x348 0xc060ebec is in uma_zfree_arg (../../../vm/uma_core.c:2420). 2420 } bash-2.05b$ ident ../../vm/uma_core.c ../../vm/uma_core.c: $FreeBSD: src/sys/vm/uma_core.c,v 1.134 2006/01/06 18:03:45 jhb Exp $ I'm quite puzzeled by the line numbers... as for the module I was unloading, it is the bktrau driver, the source is in p4 (//depot/user/jmg/bktrau/...), any other information you need? Unfortunately, I didn't get a dump: db> panic panic: from debugger cpuid = 0 Uptime: 4m50s Dumping 375 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 375MB (95984 pages) 359 343 327 311 295 279 263 247 231 215 199 183 1 67 151ad0: FAILURE - out of memory in start ... fail ** DUMP FAILED (ERROR 12) ** This is on an ata device... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."Received on Thu Jan 26 2006 - 17:04:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC