Re: Tentative summary of the AMD/ATI/NVidia issue
Cyril Brulebois dixit: >Lucas Nussbaum (2021-04-24): >> C) Do nothing and document this in the release notes > >As said above, I strongly recommend against this. Right… what about, add another Plan C… C) When X won’t work, fail gracefully, show a console login … and dump the above to Plan D? (Perhaps doing this is a good idea in general, for when a similar issue pops up in the future?) bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: Tentative summary of the AMD/ATI/NVidia issue
Le dimanche 25 avril 2021, 13:18:03 CEST Rebecca N. Palmer a écrit : > Cyril Brulebois wrote: > > getting my hands on relevant hardware is in progress > > Note that https://lists.debian.org/debian-boot/2021/04/msg00247.html > implies the affected hardware is _not_ simply "all AMD/ATI or NVidia > hardware". Do we know of hardware that is reproducibly affected? > > YunQiang Su wrote: > > The problem is that: > > the older version of GNOME, or Mate, can work with vesa driver, > > while current GNOME cannot. > > Do non-GNOME-based desktops work (either KDE, or one of the > lightweight/for-old-hardware ones e.g. icewm), or is the problem further > down the stack? Hi, having a RX 470 (POLARIS10) at hand, I thought I’d give a couple of data points for the buster vs. bullseye comparison. I confirm the graphical installer works for both buster and bullseye. I ran the standard install on this machine for the 10.9 and bullseye RC1 amd64 images for each of the following 3 desktops : GNOME, Plasma and MATE because they use different DMs (GDM, SDDM, LightDM). Here are the results for the 3 desktops without and with firmware-amd-graphics installed: |fw-amd-graphics | without | with | |Buster | GNOME | broken| not tested| | | Plasma | broken| OK (hw accel) | | | MATE | broken| OK (hw accel) | |--- |Bullseye | GNOME | OK (llvm) | OK (hw accel) | | | Plasma | broken| OK (hw accel) | | | MATE | OK (llvm) | OK (hw accel) | broken= stays on black or text kernel tty, the display manager won’t come up OK (llvm) = DM and desktop work, the OpenGL rendering is done by the CPU using LLVM, resolution is limited to 1024x768 So at least for this piece of hardware we’re better off with bullseye than what we currently ship with buster. Cheers, -- Aurélien
Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)
On 25/04/21 at 11:04 +0200, Cyril Brulebois wrote: > > B) In the installer, detect that firmware-amd-graphics or > > firmware-misc-nonfree should be installed, and either install it (?), > > or redirect the user to the unofficial installer that includes them. > > That could be achieved for an installer that has non-free enabled, > provided the proposal by Ben gets implemented, then consumed on the d-i > side. For reference, I think Ben's proposal is: https://lists.debian.org/debian-boot/2021/03/msg00088.html Lucas
Re: Tentative summary of the AMD/ATI/NVidia issue
On Sun, Apr 25, 2021 at 12:18:03PM +0100, Rebecca N. Palmer wrote: > Cyril Brulebois wrote: > > getting my hands on relevant hardware is in progress > > Note that https://lists.debian.org/debian-boot/2021/04/msg00247.html implies > the affected hardware is _not_ simply "all AMD/ATI or NVidia hardware". Do > we know of hardware that is reproducibly affected? > > YunQiang Su wrote: > > The problem is that: > > the older version of GNOME, or Mate, can work with vesa driver, > > while current GNOME cannot. > > Do non-GNOME-based desktops work (either KDE, or one of the > lightweight/for-old-hardware ones e.g. icewm), or is the problem further > down the stack? > > Though even if these do work, the performance penalty of using vesa may well > be too large for this to be a good solution. > >From looking earlier and response to Holger from my bug report: if you are using UEFI, then there is an EFI VGA fallback mode - which might be the same as VESA - so in my case is 800x600x16 or so. With my AMD machines - requiring firmware-amd-graphics == older Radeon, if the firmware is not there, then the machines will fall back to EFI VGA graphics mode. If the firmware is there, they will transfer to radeondrmfb framebuffer device. So for _one_ set of AMD hardware and specific radeon drivers, there exists a fallback mode, irrespective of graphical environment, I think. All best, Andy C.
Re: Tentative summary of the AMD/ATI/NVidia issue
Cyril Brulebois wrote: getting my hands on relevant hardware is in progress Note that https://lists.debian.org/debian-boot/2021/04/msg00247.html implies the affected hardware is _not_ simply "all AMD/ATI or NVidia hardware". Do we know of hardware that is reproducibly affected? YunQiang Su wrote: The problem is that: the older version of GNOME, or Mate, can work with vesa driver, while current GNOME cannot. Do non-GNOME-based desktops work (either KDE, or one of the lightweight/for-old-hardware ones e.g. icewm), or is the problem further down the stack? Though even if these do work, the performance penalty of using vesa may well be too large for this to be a good solution.
Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)
[ cc+=-x@ ] Hi Lucas, Thanks for your summary, I'm not sure about every single detail, but it seems to be a good basis for discussion. I might point to it from our errata page (I didn't have a specific bug report when I wrote the most recent entries): https://www.debian.org/devel/debian-installer/errata Lucas Nussbaum (2021-04-24): > Disclaimer: I read the "[AMD/ATI graphics] Missing firmware not declared > / kernel modules not included in initrd" thread. While my understanding > of the issue is not complete, I'm trying to summarize what I undertood > so far in the hope that others can jump in and fill in the blanks or > correct me. > > > There are graphic cards whose in-kernel drivers require non-free > firmwares. Typically AMD/ATI cards that require firmware-amd-graphics[1] > to work with the radeon, amdgpu and r128 drivers; or NVIDIA cards that > require firmware-misc-nonfree to work with the nouveau driver. > > [1] https://packages.debian.org/unstable/firmware-amd-graphics > > > With Debian 10, the behaviour was that the installation succeeded > without installing firmware-* packages, and then, and the first boot, X > would start in a "degraded" mode (using, for example, the vesa driver). > The user would generally then install the firmware package (or, in the > case of NVidia, switch to the proprietary drivers). > > With Debian 11, the installation also succeeds, but then at first boot, > X fails to work correctly. What happens here is unclear: reports vary > between "black screen" (but does the system works if the user switches to > console mode?), "garbled screen", "system crash" (but maybe the user did > not notice that the system works in console mode). What I briefly alluded to on IRC (#debian-boot) was something that would be an A)+B) approach. C) doesn't seem reasonable to me. > It looks like the three open paths for resolution are: > > A) understand and restore the behaviour from Debian 10, that is, get X > to work in a degraded mode after installation. How it worked with Debian > 10 (and why it doesn't with Debian 11) is unknown. Without checking with X people beforehand, what I imagined we could do when running an installer that doesn't have non-free enabled could be adding some X conf snippet to force a generic driver (a while ago, that would have been fbdev/vesa, not sure about the current state, depending on whether modesetting kicked in, etc.), to ensure one isn't left with a black screen. This might involve setting kernel parameters instead or in addition to that… It could be accompanied by an information note in the installer (to make sure the user knows about this degraded mode, and about ways to improve the situation post-installation) and/or in the installation guide and/or in the wiki. https://xorg-team.pages.debian.net/xorg/ doesn't seem like it has had many updates lately, but it might not be the worst place to have a “how to undo the snippet things and get the real deal once firmwares are installed”, or maybe “how to deal with firmwares” in general… that d-i and the installation guide could point to. (x.debian.net still exists and redirects there, so that's not a complicated URL to remember/type if it gets displayed in a note.) That being said, if an information note gets added in d-i, its content needs to be checked with the X team, reviewed by the team whose name has escaped me, and then translated into as many languages as possible. It could be possible to cheat the translation status to alleviate this requirement, and contemplate updating the relevant package in 11.1, but I'm not sure we've ever done that. On the other hand, docs on x.debian.net aren't translated, so maybe the installation guide would be a better place in the end… > B) In the installer, detect that firmware-amd-graphics or > firmware-misc-nonfree should be installed, and either install it (?), > or redirect the user to the unofficial installer that includes them. That could be achieved for an installer that has non-free enabled, provided the proposal by Ben gets implemented, then consumed on the d-i side. > C) Do nothing and document this in the release notes As said above, I strongly recommend against this. > The main blocking factor for progress seems to be that not enough > people have both hardware that is not supported (laptops/desktops with > AMD or NVidia graphic cards), and the knowledge and time to > investigate this. For the avoidance of doubt: I'm fine with working on these topics (and getting my hands on relevant hardware is in progress), along with other issues that seem to be potential blockers for the release. I just don't expect everyone to agree on a (possibly dual) solution immediately, and the relevant contributions (code, doc, translations) to be available in the very next few days. Hence my reaction to a very close “tentative release date” (fewer than 4 weeks). For completeness, we also have this now: https://bugs.debian.org/987441 Cheers, -- Cyril
Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)
Hi, Lucas Nussbaum wrote (Sat, 24 Apr 2021 11:30:03 +0200): > With Debian 10, the behaviour was that the installation succeeded > without installing firmware-* packages, and then, and the first boot, X > would start in a "degraded" mode (using, for example, the vesa driver). > The user would generally then install the firmware package (or, in the > case of NVidia, switch to the proprietary drivers). > > With Debian 11, the installation also succeeds, but then at first boot, > X fails to work correctly. What happens here is unclear: reports vary > between "black screen" (but does the system works if the user switches to > console mode?), "garbled screen", "system crash" (but maybe the user did > not notice that the system works in console mode). Please note that YunQiang Su has stated in another mail: For us (mips port), it is a long history of problem. The problem is that: the older version of GNOME, or Mate, can work with vesa driver, while current GNOME cannot. Without amd/ati non-free firmware, radeon/amdgpu cannot work at all. So on mips platform with AMDGPU (aka, Loongson-3), it has nothing on display at all, even console. The reason is that there are no vesa driver on MIPS. -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: Tentative summary of the AMD/ATI/NVidia issue
Lucas Nussbaum writes: > It looks like the three open paths for resolution are: > > A) understand and restore the behaviour from Debian 10, that is, get X > to work in a degraded mode after installation. How it worked with Debian > 10 (and why it doesn't with Debian 11) is unknown. > > B) In the installer, detect that firmware-amd-graphics or > firmware-misc-nonfree should be installed, and either install it (?), > or redirect the user to the unofficial installer that includes them. > > C) Do nothing and document this in the release notes There is at least also D) Install (non-free) firmware and include it in official install media. I don't think degraded operation (just vesa, no sound, no wifi, known issues in microcode, ...) will continue to be an attractive option. So maybe we should revisit whether we should just include firmware; I wanted to suggest so at least for Bookworm. Ansgar
Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)
On 24/04/21 at 09:25 +0200, Holger Wansing wrote: > Hi, > > Cyril Brulebois wrote (Fri, 23 Apr 2021 15:13:15 +0200): > > D-I Bullseye RC 1 was published a few hours ago. And at the risk of > > sounding like a broken record: I have *absolutely no guarantee* to > > have a fix or workaround for the amdgpu issue in less than a month, > > that would be tested somewhat. > > > > Can we please *not* release with black screens for AMD users? > > Moreover, it's not just an AMD issue. > We got a confirmation just now on debian-boot, that also NVIDIA users can > get affected by this: > https://lists.debian.org/debian-boot/2021/04/msg00225.html > Some months ago, I have confirmed with that user, that missing firmware > is indeed the issue there! Hi, Disclaimer: I read the "[AMD/ATI graphics] Missing firmware not declared / kernel modules not included in initrd" thread. While my understanding of the issue is not complete, I'm trying to summarize what I undertood so far in the hope that others can jump in and fill in the blanks or correct me. There are graphic cards whose in-kernel drivers require non-free firmwares. Typically AMD/ATI cards that require firmware-amd-graphics[1] to work with the radeon, amdgpu and r128 drivers; or NVIDIA cards that require firmware-misc-nonfree to work with the nouveau driver. [1] https://packages.debian.org/unstable/firmware-amd-graphics With Debian 10, the behaviour was that the installation succeeded without installing firmware-* packages, and then, and the first boot, X would start in a "degraded" mode (using, for example, the vesa driver). The user would generally then install the firmware package (or, in the case of NVidia, switch to the proprietary drivers). With Debian 11, the installation also succeeds, but then at first boot, X fails to work correctly. What happens here is unclear: reports vary between "black screen" (but does the system works if the user switches to console mode?), "garbled screen", "system crash" (but maybe the user did not notice that the system works in console mode). It looks like the three open paths for resolution are: A) understand and restore the behaviour from Debian 10, that is, get X to work in a degraded mode after installation. How it worked with Debian 10 (and why it doesn't with Debian 11) is unknown. B) In the installer, detect that firmware-amd-graphics or firmware-misc-nonfree should be installed, and either install it (?), or redirect the user to the unofficial installer that includes them. C) Do nothing and document this in the release notes The main blocking factor for progress seems to be that not enough people have both hardware that is not supported (laptops/desktops with AMD or NVidia graphic cards), and the knowledge and time to investigate this. Lucas
