On Mon, Sep 08, 2025 at 10:55:17AM +0200, Jocelyn Falempe wrote: > On 03/09/2025 10:19, Maxime Ripard wrote: > > On Wed, Sep 03, 2025 at 09:30:23AM +0200, Jocelyn Falempe wrote: > > > On 02/09/2025 18:58, Maxime Ripard wrote: > > > > On Mon, Sep 01, 2025 at 03:04:26PM +0200, Jocelyn Falempe wrote: > > > > > On 27/08/2025 12:45, Thomas Zimmermann wrote: > > > > > > Hi > > > > > > > > > > > > Am 21.08.25 um 11:49 schrieb Jocelyn Falempe: > > > > > > > This is a bit hacky, but very handy if you want to customize the > > > > > > > panic screen. > > > > > > > It allows to dump the generated images to the logs, and then a > > > > > > > python > > > > > > > script can convert it to .png files. It makes it easy to check how > > > > > > > the panic screen will look on different resolutions, without > > > > > > > having > > > > > > > to crash a VM. > > > > > > > To not pollute the logs, it uses a monochrome framebuffer, > > > > > > > compress > > > > > > > it with zlib, and base64 encode it. > > > > > > > > > > > > May I suggest to export the raw image via debugfs? Debugfs can also > > > > > > export additional information in additional files, such as > > > > > > width/height/ > > > > > > stride/format. This could provide the real/last image on the fly, > > > > > > simply > > > > > > by reading the files. No workarounds or encodings needed. > > > > > > > > > > I'm looking into that. The difficulty is to get the debugfs content > > > > > outside > > > > > of the test kernel. As I'm using a uml kernel for testing, I will > > > > > need a > > > > > special initrd, and a way to share files with the host. > > > > > > > > Yeah, I agree that it's not very practical. If only because the test > > > > context doesn't stick around once it's been executed, so you would > > > > effectively leak an arbritrarily long buffer with no hope of getting > > > > back its memory. > > > > > > I've made a prototype with debugfs, a small ramdisk with busybox, and > > > using > > > hostfs to mount the host filesystem in the uml kernel, and it allows to > > > dump > > > the raw panic buffer easily. > > > Even if it's a bit more complex to setup, I think this use case is not > > > really a kunit test, so it's probably better that way. > > > > > > Let me a few days to clean that up, and I will send a v2 of the kunit > > > tests, > > > and a new series to add a debugfs interface. > > > > > > Thanks for your reviews, > > > > We also have to think about how it's going to be shipped and used. If > > your debugfs integration has to be disabled everytime we're running > > kunit through uml, qemu, and in CI (because we can't retrieve the > > result), on a live system (because it would leak memory indefinitely), > > how is it useful? > > There is already a kconfig for this: > CONFIG_DRM_PANIC_DEBUG > > Also I have an implementation that doesn't leak memory. (memory is freed > when the debugfs file is closed).
So, if userspace completely ignores it, you still leak it. > It's also more flexible, as you can change the parameters, and test any > color format, and check the binary result. > > I think the goal of this is not to test for regression, but to help building > a new panic screen. > > > > > The diagnostic lines are part of the test result, are in the logs, and > > can be distributed. You're having all those problems solved already, > > without having any additional work to do. > > I feel sending an image through log is not really efficient, and I don't > want to pollute all the CI with that. Then maybe we should just ignore that part of your series for now. But having a framebuffer lingering around in the system is a no-go for me. Maxime
signature.asc
Description: PGP signature
