Description of problem: Test the classical (or Live) installer from beta3 pre-release round 1 (in this case with minimal set of packages for this bug report) on machine as here: https://wiki.mageia.org/en/QA_iso_hardware_list -> Notebooks -> dvgevers As may be seen in summary -->grub2 or when editing the grub2 menu after reboot, this adds the kernel parameter "nokmsboot" and as MartinW suggested on the QA ML that is preventing X from starting after reboot. Indeed if removed X comes up fine. The last error before X should start reads on the boot screen (twice): ... [drm:amdgpu_init [amdgpu]] *ERROR* VGACOM disables amdgpu kernel modesetting. I will add MartinW in cc , attach /root/drakx/report.bug.xz and show the result of command "/sbin/display_driver_helper --is-kms-allowed; echo $? " and mark the bug as "for errata"
Keywords: (none) => 7beta3, FOR_ERRATA7CC: (none) => mageia
Did you get any question about "there is a nonfree driver" or something about installing fglrx ?
CC: (none) => tmb
Created attachment 10890 [details] installer report bug In reply to tmb: not about fglrx. Just that the installer said I would need non-free media but I suspect this is caused by the wifi chip The result of the command /sbin/display_driver_helper --is-kms-allowed; echo $? reads: 1
(In reply to Dick Gevers from comment #2) > The result of the command /sbin/display_driver_helper --is-kms-allowed; echo > $? > reads: 1 This is the reason the installer is adding nokmsboot to the boot options. That command should return 0 for a KMS driver. But if xorg.conf selects the amdgpu driver, it returns 1. I've just tested that on my Mageia 6 system, and it does the same there.
Can uou remove the hash in front of: # DEBUG_DISPLAY_DRIVER_HELPER=yes in /sbin/display_driver_helper and run the command again. Then attach the contents of /dev/ddh_debug
Created attachment 10894 [details] ddh_debug per tmb's request in comment 4 I cheated a little bit: as the install from classical installer that is the subject of this bug report has already been overwritten by a Live iso install I changed the display_driver_helper and ran the said command again under my always present Cauldron on the exact same machine from another partition. DDH looks at the same hardware so I presume the output is the same... but if you suspect any problem I will install again with the classical iso !
CC: (none) => marja11Assignee: bugsquad => isobuild
You can easily reproduce this on any mga6 or cauldron system, just temporarily change the driver name in /etc/X11/xorg.conf to amdgpu and run display_driver_helper. It doesn't depend on what drivers are currently in use.
Priority: Normal => release_blockerSource RPM: Classical iso x86_64 beta3 => drakx-kbd-mouse-x11
(In reply to Martin Whitaker from comment #6) > You can easily reproduce this on any mga6 or cauldron system, just > temporarily change the driver name in /etc/X11/xorg.conf to amdgpu and run > display_driver_helper. It doesn't depend on what drivers are currently in > use. Yes well the Cauldron xorg.conf already has that: ... Section "Device" Identifier "device1" Vendorname "Advanced Micro Devices, Inc. [AMD/ATI]" Boardname "ATI Volcanic Islands and later (amdgpu/fglrx)" Driver "amdgpu" Option "DPMS" EndSection ... which section is identical to that in the xorg.conf written by the beta3 round 1 Live install from the 64 bit Xfce iso i ended with yesterday. So if I understand you correctly my "cheat" passes...
By the way, if it is any help: I saw the "nokmsboot noiswmd" added to the grub command line on this machine in every (test) install I did since day 1 that I am using this machine (late 2017) and removed both in Cauldron that runs every day because it proved to be not needed.
(In reply to Dick Gevers from comment #7) > So if I understand you correctly my "cheat" passes... Yes, that's what I meant to say :-) (In reply to Dick Gevers from comment #8) > By the way, if it is any help: I saw the "nokmsboot noiswmd" added to the > grub command line on this machine in every (test) install I did since day 1 > that I am using this machine (late 2017) and removed both in Cauldron that > runs every day because it proved to be not needed. Indeed, this has been wrong for a long time, but it used not to cause a problem. But Thomas recently changed the behaviour of nokmsboot (to fix another bug), and now the amdgpu driver will fail when nokmsboot is used. I think the fix for this bug is to remove the radeon <=> amdgpu conflicts in display_driver_helper, but I'll wait for Thomas to comment on that.
(In reply to Martin Whitaker from comment #9) > (In reply to Dick Gevers from comment #7) > > So if I understand you correctly my "cheat" passes... > > Yes, that's what I meant to say :-) > > (In reply to Dick Gevers from comment #8) > > By the way, if it is any help: I saw the "nokmsboot noiswmd" added to the > > grub command line on this machine in every (test) install I did since day 1 > > that I am using this machine (late 2017) and removed both in Cauldron that > > runs every day because it proved to be not needed. > > Indeed, this has been wrong for a long time, but it used not to cause a > problem. But Thomas recently changed the behaviour of nokmsboot (to fix > another bug), and now the amdgpu driver will fail when nokmsboot is used. > > I think the fix for this bug is to remove the radeon <=> amdgpu conflicts in > display_driver_helper, but I'll wait for Thomas to comment on that. Yes, I think thats the issue. There is some hw support overlap between amdgpu and radeon (wich is why we added the conflicts), but the radeon one is preferred in the kernel (and is what our ldetect-lst is following too...) so it should hopefully work without it Martin, please go ahead and drop the conflicts so we can get it tested... I'm heading out on a trip so I wont be available for some days...
Conflicts dropped in drakx-kbd-mouse-x11-1.27.1.mga7. Fix to be confirmed in next ISO build. My Radeon card hits the overlap, so I'll be able to test that.
(In reply to Martin Whitaker from comment #11) > Conflicts dropped in drakx-kbd-mouse-x11-1.27.1.mga7. Fix to be confirmed in > next ISO build. My Radeon card hits the overlap, so I'll be able to test > that. My Cauldron test machine now shows: # /sbin/display_driver_helper --is-kms-allowed; echo $? 0
M7 B3 round 2 works fine with this
Status: NEW => RESOLVEDResolution: (none) => FIXED
For the record I need to remark that my AMD Radeon R5 does experience occasional hangs of X in Cauldron with journalctl showing amdgpu_job_timeout errors which are alspo reported elsewhere (as shown by google search for amdgpu_job_timeout). So the current combination of kernel (-parameter) and X are not ideal for this hardware, I think.
CC: (none) => friKeywords: FOR_ERRATA7 => (none)