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

2019-06-03 Thread Jan Martin Mikkelsen
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"


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

2019-05-31 Thread Konstantin Belousov
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"


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

2019-05-31 Thread 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.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 
>> 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
> 

Re: Panic booting 12-RC2 on amd64

2019-05-31 Thread Jan Martin Mikkelsen
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: Panic booting 12-RC2 on amd64

2018-11-26 Thread Eugene Grosbein
26.11.2018 15:49, Christian Ullrich wrote:

>>> 26.11.2018 1:26, Christian Ullrich wrote:
>>>
 I'd really like to upgrade to 12. If anyone can suggest something I can
 try, I'll be happy to do experiments.
>>>
>>> Try verbose boot (boot -v), collect pre-panic output and post it again.
> 
> For comparison, here is the successful boot of stable/11:

[skip]

You should fill a PR attaching data you already collected.


___
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: Panic booting 12-RC2 on amd64

2018-11-26 Thread Christian Ullrich
* Christian Ullrich wrote:

> * Eugene Grosbein wrote:
> 
>> 26.11.2018 1:26, Christian Ullrich wrote:
>>
>>> I'd really like to upgrade to 12. If anyone can suggest something I can
>>> try, I'll be happy to do experiments.
>>
>> Try verbose boot (boot -v), collect pre-panic output and post it again.

For comparison, here is the successful boot of stable/11:


 >> FreeBSD EFI boot block
Loader path: /boot/loader.efi

Initializing modules: ZFS UFS
Probing 8 block devices...+..* done
 ZFS found the following pools: zroot
 UFS found no partitions
 command args: -h -S115200

Consoles: EFI console
Command line arguments: loader.efi -h -S115200
Image base: 0xaa38b000
EFI version: 2.31
EFI Firmware: American Megatrends (rev 5.09)

FreeBSD/amd64 EFI loader, Revision 1.1
(Sun Nov 25 13:51:19 CET 2018 chul@infra11build)
Load Path: 
HD(3,GPT,195395E9-217B-11E8-8DC1-003018CF5B88,0x864800,0x6EDC000)
Load Device: 
PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x1,0x0)/HD(3,GPT,195395E9-217B-11E8-8DC1-003018CF5B88,0x864800,0x6EDC000)
BootCurrent: 0008
BootOrder: 0008[*] 0005 0006 0003 0004 0009 0001 0002
Trying ZFS pool
Setting currdev to zfs:zroot/ROOT/default:
Loading /boot/defaults/loader.conf
\
/boot/kernel/kernel text=0x9522ad data=0xb73c8+0x353c48 
syms=[0x8+0xe8710+0x8+0x10451c]
/boot/entropy size=0x1000
/boot/kernel/geom_mirror.ko size 0x25790 at 0x134b000
/boot/kernel/zfs.ko size 0x3925b0 at 0x1371000
loading required module 'opensolaris'
/boot/kernel/opensolaris.ko size 0xa2e0 at 0x1704000
Booting...
Start @ 0x802a7230 ...
EFI framebuffer information:
addr, size 0xc000, 0x1d4c00
dimensions 800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00
Table 'FACP' at 0xb95fa1b8
Table 'APIC' at 0xb95fa2c8
APIC: Found table at 0xb95fa2c8
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 3: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 4: enabled
SMP: Added CPU 6 (AP)
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.2-STABLE #0 66e7e8a9d9b(local-stable-11): Sun Nov 25 14:21:51 
CET 2018
 chul@infra11build:/usr/obj/usr/src/sys/LOCAL amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on 
