[Bug 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 --- Comment #24 from Matthias Pfaller --- (In reply to Bane Ivosev from comment #23) We just gave it another try. We hopped that the problem might have been caused by a defective disk when we tried last. The problem was triggered again during the next night's backup :-( This is forcing us to keep running 11.1 on our backup machines. Any (bad/good) news from your machine? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 --- Comment #25 from Bane Ivosev --- (In reply to Matthias Pfaller from comment #24) We are still fine. No problem at all. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240762] [auditdistd] cannot receive trail files from servers running auditd on FreeBSD12
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240762 --- Comment #5 from Gordon Bergling --- This is fixed by r356962. I am not exactly sure why, because that change should only affects some parts within the hostname-part of audit-trail-files, but Jan 22 09:17 20200116071331.20200122081723. Jan 22 09:18 20200122081759.not_terminated Jan 22 09:17 current -> /var/audit/20200122081759.not_terminated -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243482] Link state change does not logged
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243482 --- Comment #1 from Toto --- The same issue on /etc/rc.d/netif stop igb0 No tracking into legfiles if link goes down. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243482] Link state change does not logged
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243482 Yuri Pankov changed: What|Removed |Added CC||yur...@freebsd.org --- Comment #2 from Yuri Pankov --- Looks like a duplicate of (or at least related to) bug 236724. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243502] date '+%s' shows wrong value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243502 Bug ID: 243502 Summary: date '+%s' shows wrong value Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: o...@zaplinski.de date '+%s' shows wrong value. Linux: 1579684042 FreeBSD: 135 According to 'man strftime', %s should be 'number of seconds since the Epoch, UTC' # date '+%s' 513 # date -r 513 Thu Jan 1 01:08:33 CET 1970 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243502] date '+%s' shows wrong value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243502 o...@zaplinski.de changed: What|Removed |Added Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243502] date '+%s' shows wrong value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243502 --- Comment #1 from Yuri Pankov --- Which date binary is that? What is the date output without modifiers? $ uname -psr FreeBSD 12.1-RELEASE-p1 amd64 $ which date /bin/date $ date '+%s' 1579687351 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243502] date '+%s' shows wrong value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243502 Pawel Biernacki changed: What|Removed |Added CC||kak...@freebsd.org --- Comment #2 from Pawel Biernacki --- Can you please share the output of: sysctl kern.boottime date; date -r `date '+%s'` Can't confirm on various installations of 13-C. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243502] date '+%s' shows wrong value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243502 o...@zaplinski.de changed: What|Removed |Added Resolution|--- |Not A Bug Status|New |Closed --- Comment #3 from o...@zaplinski.de --- I investigated further, and it turned out that a tool from sysutils/munin-contrib was setting the (wrong) date to 1.1.1970 instead of doing a convertion task. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243482] Link state change does not logged
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243482 --- Comment #3 from Toto --- But all the listed workarounds does not work for me. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243517] GENERIC Panic on boot as Virtualbox guest
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243517 Bug ID: 243517 Summary: GENERIC Panic on boot as Virtualbox guest Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: scha...@gmail.com The screenshot is here : https://imgur.com/45He1iy . No dump in /var/crash. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243523] The default size of tmpmfs is not sufficient for pkg operation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243523 Bug ID: 243523 Summary: The default size of tmpmfs is not sufficient for pkg operation Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: v...@sibptus.ru The default size of tmpmfs (tmpsize="20m") is not sufficient for pkg operation. If you do not increase the size of /tmp, "pkg update" operations will fail with the message: pkg: archive_read_extract(extract error): No space left on device Workaround: increase the size of the RAM disk on /tmp, or unmount the RAM disk. Proposed solution: the default tmpsize in /etc/defaults/rc.conf should be set to a higher value. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 234886] shutdown not installed with setuid bit in pkgbase
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234886 --- Comment #1 from Ed Maste --- Note that as of r335797 (https://reviews.freebsd.org/rS335797) we do pass the user/group/perms to install when creating the link, but tools/install.sh ignores the information. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 234733] Setting CPU frequency with sysctl dev.cpu.0.fr slows a Ryzen 2700X down
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733 --- Comment #4 from sig...@gmail.com --- Created attachment 210970 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210970&action=edit acpidump -dt (In reply to Conrad Meyer from comment #3) Alright I tested a bunch of things based on that. It doesn't seem to be related to CPB in this case. The 0x0200 bit never gets set (it always shows "MSR 0xc0010015: 0x 0x0911"). I tried to toggle it on and off again anyway in case it would reset something but it doesn't seem like it does. The CPU just seems to get stuck at the lowest frequency it has been set to. I tested by timing this: dd if=/dev/zero bs=32k count=2 | cpuset -l 0 time sha1 And by setting the frequency to 3200 (maximum), 2800 and 1550: 3200: 1.34 real 1.15 user 0.17 sys 2800: 1.78 real 1.47 user 0.30 sys 1550: 3.18 real 2.78 user 0.39 sys After lowering the frequency to a given value, there's no way to get the performance back (but it lets you set the frequency higher with sysctl without any apparent errors). With debug.hwpstate_verbose set, there's that during boot: hwpstate0: going to fetch info from acpi_perf hwpstate0: on cpu0 And a bunch of messages like that when setting the frequency with sysctl: hwpstate0: setting P1-state on cpu0 hwpstate0: setting P1-state on cpu1 hwpstate0: setting P1-state on cpu2 hwpstate0: setting P1-state on cpu3 hwpstate0: setting P1-state on cpu4 hwpstate0: setting P1-state on cpu5 hwpstate0: setting P1-state on cpu6 hwpstate0: setting P1-state on cpu7 hwpstate0: setting P1-state on cpu8 hwpstate0: setting P1-state on cpu9 hwpstate0: setting P1-state on cpu10 hwpstate0: setting P1-state on cpu11 hwpstate0: setting P1-state on cpu12 hwpstate0: setting P1-state on cpu13 hwpstate0: setting P1-state on cpu14 hwpstate0: setting P1-state on cpu15 hwpstate0: setting P2-state on cpu0 hwpstate0: setting P2-state on cpu1 hwpstate0: setting P2-state on cpu2 hwpstate0: setting P2-state on cpu3 hwpstate0: setting P2-state on cpu4 hwpstate0: setting P2-state on cpu5 hwpstate0: setting P2-state on cpu6 hwpstate0: setting P2-state on cpu7 hwpstate0: setting P2-state on cpu8 hwpstate0: setting P2-state on cpu9 hwpstate0: setting P2-state on cpu10 hwpstate0: setting P2-state on cpu11 hwpstate0: setting P2-state on cpu12 hwpstate0: setting P2-state on cpu13 hwpstate0: setting P2-state on cpu14 hwpstate0: setting P2-state on cpu15 Never anything other than P1 and P2. I tested after a reboot and an update to recent 12-STABLE r356965 and the results were all pretty much the same. That's a B450 Pro4 still with BIOS version P3.20. Using non-UEFI boot. And I reset it to default settings before the last test. At the time I first reported this it had the latest BIOS version but not anymore. So maybe a BIOS update would fix it. I'm gonna wait updating it in case more testing could be helpful. Thanks for looking into it! No other problems apart from that on this computer. And yeah after that I figured that you don't really need to run powerd on these CPUs since they'll throttle themselves automatically anyway and they seem to be doing a good job of it. But if someone does run powerd (or mess with the frequency directly) the permanent and silent slowdown can be a pretty bad surprise. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 234733] Setting CPU frequency with sysctl dev.cpu.0.fr slows a Ryzen 2700X down
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733 --- Comment #5 from Conrad Meyer --- (In reply to sigsys from comment #4) Thanks for the testing, that’s really helpful! I totally agree this is a bug that needs fixing; disabling powerd / avoiding manually reducing the clock is just a workaround until we can fix the root cause. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 93790] [cpufreq] cpufreq missing frequencies
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=93790 Conrad Meyer changed: What|Removed |Added Resolution|--- |Overcome By Events Status|Open|Closed -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243531] Unstable ena and nvme on AWS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243531 Bug ID: 243531 Summary: Unstable ena and nvme on AWS Product: Base System Version: 12.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: l...@ofwilsoncreek.com We just recently upgraded our systems on AWS to 12.1, and we're seeing errors with nvme0 and ena0. Typically, these errors manifest together. My sample size is 34 instances, all t3.medium or r4.large. I have others that are t2.small, and those are fine being that they don't use ena or nvme drivers. Of the 34, there's a group of 15 that are almost idle, and never throw these errors. Of the remaining that have load, only 5 ran without errors and 14 of them threw these errors scattered about various times in the last 4.5 days. 3 machines have crashed during this period, so the errors seem to often be nonfatal, but not always. So based on that it seems load related, and does not seem isolated to an occasional hardware problem. Here's a sample of the log from one of the machines that crashed: Jan 22 00:17:05 jdas-dev kernel: nvme0: cpl does not map to outstanding cmd Jan 22 00:17:05 jdas-dev kernel: cdw0: sqhd:000d sqid:0001 cid:0012 p:1 sc:00 sct:0 m:0 dnr:0 Jan 22 00:17:05 jdas-dev kernel: nvme0: Resetting controller due to a timeout. Jan 22 00:17:05 jdas-dev kernel: nvme0: resetting controller Jan 22 00:17:05 jdas-dev kernel: nvme0: temperature threshold not supported Jan 22 00:17:05 jdas-dev kernel: nvme0: aborting outstanding i/o Jan 22 00:17:05 jdas-dev kernel: nvme0: resubmitting queued i/o Jan 22 00:17:05 jdas-dev kernel: nvme0: WRITE sqid:2 cid:0 nsid:1 lba:691756520 len:8 Jan 22 00:17:21 jdas-dev kernel: ena0: The number of lost tx completion is above the threshold (129 > 128). Reset the device Jan 22 00:17:21 jdas-dev kernel: ena0: Trigger reset is on Jan 22 00:17:21 jdas-dev kernel: ena0: device is going DOWN Jan 22 00:17:21 jdas-dev kernel: ena0: free uncompleted tx mbuf qid 0 idx 0x154 Jan 22 00:17:22 jdas-dev kernel: ena0: device is going UP Jan 22 00:17:22 jdas-dev kernel: ena0: link is UP Jan 22 00:17:52 jdas-dev kernel: nvme0: Missing interrupt Jan 22 00:18:46 jdas-dev kernel: nvme0: Missing interrupt Jan 22 00:19:34 jdas-dev kernel: nvme0: cpl does not map to outstanding cmd Jan 22 00:19:34 jdas-dev kernel: cdw0: sqhd:001a sqid:0002 cid:001b p:0 sc:00 sct:0 m:0 dnr:0 Jan 22 00:19:34 jdas-dev kernel: nvme0: Resetting controller due to a timeout. Jan 22 00:19:34 jdas-dev kernel: nvme0: resetting controller Jan 22 00:19:35 jdas-dev kernel: nvme0: temperature threshold not supported Jan 22 00:19:35 jdas-dev kernel: nvme0: resubmitting queued i/o Jan 22 00:19:35 jdas-dev kernel: nvme0: WRITE sqid:1 cid:0 nsid:1 lba:405055248 len:8 Jan 22 00:19:35 jdas-dev kernel: nvme0: aborting outstanding i/o At this point, we rebooted the machine. Jan 22 09:02:30 jdas-dev kernel: nvme0: Resetting controller due to a timeout. Jan 22 09:02:30 jdas-dev kernel: nvme0: resetting controller Jan 22 09:02:30 jdas-dev kernel: nvme0: temperature threshold not supported Jan 22 09:02:30 jdas-dev kernel: nvme0: aborting outstanding i/o Jan 22 09:02:30 jdas-dev kernel: nvme0: DATASET MANAGEMENT sqid:2 cid:27 nsid:0 Jan 22 09:02:30 jdas-dev kernel: nvme0: INVALID OPCODE (00/01) sqid:2 cid:27 cdw0:0 Jan 22 09:02:30 jdas-dev kernel: ena0: Keep alive watchdog timeout. Jan 22 09:02:30 jdas-dev kernel: ena0: Trigger reset is on Jan 22 09:02:30 jdas-dev kernel: ena0: device is going DOWN Jan 22 09:02:30 jdas-dev kernel: ena0: ena0: device is going UP Jan 22 09:02:30 jdas-dev kernel: link is UP Jan 22 09:02:30 jdas-dev kernel: ena0: Keep alive watchdog timeout. Jan 22 09:02:30 jdas-dev kernel: ena0: Trigger reset is on Jan 22 09:02:30 jdas-dev kernel: ena0: device is going DOWN Jan 22 09:02:30 jdas-dev kernel: ena0: ena0: device is going UP Jan 22 09:02:30 jdas-dev kernel: link is UP Jan 22 09:02:30 jdas-dev kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312763, size: 4096 Jan 22 09:02:30 jdas-dev kernel: 90 second watchdog timeout expired. Shutdown terminated. Jan 22 09:02:30 jdas-dev kernel: Wed Jan 22 08:58:58 CST 2020 Jan 22 09:02:30 jdas-dev kernel: 2020-01-22T08:59:01.658827-06:00 jdas-dev.aws0.pla-net.cc init 1 - - /etc/rc.shutdown terminated abnormally, going to single user mode Jan 22 09:02:30 jdas-dev kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312763, size: 4096 Jan 22 09:02:30 jdas-dev kernel: 2020-01-22T08:59:23.108170-06:00 jdas-dev.aws0.pla-net.cc init 1 - - some processes would not die; ps axl advised Jan 22 09:02:30 jdas-dev kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 445, size: 12288 Jan 22 09:02:30 jdas-dev kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 21337, size: 4096 Jan 22 09:02:30 jdas-dev
[Bug 243532] kern.ipc.maxsockets wrong init value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243532
Bug ID: 243532
Summary: kern.ipc.maxsockets wrong init value
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: rozhuk...@gmail.com
I got:
kern.ipc.maxsockets: 517552
kern.maxfiles: 262144
/sys/kern/uipc_socket.c
static void
init_maxsockets(void *ignored)
{
TUNABLE_INT_FETCH("kern.ipc.maxsockets", &maxsockets);
maxsockets = imax(maxsockets, maxfiles);
}
SYSINIT(param, SI_SUB_TUNABLES, SI_ORDER_ANY, init_maxsockets, NULL);
looks like imin() should be used instead of imax():
sysctl_maxsockets(SYSCTL_HANDLER_ARGS)
{
int error, newmaxsockets;
newmaxsockets = maxsockets;
error = sysctl_handle_int(oidp, &newmaxsockets, 0, req);
if (error == 0 && req->newptr) {
if (newmaxsockets > maxsockets &&
newmaxsockets <= maxfiles) {
maxsockets = newmaxsockets;
EVENTHANDLER_INVOKE(maxsockets_change);
} else
error = EINVAL;
...
Also, IMHO sysctl_maxsockets() (and some other sysctl val handlers) should not
return EINVAL in case: oldval == newval.
This will avoid multiple error generation on system boot in case sysctl.conf
contains kern.ipc.maxsockets, kern.maxfiles and other things that could not be
decreased.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243533] vt_fb.c can overwrite frame buffer bounds if stride length is not a multiple of bytes-per-pixel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243533 Bug ID: 243533 Summary: vt_fb.c can overwrite frame buffer bounds if stride length is not a multiple of bytes-per-pixel Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: thoma555-...@yahoo.com Created attachment 210977 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210977&action=edit fix vt_fb_blank(). I'm developing a frame buffer driver for hardware using 3 bytes per pixel but the hardware requires the stride to be a multiple of 256 bytes. Because the stride is not a multiple of 3 bytes, the way vt_fb_blank() is coded, it writes past the end of each stride and, on the last line, writes past the end of the frame buffer. This is caught by a KASSERT in vt_fb_mem_wr1(). I think the loops in vt_fb_blank() could just stop at the end of the line (fb_width) instead of clearing memory all the way to the end of a stride. The other way would be to limit the loops with fb_stride - 1, fb_stride - 2, fb_stride - 3 for the cases of 2,3,4 bytes per pixel. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 Bug ID: 243534 Summary: Kernel panics with "panic: invalid count 2" early during boot Product: Base System Version: CURRENT Hardware: sparc64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: krail...@elderlinux.org Created attachment 210979 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210979&action=edit dmesg.boot contents from 12.1 There has been a fix proposal for unwind on SPARC64 that is looking for testers (r356552). I'd like to give it a try, but I cannot get any -CURRENT kernel booting on my machine. Both cross-compiled kernels as well as natively-built ones seem to hit the same problem, so it's likely not a GCC9 issue. I'll attach a dmesg.boot file from a natively-built 12-STABLE system to give people a clue on what hardware the system has. The newest kernel that I tested is a cross-built r356986. I re-read AF3e's chapter on crash dumps, trying to provide something useful, but I guess that the crash happens too early and the system cannot dump anything, yet. So here's the serial output that I get: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc00b8020. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 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 13.0-CURRENT #0 r356986: Wed Jan 22 16:54:54 CET 2020 r...@fbsdtest.omc.net:/usr/obj/usr/src/sparc64.sparc64/sys/GENERIC sparc64 gcc version 9.2.0 (FreeBSD Ports Collection for sparc64) WARNING: WITNESS option enabled, expect reduced performance. real memory = 1073741824 (1024 MB) avail memory = 1024761856 (977 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (548.00 MHz CPU) random: unblocking device. random: entropy device external interface [ath_hal] loaded WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. kbd0 at kbdmux0 WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "openprom" is Giant locked and may be deleted before FreeBSD 13.0. nexus0: pcib0: mem 0x1fe-0x1fe,0x1fe0100-0x1fe01ff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 66MHz pcib0: DVMA map: 0x6000 to 0x63ff 8192 entries pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 3.0 (no driver attached) dc0: port 0x1-0x100ff mem 0-0xff at device 12.0 on pci0 miibus0: on dc0 amphy0: PHY 1 on miibus0 amphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:03:ba:4e:55:e6 dc1: port 0x10100-0x101ff mem 0x2000-0x20ff at device 5.0 on pci0 miibus1: on dc1 amphy1: PHY 1 on miibus1 amphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:03:ba:4e:55:e6 ohci0: mem 0x100-0x1000fff at device 10.0 on pci0 usbus0 on ohci0 atapci0: port 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f at device 13.0 o n pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 cryptosoft0: on nexus0 nexus0: type unknown (no driver attached) rtc0: at port 0x70-0x71 pnpid PNP0b00 on isa0 rtc0: registered as a time-of-day clock, resolution 1.00s uart0: console (9600,n,8,1)> at port 0x3f8-0x3ff irq 43 pnpid PNP0501 on isa0 uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 pnpid PNP0501 on isa0 Timecounter "tick" frequency 54800 Hz quality 1000 Event timer "tick" frequency 54800 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 Obsolete code will be removed soon: random(9) is the obsolete Park-Miller LCG from 1988 panic: invalid count 2 cpuid = 0 time = 1 KDB: stack backtrace: _end() at 0xc1416fb8 vpanic() at vpanic+0x31c panic() at panic+0x20 sched_switch() at sched_switch+0x8ac mi_switch() at mi_switch+0x1dc critical_exit_preempt() at critical_exit_preempt+0x88 spinlock_exit() at spinlock_exit+0x70 __mtx_unlock_spin_flags() at __mtx_unlock_spin_flags+0xb0 sched_add() at sched_add+0x2e8 gtaskqueue_start_threads() at gtaskqueue_start_threads+0x254 taskqgroup_cpu_cre
