From owner-freebsd-stable@freebsd.org Tue Sep 11 18:16:09 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 783641098A3F for ; Tue, 11 Sep 2018 18:16:09 +0000 (UTC) (envelope-from clmoonriver@equinefiction.com) Received: from MTA-05-3.privateemail.com (mta-05-3.privateemail.com [68.65.122.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "privateemail.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17D2A8229D for ; Tue, 11 Sep 2018 18:16:08 +0000 (UTC) (envelope-from clmoonriver@equinefiction.com) Received: from MTA-05.privateemail.com (localhost [127.0.0.1]) by MTA-05.privateemail.com (Postfix) with ESMTP id BF58B60051; Tue, 11 Sep 2018 14:16:06 -0400 (EDT) Received: from wildfire.equinefiction.com (unknown [10.20.151.248]) by MTA-05.privateemail.com (Postfix) with ESMTPA id 31F6060050; Tue, 11 Sep 2018 18:16:06 +0000 (UTC) Date: Tue, 11 Sep 2018 13:16:03 -0500 From: CL Moonriver To: Pete Wright Cc: Pete French , 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: <4e71d1a8-ff74-c1c0-9369-826b2a054802@ingresso.co.uk> <039a719c-8706-fb76-8866-662379430683@nomadlogic.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 18:16:09 -0000 > 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.)