Bug 1814810
Summary: | Basic graphics mode is necessary to boot laptop with dual Intel/AMD Oland GPU | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | xzj8b3 <xzj8b3> | ||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 32 | CC: | airlied, bcotton, bskeggs, dufresnep, extras-qa, fzatlouk, gmarr, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mjg59, robatino, steved, y9t7sypezp | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | RejectedBlocker AcceptedFreezeException | ||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2021-05-25 17:18:36 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1705306 | ||||||||
Attachments: |
|
Description
xzj8b3
2020-03-18 17:04:26 UTC
(In reply to xzj8b3 from comment #0) ... > I attach dmesg again ... [ 18.475718] radeon 0000:04:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0x00000000995841ee ... [ 19.951674] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! ... That's a radeon problem, and your earlier report, Bug 1802641, has had the component changed to "linux-firmware". There is a workaround suggested in Bug 1802641, Comment 8. Did you try it? Przemek: "It can be mitigated by adding radeon.modeset=0 to the kernel commandline in /etc/defaults/grub followed by grub2-mkconfig" I suggest closing this as a duplicate of Bug 1802641. But in Fedora 32 Final will be corrected on release??? (In reply to xzj8b3 from comment #2) > But in Fedora 32 Final will be corrected on release??? OK, I now see that you opened a new bug against F32. Here is a list of available updates to linux-firmware: https://bodhi.fedoraproject.org/updates/?packages=linux-firmware Unfortunately, the notes don't mention radeon: linux-firmware-20200316-106.fc32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-9d65d662e2 From the attached file you appear to be booting a live image: [ 0.000000] Command line: BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-32_B-1-2 rd.live.image quiet You can try the workaround (in Comment 1) from the live image by editing the kernel command-line after pressing the "tab" key. Just append this to the end of the kernel command-line: radeon.modeset=0 (In reply to Steve from comment #3) ... > You can try the workaround (in Comment 1) from the live image by editing the > kernel command-line after pressing the "tab" key. Just append this to the > end of the kernel command-line: > > radeon.modeset=0 Or you could press "Troubleshooting" and then start in "basic graphics mode". (I tested that in a VM with an F31 live image, but it should be the same for F32.) I would like to know if the problem has been solved, I would like to install Fedora 32 Beta ... or how I can proceed to resolve the situation... Please answer in this way, in case of success, I could give more details about it in my hand!!! Or should I wait for final release? What version does Kernel have now? (In reply to xzj8b3 from comment #5) > I would like to know if the problem has been solved, I would like to install Fedora 32 Beta ... There hasn't been a new release of linux-firmware, so probably not: Here is a list of available updates to linux-firmware: https://bodhi.fedoraproject.org/updates/?packages=linux-firmware I believe this is the upstream git repo for linux-firmware: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > or how I can proceed to resolve the situation... Did you try the workarounds in Comment 3 and Comment 4? > Please answer in this way, in case of success, I could give more details about it in my hand!!! > > Or should I wait for final release? What version does Kernel have now? Beta releases are for testing, and you tested it and filed a bug report. There's not much more that you can do, except watch for a new release of linux-firmware, and test it, if you can successfully install by using one of the workarounds. Created attachment 1673615 [details] screenshot showing the F32 Live Beta troubleshooting menu (In reply to Steve from comment #4) ... > Or you could press "Troubleshooting" and then start in "basic graphics mode". ... Here is a screenshot showing the F32 Live Beta troubleshooting menu. NB: The word "mode" is truncated to "mo" at the right. The radeon firmware is licensed by AMD: $ head -1 /usr/share/licenses/linux-firmware/LICENSE.radeon Copyright (C) 2009-2017 Advanced Micro Devices, Inc. All rights reserved. And AMD maintains the radeon firmware: radeon: update oland rlc microcode from amdgpu https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f1c9e7b67505fcb5b7236902475286e893591916 So it will already be inserted into the next kernel???? Proposing as a Fedora 32 Final blocker bug: "Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop." https://fedoraproject.org/wiki/Basic_Release_Criteria#Initialization_requirements From the attached dmesg, this bug occurs with the F32-Beta Workstation Live image: [ 0.000000] Command line: BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-32_B-1-2 rd.live.image quiet According to: Bug 1802641 - kernel 5.4 Bug Radeon This is a radeon firmware problem: https://bodhi.fedoraproject.org/updates/?packages=linux-firmware From the attached log: [ 18.338058] [drm] initializing kernel modesetting (OLAND 0x1002:0x6607 0x1043:0x192D 0x00). ... [ 18.405837] [drm] Loading oland Microcode Upstream shows two commits related to Oland firmware: radeon: update oland rlc microcode from amdgpu (2020-01-07) Fixes clocking issues at 4k https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f1c9e7b67505fcb5b7236902475286e893591916 This reverts the above commit and appears to have gone into linux-firmware-20200316: Revert "radeon: update oland rlc microcode from amdgpu" (2020-02-04) This reverts commit f1c9e7b67505fcb5b7236902475286e893591916. This breaks UVD on some boards. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=0ff2f37095070dd142c0b4c8310d6afcf73a146e (In reply to xzj8b3 from comment #0) > Created attachment 1671177 [details] > dmesg Fedora 32 Beta > > https://bugzilla.redhat.com/show_bug.cgi?id=1802641 > > > After testing Fedora 32 Beta from pendrive I note that the kernel does not > yet work with intel integrated graphics ... > > The issue had already been reported earlier and makes it just impossible to > use the distribution on those adapters!!! > > Hopefully the final release will be presented with a working kernel testable > in live mode, otherwise it is impossible for users to check if the problem > has been solved > > I attach dmesg again So... it seems from logs that the laptop has dual Intel/AMD GPUs. Is that correct? Does either "basic graphics mode" or "radeon.modeset=0" help? iMy notebook has an I7-4510U processor with Radeon R5 M230 graphics ... I am currently using Windows 10 because the bug does not allow me a functional Fedora installation..... Dmesg was obtained from Fedora32 started in live mode!!! Hmm, seems like this is indeed limited o Oland generation of GPUs. I was able to succesfully boot Fedora 32 with dual Intel (Sandy Bridge) and AMD Mars XT (CGN 1.0) GPUs. Discussed during the 2020-04-13 blocker review meeting: [0] The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as as we think the range of hardware affected is quite small (dual Intel/AMD Oland GPU systems are not very common), but accepted as an FE as a severe problem not fixable with an update on hardware that *is* affected. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-13/f32-blocker-review.2020-04-13-16.04.txt (In reply to Geoffrey Marr from comment #15) > Discussed during the 2020-04-13 blocker review meeting: [0] > > The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as as we think the range of hardware > affected is quite small (dual Intel/AMD Oland GPU systems are not very common), but accepted as an FE as a severe problem not fixable with an update on hardware that *is* affected. > > [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-13/f32-blocker-review.2020-04-13-16.04.txt Thanks, Geoffrey. xzj8b3: What that means is that a fix will be accepted after the "Final Freeze", but this bug won't block the F32 Final release. QA:SOP freeze exception bug process https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process Fedora 32 Schedule: Key https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html I am looking at https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1865130/comments/61 and thinks it might be related. (In reply to Paul Dufresne from comment #17) > I am looking at https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1865130/ comments/61 and thinks it might be related. Thanks for pointing that out -- and my face is red, because I posted repeatedly on this bug and *not once* did I have the wits to actually look at the F32-Beta Live image itself! So it's simple: On the F32-Beta Live image (Fedora-Workstation-Live-x86_64-32_Beta-1.2.iso booted in a VM): $ rpm -q linux-firmware linux-firmware-20200122-105.fc32.noarch That is OLDER than the current linux-firmware on Bodhi: linux-firmware-20200316-106.fc32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-9d65d662e2 See Comment 11 for the rest of the story: The upstream revert went into linux-firmware-20200316-106.fc32: That can be verified by doing a text search for "radeon" on the upstream git log: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/?h=20200316 linux-firmware-20200316-106.fc32 is now in stable. So original poster can test it by downloading latest one of latest daily build at: https://www.happyassassin.net/nightlies.html (green links are known to have past all defined tests). I am writing this on Fedora-32-20200419.n.0 where: $ rpm -q linux-firmware linux-firmware-20200316-106.fc32.noarch So I know it have the needed version. Thanks for checking that, Paul. Testing a nightly is a very good idea. xzj8b3: The nightlies are ISO images of Fedora software that are built every night for testing. You can download and install one on your pendrive just like you did for the F32-Beta ISO image. There are a lot to choose from here: https://www.happyassassin.net/nightlies.html But you only need Fedora 32:Workstation live:x86_64 with a green link. The nightlies are updated every night, but I believe that the one Paul tested is here: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200419.n.0/compose/Workstation/x86_64/iso/ The latest nightly Fedora 32 Workstation build for x86_64 is here: https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-32/compose/Workstation/x86_64/iso/ Paul: Please correct me if I have said anything wrong. I installed this nightly on a pendrive and successfully booted to a desktop on two systems (desktop, laptop), and networking was functional on both: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200420.n.0/compose/Workstation/x86_64/iso/ (In reply to Steve from comment #1) > (In reply to xzj8b3 from comment #0) > ... > > I attach dmesg again > > ... > [ 18.475718] radeon 0000:04:00.0: fence driver on ring 0 use gpu addr > 0x0000000080000c00 and cpu addr 0x00000000995841ee > ... > [ 19.951674] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, > trying to reset the VCPU!!! > ... > > That's a radeon problem, and your earlier report, Bug 1802641, has had the > component changed to "linux-firmware". > > There is a workaround suggested in Bug 1802641, Comment 8. Did you try it? > > Przemek: "It can be mitigated by adding radeon.modeset=0 to the kernel > commandline in /etc/defaults/grub followed by grub2-mkconfig" > > I suggest closing this as a duplicate of Bug 1802641. But do you really want to go back to Fedora if you destroy it at every kernel release or is it still suffering from these problems?? How can you have reliability in a system you always know what problems give new kernels that instead of solving problems create them?? You windows will have poor rivacy but go'... I don't think Linux world is working so well if every time the same problems arise that never resolve and punctually come back. Windows will now also have built-in Linux and maybe it would be worth trying it all in all... Fedora has not even been able to preconfigure wireguards so it can already be readily available at first start and therefore accessible to everyone enjoying the benefits.... and even with Firefox, first subscriptions for features start popping up!! Mahhh... (In reply to František Zatloukal from comment #12) > (In reply to xzj8b3 from comment #0) > > Created attachment 1671177 [details] > > dmesg Fedora 32 Beta > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1802641 > > > > > > After testing Fedora 32 Beta from pendrive I note that the kernel does not > > yet work with intel integrated graphics ... > > > > The issue had already been reported earlier and makes it just impossible to > > use the distribution on those adapters!!! > > > > Hopefully the final release will be presented with a working kernel testable > > in live mode, otherwise it is impossible for users to check if the problem > > has been solved > > > > I attach dmesg again > > So... it seems from logs that the laptop has dual Intel/AMD GPUs. Is that > correct? Does either "basic graphics mode" or "radeon.modeset=0" help? But do you really want to go back to Fedora if you destroy it at every kernel release or is it still suffering from these problems?? How can you have reliability in a system you always know what problems give new kernels that instead of solving problems create them?? You windows will have poor rivacy but go'... I don't think Linux world is working so well if every time the same problems arise that never resolve and punctually come back. Windows will now also have built-in Linux and maybe it would be worth trying it all in all... Fedora has not even been able to preconfigure wireguards so it can already be readily available at first start and therefore accessible to everyone enjoying the benefits.... and even with Firefox, first subscriptions for features start popping up!! Mahhh... But do you really want to go back to Fedora if you destroy it at every kernel release or is it still suffering from these problems?? How can you have reliability in a system you always know what problems give new kernels that instead of solving problems create them?? You windows will have poor rivacy but go'... I don't think Linux world is working so well if every time the same problems arise that never resolve and punctually come back. Windows will now also have built-in Linux and maybe it would be worth trying it all in all... Fedora has not even been able to preconfigure wireguards so it can already be readily available at first start and therefore accessible to everyone enjoying the benefits.... and even with Firefox, first subscriptions for features start popping up!! Mahhh... xzj8b3: Thanks for your reply. Could you please test one of the nightlies and see if it works for you or not?
> Fedora has not even been able to preconfigure wireguards ...
I don't know what "wireguards" are. Could you post a link to more information?
Let's keep this bug's conversation focused on the subject. xzj8b3, if there are other issues, please feel free to open new bugs or join us on discussion.fedoraproject.org. In the meantime, can you please the latest compose: https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200420.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-32-1.4.iso (that link is for Workstation x86_64. If you need another variant or architecture, see https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200420.0/compose/ ) (In reply to Ben Cotton from comment #26) > Let's keep this bug's conversation focused on the subject. Sometimes reporters raise more than one issue in a bug report, so it is always much more polite and constructive to collect more information before referring them to another venue. I always report, "sometimes too much", but I see it was done a great job with Fedora 32 ... then of course I have my limits, otherwise I would be much more detailed each time in the description of any problems. Thank you again for the resolution of the problem that I hope in the future will no longer occur .... A wonderful distribution as Fedora can not afford similar problems can damage the image, not even because of problems of third parties!!! I've never seen a distribution with such an active team behind it....and that's what distinguishes Fedora from other distros...and I hope it will continue like this!!!! I always report, "sometimes too much", but I see it was done a great job with Fedora 32 ... then of course I have my limits, otherwise I would be much more detailed each time in the description of any problems. Thank you again for the resolution of the problem that I hope in the future will no longer occur .... A wonderful distribution as Fedora can not afford similar problems can damage the image, not even because of problems of third parties!!! I've never seen a distribution with such an active team behind it....and that's what distinguishes Fedora from other distros...and I hope it will continue like this!!!! https://betanews.com/2020/05/19/open-source-security-flaws/ A shame to read similar articles about a world as beautiful as opensource, of course nothing is perfect but I hope we can improve more and more, paying more attention to new users who are increasingly closer to this world ... I do not approve Forums that boast of Ubuntu Benkmark as if this is better than other distributions, indeed the thing has bothered me rather because for a long time I hear a lot of nonsense about Fedora communities that do not correspond to reality ... Sure ubuntu is very attentive to new users trying to make life easier, a little bit we all learned from that, but I estimate a lot Fedora for its policy and the speed of response with which you address emerging issues even in bugzilla, I would like just a little more attention to novice users when they arise in some problem that often have difficulty understanding, as it would be nice to see wikis written in a more understandable with more examples. ..I find for example the plugin section of dnf too synthetic, it would be very nice to have more understandable wikis even for new or average user and if it were possible maybe even in Italian etc. I didn't understand where I should go for more issues, which would be very nice to be able to discuss > I didn't understand where I should go for more issues, which would be very nice to be able to discuss In comment 26, Ben suggested this site: Fedora Discussion https://discussion.fedoraproject.org/ > That's Wireguard. Thanks for the link. There is a search tool in the upper-right corner of the Fedora Discussion web site. A search for "wireguard" returns several results: https://discussion.fedoraproject.org/search?q=wireguard%20order%3Alatest This will find Fedora packages supporting WireGuard: $ dnf -q search wireguard ======================================== Name & Summary Matched: wireguard ======================================== golang-zx2c4-wireguard-wgctrl-devel.noarch : Control of WireGuard interfaces on multiple platforms ============================================= Name Matched: wireguard ============================================= wireguard-tools.x86_64 : Fast, modern, secure VPN tunnel =========================================== Summary Matched: wireguard ============================================ wgctrl.x86_64 : Control of WireGuard interfaces on multiple platforms This is the WireGuard project web site: https://www.wireguard.com/ > I find for example the plugin section of dnf too synthetic ...
I'm not sure what you mean by "synthetic". Could you post the Italian word for what you mean?
Anyway, "dnf" is a command-line tool. Novices should use the gnome "Software" GUI app, which is installed by default:
$ dnf repoquery --info gnome-software
Well use linux so then it doesn't even make sense to install it and try to get to know it... I have never installed anything with Gnome Software. By "synthetic" I mean short... It would be very nice to have more extensive descriptions of plugins installable in dnf, so you know much more and use them better, perhaps with more examples in various situations I never understood the correct use of : python3-dnf-plugin-torproxy.noarch python3-dnf-plugin-snapper.noarch python3-dnf-plugin-versionlock.noarch I think it would be interesting to have more information and examples of use on each plugin so you can 'choose more properly those of our interest and learn to make the most of them, some have very poor descriptions and do not understand either the use, nor how to get more information about them ... have a few lines each in the wiki and that's it!! Then Tilix is fabulous other than software gnome. > By "synthetic" I mean short... Thanks for your clarification. I suggest opening documentation bugs, which are requests that the documentation be improved. For a documentation bug, put "[DOC]" at the beginning of the bug summary. Components in BZ are: Component dnf-plugins-extras: python3-dnf-plugin-torproxy.noarch python3-dnf-plugin-snapper.noarch https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=dnf-plugins-extras&list_id=11077378&product=Fedora&query_format=advanced Component dnf-plugins-core: python3-dnf-plugin-versionlock.noarch https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=dnf-plugins-core&list_id=11077384&product=Fedora&query_format=advanced To find the BZ component for a package, use a command like this: $ dnf -Cq repoquery --info python3-dnf-plugin-torproxy | grep 'Source' There is also a separate "Fedora Documentation" product in BZ: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&list_id=11077393&order=Importance&product=Fedora%20Documentation&query_format=advanced (In reply to Steve from comment #37) ... > To find the BZ component for a package, use a command like this: > > $ dnf -Cq repoquery --info python3-dnf-plugin-torproxy | grep 'Source' And to find the upstream git repos, run: $ dnf -Cq repoquery --info python3-dnf-plugin-torproxy | grep 'URL' This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |