> several functions that call vm_object functions in FreeBSD's kernel that > eventually call atomic_clear_short(). For some reason those functions in > between aren't in the backtrace though, and without that I can (and > have) look through the code in the kernel to see how nv_alloc_pages can > get to atomic_clear_short through vm calls, but I'm not sure that's too > awefully helpful.
Actually, after tracing through again, it appears to be following this codepath: (in reverse order from a backtrace) nv_alloc_pages() nv_free_vm_object() vm_object_deallocate() vm_object_clear_flag() atomic_clear_short() so I think it's possible that something may be getting screwed up between nv_free_vm_object and atomic_clear_short(). I'm not really sure how to tell though. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message