Re: [PATCH 2/3] fbdev/simplefb: Cleanup fb_info in .fb_destroy rather than .remove

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

Am 05.05.22 um 10:28 schrieb Javier Martinez Canillas:
Hello Thomas,

On 5/5/22 10:05, Thomas Zimmermann wrote:

[snip]


In other words, in most cases (i.e: only fbcon bound to the fbdev)
the driver's removal/ device unbind and the memory release will be
at the same time.


We're one the same page here, but it's still sort of a mystery to me why
this works in practice.

I'm specifically talking about pci_request_regions() in vmwgfx [1]. IIRC
this would fail if simplefb still owns the framebuffer region. Lots of
systems run Plymouth during boot and this should result in failures
occasionally. Still, we never heard about anything.


Yes, I think is because Plymouth IIUC waits for a /dev/dri/card? to be
present and only uses a /dev/fb? as a fallback if a timeout expires.

Oh, right! The infamous plymouth timeout. 'sleep(30)' is the swiss-army knife of concurrent programming. ;)

But I'm not blaming anyone. There are situations where nothing else helps. Plymouth really can't do anything else here. We've received reports for gfx-handover bugs when the timeout expired and plymouth uses the fbdev. The system got stuck then because of fbdev IIRC.

Best regards
Thomas


At least in Fedora (even before the efifb -> simpledrm change) it will
use KMS/DRM since the DRM kernel module for the graphics device in the
machine would be in the intird.

So efifb was only used for fbcon and plymouth would only use DRM/KMS
and not its fbdev backend.

This seems to be sort of a corner case when you have {efi,simple}fb
in the early boot but the real DRM module only in the rootfs after the
initrd has done a pivot_root(2).
Of course, it's always been broken (even long before real fbdev
hotunplugging). Switching to simpledrm resolves the problem.


Indeed. My opinion after dealing with these fbdev problems is that we
shouldn't try to fix all possible corner cases and just try to get rid
of fbdev as soon as possible.
  --
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux