[PATCH] system: install: Do not load amdgpu in the installer image.

  • Done
  • quality assurance status badge
Details
4 participants
  • Antero Mejr
  • Josselin Poiret
  • Mathieu Othacehe
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
Antero Mejr
Severity
normal
A
A
Antero Mejr wrote on 13 Sep 2022 04:42
(address . guix-patches@gnu.org)(name . Antero Mejr)(address . antero@mailbox.org)
20220913024248.2183-1-antero@mailbox.org
* 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(-)

Toggle diff (15 lines)
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
--
2.37.3
M
M
Mathieu Othacehe wrote on 14 Sep 2022 09:37
(name . Antero Mejr)(address . antero@mailbox.org)
878rmmcsoj.fsf@gnu.org
Hello,

Toggle quote (3 lines)
> 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
J
J
Josselin Poiret wrote on 14 Sep 2022 12:06
87y1um5kyu.fsf@jpoiret.xyz
Hi Mathieu and Antero,

First of all, thanks for your investigation and ensuing patch!

Mathieu Othacehe <othacehe@gnu.org> writes:
Toggle quote (2 lines)
> 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,
--
Josselin Poiret
M
M
Mathieu Othacehe wrote on 15 Sep 2022 15:43
(name . Josselin Poiret)(address . dev@jpoiret.xyz)
871qscn46w.fsf_-_@gnu.org
Hello Josselin,

Toggle quote (5 lines)
> 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.

Toggle quote (4 lines)
> 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:

Toggle snippet (30 lines)
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

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
P
P
pelzflorian (Florian Pelz) wrote on 15 Sep 2022 23:56
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87r10cl2sx.fsf@pelzflorian.de
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:
Toggle quote (5 lines)
> 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
M
M
Mathieu Othacehe wrote on 16 Sep 2022 10:16
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87pmfvhgz0.fsf@gnu.org
Hey Florian,

Thanks for sharing your thoughts.

Toggle quote (8 lines)
> 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.

Toggle quote (4 lines)
> 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
Closed
?