Date: Wed, 3 Apr 2019 09:55:42 -0400 From: Ed Maste <emaste@freebsd.org> To: kraileth@elderlinux.org Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Restore broken ThunderX support in 12 by MFCing r343764? Message-ID: <CAPyFy2CB0T6GpR5=Am_CYnrbD5KehX3YjCtnT6gd0tHP0VPcow@mail.gmail.com> In-Reply-To: <20190218022911.72261m7v5l6g1i7b@webmail.omc.net> References: <20190218022911.72261m7v5l6g1i7b@webmail.omc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Feb 2019 at 20:29, <kraileth@elderlinux.org> wrote: > > Not being a developer though, I cannot judge if [r343764] cannot be MFC'd > into 12-STABLE due to making invasive changes or if it simply never > was because it was thought to be an improvement for 13 only and not an > actually pretty vital fix for 12. I suspect jchandra@ just didn't realize it's needed also on ThunderX, and I did not encounter any trouble with the ThunderX systems I have. It could just be that our (older) ThunderX reference firmware has fewer regions in its ACPI info and so works fine without r343764. Anyhow I've now merged the change to stable/12. With respect to vt_efifb the tunable is a simple workaround, but we really need this to work out-of-the-box. Do you have any further details on the failure when vt_efifb is enabled? Also, if you're aware of any other ThunderX issues please let me know.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2CB0T6GpR5=Am_CYnrbD5KehX3YjCtnT6gd0tHP0VPcow>