Re: Another UMA panic under load
Andrew Gallatin wrote: 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. No, they should probably be wired into machdep.c, instead. It was pretty obvious (to me) that UMA could not use the kmem primitives, if it wanted to avoid Giant, even right at the beginning of integration. I just assumed that this was known, and that it would be dealt with later, using one of several approaches. IMO, the easiest approach is mapping all physical RAM into the KVA at the start of life, and then apportioning it out from there. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another UMA panic under load
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
