From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported Date: Fri, 11 Jan 2019 00:54:52 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0928753245==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 1ECBD6F4B5 for ; Fri, 11 Jan 2019 00:54:52 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0928753245== Content-Type: multipart/alternative; boundary="15471680920.5Aab00d9.5259" Content-Transfer-Encoding: 7bit --15471680920.5Aab00d9.5259 Date: Fri, 11 Jan 2019 00:54:51 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D109135 --- Comment #6 from rmuncrief@humanavance.com --- (In reply to iive from comment #5) > (In reply to rmuncrief from comment #2) > [...] > > Here's the grub line I use for all testing: > > GRUB_CMDLINE_LINUX_DEFAULT=3D"quiet > > resume=3DUUID=3Db4f71480-8fe3-43c2-99c9-fc3f5687545b libata.atapi_passt= hru16=3D0 > > rd.modules-load=3Dvfio-pci amd_iommu=3Don iommu=3Dpt amdgpu.modeset=3D1 > [...] >=20 > Would you try with "iommu=3Dsoft", aka disable the hardware one? > Maybe try tuning it off entirely. Thank you for looking into this bug. I tried all combinations of amd_iommu/iommu "soft" and "off", on kernels 4.19.13, 4.20.0, and linux-mainline from last night. And I tried them all with the BIOS iommu enabled and disabled, and also leaving and removing iommu=3Dpt. In all cases the boot failed in the same way, with a black screen and compl= ete lockup so that even ssh from another terminal would not work. And unfortuna= tely none of them generated any type of boot log that I could find. In fact if y= ou delete all the /var/log/Xorg.* log files, and then try booting with the bad kernels, not even an empty Xorg.*.old log file is generated. The only log t= hat appears after I finally change back to 4.18.20 is the single Xorg.0.log from its boot. And of course there's nothing at all in journalctl. In any case I'm an embedded systems designer, but only have a cursory knowl= edge of low level Linux kernel development. However I'm willing to invest whatev= er time is necessary to help find this bug. I bought an expensive R9 390 three years ago and have only been able to fully utilize it for about six months = off and on. By the way, I'd have no problem sticking with the 4.18 kernel as everything works great with it, and I've heard that same sentiment from others. It rea= lly seems that for whatever reasons there were systemic errors introduced after= it, and they will take a substantial amount of time to fix. Our only concern is that 4.18 will soon lose support. So given the unprecedented number of prob= lems with all later kernels it may be wise to move it to LTS, and give developers more time to work on the plethora of problems they're dealing with now. --=20 You are receiving this mail because: You are the assignee for the bug.= --15471680920.5Aab00d9.5259 Date: Fri, 11 Jan 2019 00:54:51 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Commen= t # 6 on bug 10913= 5 from rmun= crief@humanavance.com 
(In reply to iive from comment #5)
> (In reply to rmuncrief from comment #2)
> [...]
> > Here's the grub line I use for all testing:
> > GRUB_CMDLINE_LINUX_DEFAULT=3D"quiet
> > resume=3DUUID=3Db4f71480-8fe3-43c2-99c9-fc3f5687545b libata.atapi=
_passthru16=3D0
> > rd.modules-load=3Dvfio-pci amd_iommu=3Don iommu=3Dpt amdgpu.modes=
et=3D1
> [...]
>=20
> Would you try with "iommu=3Dsoft", aka disable the hardware =
one?
> Maybe try tuning it off entirely.

Thank you for looking into this bug. I tried all combinations of
amd_iommu/iommu "soft" and "off", on kernels 4.19.13, 4=
.20.0, and
linux-mainline from last night. And I tried them all with the BIOS iommu
enabled and disabled, and also leaving and removing iommu=3Dpt.

In all cases the boot failed in the same way, with a black screen and compl=
ete
lockup so that even ssh from another terminal would not work. And unfortuna=
tely
none of them generated any type of boot log that I could find. In fact if y=
ou
delete all the /var/log/Xorg.* log files, and then try booting with the bad
kernels, not even an empty Xorg.*.old log file is generated. The only log t=
hat
appears after I finally change back to 4.18.20 is the single Xorg.0.log from
its boot. And of course there's nothing at all in journalctl.

In any case I'm an embedded systems designer, but only have a cursory knowl=
edge
of low level Linux kernel development. However I'm willing to invest whatev=
er
time is necessary to help find this bug. I bought an expensive R9 390 three
years ago and have only been able to fully utilize it for about six months =
off
and on.

By the way, I'd have no problem sticking with the 4.18 kernel as everything
works great with it, and I've heard that same sentiment from others. It rea=
lly
seems that for whatever reasons there were systemic errors introduced after=
 it,
and they will take a substantial amount of time to fix. Our only concern is
that 4.18 will soon lose support. So given the unprecedented number of prob=
lems
with all later kernels it may be wise to move it to LTS, and give developers
more time to work on the plethora of problems they're dealing with now.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15471680920.5Aab00d9.5259-- --===============0928753245== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0928753245==--