Date: Fri, 31 May 2019 16:19:57 +0200 From: Jan Martin Mikkelsen <janm@transactionware.com> To: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Cc: Christian Ullrich <chris@chrullrich.net> Subject: efirtc causing panic (was Re: Panic booting 12-RC2 on amd64) Message-ID: <7E738A9B-A0B6-49D3-86A8-8E2F9ED8A098@transactionware.com> In-Reply-To: <187B6A1E-5C61-415A-A9F2-B4E3142375C7@transactionware.com> References: <6e985fa2-c372-67ef-1cd5-dd8894cca908@chrullrich.net> <187B6A1E-5C61-415A-A9F2-B4E3142375C7@transactionware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Christian has pointed me at this = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233534 which he = raised after his email. The workaround was to boot with = =E2=80=9Cefi.rt.disabled=3D1=E2=80=9D.=20 I took a closer look at what is going on. The problem is that the EFI = rt_gettime call is faulting, and the fault is handled in efirt_support.S = and a failure is reported. These messages is in the kernel output: kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled EFI rt_gettime call faulted, error 14 efirtc0: cannot read EFI realtime clock, error 14 So far, so good. The problem is that that later in startup the = "smp_targeted_tlb_shootdown: interrupts disabled=E2=80=9D panic occurs, = if the SMP is enabled. With SMP disabled this does not occur and the = system runs. I=E2=80=99m not sure whether this is a BIOS problem (seems likely) or = something that could handled after dealing with the fault in = efirt_support.S. While looking I found the code below that looks wrong in efi_enter(), = but that is not the problem in this case. Just adding this to the archive in case someone else looks more closely = later. Regards, Jan M. --- a/src/sys/dev/efidev/efirt.c 2018-11-19 15:43:47.000000000 = 1100 +++ b/src/sys/dev/efidev/efirt.c 2018-11-19 15:43:47.000000000 = 1100 @@ -245,6 +245,7 @@ static int efi_enter(void) { + int error; struct thread *td; pmap_t curpmap; =20 @@ -255,7 +256,14 @@ PMAP_LOCK(curpmap); mtx_lock(&efi_lock); fpu_kern_enter(td, NULL, FPU_KERN_NOCTX); - return (efi_arch_enter()); + error =3D efi_arch_enter(); + if (error !=3D 0) { + fpu_kern_leave(td, NULL); + mtx_unlock(&efi_lock); + PMAP_UNLOCK(curpmap); + } + + return (error); } =20 static void > On 31 May 2019, at 12:26, Jan Martin Mikkelsen = <janm@transactionware.com> wrote: >=20 > Hi, >=20 > I see exactly the same stacktrace on a Celeron J1900 based system with = 12.0-p5 when using a UEFI boot. With a non-UEFI boot it works fine = (except vt not working until the new 915kms.ko is loaded). With safe = mode on it also works fine. >=20 > Did you find any more information? >=20 > Regards, >=20 > Jan. >=20 >> On 25 Nov 2018, at 19:26, Christian Ullrich <chris@chrullrich.net> = wrote: >>=20 >> Hello, >>=20 >> I have a reproducible panic booting 12-RC2 and stable/12, 2cf4a7e0d8=20= >> from Friday, on a Jetway JNF9HG board, Celeron N2930 CPU, booting = with=20 >> UEFI. The same box has no problems with stable/11 18f83cbbc9 from = Thursday. >>=20 >> There is no serial console on the box right now, but the last = screenful=20 >> of boot output is this (from the -RC2; the panic'ing symbol is the = same=20 >> with the stable/12 kernel): >>=20 >> random: entropy device external interface >> kbd1 at kbdmux0 >> netmap: loaded module >> [ath_hal] loaded >> module_register_init: MOD_LOAD (vesa, 0xffffffff810f8750, 0) error 19 >> random: registering fast source Intel Secure Key RNG >> random: fast provider: "Intel Secure Key RNG" >> nexus0 >> kernel trap 12 with interrupts disabled >> kernel trap 12 with interrupts disabled >> cryptosoft0: <software crypto> on motherboard >> acpi0: <_> on motherboard >> panic: smp_targeted_tlb_shootdown: interrupts disabled >> cpuid =3D 2 >> time =3D 1 >> KDB: stack backtrace: >> #0 0xffffffff80be74a7 at kdb_backtrace+0x67 >> #1 0xffffffff80b9b093 at vpanic+0x1a3 >> #2 0xffffffff80b9aee3 at panic+0x43 >> #3 0xffffffff811eda2f at smp_targeted_tlb_shootdown+0x40f >> #4 0xffffffff811ed60d at smp_masked_invltlb+0x3d >> #5 0xffffffff8105d5c5 at pmap_invalidate_range+0x1b5 >> #6 0xffffffff8106a429 at pmap_change_attr_locked+0x859 >> #7 0xffffffff81069804 at pmap_mapdev_internal+0x424 >> #8 0xffffffff81075ed0 at pcie_cfgregopen+0x60 >> #9 0xffffffff80451f10 at acpi_attach+0x390 >> #10 0xffffffff80bd6efc at device_attach+0x3ec >> #11 0xffffffff80bd81dc at bus_generic_attach+0x5c >> #12 0xffffffff80bd6efc at device_attach+0x3ec [sic!] >> #13 0xffffffff80bd88b8 at bus_generic_new_pass+0x118 >> #14 0xffffffff80bda577 at root_bus_configure+0x77 >> #15 0xffffffff811dbce9 at configure+0x9 >> #16 0xffffffff80b31a78 at mi_startup+0x118 >> #17 0xffffffff8034102c at btext+0x2c >> Uptime: 1s >> Automatic reboot in 15 seconds - press a key on the console to abort >>=20 >> If it matters, the build from svn was with CPUTYPE=3Dslm, the -RC2 is=20= >> FreeBSD-12.0-RC2-amd64-mini-memstick.img, i.e. without CPUTYPE. I = have=20 >> been running stable/11 with CPUTYPE=3Dslm on this and other identical = CPUs=20 >> for a long time with no trouble, so I think it is unrelated. >>=20 >> I'd really like to upgrade to 12. If anyone can suggest something I = can=20 >> try, I'll be happy to do experiments. >>=20 >> --=20 >> Christian >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7E738A9B-A0B6-49D3-86A8-8E2F9ED8A098>