LLVM 6.0.1)
Table 'FACP' at 0xb95fa1b8
Table 'APIC' at 0xb95fa2c8
Table 'FPDT' at 0xb95fa350
Table 'MCFG' at 0xb95fa398
Table 'LPIT' at 0xb95fa3d8
Table 'HPET' at 0xb95fa4e0
Table 'SSDT' at 0xb95fa518
Table 'SSDT' at 0xb95fac80
Table 'SSDT' at 0xb95faf10
Table 'UEFI' at 0xb95fb090
ACPI: No SRAT table found
PPIM 0: PA=0xc000, VA=0x8181, size=0x1d5000, mode=0x1
VT(efifb): resolution 800x600
Preloaded elf kernel "/boot/kernel/kernel" at 0x8171.
Preloaded boot_entropy_cache "/boot/entropy" at 0x817111a8.
Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 
0x81711200.
Preloaded elf obj module "/boot/kernel/zfs.ko" at 0x81711870.
Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 
0x81712098.
Calibrating TSC clock ... TSC clock: 1833378646 Hz
CPU: Intel(R) Celeron(R) CPU  N2930  @ 1.83GHz (1833.38-MHz K8-class CPU)
   Origin="GenuineIntel"  Id=0x30678  Family=0x6  Model=0x37  Stepping=8
 
Features=0xbfebfbff
 
Features2=0x41d8e3bf
   AMD Features=0x28100800
   AMD Features2=0x101
   Structured Extended Features=0x2282
   VT-x: (disabled in BIOS) Basic Features=0xda0400
 Pin-Based Controls=0x7f
 Primary Processor 
Controls=0xfff9fffe
 Secondary Processor 
Controls=0x28ef
 Exit Controls=0xda0400
 Entry Controls=0xda0400
 EPT Features=0x6114141
 VPID Features=0xf01
   TSC: P-state invariant, performance statistics
DTLB: 4k pages, fully associative, 32 entries
Data TLB: 4 KB Pages, 4-way set associative, 128 entries
Instruction TLB: 4 KByte pages, fully associative, 48 entries
DTLB: 4 KByte/2 MByte pages, 4-way associative, 16 entries
L2 cache: 1024 kbytes, 16-way associative, 64 bytes/line
real memory  = 8589934592 (8192 MB)
Physical memory chunk(s):
0x0001 - 0x0003afff, 176128 bytes (43 pages)
0x0004 - 0x0009, 393216 bytes (96 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x0180 - 0x1fff, 511705088 bytes (124928 pages)
0x2010 - 0xb95bbfff, 2571878400 bytes (627900 pages)
0xb9b86000 - 0xb9b86fff, 4096 bytes (1 pages)
0xb9bc9000 - 0xb9d37fff, 1503232 bytes (367 pages)
0xb9ffa000 - 0xb9ff, 24576 bytes (6 pages)
0x0001 - 0x000231aa1fff, 5128200192 bytes 

Re: Panic booting 12-RC2 on amd64

2018-11-26 Thread Christian Ullrich
* Eugene Grosbein wrote:

> 26.11.2018 1:26, Christian Ullrich wrote:
> 
>> I'd really like to upgrade to 12. If anyone can suggest something I can
>> try, I'll be happy to do experiments.
> 
> Try verbose boot (boot -v), collect pre-panic output and post it again.

This is from the 12-RC2 memstick.img again:


 >> FreeBSD EFI boot block
Loader path: /boot/loader.efi

Initializing modules: ZFS UFS
Load Path: \EFI\BOOT\BOOTX64.EFI
Load Device: 
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
BootCurrent: 0009
BootOrder: 0007 0008 0005 0006 0003 0004 0009[*] 0001 0002
Probing 11 block devices.*+..+ done
 ZFS found the following pools: zroot
 UFS found 1 partition
Consoles: EFI console
FreeBSD/amd64 EFI loader, Revision 1.1

Command line arguments: loader.efi
EFI version: 2.31
EFI Firmware: American Megatrends (rev 5.09)
Console: efi (0x2000)
Load Path: HD(2,MBR,0x90909090,0x641,0xB7990)
Load Device: 
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/HD(2,MBR,0x90909090,0x641,0xB7990)
BootCurrent: 0009
BootOrder: 0007 0008 0005 0006 0003 0004 0009[*] 0001 0002
BootInfo Path: 
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
BootInfo Path: 
VenHw(2D6447EF-3BC9-41A0-AC19-4D51D01B4CE6,430038003600300030003000380038003600310034004400450046003600300036004100310035004100310042003500)
Ignoring Boot0009: No Media Path
Trying ESP: 
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/HD(2,MBR,0x90909090,0x641,0xB7990)
Setting currdev to disk0p2:
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
-
Loading kernel...
/boot/kernel/kernel text=0x1677738 data=0x1cd288+0x768b40 
syms=[0x8+0x174cd8+0x8+0x19224a]
Loading configured modules...
can't find '/boot/entropy'
Start @ 0x80341000 ...
EFI framebuffer information:
addr, size 0xc000, 0x1d4c00
dimensions 800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00
---<>---
Table 'FACP' at 0xb95fa1b8
Table 'APIC' at 0xb95fa2c8
APIC: Found table at 0xb95fa2c8
APIC: Using the MADT enumerator.
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RC2 r340839 GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on 
LLVM 6.0.1)
Table 'FACP' at 0xb95fa1b8
Table 'APIC' at 0xb95fa2c8
Table 'FPDT' at 0xb95fa350
Table 'MCFG' at 0xb95fa398
Table 'LPIT' at 0xb95fa3d8
Table 'HPET' at 0xb95fa4e0
Table 'SSDT' at 0xb95fa518
Table 'SSDT' at 0xb95fac80
Table 'SSDT' at 0xb95faf10
Table 'UEFI' at 0xb95fb090
ACPI: No SRAT table found
PPIM 0: PA=0xc000, VA=0x8281, size=0x1d5000, mode=0x1
pmap: large map 8 PML4 slots (4096 Gb)
VT(efifb): resolution 800x600
Preloaded elf kernel "/boot/kernel/kernel" at 0x8263e000.
Table 'FACP' at 0xb95fa1b8
FACP: Found table at 0xb95fa1b8
Calibrating TSC clock ... TSC clock: 1833378866 Hz
CPU: Intel(R) Celeron(R) CPU  N2930  @ 1.83GHz (1833.38-MHz K8-class CPU)
   Origin="GenuineIntel"  Id=0x30678  Family=0x6  Model=0x37  Stepping=8
 
Features=0xbfebfbff
 
Features2=0x41d8e3bf
   AMD Features=0x28100800
   AMD Features2=0x101
   Structured Extended Features=0x2282
   VT-x: (disabled in BIOS) Basic Features=0xda0400
 Pin-Based Controls=0x7f
 Primary Processor 
Controls=0xfff9fffe
 Secondary Processor 
Controls=0x28ef
 Exit Controls=0xda0400
 Entry Controls=0xda0400
 EPT Features=0x6114141
 VPID Features=0xf01
   TSC: P-state invariant, performance statistics
DTLB: 4k pages, fully associative, 32 entries
Data TLB: 4 KB Pages, 4-way set associative, 128 entries
Instruction TLB: 4 KByte pages, fully associative, 48 entries
DTLB: 4 KByte/2 MByte pages, 4-way associative, 16 entries
L2 cache: 1024 kbytes, 16-way associative, 64 bytes/line
real memory  = 8589934592 (8192 MB)
Physical memory chunk(s):
0x0001 - 0x0003efff, 192512 bytes (47 pages)
0x0004 - 0x0009efff, 389120 bytes (95 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x0280 - 0x1fff, 494927872 bytes (120832 pages)
0x2010 - 0xb95bbfff, 2571878400 bytes (627900 pages)
0xb9b86000 - 0xb9b86fff, 4096 bytes (1 pages)
0xb9bc9000 - 0xb9d37fff, 1503232 bytes (367 pages)
0xb9ffd000 - 0xb9ff, 12288 bytes (3 pages)
0x0001 - 0x000231aaefff, 5128253440 bytes (1252015 pages)
avail memory = 8164179968 (7785 MB)
intel stolen mem: base 0xbb00 size 64 MB
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 

Re: Panic booting 12-RC2 on amd64

2018-11-25 Thread Eugene Grosbein
26.11.2018 1:26, Christian Ullrich wrote:

> I'd really like to upgrade to 12. If anyone can suggest something I can 
> try, I'll be happy to do experiments.

Try verbose boot (boot -v), collect pre-panic output and post it again.


___
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"


Panic booting 12-RC2 on amd64

2018-11-25 Thread Christian Ullrich
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"