Date: Tue, 11 Sep 2018 13:16:03 -0500 From: CL Moonriver <clmoonriver@equinefiction.com> To: Pete Wright <pete@nomadlogic.org> Cc: Pete French <petefrench@ingresso.co.uk>, freebsd-stable@freebsd.org Subject: Re: Using drm-next in 11.2 Message-ID: <20180911131603.7084fb38@wildfire.equinefiction.com> In-Reply-To: <039a719c-8706-fb76-8866-662379430683@nomadlogic.org> References: <E1fzi7c-0000z2-32@dilbert.ingresso.co.uk> <CAPS9%2BSvNT7fAsbM_Nrdde32ngdcZibW6%2B4pxCdg9JHgyktyaoA@mail.gmail.com> <4e71d1a8-ff74-c1c0-9369-826b2a054802@ingresso.co.uk> <b85e8a70-0962-871d-ce3e-9b9f14e4ca2c@ingresso.co.uk> <039a719c-8706-fb76-8866-662379430683@nomadlogic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> also, please ensure you are booting in "classic" BIOS mode and not > UEFI, IIRC there are some issues surrounding amdgpu with UEFI - i > don't have that hardware tho so can't elaborate. Just to add to this, the conflicts involve kernel mode switching between the scfb driver and the AMD driver. However, there are work arounds for it. And in all honesty, with AMD A10 series CPU, I've actually found it easier to get things working properly in UEFI mode instead of classic / legacy / bios mode. The work around (as I learned from a thread in the x11 mailing lists) involves disabling the system console completely by adding hw.syscons.disable=1 to /boot/loader.conf. Obviously, this is not without some risk. But it does work for me. And I have had no problems at all with radeonkms.ko since doing this. (The only problem I had before adding this was the occasional X server hang where the GPU had to be restarted. But even that problem is gone now.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180911131603.7084fb38>