Re: 14.0-CURRENT panic in early boot
Completely speculating, but since you don't see ioapic's are you sure this is just ~2 weeks old build? If not, then it may be relevant to: commit 1b7a2680fba589daf6f700565214919cb941ab56 Author: Jung-uk Kim Date: Thu Sep 30 16:23:21 2021 -0400 Import ACPICA 20210930 (cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e) IMHO! On 11/18/21 6:22 AM, Dustin Marquess wrote: I just updated a machine from a build that was ~2 weeks old. The latest commit when I built it was 2e946f87055. The system boots using UEFI, if that matters. The system is panicking pretty early in the boot, however: real memory = 137438953472 (131072 MB) avail memory = 133651496960 (127460 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. kernel trap 12 with interrupts disabled panic: vm_fault_lookup: fault on nofault entry, addr: 0x81e1d000 cpuid = 0 time = 1 The backtrace shows: KDB: stack backtrace: #0 0x806deb5b at kdb_backtrace+0x6b #1 0x80693b44 at vpanic+0x184 #2 0x806939b3 at panic+0x43 #3 0x8091d4b3 at vm_fault+0x1423 #4 0x8091bfb0 at vm_fault_trap+0xb0 #5 0x809c0902 at trap_pfault+0x1f2 #6 0x809992b8 at calltrap+0x8 #7 0x806ebcc1 at vsscanf+0x31 #8 0x806ebc7f at sscanf+0x3f #9 0x806bd9ab at validate_uuid+0x8b #10 0x80655be0 at prison0_init+0x90 #11 0x80623aba at proc0_init+0x29a #12 0x80623689 at mi_startup+0xe9 #13 0x802e3062 at btext+0x22 Uptime: 1s Compared to a boot using the old working kernel: real memory = 137438953472 (131072 MB) avail memory = 133651505152 (127460 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-23 ioapic1 irqs 24-47 ioapic2 irqs 48-71 Launching APs: 1 11 28 15 18 6 29 4 16 9 24 7 3 10 27 22 14 13 12 23 25 20 26 30 17 5 2 21 19 8 31 Timecounter "TSC-low" frequency 1197250876 Hz quality 1000 Has anybody else seen this? -Dustin
make buildworld broken on RISC-V.
Hello,
I'm using 14-CURRENT oprovided qcow2 image from September 30 in
qemu-system-risc64. It runs fine so I'm testing it with attempting make
buildworld. This unfortunately fails with:
===> lib/clang/headers (includes)
[Creating objdir /usr/obj/usr/src/riscv.riscv64/lib/clang/headers...]
clang-tblgen -gen-arm-bf16 -I
/usr/src/contrib/llvm-project/clang/include/clang/Basic -d arm_bf16.h.d
-o arm_bf16.h
/usr/src/contrib/llvm-project/clang/include/clang/Basic/arm_bf16.td
ELF binary type "0" not known.
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: ELF�Т:
not found
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @h�a@8:
not found
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @@@0�:
not found
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: �: not
found
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 1:
Syntax error: "(" unexpected
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 5:
Syntax error: Error in command substitution
*** Error code 2
Stop.
make[5]: stopped in /usr/src/lib/clang/headers
*** Error code 1
Stop.
make[4]: stopped in /usr/src/lib/clang
*** Error code 1
Stop.
make[3]: stopped in /usr/src/lib
*** Error code 1
Stop.
make[2]: stopped in /usr/src
370.58 real 114.97 user 258.16 sys
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
I'm not sure which from available clang-tblgen is invoked:
# find / -type f -name
'clang-tblgen'/usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen
/usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen
but both seems to be reasonable file types:
root@freebsd:/usr/src/lib/clang/headers # file
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen
/usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen: ELF 64-bit
LSB executable, UCB RISC-V, version 1 (SYSV), statically linked,
FreeBSD-style, not stripped
root@freebsd:/usr/src/lib/clang/headers # file
/usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen
/usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen:
ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically
linked, FreeBSD-style, not stripped
Is there any trick how to solve this issue?
Thanks,
Karel
ELF binary type "0" not known. (while compiling buildworld on risc-v/qemu)
Hello, I'm playing with compiling freebsd 13 (releng/13.0 2 days ago) and current (git HEAD as of today) on qemu-5.1.0/qemu-6.1.0 on risv64 platform. The emulator invocation is: qemu-system-riscv64 -machine virt -smp 8 -m 16G -nographic -device virtio-blk-device,drive=hd -drive file=FreeBSD-14.0-CURRENT-riscv-riscv64.qcow2,if=none,id=hd -device virtio-net-device,netdev=net -netdev user,id=net,hostfwd=tcp::2233-:22 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng -nographic -append "root=LABEL=rootfs console=ttyS0" and the host is Ubuntu 20.04.x LTS. Both qemu 5.1.0 and qemu 6.1.0 are compiled from, source, but both OpenSBI and u-boot for risc-v are Ubuntu packages provided (to accompany ubuntu provided qemu 4.2.1) My issue while compiling both 13 and current is that compilation after some time fails with: root@freebsd:/usr/src # time make -j8 buildworld > /tmp/build-j8-2.txt ELF binary type "0" not known. 17784.134u 21388.907s 1:50:13.83 592.2% 30721+572k 10+2177io 0pf+0w I'm curious if this is a know issue either in Qemu or in FreeBSD for risc-v or if I'm doing anything wrong here? Thanks! Karel
Re: Install to ZFS root is using device names hence failing when device tree is changed.
On 9/7/21 10:29 AM, Peter Jeremy wrote: On 2021-Sep-06 17:45:31 +0200, Karel Gardas wrote: just installed 14-current snapshot from 2.9. on uefi amd64 machine. Installed from USB memstick which was detected as da0 into the ssd hanging on usb3 in external enclosure which was detected as da1. ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as /boot/efi and probably also something as root zpool. Anyway, expected thing happen. When I pulled out USB stick identified as da0 on reboot, the drive on USB3 switch from da1 to da0 and result is unbootable system with complains about various /dev/da1xx drives missing for swap efi boot etc. Can you give more details about exactly what the errors and when they occur during the boot cycle. In particular: * Low-level boot (anything prior to the FreeBSD kernel) knows nothing about da0 or da1, so any problems there are associated with your BIOS config, not FreeBSD. Low level boot is all right since kernel is booting. What's broken is root/zfs mount and swap enablement. * The swap partition will, by default, appear as a hard-wired device name in /etc/fstab - that will definitely need updating. This will prevent the "swapon" working but won't prevent the boot. ACK. Good to know. * ZFS doesn't care about device names - it looks for ZFS labels on all possible devices. I think you are wrong here. Let's see zpool status: karel@freebsd:~ $ zpool status pool: zroot state: ONLINE config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 da1p4 ONLINE 0 0 0 errors: No known data errors Now, let's reboot and see error on serial console when install da0 is not attached: Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.5: at usbus0 umass0 numa-domain 0 on uhub1 umass0: addr 4> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:9:0: Attached to scbus9 da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 201701C7 da0: 400.000MB/s transfers da0: 238475MB (488397168 512 byte sectors) da0: quirks=0x2 Dual Console: Serial Primary, Video Secondary No suitable dump device was found. Setting hostuuid: 8cdf33eb-6866-42ae-a49d-ae7ee4c0c33c. Setting hostid: 0xdf6467d8. no pools available to import swapon: /dev/da1p3: No such file or directory Starting file system checks: Can't open `/dev/da1p1' /dev/da1p1: UNEXPECTED INCONSISTENCY; RUN fsck_msdosfs MANUALLY. THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: msdosfs: /dev/da1p1 (/boot/efi) Automatic file system check failed; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! 2021-09-07T11:23:23.710549+02:00 - init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: So this is problematic /efi parition, if I remove it from the /etc/fstab I get this boot: Wow! It boots well, so you were indeed right. Checking zpool status reveals: karel@freebsd:~ $ zpool status pool: zroot state: ONLINE config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p4 ONLINE 0 0 0 errors: No known data errors karel@freebsd:~ $ so indeed, ZFS on FreeBSD is similar to this on Solaris. On Linux I got different experience (e.g. /dev/sdaX hardwired and failing to boot) hence I've been in impression that this is also a case of FreeBSD when code is shared thorough OpenZFS project. Great to know and thanks for kicking me into it. So just /efi partition mount is the culprit here... Thanks! Karel
Re: EFI/loader show garbage in console when set to some resolution in loader.conf
On 9/6/21 6:59 PM, Toomas Soome wrote: On 6. Sep 2021, at 19:44, Karel Gardas <mailto:gard...@gmail.com>> wrote: Hello, I'm attempting to set EFI console resolution in loader to 1920x1920. This is working fine on all 3 tested* combinations when interrupting loader with '3' key and then issueing 'gop set 11' command and then 'boot' command. However I'd like to make that permanent and here issue comes. I've tried both: - edit /boot/loader.conf by adding 'exec="gop set 11"' - edit /boot/loader.conf by adding 'efi_max_resolution="1920x1920"' neither of those works on neither of 3 tested combinations where tested combinations are: if you have this setting, what does gop get report? With the versions listed below, was the loader in ESP updated too? Good question. I'm not entirely sure if my 13.x installation is not update from 12.x. It probably is. IIRC I followed the update procedure recommended, but certainly 13.0 -> 13.0-p4 is just `fetch` and `install` matter. If you like me to update ESP bootloader, I'm happy to follow your instructions how to do that. Anyway, my 14.0-CURRENT is fresh install to separate drive in an attempt to duplicate issue also on current to report it here. So gop get reports this (manually rewritten by hand): - FreeBSD 14.0 - current: EDID 1920x1920 1920x1920 1920x1200 1920x1080 1600x1200 1600x900 1280x1024 1280x960 1280x720 mode 4: 1024x768x32, stride=1024 frame buffer: address=d000, size=30 color mark: R=00ff, G=ff00, B=00ff - FreeBSD 13.0-p4: EDID 1920x1920 1920x1920 1920x1200 1920x1080 1600x1200 1600x900 1280x1024 1280x960 1280x720 mode 4: 1024x768x32, stride 1024 frame buffer: address=d000, size 30 color mark: R00ff, G=ff00, B00ff (1) 13.0 release (2) 13.0-p4 (stable) (3) 14.0 snapshot from 2.9. The behavior is still the same. Screen blanks (like it would do gop set 11), then switches to text mode to show loader UI and when kernel is loaded it correctly shows that efi resolution is 1920x1920 but then when kernels boot, it produce just garbage to the console like loader and kernel resolution would be off by some unknown number... Is this is known issue, is there a known workaround for it? Or shall I report it properly to bugzilla? Thanks! Karel what you get from: dmesg | grep efifb - FreebSD 14.0-current: VT(efifb): resolution 1920x1920 - FreeBSD 13.0-p4: VT(efifb): resolution 1920x1920 Thanks, Karel
Install to ZFS root is using device names hence failing when device tree is changed.
Hello, just installed 14-current snapshot from 2.9. on uefi amd64 machine. Installed from USB memstick which was detected as da0 into the ssd hanging on usb3 in external enclosure which was detected as da1. ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as /boot/efi and probably also something as root zpool. Anyway, expected thing happen. When I pulled out USB stick identified as da0 on reboot, the drive on USB3 switch from da1 to da0 and result is unbootable system with complains about various /dev/da1xx drives missing for swap efi boot etc. Would be great if ZFS root install was using kind of device uuids or serial numbers or so so such device change would not disrupt freebsd from running correctly. Thanks, Karel
EFI/loader show garbage in console when set to some resolution in loader.conf
Hello, I'm attempting to set EFI console resolution in loader to 1920x1920. This is working fine on all 3 tested* combinations when interrupting loader with '3' key and then issueing 'gop set 11' command and then 'boot' command. However I'd like to make that permanent and here issue comes. I've tried both: - edit /boot/loader.conf by adding 'exec="gop set 11"' - edit /boot/loader.conf by adding 'efi_max_resolution="1920x1920"' neither of those works on neither of 3 tested combinations where tested combinations are: (1) 13.0 release (2) 13.0-p4 (stable) (3) 14.0 snapshot from 2.9. The behavior is still the same. Screen blanks (like it would do gop set 11), then switches to text mode to show loader UI and when kernel is loaded it correctly shows that efi resolution is 1920x1920 but then when kernels boot, it produce just garbage to the console like loader and kernel resolution would be off by some unknown number... Is this is known issue, is there a known workaround for it? Or shall I report it properly to bugzilla? Thanks! Karel
Install to ZFS root is using device names hence failing when device tree is changed.
Hello, just installed 14-current snapshot from 2.9. on uefi amd64 machine. Installed from USB memstick which was detected as da0 into the ssd hanging on usb3 in external enclosure which was detected as da1. ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as /boot/efi and probably also something as root zpool. Anyway, expected thing happen. When I pulled out USB stick identified as da0 on reboot, the drive on USB3 switch from da1 to da0 and result is unbootable system with complains about various /dev/da1xx drives missing for swap efi boot etc. Would be great if ZFS root install was using kind of device uuids or serial numbers or so so such device change would not disrupt freebsd from running correctly. Thanks, Karel
Re: current crashing VBox 6.1.16
The same problem is also duplicable on 13-RC2. Workaround exists: switch VBox storage layer from PIIX3 to AHCI. E.g. VM's Setting -> Storage -> select Controller node and on the right side -- in Attributes pane -- switch Type from PIIX3/4 to AHCI. This way I've been able to rebuild both 13 and current (both world and kernel) successfully. On 3/14/21 3:25 PM, Karel Gardas wrote: Hello, I'm trying to follow current installed in VBox VM. The VM is created with default configuration of 6.1.x suggested for 64bit FreeBSD. The RAM is set to 32GB and CPUs to 12 cores. Te host is running ubuntu 20.04.x. Anyway, while running 'make -j12 buildworld' the VM crash with following information in the VBox log: 00:02:26.650587 PIIX3 IDE: guest issued command 0xca while controller busy 00:02:26.652335 PIIX3 IDE: guest issued command 0xca while controller busy 00:02:26.653115 00:02:26.653115 !!Assertion Failed!! 00:02:26.653115 Expression: ReqType == ATA_AIO_RESET_ASSERTED || ReqType == ATA_AIO_RESET_CLEARED || ReqType == ATA_AIO_ABORT || pCtl->uAsyncIOState == ReqType 00:02:26.653116 Location : /build/virtualbox-9t4MJt/virtualbox-6.1.16-dfsg/src/VBox/Devices/Storage/DevATA.cpp(5838) int ataR3AsyncIOThread(RTTHREAD, void*) 00:02:26.653262 Stack : 00:02:26.653262 7f86d41e5a11 VBoxRT.so!RTAssertMsg2V+0xaf (rva:0x178a11) 00:02:26.653262 00:02:26.653286 I/O state inconsistent: state=0 request=1 Now, the question is if FBSD is allowed to issue command 0xca while controller is busy or if this is something which it should not do. Thanks, Karel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
current crashing VBox 6.1.16
Hello, I'm trying to follow current installed in VBox VM. The VM is created with default configuration of 6.1.x suggested for 64bit FreeBSD. The RAM is set to 32GB and CPUs to 12 cores. Te host is running ubuntu 20.04.x. Anyway, while running 'make -j12 buildworld' the VM crash with following information in the VBox log: 00:02:26.650587 PIIX3 IDE: guest issued command 0xca while controller busy 00:02:26.652335 PIIX3 IDE: guest issued command 0xca while controller busy 00:02:26.653115 00:02:26.653115 !!Assertion Failed!! 00:02:26.653115 Expression: ReqType == ATA_AIO_RESET_ASSERTED || ReqType == ATA_AIO_RESET_CLEARED || ReqType == ATA_AIO_ABORT || pCtl->uAsyncIOState == ReqType 00:02:26.653116 Location : /build/virtualbox-9t4MJt/virtualbox-6.1.16-dfsg/src/VBox/Devices/Storage/DevATA.cpp(5838) int ataR3AsyncIOThread(RTTHREAD, void*) 00:02:26.653262 Stack : 00:02:26.653262 7f86d41e5a11 VBoxRT.so!RTAssertMsg2V+0xaf (rva:0x178a11) 00:02:26.653262 00:02:26.653286 I/O state inconsistent: state=0 request=1 Now, the question is if FBSD is allowed to issue command 0xca while controller is busy or if this is something which it should not do. Thanks, Karel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
