From owner-freebsd-hackers@freebsd.org Thu Jan 21 12:08:52 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 609AFA8A305 for ; Thu, 21 Jan 2016 12:08:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 563A41616; Thu, 21 Jan 2016 12:08:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23346; Thu, 21 Jan 2016 14:08:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aME2i-0007as-F0; Thu, 21 Jan 2016 14:08:48 +0200 Subject: Re: How to get anything useful out of kgdb? To: John Baldwin References: <554E41EE.2010202@ignoranthack.me> <1595419.L0rkNTMkPe@ralph.baldwin.cx> <560EF73A.8050505@FreeBSD.org> <16207260.7oBjvc4tcM@ralph.baldwin.cx> Cc: Ryan Stone , "freebsd-hackers@freebsd.org" From: Andriy Gapon Message-ID: <56A0CA17.7030204@FreeBSD.org> Date: Thu, 21 Jan 2016 14:07:51 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <16207260.7oBjvc4tcM@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 12:08:52 -0000 On 08/01/2016 22:05, John Baldwin wrote: > So I figured out why newer kgdb wasn't unwinding through NULL function pointer > traps yesterday. I'm not sure if the fix will help with your case as well, > but it might be worth trying. The changes are in > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206044 Thank you very much! It does help in my case: (kgdb) bt #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:291 #1 0xffffffff8063453f in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:359 #2 0xffffffff80634ba4 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:635 #3 0xffffffff806348a3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:568 #4 0xffffffff8041bba7 in db_panic (addr=, have_addr=, count=, modif=) at /usr/src/sys/ddb/db_command.c:473 #5 0xffffffff8041b67b in db_command (last_cmdp=, cmd_table=0x0, dopager=) at /usr/src/sys/ddb/db_command.c:440 #6 0xffffffff8041b524 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #7 0xffffffff8041de0b in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #8 0xffffffff80669de8 in kdb_trap (type=19, code=0, tf=0xffffffff80f976d0 ) at /usr/src/sys/kern/subr_kdb.c:653 #9 0xffffffff80820d26 in trap (frame=0xffffffff80f976d0 ) at /usr/src/sys/amd64/amd64/trap.c:381 #10 #11 0xffffffff80619e1f in __mtx_assert (c=, what=, file=, line=) at /usr/src/sys/kern/kern_mutex.c:842 #12 0xffffffff807fef86 in vm_reserv_free_page (m=0xfffff80229e07cc0) at /usr/src/sys/vm/vm_reserv.c:832 #13 0xffffffff807f2b96 in vm_page_free_toq (m=0xfffff80229e07cc0) at /usr/src/sys/vm/vm_page.c:2432 #14 0xffffffff807f2e4d in vm_page_free (m=0xffffffff81129198 ) at /usr/src/sys/vm/vm_page.c:962 #15 0xffffffff821c28e2 in ttm_bo_vm_fault (vm_obj=0xfffff8021fcdeb00, offset=5304320, prot=, mres=0xfffffe02b8357050) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_bo_vm.c:269 #16 0xffffffff807d4fd3 in dev_pager_getpages (object=0xfffff8021fcdeb00, ma=0xfffffe02b8357050, count=1, reqpage=0) at /usr/src/sys/vm/device_pager.c:321 #17 0xffffffff807f9d67 in vm_pager_get_pages (object=0xfffff8021fcdeb00, m=0xfffffe02b8357050, count=1, reqpage=0) at /usr/src/sys/vm/vm_pager.c:291 #18 0xffffffff807e0d84 in vm_fault_hold (map=0xfffff8001dd57000, vaddr=34729947136, fault_type=2 '\002', fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:672 #19 0xffffffff807e05ee in vm_fault (map=0xfffff8001dd57000, vaddr=, fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277 #20 0xffffffff80821342 in trap_pfault (frame=0xfffffe02b8357c00, usermode=1) at /usr/src/sys/amd64/amd64/trap.c:734 #21 0xffffffff80820bda in trap (frame=0xfffffe02b8357c00) at /usr/src/sys/amd64/amd64/trap.c:326 #22 0xffffffff8082154a in trap_check (frame=0xfffffe02b8357c00) at /usr/src/sys/amd64/amd64/trap.c:628 #23 #24 0x00000008022b4046 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffe7c8 See http://article.gmane.org/gmane.os.freebsd.devel.hackers/56410 for comparison. One small regression is that previously there was nmi_calltrap in the trace, now it's just "". -- Andriy Gapon