Warn of AMD GPUs unusable with Guix System

  • Done
  • quality assurance status badge
Details
4 participants
  • Denis 'GNUtoo' Carikli
  • Ludovic Courtès
  • pelzflorian (Florian Pelz)
  • Ricardo Wurmus
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
normal
P
P
pelzflorian (Florian Pelz) wrote on 24 Jul 2019 16:56
(address . bug-guix@gnu.org)
20190724145602.vtpnqd6kxexypdmx@pelzflorian.localdomain
Back in
I wrote:

On Fri, Apr 26, 2019 at 10:35:43AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (15 lines)
> On Sat, Apr 20, 2019 at 11:47:56AM +0200, Ludovic Courtès wrote:
> > "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > > I believe issues with (some?) AMD GPUs should be mentioned in the
> > > manual. Also, on the downloads page perhaps it should be mentioned
> > > that there may be issues with some hardware, referring users to the
> > > Hardware Considerations in the Guix manual.
> >
> > We could do that, but these kind of kernel-side issues tend to appear
> > and vanish quickly, no? But I don’t know much about these AMD GPU
> > issues, so I’m happy to do what people consider appropriate.
> >
>
> My AMD GPU machine started working with VESA Xorg drivers at full resolution.
> I reconfigured a while ago but did not test back then.

Aside from the fact that 3d acceleration is out of reach for modern
AMD GPUs on a linux-libre kernel, Guix had at least two further
reports of trouble with old and very new AMD GPUs like:


and



Part of the reason a warning about AMD GPUs should be considered is
that AMD Radeon is often claimed to be usable with drivers that are
“entirely free and open-source software”
making people believe they do not require nonfree firmware.

I suppose but do not know that recent Nvidia hardware works without 3d
acceleration, even when the Nouveau Xorg driver does not support it
yet. I suppose but am unsure if recent Intel GPUs work out of the box
without blobs. If correct, this would make AMD in particular notable.

On the other hand, Pierre Neidhard commented at
that many AMD GPUs work well.

Possibly I am overly negative because my computer is affected as well.
Still, I think the hardware considerations section in the manual
should list at least that Xorg graphics on some AMD GPUs do not work
and that using the console might require tweaks like
modprobe.blacklist=radeon. The website too should tell users on the
downloads page that, even though most machines work well, wi-fi
vendors like Broadcom and graphics card vendor AMD refuse to make *some*
of their devices work with the linux-libre kernel used by Guix System.

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 24 Jul 2019 17:42
(address . 36786@debbugs.gnu.org)
20190724154249.qgd4ganifakxmo2f@pelzflorian.localdomain
On Wed, Jul 24, 2019 at 04:56:03PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (5 lines)
> very new AMD GPUs like:
> […]
> https://lists.gnu.org/archive/html/help-guix/2019-07/msg00179.html
>

Sorry. The reporter said this GPU is a Radeon R9 280X 3G. I was
wrong to believe it was a new GPU just because the CPU was reported to
be recent. It is from the same


as my AMD GPU.

We could make a list of known bad GPUs.
P
P
pelzflorian (Florian Pelz) wrote on 24 Jul 2019 19:53
(address . 36786@debbugs.gnu.org)
20190724175327.lx2e53it46xnjxz6@pelzflorian.localdomain
On Wed, Jul 24, 2019 at 05:42:49PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (3 lines)
> We could make a list of known bad GPUs.
>

When thinking about it, a list of known bad GPUs might be legally
safer than saying AMD GPUs are often bad.

Regards,
Florian
R
R
Ricardo Wurmus wrote on 24 Jul 2019 21:05
(address . pelzflorian@pelzflorian.de)(address . 36786@debbugs.gnu.org)
874l3bb6e5.fsf@elephly.net
pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> writes:

Toggle quote (7 lines)
> On Wed, Jul 24, 2019 at 05:42:49PM +0200, pelzflorian (Florian Pelz) wrote:
>> We could make a list of known bad GPUs.
>>
>
> When thinking about it, a list of known bad GPUs might be legally
> safer than saying AMD GPUs are often bad.

I sympathize with the frustration that comes along with the realization
that hardware you own cannot be used with free software. I would like
to alert people to the fact that certain GPUs won’t be usable with
linux-libre.

I just think that there might be a better distro-independent place for
this kind of information. Some free distros suggest checking for free
software compatibility on h-node.org, a shared resource. That’s also
where we could record known bad GPUs.

(h-node.org isn’t the prettiest resource out there, but perhaps this can
be changed.)

