diff mbox series

[bug#57760] system: install: Do not load amdgpu in the installer image.

Message ID 20220913024248.2183-1-antero@mailbox.org
State New
Headers
Series [bug#57760] system: install: Do not load amdgpu in the installer image. |

Commit Message

Antero Mejr Sept. 13, 2022, 2:42 a.m. UTC 
* gnu/system/install.scm (installation-os): Add amdgpu to
modprobe.blacklist.
---
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.

 gnu/system/install.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Mathieu Othacehe Sept. 14, 2022, 7:37 a.m. UTC | #1 
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
Josselin Poiret Sept. 14, 2022, 10:06 a.m. UTC | #2 
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,
Mathieu Othacehe Sept. 15, 2022, 1:43 p.m. UTC | #3 
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
pelzflorian (Florian Pelz) Sept. 15, 2022, 9:56 p.m. UTC | #4 
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
Mathieu Othacehe Sept. 16, 2022, 8:16 a.m. UTC | #5 
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 mbox series

Patch

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