FreeBSD 11.3-BETA2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The second BETA build of the 11.3-RELEASE release cycle is now available. Installation images are available for: o 11.3-BETA2 amd64 GENERIC o 11.3-BETA2 i386 GENERIC o 11.3-BETA2 powerpc GENERIC o 11.3-BETA2 powerpc64 GENERIC64 o 11.3-BETA2 sparc64 GENERIC o 11.3-BETA2 armv6 BANANAPI o 11.3-BETA2 armv6 BEAGLEBONE o 11.3-BETA2 armv6 CUBIEBOARD o 11.3-BETA2 armv6 CUBIEBOARD2 o 11.3-BETA2 armv6 CUBOX-HUMMINGBOARD o 11.3-BETA2 armv6 RPI-B o 11.3-BETA2 armv6 RPI2 o 11.3-BETA2 armv6 PANDABOARD o 11.3-BETA2 armv6 WANDBOARD o 11.3-BETA2 aarch64 GENERIC Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.3/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/11" branch. A summary of changes since 11.3-BETA1 includes: o The fsck_readdir() and dircheck() functions have been rewritten for clarity and correctness. o contrib/zlib has been moved to sys/contrib/zlib so that it can be used in the kernel. o The bhyve SMBIOS table has been made topology-aware. o Accessor function for vm->maxcpus have been added. o The bectl(8) jail with numeric boot environment (BE) names has been fixed. o OpenSSL has been updated to version 1.0.2s. o An update to prevent calling hw_mds_recalculate() from initializecpu(). o An upstream LLVM fix has been merged to fix an assertion when building the graphics/mesa-dri port for PowerPC64. o A fix to the NDIS driver printing "(null)" when uninitialized when using the '-h' (help) flag. o An uart emulation bug has been fixed. o Increase the VirtIO segment count to support modern Windows guests. o A fix to prevent exposing the uptime via the TCP timestamps. o Expose the MD_CLEAR capability used by Intel MDS mitigations to guests. A list of changes since 11.2-RELEASE is available in the stable/11 release notes: https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 11.3-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/11.3-BETA2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: eu-north-1 region: ami-010af11cb640a6dee ap-south-1 region: ami-02b1930180c7e1f84 eu-west-3 region: ami-02c0fbb70c27140c9 eu-west-2 region: ami-0a153ee6417cc762a eu-west-1 region: ami-0d408e28706df7df4 ap-northeast-2 region: ami-06fb52e8cf793dd53 ap-northeast-1 region: ami-0bf79180cdb0e6923 sa-east-1 region: ami-0f4aff5453cb72b01 ca-central-1 region: ami-056a0b9ce2bd839f5 ap-southeast-1 region: ami-0f73e82a020a5137f ap-southeast-2 region: ami-06468078ec3e31029 eu-central-1 region: ami-0a6e0eb4c2a169f66 us-east-1 region: ami-0bc8f1f1ed85baa0f us-east-2 region: ami-041a4cee6e5445ee3 us-west-1 region: ami-00c3ebed64c1338e2 us-west-2 region: ami-01288513b23077913 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-11.3-BETA2 % vagrant up === Upgrading === The freebsd
Re: 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)
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)
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(&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
> 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
> https://list
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"
