GNU bug report logs -
#57760
[PATCH] system: install: Do not load amdgpu in the installer image.
Previous Next
Reported by: Antero Mejr <antero <at> mailbox.org>
Date: Tue, 13 Sep 2022 02:44:02 UTC
Severity: normal
Tags: patch
Done: Mathieu Othacehe <othacehe <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57760 in the body.
You can then email your comments to 57760 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#57760
; Package
guix-patches
.
(Tue, 13 Sep 2022 02:44:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Antero Mejr <antero <at> mailbox.org>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Tue, 13 Sep 2022 02:44:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
* 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(-)
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#57760
; Package
guix-patches
.
(Wed, 14 Sep 2022 07:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 57760 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#57760
; Package
guix-patches
.
(Wed, 14 Sep 2022 10:07:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 57760 <at> debbugs.gnu.org (full text, mbox):
Hi Mathieu and Antero,
First of all, thanks for your investigation and ensuing patch!
Mathieu Othacehe <othacehe <at> 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,
--
Josselin Poiret
Information forwarded
to
guix-patches <at> gnu.org
:
bug#57760
; Package
guix-patches
.
(Thu, 15 Sep 2022 13:44:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 57760 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#57760
; Package
guix-patches
.
(Thu, 15 Sep 2022 21:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 57760 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Reply sent
to
Mathieu Othacehe <othacehe <at> gnu.org>
:
You have taken responsibility.
(Fri, 16 Sep 2022 08:17:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Antero Mejr <antero <at> mailbox.org>
:
bug acknowledged by developer.
(Fri, 16 Sep 2022 08:17:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 57760-done <at> debbugs.gnu.org (full text, mbox):
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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 14 Oct 2022 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.