[Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time

Wed Sep 6 11:06:31 UTC 2023

Hi

Am 06.09.23 um 11:48 schrieb suijingfeng:
[...]
> 
>> There's 'nomodeset', which disables all native drivers. It's useful 
>> for debugging or as a quick-fix if the graphics driver breaks. If you 
>> want to disable a specific driver, please use one of the options for 
>> blacklisting.
>>
> Yeah, the 'nomodeset' disables all native drivers,
> this is a good point of it, but this is also the weak point of it.

Well, that's by design. Graphics is at the core of the user experience. 
We often cannot _not_ provide it. And if it's broken, there needs to be 
a reliable fallback. There needs to be at least enough graphics support 
to run a terminal and repair the system. And it also needs to be simple 
enough for the average user. Falling back to serial terminals if often 
not an option.

At least here at SUSE, when users or customers report a broken graphics 
driver, we can tell them to start with 'nomodeset' and get at least the 
basic graphics. That's good enough for most productivity/office 
software. In the meantime, we investigate the problem.

There were concerns about the need of nomodeset, but I think it has 
proven to be useful in practice.

> Sometimes, when you are developing a drm driver for a new device.
> You will see the pain. Its too often a programmer's modification
> make the entire Linux kernel hang there. The problematic drm
> driver kernel module already in the initrd. Then, the real
> need to disable the ill-functional drm driver kernel module
> only. While what you recommend to disable them all. There
> are subtle difference.

I found that initcall_blacklist=<func name> works reliable for me.

> 
> Another limitation of the 'nomodeset' parameter is that
> it is only available on recent upstream kernel. Low version
> downstream kernel don't has this parameter supported yet.
> So this create inconstant developing experience. I believe that
> there always some people need do back-port and upstream work
> for various reasons.

Nomodeset used to be there, but in a different form. It forced VGA text 
mode IIRC. 'git grep' for vga_text_force() in an old kernel. We adopted 
the parameter for all of graphics, because it already did what we needed.

Best regards
Thomas

> 
> While (kindly, no offensive) debating, since we have the modprobe.blacklist
> why we still need the 'nomodeset' parameter ?
> why not try 
> modprobe.blacklist="amdgpu,radeon,i915,ast,nouveau,gma500_gfx, ..."
> 
> :-/
> 
> 
> But OK in overall, I will listen to your advice.
> 
> 
>> Best regards
>> Thomas
>>
>> [1] 
>> https://elixir.bootlin.com/linux/v6.5/source/include/drm/drm_module.h#L83
>>
>>
>>> for the modeset parameter, authors of various device driver try to 
>>> make the usage not
>>> conflict with others. I believe that this is good thing for Linux users.
>>> It is probably the responsibility of the drm core maintainers to 
>>> force various drm
>>> drivers to reach a minimal consensus. Probably it pains to do so and 
>>> doesn't pay off.
>>> But reach a minimal consensus do benefit to Linux users.
>>>
>>>
>>>> You can use modprobe.blacklist or initcall_blacklist on the kernel 
>>>> command line.
>>>>
>>> There are some cases where the modprobe.blacklist doesn't works,
>>> I have come cross several time during the past.
>>> Because the device selected by the VGAARB is device-level thing,
>>> it is not the driver's problem.
>>>
>>> Sometimes when VGAARB has a bug, it will select a wrong device as 
>>> primary.
>>> And the X server will use this wrong device as primary and completely 
>>> crash
>>> there, due to lack a driver. Take my old S3 Graphics as an example:
>>>
>>> $ lspci | grep VGA
>>>
>>>   00:06.1 VGA compatible controller: Loongson Technology LLC DC 
>>> (Display Controller) (rev 01)
>>>   03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
>>> [AMD/ATI] Caicos XT [Radeon HD 7470/8470 / R5 235/310 OEM]
>>>   07:00.0 VGA compatible controller: S3 Graphics Ltd. Device 9070 
>>> (rev 01)
>>>   08:00.0 VGA compatible controller: S3 Graphics Ltd. Device 9070 
>>> (rev 01)
>>>
>>> Before apply this patch:
>>>
>>> [    0.361748] pci 0000:00:06.1: vgaarb: setting as boot VGA device
>>> [    0.361753] pci 0000:00:06.1: vgaarb: VGA device added: 
>>> decodes=io+mem,owns=io+mem,locks=none
>>> [    0.361765] pci 0000:03:00.0: vgaarb: VGA device added: 
>>> decodes=io+mem,owns=none,locks=none
>>> [    0.361773] pci 0000:07:00.0: vgaarb: VGA device added: 
>>> decodes=io+mem,owns=none,locks=none
>>> [    0.361779] pci 0000:08:00.0: vgaarb: VGA device added: 
>>> decodes=io+mem,owns=none,locks=none
>>> [    0.361781] vgaarb: loaded
>>> [    0.367838] pci 0000:00:06.1: Overriding boot device as 1002:6778
>>> [    0.367841] pci 0000:00:06.1: Overriding boot device as 5333:9070
>>> [    0.367843] pci 0000:00:06.1: Overriding boot device as 5333:9070
>>>
>>>
>>> For known reason, one of my system select the S3 Graphics as primary 
>>> GPU.
>>> But this S3 Graphics not even have a decent drm upstream driver yet.
>>> Under such a case, I begin to believe that only the device who has a
>>> driver deserve the primary.
>>>
>>> Under such a condition, I want to reboot and enter the graphic 
>>> environment
>>> with other working video cards. Either platform integrated and 
>>> discrete GPU.
>>> This don't means I should compromise by un-mount the S3 graphics card 
>>> from
>>> the motherboard, this also don't means that I should update my BIOS 
>>> setting.
>>> As sometimes, the BIOS is more worse.
>>>
>>> With this series applied, all I need to do is to reboot the computer and
>>> pass a command line. By force override another video card (who has a
>>> decent driver support) as primary, I'm able to do the debugging under
>>> graphic environment. I would like to examine what's wrong with the 
>>> vgaarb
>>> on a specific platform under X server graphic environment.
>>>
>>> Probably try compile a driver for this card and see it works, simply 
>>> reboot
>>> without the need to change anything. It is so efficient. So this is 
>>> probably
>>> the second usage of my patch. It hand the right of control back to the
>>> graphic developer.
>>>
>>>
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20230906/d58823fa/attachment-0001.sig>