NetBSD Problem Report #57543

From brad@anduin.eldar.org  Wed Jul 26 14:14:33 2023
Return-Path: <brad@anduin.eldar.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_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 EC0011A9238
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 26 Jul 2023 14:14:32 +0000 (UTC)
Message-Id: <202307261414.36QEETTF025173@anduin.eldar.org>
Date: Wed, 26 Jul 2023 10:14:29 -0400 (EDT)
From: brad@anduin.eldar.org
Reply-To: brad@anduin.eldar.org
To: gnats-bugs@NetBSD.org
Subject: Panic in -current during world builds
X-Send-Pr-Version: 3.95

>Number:         57543
>Category:       kern
>Synopsis:       Panic in -current during world builds
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 26 14:15:00 +0000 2023
>Originator:     brad@anduin.eldar.org
>Release:        NetBSD 10.99.6
>Organization:
	eldar.org
>Environment:
System: NetBSD samwise.nat.eldar.org 10.99.6 NetBSD 10.99.6 (SAMWISE) #1: Wed Jul 26 07:36:06 EDT 2023  brad@samwise.nat.eldar.org:/usr/src/sys/arch/amd64/compile/SAMWISE amd64
Architecture: x86_64
Machine: amd64
>Description:

The system is a normal PV DOMU with 2 VCPUs and 12 GB of memory
running on a Xen 4.15 DOM0.  The DOMU was doing a couple of world
builds, using -j2 on the build line.  The load would have been pretty
high with a fair bit of disk activity.  The following panic and reboot
occured:

[ 7177.6228776] panic: kernel diagnostic assertion "x86_read_psl() == 0" failed: file "../../../../arch/x86/x86/pmap.c", line 3593 
[ 7177.6228776] cpu1: Begin traceback...
[ 7177.6228776] vpanic() at netbsd:vpanic+0x163
[ 7177.6228776] kern_assert() at netbsd:kern_assert+0x4b
[ 7177.6228776] pmap_load() at netbsd:pmap_load+0x138
[ 7177.6228776] do_pmap_load() at netbsd:do_pmap_load+0x1d
[ 7177.6228776] copyout() at netbsd:copyout+0x48
[ 7177.6228776] dmu_read_uio_dnode() at zfs:dmu_read_uio_dnode+0x83
[ 7177.6228776] dmu_read_uio_dbuf() at zfs:dmu_read_uio_dbuf+0x41
[ 7177.6311873] zfs_netbsd_read() at zfs:zfs_netbsd_read+0x37d
[ 7177.6311873] VOP_READ() at netbsd:VOP_READ+0x3c
[ 7177.6311873] vn_rdwr() at netbsd:vn_rdwr+0xfc
[ 7177.6311873] vmcmd_readvn() at netbsd:vmcmd_readvn+0x5c
[ 7177.6311873] execve_runproc() at netbsd:execve_runproc+0x352
[ 7177.6311873] execve1() at netbsd:execve1+0x4f
[ 7177.6311873] sys_execve() at netbsd:sys_execve+0x2a
[ 7177.6311873] syscall() at netbsd:syscall+0x18c
[ 7177.6311873] --- syscall (number 59) ---
[ 7177.6311873] netbsd:syscall+0x18c:
[ 7177.6311873] cpu1: End traceback...

[ 7177.6311873] dumping to dev 142,17 (offset=33554431, size=0): not possible
[ 7177.(XEN) 6d[IDLE]v0 Failed to bring down CPU#0: -223

This may or may not be related to ZFS..  but, both the source and
artifact file systems are zfs file sets.  It simply may have been a
lucky race.

>How-To-Repeat:

Unknown if this can be a reproducable panic.

>Fix:

Unknown

Home	PR Database Search