Re: 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 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)
> movqPCPU(CURTHREAD), %rax
> movq%rdi, TD_MD+MD_EFIRT_TMP(%rax)
> movqPCPU(CURPCB), %rsi
> @@ -98,6 +101,8 @@ efi_rt_arch_call_tail:
> movqEC_RBP(%rdi), %rbp
> movqEC_RSP(%rdi), %rsp
> movqEC_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@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"
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.c2018-11-19 15:43:47.0 1100
+++ b/src/sys/dev/efidev/efirt.c2018-11-19 15:43:47.0 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(_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(_lock);
+ PMAP_UNLOCK(curpmap);
+ }
+
+ return (error);
}
static void
> On 31 May 2019, at 12:26, Jan Martin Mikkelsen
> 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 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, 0x810f8750, 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: on motherboard
>> acpi0: <_> on motherboard
>> panic: smp_targeted_tlb_shootdown: interrupts disabled
>> cpuid = 2
>> time = 1
>> KDB: stack backtrace:
>> #0 0x80be74a7 at kdb_backtrace+0x67
>> #1 0x80b9b093 at vpanic+0x1a3
>> #2 0x80b9aee3 at panic+0x43
>> #3 0x811eda2f at smp_targeted_tlb_shootdown+0x40f
>> #4 0x811ed60d at smp_masked_invltlb+0x3d
>> #5 0x8105d5c5 at pmap_invalidate_range+0x1b5
>> #6 0x8106a429 at pmap_change_attr_locked+0x859
>> #7 0x81069804 at pmap_mapdev_internal+0x424
>> #8 0x81075ed0 at pcie_cfgregopen+0x60
>> #9 0x80451f10 at acpi_attach+0x390
>> #10 0x80bd6efc at device_attach+0x3ec
>> #11 0x80bd81dc at bus_generic_attach+0x5c
>> #12 0x80bd6efc at device_attach+0x3ec [sic!]
>> #13 0x80bd88b8 at bus_generic_new_pass+0x118
>> #14 0x80bda577 at root_bus_configure+0x77
>> #15 0x811dbce9 at configure+0x9
>> #16 0x80b31a78 at mi_startup+0x118
>> #17 0x8034102c 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
Re: Panic booting 12-RC2 on amd64
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 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, 0x810f8750, 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: on motherboard > acpi0: <_> on motherboard > panic: smp_targeted_tlb_shootdown: interrupts disabled > cpuid = 2 > time = 1 > KDB: stack backtrace: > #0 0x80be74a7 at kdb_backtrace+0x67 > #1 0x80b9b093 at vpanic+0x1a3 > #2 0x80b9aee3 at panic+0x43 > #3 0x811eda2f at smp_targeted_tlb_shootdown+0x40f > #4 0x811ed60d at smp_masked_invltlb+0x3d > #5 0x8105d5c5 at pmap_invalidate_range+0x1b5 > #6 0x8106a429 at pmap_change_attr_locked+0x859 > #7 0x81069804 at pmap_mapdev_internal+0x424 > #8 0x81075ed0 at pcie_cfgregopen+0x60 > #9 0x80451f10 at acpi_attach+0x390 > #10 0x80bd6efc at device_attach+0x3ec > #11 0x80bd81dc at bus_generic_attach+0x5c > #12 0x80bd6efc at device_attach+0x3ec [sic!] > #13 0x80bd88b8 at bus_generic_new_pass+0x118 > #14 0x80bda577 at root_bus_configure+0x77 > #15 0x811dbce9 at configure+0x9 > #16 0x80b31a78 at mi_startup+0x118 > #17 0x8034102c 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"
Re: mps and LSI SAS2308: controller resets on 12.0 - IOC Fault 0x40000d04, Resetting
> On 17 Dec 2018, at 20:14, Mike Tancsa wrote: > > On 12/17/2018 10:52 AM, Mark Martinec wrote: >> Anyone else seen problems with mps driver and LSI SAS2308 controller? >> >> (btw, on another machine the mps driver with LSI SAS2004 is working >> just fine under 12.0) > > > Sort of ran into this as well, but with the mfi driver. The same card in > *some* machines would boot just fine, but in others, it would hang at > boot time. Not sure if its related or not > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231432 > > I was able to get a MegaRAID SAS-3 3108 [Invader] card working by > forcing it to use the mrsas driver instead of the mfi. However, my > 9240s fail with the mfi and they will not work with the mrsas > Interesting. I have a machine with a 9240 and a 9261 that I have just upgraded to 12.0 from 10.2 and is working fine with the mfi driver. However, the standard machine build procedure here includes: hw.mfi.msi=“1” in /boot/loader.conf. This was added to our build procedure back in 2011 to deal with the 9261 not working on FreeBSD 9.0. I wonder if using MSI interrupts would help with your problem? Regards, Jan M. ___ 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"
