On Wed, 1 Jul 2009, Kostik Belousov wrote: >> at /usr/src/sys/vm/vm_object.c:715 >> #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) >> at /usr/src/sys/vm/vm_object.c:592 > I am interested in the output of > p *object > from the frame 6, and the output of > p swap_total > p swap_reserved > all from kgdb. > ... (kgdb) frame 6 #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:592 592 vm_object_terminate(object); (kgdb) list 587 * Don't double-terminate, we could be in a termination 588 * recursion due to the terminate having to sync data 589 * to disk. 590 */ 591 if ((object->flags & OBJ_DEAD) == 0) 592 vm_object_terminate(object); 593 else 594 VM_OBJECT_UNLOCK(object); 595 object = temp; 596 } (kgdb) p *object $1 = {mtx = {lock_object = {lo_name = 0xc06ce176 "vm object", lo_flags = 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, object_list = {tqe_next = 0xc43217f8, tqe_prev = 0xc41b1454}, shadow_head = { lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xc415c5f4}, memq = {tqh_first = 0x0, tqh_last = 0xc4300028}, root = 0x0, size = 245, generation = 271, ref_count = 0, shadow_count = 0, type = 0 '\0', flags = 12552, pg_color = 250, paging_in_progress = 0, resident_page_count = 0, backing_object = 0x0, backing_object_offset = 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { lh_first = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = { vnp_size = 0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_bcount = 0}}, uip = 0xc3d10340, charge = 1003520} (kgdb) p swap_total $2 = 2147483648 (kgdb) p swap_reserved $3 = 634880 > Also, please describe the load on the machine, > It happens regardless of the load. For example, just booting multi-user and immediately running shutdown (either by logging in or pressing the ACPI power button) triggers the panic. > ... and look up what process exited when the panic happens. > The panic message on the console does not show the process. Can that be determined from kgdb? If so, how? > Thanks for the report. > Thanks for looking into it! -- Greg RiversReceived on Wed Jul 01 2009 - 21:54:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC