Date: Fri, 14 Apr 2023 00:12:54 +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: <ea9721c6-f184-e306-8396-a84ea04e4524@FreeBSD.org> In-Reply-To: <CACNAnaH_dv8ZDJV2PH6tr8UCAHi=C=Mdw=qYCgMqwoW-rwQjTQ@mail.gmail.com> References: <4ed85151-09e8-db3e-0e0b-d0a8f3bb937c@FreeBSD.org> <CACNAnaH_dv8ZDJV2PH6tr8UCAHi=C=Mdw=qYCgMqwoW-rwQjTQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/04/2023 23:33, Kyle Evans wrote: > FWIW, I have a related patch that I maintain in my tree that I simply > haven't found time to try and upstream. When the system panics, it > tries to switch back to ttyv0, but it calls into vd_postswitch() with > the vt lock still held. In my case, with i915kms, the vd_postswitch > implementation attempts to sleep with the lock still held and > everything goes off the rails. See below. Indeed, there are several locking issues in the DRM driver callbacks related to vt(4) because of the different contraints in Linux. I'm currently working on revisiting the way we integrate the DRM drivers in vt(4), hopefully this work will address the problem you hit. -- 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?ea9721c6-f184-e306-8396-a84ea04e4524>