Date: Fri, 14 Apr 2023 00:10:55 +0200 From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= <dumbbell@FreeBSD.org> To: freebsd-hackers@freebsd.org Subject: Re: Handling panics inside vt(4) callbacks Message-ID: <f51a404e-18a1-15f2-ecdd-a6e5438214df@FreeBSD.org> In-Reply-To: <ZDgdW4M%2BXf0L1wmA@nuc> References: <4ed85151-09e8-db3e-0e0b-d0a8f3bb937c@FreeBSD.org> <ZDgdW4M%2BXf0L1wmA@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13/04/2023 17:18, Mark Johnston wrote: > On Wed, Apr 12, 2023 at 10:45:27PM +0200, Jean-Sébastien Pédron wrote: >> I could not find something in panic(9) code that would reboot the >> computer in case of a nested panic. > > In the case of a nested panic, vpanic() will not set RB_DUMP when it > calls kern_reboot(), so it won't write a kernel dump. And, if > debug.debugger_on_recursive_panic is not set, the kernel will not try to > re-enter the debugger. So the kernel will simply reboot. That was exactly the problem and I missed it even though I read that function many times... Thank you very much! If I always set RB_DUMP, it does what I want in the context of that forced nested panic. I will continue to test with the DRM driver and the actual issues I'm currently chasing. Once done, I will prepare a patch. > Perhaps we should set RB_DUMP in the case of a recursive panic so long > as dumping == 0, i.e., we did not panic again while trying to dump core. > In fact, kern_reboot() already checks this. In fact, "kern_reboot()" already verify if "dumping" is non-zero. I think "vpanic()" could set the flag regardless of that variable. Thank you! -- Jean-Sébastien Pédron The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f51a404e-18a1-15f2-ecdd-a6e5438214df>