NetBSD Problem Report #59886

From www@netbsd.org  Sat Jan  3 22:55:36 2026
Return-Path: <www@netbsd.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)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id BD8EA1A923D
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  3 Jan 2026 22:55:36 +0000 (UTC)
Message-Id: <20260103225535.2D75D1A923F@mollari.NetBSD.org>
Date: Sat,  3 Jan 2026 22:55:35 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: crash dumps are terrible
X-Send-Pr-Version: www-1.0

>Number:         59886
>Category:       kern
>Synopsis:       crash dumps are terrible
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 03 23:00:00 +0000 2026
>Last-Modified:  Sun Jan 04 00:30:02 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, 9, ...
>Organization:
The Core Don't, Inc.
>Environment:
>Description:

	NetBSD crash dumps are terrible.  Here is a litany of issues
	that should all be fixed:

	1. savecore(8) depends on the _running_ kernel's configuration
	   to read out what dumpdev is.

	   It should be able to save a core from any specified dumpdev
	   without asking the running kernel so you can:
	   (a) boot a broken kernel,
	   (b) crash,
	   (c) reboot into a working kernel,
	   (d) savecore from the broken kernel,
	   even if the working and broken kernel have different
	   configurations and default dumpdevs and what not.

	2. The kernel core dump format is undocumented and apparently
	   unreliable, because it often fails in mysterious ways like:

[running /etc/rc.d/savecore]
Checking for core dump...
savecore: msgbuf magic incorrect (706050403020100 != 63061)
savecore: reboot after panic: kernel diagnostic assertion "uvmexp.swpgonly > 0" failed: file "/zfs/source/src/sys/uvm/uvm_anon.c", line 175
savecore: system went down at Sat Jan  3 23:15:44 2026

savecore: writing compressed core to /var/crash/netbsd.2.core.gz
 8086 M
...
  540 K
savecore: writing compressed kernel to /var/crash/netbsd.2.gz
savecore: kvm_read ksyms: _kvm_kvatop(ffffc68022f77000)
savecore: (null): Bad address
/etc/rc.d/savecore exited with code 1

	3. The kernel doesn't compress memory as it dumps so it's very
	   slow and requires an unreasonably large dumpdev to work.

	4. If dumping core doesn't work, the only fallback is to hope
	   that the panic and stack trace are preserved in dmesg on
	   reboot, which often isn't the case -- especially if the
	   system hangs and it is forcibly powered _off_ before the
	   operator powers it back on.  It should be able to take
	   advantage of things like UEFI storage or ACPI APEI ERST
	   storage to store diagnostic information about the crash
	   dump.

	5. Preserving dmesg on reboot also often doesn't work if the
	   previous and current kernel are different and have different
	   parameters; presumably it is not adequately marked in
	   memory.

>How-To-Repeat:

	watch users struggle to get diagnostics out of crashes for PRs

>Fix:

	Yes, please!

>Audit-Trail:
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59886 crash dumps are terrible
Date: Sat, 3 Jan 2026 16:26:41 -0800 (PST)

 Note cross-references to bin/55120 and bin/55967

 +---------------------+--------------------------+----------------------+
 | Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
 | (Retired)           | 1B11 1849 721C 56C8 F63A | paul@whooppee.com    |
 | Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org  |
 | & Network Engineer  |                          | pgoyette99@gmail.com |
 +---------------------+--------------------------+----------------------+

Home	PR Database Search