Date: Fri, 5 Apr 2019 07:15:14 -0700 From: Marcel Flores <marcel@brickporch.com> To: freebsd-arm@freebsd.org Subject: Re: Restore broken ThunderX support in 12 by MFCing r343764? Message-ID: <AEF036AB-D81E-4D46-BE04-E470A2B350D1@brickporch.com> In-Reply-To: <3996B352-ABFB-4CA5-A897-6C6CD1D2A132@brickporch.com> References: <20190218022911.72261m7v5l6g1i7b@webmail.omc.net> <CAPyFy2CB0T6GpR5=Am_CYnrbD5KehX3YjCtnT6gd0tHP0VPcow@mail.gmail.com> <3996B352-ABFB-4CA5-A897-6C6CD1D2A132@brickporch.com>
index | next in thread | previous in thread | raw e-mail
> On Apr 3, 2019, at 10:16 PM, Marcel Flores <marcel@brickporch.com> wrote: > > > >> On Apr 3, 2019, at 6:55 AM, Ed Maste <emaste@freebsd.org> wrote: >> >> 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.] > > stable/12 now works. In fact, the hw.syscons.disable tuneable is no longer needed either — a fresh build stable/12 appears to be working with GENERIC out of the box. Based on this thread, that doesn’t totally make sense to me, but I’m not sure what all else has made it into stable/12. > > The same can’t be said for 13, which, as of about 2 weeks ago (I can confirm later this week if that would be worthwhile), behaves as described here without it: > https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html <https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html><https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html <https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html>>; > > Since the serial console essentially hangs, I’m not sure how to get any additional information, but happy to try any suggestions. > > > The only other issues I’ve had with the ThunderX Gigabyte board I have is getting the onboard NIC to work (Seems to be about like this, looking at dmesg: https://lists.freebsd.org/pipermail/freebsd-arm/2018-April/017865.html <https://lists.freebsd.org/pipermail/freebsd-arm/2018-April/017865.html>), but I imagine this is a driver question for the Gigabyte portions, rather than an issue with the ThunderX itself. > Correction to the above — just tried to boot current/13 r345863 via USB installer, it actually gets further, sans tuneable, but gets stuck somewhere. Boot output attached. https://hastebin.com/xeteyuhome -mhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEF036AB-D81E-4D46-BE04-E470A2B350D1>