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"
Konstantin Belousov
2019-May-31 18:35 UTC
efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)
On Fri, May 31, 2019 at 04:19:57PM +0200, Jan Martin Mikkelsen wrote:> 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.Try this. Only compile-time tested. diff --git a/sys/amd64/amd64/efirt_support.S b/sys/amd64/amd64/efirt_support.S index cd578eddcfb..b54b13b01fe 100644 --- a/sys/amd64/amd64/efirt_support.S +++ b/sys/amd64/amd64/efirt_support.S @@ -47,6 +47,9 @@ ENTRY(efi_rt_arch_call) movq %r13, EC_R13(%rdi) movq %r14, EC_R14(%rdi) movq %r15, EC_R15(%rdi) + pushfq + popq %rax + movq %rax, EC_RFLAGS(%rdi) movq PCPU(CURTHREAD), %rax movq %rdi, TD_MD+MD_EFIRT_TMP(%rax) movq PCPU(CURPCB), %rsi @@ -98,6 +101,8 @@ efi_rt_arch_call_tail: movq EC_RBP(%rdi), %rbp movq EC_RSP(%rdi), %rsp movq EC_RBX(%rdi), %rbx + pushq EC_RFLAGS(%rdi) + popfq popq %rbp ret diff --git a/sys/amd64/amd64/genassym.c b/sys/amd64/amd64/genassym.c index de3969734a1..2e81b823262 100644 --- a/sys/amd64/amd64/genassym.c +++ b/sys/amd64/amd64/genassym.c @@ -272,3 +272,4 @@ ASSYM(EC_R12, offsetof(struct efirt_callinfo, ec_r12)); ASSYM(EC_R13, offsetof(struct efirt_callinfo, ec_r13)); ASSYM(EC_R14, offsetof(struct efirt_callinfo, ec_r14)); ASSYM(EC_R15, offsetof(struct efirt_callinfo, ec_r15)); +ASSYM(EC_RFLAGS, offsetof(struct efirt_callinfo, ec_rflags)); diff --git a/sys/amd64/include/efi.h b/sys/amd64/include/efi.h index 082223792ac..e630a338c17 100644 --- a/sys/amd64/include/efi.h +++ b/sys/amd64/include/efi.h @@ -72,6 +72,7 @@ struct efirt_callinfo { register_t ec_r13; register_t ec_r14; register_t ec_r15; + register_t ec_rflags; }; #endif /* __AMD64_INCLUDE_EFI_H_ */
Jan Martin Mikkelsen
2019-Jun-03 09:53 UTC
efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)
Hi, This patch resolves the panic when booting without efi.rt.disabled=1 for me. Thanks! Jan M.> On 31 May 2019, at 20:35, Konstantin Belousov <kib at freebsd.org> wrote: > > On Fri, May 31, 2019 at 04:19:57PM +0200, Jan Martin Mikkelsen wrote: >> 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. > > Try this. Only compile-time tested. > > diff --git a/sys/amd64/amd64/efirt_support.S b/sys/amd64/amd64/efirt_support.S > index cd578eddcfb..b54b13b01fe 100644 > --- a/sys/amd64/amd64/efirt_support.S > +++ b/sys/amd64/amd64/efirt_support.S > @@ -47,6 +47,9 @@ ENTRY(efi_rt_arch_call) > movq %r13, EC_R13(%rdi) > movq %r14, EC_R14(%rdi) > movq %r15, EC_R15(%rdi) > + pushfq > + popq %rax > + movq %rax, EC_RFLAGS(%rdi) > movq PCPU(CURTHREAD), %rax > movq %rdi, TD_MD+MD_EFIRT_TMP(%rax) > movq PCPU(CURPCB), %rsi > @@ -98,6 +101,8 @@ efi_rt_arch_call_tail: > movq EC_RBP(%rdi), %rbp > movq EC_RSP(%rdi), %rsp > movq EC_RBX(%rdi), %rbx > + pushq EC_RFLAGS(%rdi) > + popfq > > popq %rbp > ret > diff --git a/sys/amd64/amd64/genassym.c b/sys/amd64/amd64/genassym.c > index de3969734a1..2e81b823262 100644 > --- a/sys/amd64/amd64/genassym.c > +++ b/sys/amd64/amd64/genassym.c > @@ -272,3 +272,4 @@ ASSYM(EC_R12, offsetof(struct efirt_callinfo, ec_r12)); > ASSYM(EC_R13, offsetof(struct efirt_callinfo, ec_r13)); > ASSYM(EC_R14, offsetof(struct efirt_callinfo, ec_r14)); > ASSYM(EC_R15, offsetof(struct efirt_callinfo, ec_r15)); > +ASSYM(EC_RFLAGS, offsetof(struct efirt_callinfo, ec_rflags)); > diff --git a/sys/amd64/include/efi.h b/sys/amd64/include/efi.h > index 082223792ac..e630a338c17 100644 > --- a/sys/amd64/include/efi.h > +++ b/sys/amd64/include/efi.h > @@ -72,6 +72,7 @@ struct efirt_callinfo { > register_t ec_r13; > register_t ec_r14; > register_t ec_r15; > + register_t ec_rflags; > }; > > #endif /* __AMD64_INCLUDE_EFI_H_ */ > _______________________________________________ > 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"