Date: Mon, 13 Jul 2020 19:42:50 -0700 From: Mark Millard <marklmi@yahoo.com> To: "mmel@freebsd.org" <mmel@FreeBSD.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Rock64 head -r363021 -> -r363123 kernel upgrade: hangs after "rk_tsadc0: <RockChip temperature sensors> mem ... irq 22 on ofwbus0" Message-ID: <78EA1B36-904C-4CB5-89D1-D6873F4EB981@yahoo.com> In-Reply-To: <DCA57F06-4735-4A68-8201-C48A25B937C6@yahoo.com> References: <7BB9973C-CCC4-4599-98D5-864BEBECE3DF@yahoo.com> <DCA57F06-4735-4A68-8201-C48A25B937C6@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jul-13, at 02:10, Mark Millard <marklmi at yahoo.com> wrote: > On 2020-Jul-13, at 00:59, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> With boot -v the kernel crashes instead of being >> silently-hung: >>=20 >> . . . >> generic_timer0: <ARMv8 Generic Timer> irq 4,5,6,7 on ofwbus0 >> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 >> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >> rk_tsadc0: <RockChip temperature sensors> mem 0xff250000-0xff2500ff = irq 22 on ofwbus0 >> panic: stack overflow detected; backtrace may be corrupted >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: > . . . >=20 > Trying artifact.ci.freebsd.org debug kernels > for an approximate bisect: >=20 > -r363121 works. > -r363122 has no aarch64 artifacts. > -r363123 fails. >=20 > (So the specifics of my personal builds are > not involved.) >=20 >=20 > -r363122 is: >=20 > Author: mmel > Date: Sun Jul 12 07:42:21 2020 > New Revision: 363122 > URL:=20 > https://svnweb.freebsd.org/changeset/base/363122 >=20 > Log: > Assigned clocks: fix off-by-one bug, don't leak allocated memory. >=20 > MFC after: 1 week > . . . >=20 >=20 > -r363123 is: >=20 > Author: mmel > Date: Sun Jul 12 07:59:15 2020 > New Revision: 363123 > URL:=20 > https://svnweb.freebsd.org/changeset/base/363123 >=20 > Log: > Reverse the processing order of assigned clocks property. > Linux processes these clocks in reverse order and some DT relies > on this fact. For example, the frequency setting for a given PLL > is the last in the list, preceded by the frequency setting of its > following divider or so... >=20 > MFC after: 1 week >=20 > . . . >=20 Updating from: U-Boot TPL 2020.04 (Apr 25 2020 - 07:18:42) U-Boot SPL 2020.04 (Apr 25 2020 - 07:18:42 +0000) U-Boot 2020.04 (Apr 25 2020 - 07:19:22 +0000) to sysutils/u-boot-rock64 and sysutils/u-boot-master producing : U-Boot TPL 2020.07 (Jul 13 2020 - 18:51:17) U-Boot SPL 2020.07 (Jul 13 2020 - 18:51:17 +0000) U-Boot 2020.07 (Jul 13 2020 - 18:56:13 +0000) made no difference when installed and tested. (The detailed last-messasge point does seem to vary generally, so I've not considered that when comparing. It still hangs up with the updated sysutils/u-boot-rock64 related materials.) =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?78EA1B36-904C-4CB5-89D1-D6873F4EB981>