Do you think it would be enough if we pointed to h-node.org and
mentioned kernel flags that might be useful in certain generic cases?

--
Ricardo
P
P
pelzflorian (Florian Pelz) wrote on 24 Jul 2019 23:22
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 36786@debbugs.gnu.org)
20190724212254.6odl6pfn42y3rytj@pelzflorian.localdomain
On Wed, Jul 24, 2019 at 09:05:06PM +0200, Ricardo Wurmus wrote:
Toggle quote (4 lines)
> Do you think it would be enough if we pointed to h-node.org and
> mentioned kernel flags that might be useful in certain generic cases?
>

Yes, that is a very good suggestion and easiest to do. I did not
think about h-node… The manual already points there, but the website
should too. Then this bug can be closed, I think.

Find attached a patch that mentions the kernel flag in the manual’s
Hardware Considerations section. I do not know if a separate section
would be better. (The alternative kernel flag “nomodeset” was
reported to not work as well, so I did not mention it, see here:

h-node currently appears to have no information on those video cards.
I will take a look at how to add information there later.

Regards,
Florian
From e88ee68c09266e1d09d24ff0d1b6ec6a4708841b Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Wed, 24 Jul 2019 23:02:21 +0200
Subject: [PATCH] doc: Mention AMD Radeon workaround when TTYs are not redrawn.

* doc/guix.texi (Hardware Considerations): Describe workaround.
---
doc/guix.texi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

Toggle diff (31 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index f6d9718f59..b9e18e55c4 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1879,6 +1879,24 @@ Another useful resource is the @uref{https://www.h-node.org/, H-Node}
web site. It contains a catalog of hardware devices with information
about their support in GNU/Linux.
+Some hardware requires specific tweaks to work better with Guix System. The
+following is an incomplete list of known workarounds:
+
+@itemize
+@item
+Some @emph{AMD Radeon} graphics cards stop redrawing the virtual console TTYs
+when booting because of an error with Kernel Mode Setting. The problem
+disappears when blacklisting the kernel module for the driver. To do so, you
+can add @code{modprobe.blacklist=radeon} to the Linux-libre kernel flags,
+either for only one boot by pressing the @kbd{e} key in the GRUB bootloader
+and adding this kernel flag to the end of the @code{linux} command-line, or
+permanently by changing the @code{kernel-arguments} field in your
+@code{operating-system} declaration, e.g.:
+
+@example
+(kernel-arguments '("quiet" "modprobe.blacklist=radeon"))
+@end example
+@end itemize
@node USB Stick and DVD Installation
@section USB Stick and DVD Installation
--
2.22.0
L
L
Ludovic Courtès wrote on 26 Jul 2019 01:04
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87zhl1pvg7.fsf@gnu.org
Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (22 lines)
> pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> writes:
>
>> On Wed, Jul 24, 2019 at 05:42:49PM +0200, pelzflorian (Florian Pelz) wrote:
>>> We could make a list of known bad GPUs.
>>>
>>
>> When thinking about it, a list of known bad GPUs might be legally
>> safer than saying AMD GPUs are often bad.
>
> I sympathize with the frustration that comes along with the realization
> that hardware you own cannot be used with free software. I would like
> to alert people to the fact that certain GPUs won’t be usable with
> linux-libre.
>
> I just think that there might be a better distro-independent place for
> this kind of information. Some free distros suggest checking for free
> software compatibility on h-node.org, a shared resource. That’s also
> where we could record known bad GPUs.
>
> (h-node.org isn’t the prettiest resource out there, but perhaps this can
> be changed.)

What about adding a few words under “Hardware Considerations”?

Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 26 Jul 2019 07:57
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190726055704.vev4wy56q5osznzi@pelzflorian.localdomain
On Fri, Jul 26, 2019 at 01:04:40AM +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> What about adding a few words under “Hardware Considerations”?
>

While my patch before addresses AMD-specific tweaks in the manual
under Hardware Considerations, it is not enough if on the *download
page* Guix is claimed to run on “an i686, x86_64, ARMv7, or AArch64
machine“ without saying linux-libre *on some hardware, is not
supported* and referencing the Hardware Considerations section and
h-node, I think.

Regards,
Florian
L
L
Ludovic Courtès wrote on 26 Jul 2019 17:56
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87o91glrh4.fsf@gnu.org
Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (3 lines)
> On Fri, Jul 26, 2019 at 01:04:40AM +0200, Ludovic Courtès wrote:
>> What about adding a few words under “Hardware Considerations”?

Oops, I hadn’t seen your patch when I replied.

Toggle quote (7 lines)
> While my patch before addresses AMD-specific tweaks in the manual
> under Hardware Considerations, it is not enough if on the *download
> page* Guix is claimed to run on “an i686, x86_64, ARMv7, or AArch64
> machine“ without saying linux-libre *on some hardware, is not
> supported* and referencing the Hardware Considerations section and
> h-node, I think.

Well, ‘Limitations’ and ‘Hardware Considerations’ are the first sections
one see when following ‘Installation Instructions’ at
http://guix.gnu.org/download/. We can always move things one level
higher, but eventually everything ends up at the top level. :-)

Toggle quote (7 lines)
> >From e88ee68c09266e1d09d24ff0d1b6ec6a4708841b Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian@pelzflorian.de>
> Date: Wed, 24 Jul 2019 23:02:21 +0200
> Subject: [PATCH] doc: Mention AMD Radeon workaround when TTYs are not redrawn.
>
> * doc/guix.texi (Hardware Considerations): Describe workaround.

[…]

Toggle quote (19 lines)
> +Some hardware requires specific tweaks to work better with Guix System. The
> +following is an incomplete list of known workarounds:
> +
> +@itemize
> +@item
> +Some @emph{AMD Radeon} graphics cards stop redrawing the virtual console TTYs
> +when booting because of an error with Kernel Mode Setting. The problem
> +disappears when blacklisting the kernel module for the driver. To do so, you
> +can add @code{modprobe.blacklist=radeon} to the Linux-libre kernel flags,
> +either for only one boot by pressing the @kbd{e} key in the GRUB bootloader
> +and adding this kernel flag to the end of the @code{linux} command-line, or
> +permanently by changing the @code{kernel-arguments} field in your
> +@code{operating-system} declaration, e.g.:
> +
> +@example
> +(kernel-arguments '("quiet" "modprobe.blacklist=radeon"))
> +@end example
> +@end itemize

I think this doesn’t fit well here: the previous paragraphs are about
RYF, h-node.org, and the more general issue.

Like Ricardo wrote, since this is not Guix-specific, it would be great
if we could link to other resources on this topic. Are you aware of any
such on-line resource?

If there’s no such thing, then we should definitely add this
information, but perhaps we should move the paragraph a bit higher (next
to Wifi), and possibly turn Wifi into an item of this list. WDYT?

Thanks,
Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 26 Jul 2019 22:03
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190726200325.25npy5xwkjp7m353@pelzflorian.localdomain
On Fri, Jul 26, 2019 at 05:56:23PM +0200, Ludovic Courtès wrote:
Toggle quote (14 lines)
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > While my patch before addresses AMD-specific tweaks in the manual
> > under Hardware Considerations, it is not enough if on the *download
> > page* Guix is claimed to run on “an i686, x86_64, ARMv7, or AArch64
> > machine“ without saying linux-libre *on some hardware, is not
> > supported* and referencing the Hardware Considerations section and
> > h-node, I think.
>
> Well, ‘Limitations’ and ‘Hardware Considerations’ are the first sections
> one see when following ‘Installation Instructions’ at
> <http://guix.gnu.org/download/>. We can always move things one level
> higher, but eventually everything ends up at the top level. :-)
>

I would rather see a more prominent link to the manual and h-node
where on the downloads page it says “runs on i686, x86_64, ARM”,
because I suppose many people do not read the manual until they know
they need to, and instead expect things to just work, especially now
that there’s a graphical installer.



Toggle quote (21 lines)
> > >From e88ee68c09266e1d09d24ff0d1b6ec6a4708841b Mon Sep 17 00:00:00 2001
> > From: Florian Pelz <pelzflorian@pelzflorian.de>
> > Date: Wed, 24 Jul 2019 23:02:21 +0200
> > Subject: [PATCH] doc: Mention AMD Radeon workaround when TTYs are not redrawn.
> >
> > * doc/guix.texi (Hardware Considerations): Describe workaround.
>
> […]
>
> I think this doesn’t fit well here: the previous paragraphs are about
> RYF, h-node.org, and the more general issue.
>
> Like Ricardo wrote, since this is not Guix-specific, it would be great
> if we could link to other resources on this topic. Are you aware of any
> such on-line resource?
>
> If there’s no such thing, then we should definitely add this
> information, but perhaps we should move the paragraph a bit higher (next
> to Wifi), and possibly turn Wifi into an item of this list. WDYT?
>

Yes, I agree this is not a good place in the manual. However, I
thought of it more as a list of hardware-specific *and* Guix-specific
tweaks. Note that the patch does not mention Xorg not working on some
AMD GPUs (h-node is the place for that, even though currently it does
not yet list many AMD Radeons), instead the patch is about
hardware-specific tweaks that can be made. For example, a
recommendation of thinkfan for Thinkpads could be placed in such a
section too (once there is a Guix service for thinkfan; I do not know
how important thinkfan is and do not own a Thinkpad, it is just an
example). The Arch wiki for example has articles on various specific
kinds of hardware.

Regards,
Florian
D
D
Denis 'GNUtoo' Carikli wrote on 7 Dec 2021 18:42
Re: Warn of AMD GPUs unusable with Guix System
(address . 36786@debbugs.gnu.org)
20211207184252.66ea8c2a@primarylaptop.localdomain
Would it be better to find a way to fix these issue rather than warn
people about it? They look realatively easy to fix.

For the Radeon / AMDGPU drivers to work, you need:
- A patch need to be upstreamed in linux-libre for the GPU family to
make the driver load. That patch needs to be tested on real hardware.
- Potentially some configuration for Xorg for recent cards to account
for the lack of hardware 2D acceleration. Without it we could have
something like that (from Parabola):
'/usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol:
exaGetPixmapDriverPrivate'

The Libreplanet wiki[1] has all the information about that. If each
person with an unsupported GPU and a bit of skills (it requires to
compile linux-libre) and a bit of time (it should not take that long,
it'll probably be something between less than 1 hour to 1 day), or that
we try to help people with these GPU doing that, we could fix it for
good.

I already did it for all the AMD GPUs I had access to, but despite the
fact that it's really a low hanging fruit, only 1 person that needed a
lot of help tried to follow these tutorials (though I didn't manage to
find the time it required to help that person until the end).

All the information about was added in the libreplanet wiki[1] as it is
relevant to most GNU/Linux FSDG compliant distributions and the problem
is not specific to a given distribution.

References:
-----------

Denis.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmGvnR8ACgkQX138wUF3
4mNJHxAAlPTtXS2Xzp+H7JBezN4mW7yHxtFfhHw+Inr1CtZFqWliBhbTmS0JB8Fl
7tVTphGMxXM4eQ+35TVnFoAKT6iuyDQFIbFciMGElcoFh+KtL1w8kQUgrf1XNKZ+
G3vSvghD6i00Sk6i8JjcHoe6vHHuauuVP+zJkATP2x7EYRMyVBXDnaslvSX2Nhsh
xvEKbEvYH7wXaqPZB/ERNOfkbyWalX/NsrrdGRxaRjbmvUZ3o0kQ8taqpZlBjQwA
konbV1zWyHtGn2TWgJMRlUcF363QCD6OLsUuBYnJrazchBWY5XBa6jD2ufLplcwn
7Rgl/qEHT9NfmcTlvLALBjLgHKiOEQNJCjbBDJxTYL5WgmEMvHY/gbAnp1Gghawt
obkyOOEEQ3GgzhuBUOYwXFNKpKm+ftbAAzTUrSgBG2vJ5Ea8DGLiN8B3HsNDPh2z
Pzirt+xLjuhW1I+c+xRWZG/O57Hddpa9arJGrEQNJ7R7PAFw+w04cdRozTSbnFqJ
VvdsXE4ihyDZh2JqeXvdkJjuVBvWV1eC/QEIk2/Yy8wCcqYODqkrTd0p/qD8hK3N
xxHLRxd1zc2oFFNzpAR7jRrV+oTx47oGeIjlMfeegEa1dTgkVpZ/he73prmXlthl
fvOmgWUD2RPmhNci5NPdRV2VUuqcqhZHqkpH1Ujlm6R5B9Cn68c=
=mfXi
-----END PGP SIGNATURE-----


P
P
pelzflorian (Florian Pelz) wrote on 16 Nov 2022 00:28
Re: bug#36786: Warn of AMD GPUs unusable with Guix System
(address . 36786-done@debbugs.gnu.org)
875yffbxwo.fsf@pelzflorian.de
pelzflorian (Florian Pelz) wrote on 26 Jul 2019 22:03
Toggle quote (6 lines)
> I would rather see a more prominent link to the manual and h-node
> where on the downloads page it says “runs on i686, x86_64, ARM”,
> because I suppose many people do not read the manual until they know
> they need to, and instead expect things to just work, especially now
> that there’s a graphical installer.

Closing. Documenting non-working hardware is no longer necessary since
warnings were prominently added within the installer, as discussed at
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 36786@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 36786
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch