Re: [SUCCESS] Debugging/fixing a kernel stalled not crashing

[tlaronde%polynum.com@localhost]

Le Sun, Aug 21, 2022 at 03:25:36PM +0000, Emmanuel Dreyfus a écrit :
> On Sun, Aug 21, 2022 at 02:16:58PM +0200, tlaronde%polynum.com@localhost wrote:
> > Addition (asked by Taylor R Campbell): a current GENERIC boots only
> > with i915drmkms disabled.
> > 
> > With the framebuffer stuff enabled, it does not boot, and does not even
> > panic and reboot. It freezes somewhere. The same as the 9.x series.
> 
> I have a machine that randomy crash during boot since we had the Linux 5.x
> DRM import. The feature is still an asset, since it supports the GPU
> that was not supported before, but it suggests booting with DRM based
> framebuffer is more fragile than booting without. Perhaps we need a boot
> flag to disable framebuffer?

This is my feeling too that a generic flag to disable it via userconf
would be a good thing instead of explicitely listing all the drivers.
And, at the very least, to advertise, for people
installing on a server, to try with framebuffer disabled first, to see
if NetBSD boots, and to try it with only after. When one installs on a
remote server, without seeing anything about the boot process[*], it is
quite frustating.

*: I plan to play a little with UEFI EDKII to see if installing it and
dealing with an ethernet card EFI Runtime driver (persistent after exiting boot)
could be a solution for remote debugging. But no schedule set so don't
hold your breath; it's vaporware for the moment. Other idea: write messages
to memory in a place kept untouched by UEFI and NetBSD so that rebooting
(in case of crash) in UEFI, an UEFI application could dump the
memory on some place on the disk, in the EFI partition, for
post-mortem inspection.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C