NetBSD Problem Report #53060
From martin@duskware.de Tue Feb 27 19:02:48 2018
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 233D87A1D3
for <gnats-bugs@gnats.NetBSD.org>; Tue, 27 Feb 2018 19:02:48 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: gdb trapframe sniffer not up to date with -current
X-Send-Pr-Version: 3.95
>Number: 53060
>Category: toolchain
>Synopsis: gdb trapframe sniffer not up to date with -current
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: toolchain-manager
>State: feedback
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Feb 27 19:05:00 +0000 2018
>Closed-Date:
>Last-Modified: Mon Jun 04 09:25:17 +0000 2018
>Originator: Martin Husemann
>Release: NetBSD 8.99.12
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD night-owl.duskware.de 8.99.12 NetBSD 8.99.12 (NIGHT-OWL) #581: Mon Feb 19 16:51:19 CET 2018 martin@night-owl.duskware.de:/usr/src/sys/arch/amd64/compile/NIGHT-OWL amd64
Architecture: x86_64
Machine: amd64
>Description:
Trying to debug a kernel crash dump with gdb in -current is mostly futile:
Reading symbols from netbsd.gdb...done.
(gdb) target kvm netbsd.core
0xffffffff80222727 in cpu_reboot (howto=howto@entry=256,
bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:708
708 dumpsys();
(gdb) bt
#0 0xffffffff80222727 in cpu_reboot (howto=howto@entry=256,
bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:708
#1 0xffffffff80774864 in db_sync_cmd (addr=<optimized out>,
have_addr=<optimized out>, count=<optimized out>, modif=<optimized out>)
at ../../../../ddb/db_command.c:1380
#2 0xffffffff8077502c in db_command (
last_cmdp=last_cmdp@entry=0xffffffff8146fa00 <db_last_command>)
at ../../../../ddb/db_command.c:914
#3 0xffffffff80775393 in db_command_loop ()
at ../../../../ddb/db_command.c:572
#4 0xffffffff80778be4 in db_trap (type=type@entry=1, code=code@entry=0)
at ../../../../ddb/db_trap.c:90
#5 0xffffffff8021f252 in kdb_trap (type=type@entry=1, code=code@entry=0,
regs=regs@entry=0xffff800144bd8970)
at ../../../../arch/amd64/amd64/db_interface.c:239
#6 0xffffffff80223e34 in trap (frame=0xffff800144bd8970)
at ../../../../arch/amd64/amd64/trap.c:320
#7 0xffffffff8021d237 in alltraps ()
#8 0xffffffff8021db05 in breakpoint ()
#9 0xffffffff805d1a4e in comintr (arg=0xffffe4011daa0408)
at ../../../../dev/ic/com.c:2113
#10 0xffffffff8020aeb6 in handle_ioapic_edge6 ()
#11 0x0000000000000000 in ?? ()
Looking at the same dump with crash(8) shows:
db_reboot_cmd() at db_reboot_cmd
db_command() at db_command+0xeb
db_command_loop() at db_command_loop+0x90
db_trap() at db_trap+0xe6
kdb_trap() at kdb_trap+0xe2
trap() at trap+0x4ed
--- trap (number 1) ---
breakpoint() at breakpoint+0x5
comintr() at comintr+0x782
handle_ioapic_edge6() at handle_ioapic_edge6+0x66
nvme_poll() at nvme_poll+0x12d
nvmeioctl() at nvmeioctl+0x19a
cdev_ioctl() at cdev_ioctl+0x98
VOP_IOCTL() at VOP_IOCTL+0x3b
vn_ioctl() at vn_ioctl+0xa1
sys_ioctl() at sys_ioctl+0x103
syscall() at syscall+0x1d8
--- syscall (number 54) ---
Note the interrupt frame at "handle_ioapic_edge6".
Looking at older crash dumps works, for example the one displayed by crash
like this works:
db_reboot_cmd() at db_reboot_cmd
db_command() at db_command+0xeb
db_command_loop() at db_command_loop+0x90
db_trap() at db_trap+0xe3
kdb_trap() at kdb_trap+0xe2
trap() at trap+0x593
--- trap (number 1) ---
breakpoint() at breakpoint+0x5
vpanic() at vpanic+0x140
__udivmoddi4() at __udivmoddi4
usb_transfer_complete() at usb_transfer_complete+0x292
ehci_softintr() at ehci_softintr+0x15c
usb_soft_intr() at usb_soft_intr+0x1f
softint_dispatch() at softint_dispatch+0x7a
DDB lost frame for Xsoftintr+0x4f, trying 0xffffe400bf7a7ff0
Xsoftintr() at Xsoftintr+0x4f
--- interrupt ---
Looking at amd64nbsd_trapframe_sniffer in src/external/gpl3/gdb/dist/gdb
there is a list of know interrupt frame symbols:
find_pc_partial_function (get_frame_pc (this_frame), &name, NULL, NULL);
return (name && ((strcmp (name, "alltraps") == 0)
|| (strcmp (name, "calltrap") == 0)
|| (strncmp (name, "Xtrap", 5) == 0)
|| (strcmp (name, "osyscall1") == 0)
|| (strcmp (name, "Xsyscall") == 0)
|| (strncmp (name, "Xintr", 5) == 0)
|| (strncmp (name, "Xresume", 7) == 0)
|| (strncmp (name, "Xstray", 6) == 0)
|| (strncmp (name, "Xrecurse", 8) == 0)
|| (strncmp (name, "Xsoft", 5) == 0)
|| (strcmp (name, "Xdoreti") == 0)));
but handle_ioapic_* is not in there. Not sure this would help...
>How-To-Repeat:
s/a
>Fix:
n/a
>Release-Note:
>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, toolchain-manager@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: toolchain/53060: gdb trapframe sniffer not up to date with -current
Date: Tue, 27 Feb 2018 14:47:52 -0500
On Feb 27, 7:05pm, martin@NetBSD.org (martin@NetBSD.org) wrote:
-- Subject: toolchain/53060: gdb trapframe sniffer not up to date with -curre
The optimizations in vector.S (1.56, 1.57) I believe broke the trampoline
sniffer.
christos
From: "Maxime Villard" <maxv@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53060 CVS commit: src/sys/arch/amd64/amd64
Date: Fri, 16 Mar 2018 08:48:34 +0000
Module Name: src
Committed By: maxv
Date: Fri Mar 16 08:48:34 UTC 2018
Modified Files:
src/sys/arch/amd64/amd64: db_machdep.c vector.S
Log Message:
Rename "handle_" -> "Xhandle_", and add the function names (introduced by
SVS) in db_machdep.c.
Should fix the DDB part of PR/53060.
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/amd64/amd64/db_machdep.c
cvs rdiff -u -r1.60 -r1.61 src/sys/arch/amd64/amd64/vector.S
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 04 Jun 2018 09:25:17 +0000
State-Changed-Why:
Does this fix the issue? want to request a pullup to -8 which also has SVS?
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.