Panic during shutdown
Kostik Belousov
kostikbel at gmail.com
Thu Jul 2 08:41:55 UTC 2009
On Wed, Jul 01, 2009 at 06:54:22PM -0500, Greg Rivers wrote:
> 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.
No, it does not happen regardless of the load. The patch was tested on
the semi-standard set of programs run on the system, and all seen accounting
mistakes were fixed.
You have some process that does exhibit the behaviour causing error in
swap accounting. I think for start you could just show me ps auxww output,
in private, if you prefer.
>
>
> >... 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?
It does show the process, like
KDB: enter: panic
[thread pid 32021 tid 100598 ]
there, you can look up pid/tid and then do ps in ddb to look at the processes.
Also, you may do "show allpcpu" in ddb.
In kgdb, info threads should do the trick, AFAIR.
BTW, did you saw the kernel messages like
negative vmsize for uid = XXX ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090702/f1490a69/attachment.pgp
More information about the freebsd-current
mailing list