| Message ID | 20220913024248.2183-1-antero@mailbox.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#57760] system: install: Do not load amdgpu in the installer image. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git-branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
Hello, > Booting the installer OS will fail when it fails to load blobs for amdgpu. > This will allow the installer OS to boot on systems with affected hardware. Seems reasonable to me. Florian, Josselin, any take on that? Thanks, Mathieu
Hi Mathieu and Antero,
First of all, thanks for your investigation and ensuing patch!
Mathieu Othacehe <othacehe@gnu.org> writes:
> Seems reasonable to me. Florian, Josselin, any take on that?
Seems good to me. I'm still pretty uneducated about DRM, the
framebuffers and whatnot though. IIUC, we require either DRI or FB for
kmscon to work (which is better than just FB for the kernel's default fb
console).
Also, are there other DRM drivers that we could blacklist because they
may try to load non-free blobs? Do some specific systems *require*
non-free blobs in order to display anything?
Best,
Hello Josselin, > Seems good to me. I'm still pretty uneducated about DRM, the > framebuffers and whatnot though. IIUC, we require either DRI or FB for > kmscon to work (which is better than just FB for the kernel's default fb > console). Same here. > Also, are there other DRM drivers that we could blacklist because they > may try to load non-free blobs? Do some specific systems *require* > non-free blobs in order to display anything? According to this command: --8<---------------cut here---------------start------------->8--- mathieu@meije ~/linux/drivers/gpu/drm$ grep FW_LOADER Kconfig -B 5 source "drivers/gpu/drm/arm/Kconfig" config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU select FW_LOADER -- source "drivers/gpu/drm/radeon/Kconfig" config DRM_AMDGPU tristate "AMD GPU" depends on DRM && PCI && MMU select FW_LOADER -- graphics card. If M is selected, the module will be called tdfx. config DRM_R128 tristate "ATI Rage 128" depends on DRM && PCI select FW_LOADER -- for this driver to work. config DRM_MGA tristate "Matrox g200/g400" depends on DRM && PCI select FW_LOADER --8<---------------cut here---------------end--------------->8--- the radeon, amdgpu, r128 and mga DRM drivers are probably relying on firmware loading. So we should maybe extend this patch and add the latter two drivers, even though they are supporting really old hardware. Thanks, Mathieu
Hi all, So the issue was that the installer’s display gets stuck at boot when not blacklisting radeon. This patch means the same apparently goes for probably goes for amdgpu? If there are amdgpu systems that cannot boot the installer otherwise, this is enough reason for this patch and this patch is a good idea. What Denis 'GNUtoo' Carikli wrote at <https://issues.guix.gnu.org/36786#9> indicates that non-3d graphics works for some radeon/amdgpu GPUs, because the code that prevents booting could be removed from linux-libre for these GPUs. If so (and it didn’t work for one GPU of mine even though it is listed as freed at libreplanet), these amdgpu ones would get a lower screen resolution from uvesafb if this patch were added. But it is worth the trade-off. However, Mathieu Othacehe <othacehe@gnu.org> writes: > the radeon, amdgpu, r128 and mga DRM drivers are probably relying on > firmware loading. So we should maybe extend this patch and add the > latter two drivers, even though they are supporting really old > hardware. Back then when we blacklisted radeon, we chose to wait for a report of amdgpu not working instead of adding amdgpu to the blacklist right away. Maybe booting is not broken there? Regards, Florian
Hey Florian, Thanks for sharing your thoughts. > What Denis 'GNUtoo' Carikli wrote at > <https://issues.guix.gnu.org/36786#9> indicates that non-3d graphics > works for some radeon/amdgpu GPUs, because the code that prevents > booting could be removed from linux-libre for these GPUs. If so (and it > didn’t work for one GPU of mine even though it is listed as freed at > libreplanet), these amdgpu ones would get a lower screen resolution from > uvesafb if this patch were added. But it is worth the trade-off. Agreed. > Back then when we blacklisted radeon, we chose to wait for a report of > amdgpu not working instead of adding amdgpu to the blacklist right away. > Maybe booting is not broken there? Yeah, plus the corresponding hardware is way less common. So let's proceed with this patch as-is. Pushed as d0376f6718b57be90b2f7697c90e4ecbe0090e0f. Thanks, Mathieu
diff --git a/gnu/system/install.scm b/gnu/system/install.scm index a7b7c246bf..003c49a3e7 100644 --- a/gnu/system/install.scm +++ b/gnu/system/install.scm @@ -476,7 +476,7 @@ (define installation-os ;; non-functional: ;; <https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00441.html>. ;; Thus, blacklist it. - (kernel-arguments '("quiet" "modprobe.blacklist=radeon")) + (kernel-arguments '("quiet" "modprobe.blacklist=radeon,amdgpu")) (file-systems ;; Note: the disk image build code overrides this root file system with