Resurrecting fbdev

Posted Jan 20, 2022 18:32 UTC (Thu) by JoeBuck (subscriber, #2330)
In reply to: Resurrecting fbdev by Karellen
Parent article: Resurrecting fbdev

Or on a panic, do a switch to dumb mode and print raw, but this needs to work in the face of unknown kernel corruption.

Resurrecting fbdev

Posted Jan 20, 2022 21:42 UTC (Thu) by MrWim (subscriber, #47432) [Link] (1 responses)

> work in the face of unknown kernel corruption.

I quite like the scheme described here: https://apenwarr.ca/log/20190216 . The kmsg buffer is at a fixed location in memory, so you can write there which should be reliable even in the face of significant kernel memory corruption. On the next boot the kernel checks if there are valid messages there and preserves them so you can see what went wrong. It's beautiful in its simplicity.

The patches were posted upstream, but it never went anywhere.

https://lore.kernel.org/lkml/1331617001-20906-1-git-send-...

Resurrecting fbdev

Posted Jan 21, 2022 18:29 UTC (Fri) by bnorris (subscriber, #92090) [Link]

You mean something like this?

https://www.kernel.org/doc/html/latest/admin-guide/ramoop...

That's been upstream for quite a while, and it works just fine. Chrome OS uses it heavily for field crash logging. Despite its naming, it can be configured to dump logs to RAM even on non-crashes.