NetBSD Problem Report #53557

From gson@gson.org  Mon Aug 27 14:39:42 2018
Return-Path: <gson@gson.org>
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 37FC47A18D
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 27 Aug 2018 14:39:42 +0000 (UTC)
Message-Id: <20180827143936.3BFD398A35B@guava.gson.org>
Date: Mon, 27 Aug 2018 17:39:36 +0300 (EEST)
From: gson@gson.org (Andreas Gustafsson)
Reply-To: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@NetBSD.org
Subject: NetBSD 7.1.2 Xen dom0 panics on unclean shutdown
X-Send-Pr-Version: 3.95

>Number:         53557
>Category:       port-xen
>Synopsis:       NetBSD 7.1.2 Xen dom0 panics on unclean shutdown
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-xen-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 27 14:40:00 +0000 2018
>Closed-Date:    Fri Jul 17 11:12:08 +0000 2020
>Last-Modified:  Fri Jul 17 11:12:08 +0000 2020
>Originator:     Andreas Gustafsson
>Release:        NetBSD 7.1.2
>Organization:
>Environment:
System: NetBSD
Architecture: x86_64
Machine: amd64
>Description:

When I tried to "halt -p" a NetBSD 7.1.1/amd64 Xen dom0 that I had set
up for testing and that still had some test domUs running off vnd
devices, not caring about doing a clean shutdown because I was going
to wipe the system anyway, it paniced during shutdown and rebooted
instead of powering off like I had asked it to.

Console output from around the panic:

vnd2: detached
vnd1: detached
vnd0: detached
fatal integer divide fault in supervisor mode
trap type 8 code 0 rip ffffffff806f8fcd cs e030 rflags 10293 cr2 7f7ff25570c8 ilevel 0 rsp ffffa0001c01de58
curlwp 0xffffa00000ed8520 pid 0.77 lowest kstack 0xffffa0001c01b2c0
Skipping crash dump on recursive panic
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x9f
cpu0: End traceback...
rebooting...
(XEN) Hardware Dom0 shutdown: rebooting machine

Identifying the faulting instruction:

# gunzip /netbsd-XEN3_DOM0.gz
# gdb /netbsd-XEN3_DOM0
(gdb) x/i 0xffffffff806f8fcd
   0xffffffff806f8fcd <vndthread+703>:	idivq  -0x58(%rbp)

A bit of context leading up to the faulting instruction:

   0xffffffff806f8fa5 <vndthread+663>:  callq  0xffffffff806fb143 <VOP_STRATEGY>
   0xffffffff806f8faa <vndthread+668>:	add    %rbx,%r12
   0xffffffff806f8fad <vndthread+671>:	sub    %rbx,%r13
   0xffffffff806f8fb0 <vndthread+674>:	add    %rbx,%r14
   0xffffffff806f8fb3 <vndthread+677>:	movl   $0x0,-0x3c(%rbp)
   0xffffffff806f8fba <vndthread+684>:	mov    0x18(%r15),%rdi
   0xffffffff806f8fbe <vndthread+688>:	mov    $0x20002,%esi
   0xffffffff806f8fc3 <vndthread+693>:	callq  0xffffffff806eeabc <vn_lock>
   0xffffffff806f8fc8 <vndthread+698>:	mov    %r12,%rax
   0xffffffff806f8fcb <vndthread+701>:	cqto   
   0xffffffff806f8fcd <vndthread+703>:	idivq  -0x58(%rbp)

This is reproducible.  Perhaps I got what I deserved doing an unclean
shutdown, but I'm reporting it anyway (as a low priority issue) in
case someone cares.

>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->closed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Fri, 17 Jul 2020 11:12:08 +0000
State-Changed-Why:
Unable to reproduce with -current.


>Unformatted:

Home	PR Database Search