efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)

[Jan Martin Mikkelsen]

Hi,

Christian has pointed me at this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233534 which he raised after his email. The workaround was to boot with “efi.rt.disabled=1”. 

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” panic occurs, if the SMP is enabled. With SMP disabled this does not occur and the system runs.

I’m 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;
 
@@ -255,7 +256,14 @@
 	PMAP_LOCK(curpmap);
 	mtx_lock(&efi_lock);
 	fpu_kern_enter(td, NULL, FPU_KERN_NOCTX);
-	return (efi_arch_enter());
+	error = efi_arch_enter();
+	if (error != 0) {
+		fpu_kern_leave(td, NULL);
+		mtx_unlock(&efi_lock);
+		PMAP_UNLOCK(curpmap);
+	}
+
+	return (error);
 }
 
 static void


> On 31 May 2019, at 12:26, Jan Martin Mikkelsen <janm at transactionware.com> wrote:
> 
> Hi,
> 
> 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.
> 
> Did you find any more information?
> 
> Regards,
> 
> Jan.
> 
>> On 25 Nov 2018, at 19:26, Christian Ullrich <chris at chrullrich.net> wrote:
>> 
>> Hello,
>> 
>> I have a reproducible panic booting 12-RC2 and stable/12, 2cf4a7e0d8 
>> from Friday, on a Jetway JNF9HG board, Celeron N2930 CPU, booting with 
>> UEFI. The same box has no problems with stable/11 18f83cbbc9 from Thursday.
>> 
>> There is no serial console on the box right now, but the last screenful 
>> of boot output is this (from the -RC2; the panic'ing symbol is the same 
>> with the stable/12 kernel):
>> 
>> 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 = 2
>> time = 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
>> 
>> If it matters, the build from svn was with CPUTYPE=slm, the -RC2 is 
>> FreeBSD-12.0-RC2-amd64-mini-memstick.img, i.e. without CPUTYPE. I have 
>> been running stable/11 with CPUTYPE=slm on this and other identical CPUs 
>> for a long time with no trouble, so I think it is unrelated.
>> 
>> I'd really like to upgrade to 12. If anyone can suggest something I can 
>> try, I'll be happy to do experiments.
>> 
>> -- 
>> Christian
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"