Date: Wed, 6 Apr 2022 16:37:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: Free BSD <freebsd-arm@freebsd.org>, "freebsd-acpi@freebsd.org" <freebsd-acpi@FreeBSD.org> Cc: Andrew Turner <andrew@freebsd.org> Subject: Re: https://github.com/pftf/RPi3 UEFI/ACPI based booting: gic_acpi_identify crashes dereferencing a NULL pointer value Message-ID: <ADBE6385-1DEA-4D54-A0EE-9007A414F315@yahoo.com> In-Reply-To: <6609AB07-942C-4E06-A99A-2B3A0D65D970@yahoo.com> References: <6609AB07-942C-4E06-A99A-2B3A0D65D970@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Apr-6, at 01:01, Mark Millard <marklmi@yahoo.com> wrote: > https://github.com/pftf/RPi3 UEFI/ACPI use gets a boot crash in > FreeBSD's gic_acpi_identify: >=20 > . . . > MAP 1d0000 mode 2 pages 32 > MAP 339d0000 mode 2 pages 80 > MAP 33a20000 mode 2 pages 256 > MAP 37000000 mode 2 pages 400 > MAP 37190000 mode 2 pages 592 > kbd0 at kbdmux0 > acpi0: <BC2836 RPI3> > acpi0: Power Button (fixed) > acpi0: Could not update all GPEs: AE_NOT_CONFIGURED > psci0: <ARM Power State Co-ordination Interface Driver> on acpi0 > Fatal data abort: > x0: ffff000086ffe6b4 (crypto_dev + 858f044c) > x1: ffff00000103d0d0 (initstack + 30d0) > x2: ffff00000080ed2c (madt_handler + 0) > x3: ffff00000103d0d0 (initstack + 30d0) > x4: d2d9fffc > x5: 0 > x6: ffffffffffffffff > x7: 2001 > x8: 0 > x9: 400 > x10: 800 > x11: 0 > x12: ffff00000103d8dc (initstack + 38dc) > x13: b6 > x14: 551 > x15: 16c > x16: 0 > x17: 1 > x18: ffff00000103d0d0 (initstack + 30d0) > x19: ffff000086ffe598 (crypto_dev + 858f0330) > x20: ffffa00000dba200 > x21: ffff00000103d0e0 (initstack + 30e0) > x22: ffffa00000c37a40 > x23: ffff000000ec8000 (devsoftc + 88) > x24: ffff00000097fe1a (digits + 102f6) > x25: 3800000 > x26: ffff000000e74000 (gdb_tx_u + a98) > x27: ffff000000e74000 (gdb_tx_u + a98) > x28: ffff00004042bd28 (crypto_dev + 3ed1dac0) > x29: ffff00000103d8e0 (initstack + 38e0) > sp: ffff00000103d0d0 > lr: ffff00000080e908 (gic_acpi_identify + 7c) > elr: ffff00000080e90c (gic_acpi_identify + 80) > spsr: 600000c5 > far: 14 > esr: 96000004 > panic: vm_fault failed: ffff00000080e90c error 1 > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x178 > panic() at panic+0x44 > data_abort() at data_abort+0x2bc > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000004 > gic_acpi_identify() at gic_acpi_identify+0x80 > bus_generic_new_pass() at bus_generic_new_pass+0x44 > bus_generic_new_pass() at bus_generic_new_pass+0xb0 > bus_generic_new_pass() at bus_generic_new_pass+0xb0 > root_bus_configure() at root_bus_configure+0x40 > mi_startup() at mi_startup+0x224 > virtdone() at virtdone+0x7c > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x48: undefined f901c11f >=20 > This turns out to have gic_acpi_identify+0x80 > with the code shown below: >=20 > ffff00000080e904 <gic_acpi_identify+0x78> bl ffff00000011d640 = <acpi_walk_subtables> > ffff00000080e908 <gic_acpi_identify+0x7c> ldr x8, [sp, #8] > ffff00000080e90c <gic_acpi_identify+0x80> ldrb w8, [x8, #20] >=20 > and the register dump above shows: >=20 > x8: 0 >=20 > Looking up the source ( sys/arm/arm/gic_acpi.c ) there is > the likes of: >=20 > struct madt_table_data { > device_t parent; > ACPI_MADT_GENERIC_DISTRIBUTOR *dist; > ACPI_MADT_GENERIC_INTERRUPT *intr[MAXCPU]; > }; > . . . > bzero(&madt_data, sizeof(madt_data)); > madt_data.parent =3D parent; > madt_data.dist =3D NULL; >=20 > acpi_walk_subtables(madt + 1, (char *)madt + = madt->Header.Length, > madt_handler, &madt_data); >=20 > /* Check the version of the GIC we have */ > switch (madt_data.dist->Version) { >=20 > So it appears that madt_data.dist held a NULL pointer value > that was not checked for. (I've no clue if such a NULL is > supposed to be possible --but I do know it occured.) >=20 > The following lines are: >=20 > case ACPI_MADT_GIC_VERSION_NONE: > case ACPI_MADT_GIC_VERSION_V1: > case ACPI_MADT_GIC_VERSION_V2: > break; > default: > goto out; > } > . . . > out: > acpi_unmap_table(madt); > } >=20 > That might suggest that madt_data.dist=3D=3DNULL should lead to > a "goto out". >=20 >=20 QUOTE ( https://en.wikipedia.org/wiki/Raspberry_Pi ) The Raspberry Pi 4 uses a Broadcom BCM2711 SoC . . . Unlike previous = models, which all used a custom interrupt controller poorly suited for = virtualisation, the interrupt controller on this SoC is compatible with = the ARM Generic Interrupt Controller (GIC) architecture 2.0, providing = hardware support for interrupt distribution when using ARM = virtualisation capabilities. END QUOTE So it looks like the madt_data.dist=3D=3DNULL corresponds to there not being a GIC of any version present to find in MADT for an RPi3. I'll note that the value ACPI_MADT_GIC_VERSION_NONE is listed in ACPI_Spec_6_4_Jan22.pdf as: QUOTE 0x00: No GIC version is specified, fall back to hardware discovery for = GIC version END QUOTE I'd take that wording as still presuming the presence of a GIC to do version discovery with. If true, the madt_data.dist=3D=3DNULL for the RPi3B may well be the way to indicate that no GIC is present to even do hardware version discovery with. FreeBSD may well not want to support https://github.com/pftf/RPi3 use in ACPI mode. But it still may want to avoid a non-obvious crash as the means of rejecting the ACPI it is provided. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ADBE6385-1DEA-4D54-A0EE-9007A414F315>