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

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2373 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]