On Tue, Jun 19, 2012 at 09:30:59PM -0400, Steve Wills wrote: > Hi, > > I just got a panic out of my r237195 system. The panic looks like: > > Sleeping thread (tid 173153, pid 42034) owns a non-sleepable lock > KDB: stack backtrace of thread 173153: > sched_switch() at sched_switch+0x28a > mi_switch() at mi_switch+0xdf > sleepq_timedwait() at sleepq_timedwait+0x3a > _sleep() at _sleep+0x266 > swp_pager_meta_build() at swp_pager_meta_build+0x259 > swap_pager_copy() at swap_pager_copy+0x17b > vm_object_collapse() at vm_object_collapse+0x123 > vm_object_deallocate() at vm_object_deallocate+0x457 > vm_map_process_deferred() at vm_map_process_deferred+0x72 > vm_pageout_oom() at vm_pageout_oom+0x180 > swp_pager_meta_build() at swp_pager_meta_build+0x248 > swap_pager_copy() at swap_pager_copy+0x17b > vm_object_collapse() at vm_object_collapse+0x123 > vm_object_deallocate() at vm_object_deallocate+0x457 > vm_map_process_deferred() at vm_map_process_deferred+0x72 > vm_map_remove() at vm_map_remove+0x116 > exec_new_vmspace() at exec_new_vmspace+0x1bc > exec_elf64_imgact() at exec_elf64_imgact+0x5f4 > kern_execve() at kern_execve+0x6f0 > sys_execve() at sys_execve+0x37 > amd64_syscall() at amd64_syscall+0x351 > Xfast_syscall() at Xfast_syscall+0xfb > --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d2eddc, rsp = > 0x7fffffffd328, rbp = 0x7fffffffd470 --- > panic: sleeping thread > cpuid = 4 > > The system was very busy and using lots of swap, but I didn't expect a > panic. If any more detail is needed or I should just get more RAM, let > me know. :) John has patches for this case.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC