Re: DRM-based Oops viewer

From: Martin Steigerwald
Date: Sun Mar 10 2019 - 04:44:27 EST


Hell Ahmed.

Ahmed S. Darwish - 10.03.19, 02:31:
> Hello DRM/UEFI maintainers,
>
> Several years ago, I wrote a set of patches to dump the kernel
> log to disk upon panic -- through BIOS INT 0x13 services. [1]
>
> The overwhelming response was that it's unsafe to do this in a
> generic manner. Linus proposed a video-based viewer instead: [2]
[â]
> Of course it's 2019 now though, and it's quite known that
> Intel is officially obsoleting the PC/AT BIOS by 2020.. [3]
[â]
> The maximum possible that UEFI can provide is a GOP-provided
> framebuffer that's ready to use by the OS -- even after the UEFI
> boot phase is marked as done through ExitBootServices(). [5]
>
> Of course, once native drivers like i915 or radeon take over,
> such a framebuffer is toast... [6]
>
> Thus a possible remaining option, is to display the oops through
> "minimal" DRM drivers provided for each HW variant... Since
> these special drivers will run only and fully under a panic()
> context though, several constraints exist:

Thank you for your idea and willingness to work on something like this.

As a user I'd very much favor a solution that could not only work with
UEFI but with other firmwares. I still dream to be able to buy a laptop
with up to date hardware and with Coreboot/Libreboot at some time.

While this would not solve all "I just freeze" kind of crashes, it may
at least give some information about some of them. When testing rc
kernels I often enough faced "I just freeze" crashes that just happened
*sometimes*. On a machine that I also use for production work I find it
infeasible to debug it as bisecting could take a long, long time. And
well the machine could just crash every momentâ even during doing
important work with it.

In my ideal world an operating system would never ever crash or hang
without telling why. Well it would not crash or hang at allâ but there
you go. Maybe some time with a widely usable micro kernel based OS that
can restart device drivers in a broken state â at least almost. No
discussion of that micro kernel topic required here. :)

Thanks,
--
Martin