Restore broken ThunderX support in 12 by MFCing r343764?

[Rodney W. Grimes]

> 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

I am cc'ing this to the developer who made commit 343764,

Is there any reason that this can not be merged to stable/12?
We don't issue errata for this platform, but at least this
should fix the weekly snapshots that are built.

Michael, have you tried any of the stable/12 snapshots?
Would you be willing to confirm that they are broken in the
same way, perhaps waiting after the response from the developer,
as if this is mergable that would be pointless to test what
we know to be broken.

-- 
Rod Grimes                                                 rgrimes at freebsd.org