Date: Sat, 1 Feb 2020 20:54:41 -0800 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: head -r357356: fails to boot RPi4 but boots Rock64 (same media, moved between machines); -r356426 booted both Message-ID: <1833F4B9-BD56-466D-AF64-7C5E63FBF46C@yahoo.com> In-Reply-To: <E74D74DA-5436-4B3A-9075-3897357963C7@googlemail.com> References: <63205335-8E8A-4CCB-BC80-E4EC767FBC09.ref@yahoo.com> <63205335-8E8A-4CCB-BC80-E4EC767FBC09@yahoo.com> <e083e017-af5a-e219-3a3c-bc82b16c6027@fgznet.ch> <62250B30-E1F6-470D-BB84-F9565D063A06@yahoo.com> <78694513-66DE-4616-91C0-896D99C97B33@yahoo.com> <E74D74DA-5436-4B3A-9075-3897357963C7@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Feb-1, at 20:32, Klaus K=C3=BCchemann <maciphone2 at = googlemail.com> wrote: >> Am 02.02.2020 um 05:28 schrieb Mark Millard <marklmi@yahoo.com>: >>=20 >> [head -r357392 made no difference in the failure sequence >> for booting the RPi4B.] >>=20 >> On 2020-Feb-1, at 16:11, Mark Millard <marklmi at yahoo.com> wrote: >>=20 >>=20 >>=20 >>> On 2020-Feb-1, at 14:25, Andreas Tobler <andreast-list at fgznet.ch> = wrote: >>>=20 >>>> 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.) >>>>=20 >>>> I see the same on a rpi3b+. Try r356775, r356776 is the breaking = commit for me. >>=20 >> I still get the above sort of thing from -r357392 >> (non-debug kernel, as I usually run). >>=20 >> I also still get "APs not started" and the like. >>=20 >> The fix seems to have made no difference for this issue. >> If -r356775 really works, then there is more to the >> -r356776 story. >>=20 >>> Looks like head -r357392 is an intended fix >>> to head -r356776 : >>>=20 >>> Author: jeff >>> Date: Sat Feb 1 23:46:30 2020 >>> New Revision: 357392 >>> URL:=20 >>> https://svnweb.freebsd.org/changeset/base/357392 >>>=20 >>>=20 >>> 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. >>>=20 >>> Reported by: pho, bdragon >>>=20 >>> Modified: >>> head/sys/vm/uma_core.c >>>=20 >>> Modified: head/sys/vm/uma_core.c >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> --- 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) !=3D 0) >>> return; >>> KEG_GET(zone, keg); >>> - if (keg->uk_allocf =3D=3D startup_alloc) >>> + if (keg->uk_flags & UMA_ZONE_PCPU) >>> + keg->uk_allocf =3D pcpu_page_alloc; >>> + else if (keg->uk_allocf =3D=3D startup_alloc) >>> keg->uk_allocf =3D page_alloc; >>> } >>>=20 >>>=20 >>> I'll probably try it later today sometime. >>>=20 >>=20 >> I tried -r357392 for the RPi4B boot issue, but it >> was not a solution. >>=20 >> The fix may well be a solution to some other >> issue(s). >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >=20 > That was my guess because there=E2=80=99s nothing directly related to = mmc issue in the code =E2=80=A6 , > Thanks for reporting ! >=20 I keep saying that the "APs not started" issue (for example) is likely not an mmc issue at all. I got no noticeable behavior change in any direction. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1833F4B9-BD56-466D-AF64-7C5E63FBF46C>