Re: 14.0-CURRENT panic in early boot
I've seen it on an arm64 system: KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 do_el1h_sync() at do_el1h_sync+0x184 handle_el1h_sync() at handle_el1h_sync+0x78 --- exception, esr 0x200 vt_conswindow() at vt_conswindow+0x10 (null)() at -0x4 (null)() at 0x0001 Uptime: 3s The full log is here: http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-4082b189d2c/failed-boot1.txt On 11/18/2021 12: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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [HEADSUP] making /bin/sh the default shell for root
Will history/completion continue to work the same way? (for example typing part of the command, pressing UP and having it complete based on history) On 9/22/2021 4:36 AM, Baptiste Daroussin wrote: Hello, TL;DR: this is not a proposal to deorbit csh from base!!! For years now, csh is the default root shell for FreeBSD, csh can be confusing as a default shell for many as all other unix like settled on a bourne shell compatible interactive shell: zsh, bash, or variant of ksh. Recently our sh(1) has receive update to make it more user friendly in interactive mode: * command completion (thanks pstef@) * improvement in the emacs mode, to make it behave by default like other shells * improvement in the vi mode (in particular the vi edit to respect $EDITOR) * support for history as described by POSIX. This makes it a usable shell by default, which is why I would like to propose to make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) If no strong arguments has been raised until October 15th, I will make this proposal happen. Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! Best regards, Baptiste smime.p7s Description: S/MIME Cryptographic Signature
Re: dumpdev AUTO in rc.conf does not work
Yes my fstab entry is: /dev/gpt/swap none swap sw 0 0 It looks though that this issue might only happen on arm64? I tried to reproduce on amd64 without any luck. On 8/8/2021 3:03 AM, Gary Jennejohn wrote: On Sat, 7 Aug 2021 20:10:50 -0400 Daniel Morante via freebsd-current wrote: Hello, I am running 14.0-CURRENT using the snapshot from 2021-08-05.__ It looks as if setting dumpdev="AUTO" in /etc/rc.conf has no effect on enabling kernel crash dumps. root@callisto:~ # uname -a FreeBSD callisto 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n248478-f3a3b061216: Thu Aug__ 5 06:03:20 UTC 2021 root@releng 1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 root@callisto:~ # swapinfo -h DeviceSize Used Avail Capacity /dev/gpt/swap 30G030G0% root@callisto:~ # dumpon -l /dev/null root@callisto:~ # sysrc dumpdev dumpdev: AUTO I have to manually enable it via dumpon even though it's set to AUTO in__ rc.conf root@callisto:~ # dumpon /dev/gpt/swap root@callisto:~ # dumpon -l gpt/swap Works for me if I set dumpdev to AUTO. I ran '/bin/sh -x dumpon start' and it found the swap entry in /etc/fstab, as expected. Does your /etc/fstab entry for swap have the correct syntax? Mine looks like this: /dev/ada0p5 noneswapsw 0 0 smime.p7s Description: S/MIME Cryptographic Signature
dumpdev AUTO in rc.conf does not work
Hello, I am running 14.0-CURRENT using the snapshot from 2021-08-05. It looks as if setting dumpdev="AUTO" in /etc/rc.conf has no effect on enabling kernel crash dumps. root@callisto:~ # uname -a FreeBSD callisto 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n248478-f3a3b061216: Thu Aug 5 06:03:20 UTC 2021 root@releng 1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 root@callisto:~ # swapinfo -h Device Size Used Avail Capacity /dev/gpt/swap 30G 0B 30G 0% root@callisto:~ # dumpon -l /dev/null root@callisto:~ # sysrc dumpdev dumpdev: AUTO I have to manually enable it via dumpon even though it's set to AUTO in rc.conf root@callisto:~ # dumpon /dev/gpt/swap root@callisto:~ # dumpon -l gpt/swap smime.p7s Description: S/MIME Cryptographic Signature
Re: Update to the 13.0-RELEASE schedule
Also, this release seems to have gotten a lot more attention than usual. So probably more people are testing. On 3/31/21 1:24 PM, Rainer Duffner wrote: Am 31.03.2021 um 17:58 schrieb Glen Barber : A small set of updates that we consider blocking the 13.0 release have been brought to our attention. As such, the 13.0-RELEASE schedule has been updated to include a fifth release candidate (RC5). The updated schedule is available on the FreeBSD Project website: https://www.freebsd.org/releases/13.0R/schedule/ As usual, we will continue to consider critical bug fixes only for the duration of this release cycle. Thank you for your cooperation, and for your patience. Glen On behalf of: re@ The truth is that a lot people don’t really start testing until the later release candidates. So, having more of these release candidates with just refinements is a good thing, IMHO. ___ 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" smime.p7s Description: S/MIME Cryptographic Signature
