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 <j...@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 <ch...@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@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
