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"
Jan Martin Mikkelsen
2019-May-31 14:19 UTC
efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)
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"