LKML Archive on
help / color / mirror / Atom feed
From: "Ahmed S. Darwish" <>
To: "David Airlie" <>,
	"Daniel Vetter" <>,
	"Jani Nikula" <>,
	"Joonas Lahtinen" <>,
	"Rodrigo Vivi" <>,
	"Alex Deucher" <>,
	"Christian König" <>,
	"David Zhou" <>,
	"Ard Biesheuvel" <>,
	"Matt Fleming" <>
Cc: Linus Torvalds <>,
	Greg Kroah-Hartman <>,
	John Ogness <>,,
Subject: DRM-based Oops viewer
Date: Sun, 10 Mar 2019 02:31:42 +0100	[thread overview]
Message-ID: <20190310013142.GA3376@darwi-home-pc> (raw)

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]

    If you want to do the BIOS services thing, do it for video: copy the
    oops to low RAM, return to real mode, re-run the graphics card POST
    routines to initialize text-mode, and use the BIOS to print out the
    oops.  That is WAY less scary than writing to disk.

Of course it's 2019 now though, and it's quite known that
Intel is officially obsoleting the PC/AT BIOS by 2020.. [3]

Researching whether this can be done from UEFI, it was also clear
that UEFI "Runtime Services" do not provide any re-initialization
routines. [4]

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:

  - The code should be fully synchronous (irqs are disabled)
  - It should not allocate any dynamic memory
  - It should make minimal assumptions about HW state
  - It should not chain into any other kernel subsystem
  - It has ample freedom to use delay-based loops and the
    like, the kernel is already dead.

How feasible is it to have such a special "DRM viewoops"
framework + its minimal drivers in the kernel?

The target is to start from i915, since that's what in my
laptop now, and work from there..

Some final notes:

  - The NT kernel has a similar concept, but for storage instead.
    They're used to dump core under kernel panic() situations,
    and are called "Minoport storage drivers". [7]

  - Since Windows 7+, a very fancy Blue Screen of Death is
    displayed, with Unicode and whatnot, implying GPU drivers
    involvement. [8]

  - Mac OS X also does something similar [9]

  - On Linux laptops, the current situation is _really_ bad.

    In any graphical session, type "echo c > /proc/sysrq-trigger";
    the screen will just completely freeze...

    Desired first goal: just print the panic() log

Thanks a lot,



[4] UEFI v2.7 spec, Chapter 8, "Services — Runtime Services"
[5] UEFI v2.7 spec, Section 12.9, "Graphics Output Protocol"
    "The Graphics Output Protocol supports this capability by
     providing the EFI OS loader access to a hardware frame buffer
     and enough information to allow the OS to draw directly to
     the graphics output device."

[6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()




             reply	other threads:[~2019-03-10  1:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-10  1:31 Ahmed S. Darwish [this message]
2019-03-10  8:44 ` Martin Steigerwald
2019-03-11  9:04 ` Jani Nikula
2019-03-11 13:49   ` Daniel Vetter
2019-03-11 23:39     ` Ahmed S. Darwish
2019-03-11 22:12   ` Ahmed S. Darwish
2019-03-12 10:20     ` Jani Nikula
2019-03-11 12:10 ` Joonas Lahtinen
2019-03-11 17:47 ` Noralf Trønnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190310013142.GA3376@darwi-home-pc \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: DRM-based Oops viewer' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox