Ugh. Since it may call kmem_malloc(), UMA must hold Giant. This is the same problem the mbuf system has, and its what's keeping network device drivers under Giant in 5.0.
Both subsytems should probably have GIANT_REQUIRED at all entry points so as to catch locking problems like this earlier. Drew Kris Kennaway writes: > I think this is the same one I reported a few days ago (another alpha > under heavy load). > > panic: mutex Giant not owned at /local0/src-client/sys/vm/vm_kern.c:312 > db_print_backtrace() at db_print_backtrace+0x18 > panic() at panic+0x104 > _mtx_assert() at _mtx_assert+0xb4 > kmem_malloc() at kmem_malloc+0x50 > page_alloc() at page_alloc+0x3c > uma_large_malloc() at uma_large_malloc+0x58 > malloc() at malloc+0x10c > fdalloc() at fdalloc+0x1b0 > do_dup() at do_dup+0x1a4 > dup2() at dup2+0x24 > syscall() at syscall+0x338 > XentSys() at XentSys+0x64 > --- syscall (90) --- > --- user mode --- > panic > > Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
