Re: install/49470

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR port-amd64/49470; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: install/49470
Date: Mon, 22 Jul 2024 09:51:06 +0300

 On Mon, Jul 22, 2024 at 9:40=E2=80=AFAM Andrius V <vezhlys%gmail.com@localhost> wrote=
 :
 >
 > Hi,
 >
 > On Tue, Jul 2, 2024 at 1:53=E2=80=AFPM Andrius V <vezhlys%gmail.com@localhost> wrot=
 e:
 >
 > Initial analysis:
 > The issue seems to have started with switch to gcc 4.8
 > (https://github.com/NetBSD/src/commit/ad33dd774c2fe8beb41c96d1d29aef4ebce=
 3f5cb
 > and https://github.com/NetBSD/src/commit/f8008b9438a836d85ee0b14cb56ee829=
 66fd8216).
 >
 > It prints this log and reboots:
 > booting hd0a:netbsd (howto 0xa0000)
 > 22005524+593000+742296 [1003696+1091430+13604]=3D0x1846608
 > [   1.0000000] cpu_rng: via
 > [   1.0000000] pmap_kenter_pa: mapping already present
 >
 > It reboots on memcpy() call, I assume because both source and
 > destination pointers are NULL (printed them out for testing):
 > https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf35=
 80/sys/kern/subr_kcpuset.c#L351
 > which in turn was called from pmap_tlb_shootdown() ->
 > kcpuset_copy(ci->ci_tlb_cpuset, kcpuset_running)
 > https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf35=
 80/sys/arch/x86/x86/x86_tlb.c#L289
 > And finally shootdown was called from kenter funciton -
 > pmap_kenter_pa() in the "/* This should not happen. */" path:
 > https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf35=
 80/sys/arch/x86/x86/pmap.c#L1056
 >
 > This typically happens if arguments are passed to the boot command
 > (e.g. boot netbsd or boot netbsd -vx), but boots properly without
 > passing the kernel (e.g. boot or boot -vx), but it's not always the
 > case for all my setups (it is an opposite in one setup, where system
 > is installed in sd media (a bit older release)). If it boots, it
 > doesn't enter the unexpected path in kenter function.
 
 To complement this, for ACPI v2.0, it also enters the condition but
 values are not null for memcpy and crash doesn't happen.
 
 >
 > It happens only if ACPI version is set to v3.0 in BIOS. It boots in
 > all combinations I have tried if ACPI version is set to v2.0 or v1.0.
 >
 > I see it is likely at least two issues:
 > No checks before memcpy() or kcpuset_copy() that values are null and I
 > guess some additional asserts are needed here as a band-aid before one
 > of these calls?
 >
 > Another issue is the root cause why this unintended path is taken,
 > somehow related to ACPI version and boot command. Is it also some kind
 > of undesirable optimization, maybe CPU bug or something else, I still
 > need to understand.
 >
 > Regards,
 > Andrius V