From owner-freebsd-current@freebsd.org Tue Nov 5 19:28:49 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C7F9E1B1EF9 for ; Tue, 5 Nov 2019 19:28:49 +0000 (UTC) (envelope-from brennan@umanwizard.com) Received: from smtp.umanwizard.com (smtp.umanwizard.com [54.203.248.109]) by mx1.freebsd.org (Postfix) with ESMTP id 47708K0kl1z3wt2; Tue, 5 Nov 2019 19:28:48 +0000 (UTC) (envelope-from brennan@umanwizard.com) X-Fes-Encrypted: true X-Fes-Ehlo-Domain: [10.30.91.165] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Kernel panics sometimes resulting in no core dump. From: Brennan Vincent In-Reply-To: <20191105190031.GC96050@raichu> Date: Tue, 5 Nov 2019 14:28:35 -0500 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C7D409D-7305-4E3A-9F66-F518A8D321B8@umanwizard.com> <20191105182212.GB96050@raichu> <54D42CD1-E805-4FA4-9F48-39EF3976FFB0@umanwizard.com> <20191105190031.GC96050@raichu> To: Mark Johnston X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 47708K0kl1z3wt2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 19:28:49 -0000 Yes, debug.kdb.panic=3D1 was done from within a graphical desktop. As = for whether the sporadic panics cause a hang before reboot, I will have = to get back to you on that later once I=E2=80=99m at my home desktop. > On Nov 5, 2019, at 2:00 PM, Mark Johnston wrote: >=20 > On Tue, Nov 05, 2019 at 01:49:26PM -0500, Brennan Vincent wrote: >> I=E2=80=99m using the latest version of `nvidia-driver` from ports = (440.31). Is that considered a DRM driver? >=20 > No, my suggestion doesn't apply to your case then. >=20 > When you tested debug.kdb.panic=3D1, did you have a graphical desktop > running? When you have debugger_on_panic set to 0, do you notice a = hang > before the system reboots, or does the system reboot immediately? >=20 >>> On Nov 5, 2019, at 1:22 PM, Mark Johnston wrote: >>>=20 >>> On Tue, Nov 05, 2019 at 12:44:06PM -0500, Brennan Vincent wrote: >>>> (Note: I have also posted this to the forums, but upon reading the = forum guidelines more carefully I realized the mailing list is probably = a better venue. So if you are also a forum reader, I apologize for the = extra churn.) >>>>=20 >>>> Hello, I am running 13-CURRENT (compiled recently from source using = default build settings) and recently I have been kernel panics every so = often. They can happen at any time but seem to be more likely when the = system is running a graphical environment and is at high load (e.g., = during `make -j64 buildworld`). >>>>=20 >>>> I have configured my system to collect core dumps: my swap = partition is 50 GB (large enough to contain any conceivable minidump), = `dumpon` reports that it is indeed configured as a dump partition, and I = have `savecore_enable=3D"YES"` in /etc/rc.conf. I also have the sysctl = `debug.debugger_on_panic` set to 0, which seems to be necessary for core = dumps to happen (instead of breaking into the debugger on panic). = Before, when that sysctl was set to 1, my graphical environment would = hand; now it reboots. The changing behavior depending on the value of = `debug.debugger_on_panic` is what makes me think this really is a kernel = panic, as opposed to some other possible issue that could cause a crash. >>>>=20 >>>> The weird thing is that when I manually cause a panic via `sudo = sysctl debug.kdb.panic=3D1` , my system reboots as expected, and a core = dump **does** get generated and saved in /var/crash! So it's only the = mysterious random crashes that aren't causing core dumps. >>>>=20 >>>> Can anyone help me figure out why core dumps are not getting = generated, and how I can possibly debug what is going on? >>>=20 >>> Are you using one of the DRM graphics drivers? I've found that = setting >>> dev.drm.skip_ddb=3D"1" in loader.conf is sometimes necessary. >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 >>=20