Date: Mon, 18 Feb 2019 02:29:11 +0100 From: kraileth@elderlinux.org To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Restore broken ThunderX support in 12 by MFCing r343764? Message-ID: <20190218022911.72261m7v5l6g1i7b@webmail.omc.net>
next in thread | raw e-mail | index | archive | help
Hi, FreeBSD was working well on 11.x but stopped with r336520 when vt_efifb was added to GENERIC on ARM64. As pointed out by John F Carr, all it takes to fix this locally, is setting the tunable hw.syscons.disable (https://lists.freebsd.org/pipermail/freebsd-arm/2019-February/019422.html). However -CURRENT broke _twice_ during the development phase of 12. After a few more nights of building kernels to exactly nail down the second issue, I have the commit that broke support and the one that restored it uncovered: While r338537's commit message says that it's increasing two values because of ThunderX, after the commit the kernel wouldn't boot any longer even with the tunable set. Some time later commit r343764 (targeting ThunderX2) accidentally fixed the problem for ThunderX, too. After that point setting the tunable results in a working system again. However the second commit was made after 12 was branched off and so to this day 12 is completely broken. I've confirmed that both 12-STABLE and 12.0-RELEASE work when the following patch is applied before building the kernel: ------ --- sys/arm/arm/physmem.c.orig 2019-02-17 08:47:05.675448000 +0100 +++ sys/arm/arm/physmem.c 2019-02-17 08:48:53.209050000 +0100 @@ -29,6 +29,7 @@ #include <sys/cdefs.h> __FBSDID("$FreeBSD: stable/12/sys/arm/arm/physmem.c 341760 2018-12-09 06:46:53Z mmel $"); +#include "opt_acpi.h" #include "opt_ddb.h" /* @@ -48,8 +49,13 @@ * that can be allocated, or both, depending on the exclusion flags associated * with the region. */ +#ifdef DEV_ACPI +#define MAX_HWCNT 32 /* ACPI needs more regions */ +#define MAX_EXCNT 32 +#else #define MAX_HWCNT 16 #define MAX_EXCNT 16 +#endif #if defined(__arm__) #define MAX_PHYS_ADDR 0xFFFFFFFFull ------ Not being a developer though, I cannot judge if this 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. If the changes from r343764 can be applied to 12-STABLE that would mean a future 12.1 could run on ThunderX again. If not, the reference platform for server-class ARM64 would be broken in all of 12 which would be rather unfortunate. Is there a chance to get the fix into 12-STABLE? Regards, Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190218022911.72261m7v5l6g1i7b>