head -r357356: fails to boot RPi4 but boots Rock64 (same media, moved between machines); -r356426 booted both

[Mark Millard]

[head -r357392 made no difference in the failure sequence
for booting the RPi4B.]

On 2020-Feb-1, at 16:11, Mark Millard <marklmi at yahoo.com> wrote:



> On 2020-Feb-1, at 14:25, Andreas Tobler <andreast-list at fgznet.ch> wrote:
> 
>> On 01.02.20 12:58, Mark Millard via freebsd-arm wrote:
>>> I had a working head -r356426 based microSD card that booted
>>> both the Rock64 and the RPi4.
>>> I upgraded it to be based on head -r357356 .
>>> Now the RPi4B hangs up during boot and does not start its APs.
>>> But the Rock64 boots fine via the same media.
>>> Diffing RPi4B console logs for -r356426 vs. -r357356 shows
>>> -r357356 shw the following as the only types of
>>> textual differences:
>>> psci0: PSCI version number mismatched with DT
>>> device_attach: psci0 attach returned 6
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number mismatched with DT
>>> device_attach: psci0 attach returned 6
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number mismatched with DT
>>> device_attach: psci0 attach returned 6
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number mismatched with DT
>>> device_attach: psci0 attach returned 6
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number mismatched with DT
>>> device_attach: psci0 attach returned 6
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number mismatched with DT
>>> device_attach: psci0 attach returned 6
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number mismatched with DT
>>> device_attach: psci0 attach returned 6
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number mismatched with DT
>>> (More blocks of 3 such lines at a time happen later as well.)
>> 
>> I see the same on a rpi3b+. Try r356775, r356776 is the breaking commit for me.

I still get the above sort of thing from -r357392
(non-debug kernel, as I usually run).

I also still get "APs not started" and the like.

The fix seems to have made no difference for this issue.
If -r356775 really works, then there is more to the
-r356776 story.

> Looks like head -r357392 is an intended fix
> to head -r356776 :
> 
> Author: jeff
> Date: Sat Feb  1 23:46:30 2020
> New Revision: 357392
> URL: 
> https://svnweb.freebsd.org/changeset/base/357392
> 
> 
> Log:
>  Fix a bug in r356776 where the page allocator was not properly restored to
>  the percpu page allocator after it had been temporarily overridden by
>  startup_alloc.
> 
>  Reported by:	pho, bdragon
> 
> Modified:
>  head/sys/vm/uma_core.c
> 
> Modified: head/sys/vm/uma_core.c
> ==============================================================================
> --- head/sys/vm/uma_core.c	Sat Feb  1 23:16:30 2020	(r357391)
> +++ head/sys/vm/uma_core.c	Sat Feb  1 23:46:30 2020	(r357392)
> @@ -2101,7 +2101,9 @@ zone_kva_available(uma_zone_t zone, void *unused)
> 	if ((zone->uz_flags & UMA_ZFLAG_CACHE) != 0)
> 		return;
> 	KEG_GET(zone, keg);
> -	if (keg->uk_allocf == startup_alloc)
> +	if (keg->uk_flags & UMA_ZONE_PCPU)
> +		keg->uk_allocf = pcpu_page_alloc;
> +	else if (keg->uk_allocf == startup_alloc)
> 		keg->uk_allocf = page_alloc;
> }
> 
> 
> I'll probably try it later today sometime.
> 

I tried -r357392 for the RPi4B boot issue, but it
was not a solution.

The fix may well be a solution to some other
issue(s).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)