[Bug 231793] panic: [pmc,4965] pm=0xfffff80480ff2400 runcount 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231793 Matt Macy changed: What|Removed |Added Resolution|--- |FIXED 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 231793] panic: [pmc,4965] pm=0xfffff80480ff2400 runcount 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231793 --- Comment #5 from commit-h...@freebsd.org --- A commit references this bug: Author: mmacy Date: Fri Oct 5 05:55:57 UTC 2018 New revision: 339188 URL: https://svnweb.freebsd.org/changeset/base/339188 Log: hwpmc: Refactor sample ring buffer handling to fix races Refactor sample ring buffer ring handling to make it more robust to long running callchain collection handling r338112 introduced a (now fixed) regression that exposed a number of race conditions within the management of the sample buffers. This simplifies the handling and moves the decision to overwrite a callchain sample that has taken too long out of the NMI in to the hardlock handler. With this change the problem no longer shows up as a ring corruption but as the code spending all of its time in callchain collection. - Makes the producer / consumer index incrementing monotonic, making it easier (for me at least) to reason about. - Moves the decision to overwrite a sample from NMI context to interrupt context where we can enforce serialization. - Puts a time limit on waiting to collect a user callchain - putting a bound on head-of-line blocking causing samples to be dropped - Removes the flush routine which was previously needed to purge dangling references to the pmc from the sample buffers but now is only a source of a race condition on unload. Previously one could lock up or crash HEAD by running: pmcstat -S inst_retired.any_p -T and then hitting ^C After this change it is no longer possible. PR: 231793 Reviewed by: markj@ Approved by: re (gjb@) Differential Revision:https://reviews.freebsd.org/D17011 Changes: head/sys/dev/hwpmc/hwpmc_logging.c head/sys/dev/hwpmc/hwpmc_mod.c head/sys/sys/pmc.h head/sys/sys/pmckern.h -- 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 231967] [PowerPC64] Rebooting results in a hang after an OPAL command issued
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231967 Bug ID: 231967 Summary: [PowerPC64] Rebooting results in a hang after an OPAL command issued Product: Base System Version: CURRENT Hardware: powerpc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: sbr...@freebsd.org When rebooting the power8 machines (pylon and archon), the host will fully shutdown and hang after issuing the OPAL reboot command. I can see similar behavior from the debugger when I try to reset the host as well. I'm trying to update petitboot on these machines to see if that's a cause, but they are resisting. r...@pylon.nyi:~ # reboot Oct 3 14:50:58 pylon reboot[9337]: rebooted by root Oct 3 14:50:58 pylon syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 0 0 0 0 0 0 0 0 done Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop... done All buffers synced. Uptime: 5m1s [288855839410,5] OPAL: Reboot request... -- 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 231965] [PowerPC64] Cross compiling powerpc64 from amd64 results in nonfunctional locale installations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231965 Bug ID: 231965 Summary: [PowerPC64] Cross compiling powerpc64 from amd64 results in nonfunctional locale installations Product: Base System Version: CURRENT Hardware: powerpc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: sbr...@freebsd.org On the FreeBSD.ORG hosts, pylon, archon and ref12-ppc64, the installation of locales doesn't seem to be functional as reported by the use of tmux: sbruno@ref12-ppc64:~ % tmux tmux: need UTF-8 locale (LC_CTYPE) but have US-ASCII I'm unsure what we need to look at here to resolve this. It is reported that a native build of powerpc64 on a powerpc64 host results in a working locale installation. -- 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 231964] [PowerPC64] startup of local_unbound doesn't work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231964 Bug ID: 231964 Summary: [PowerPC64] startup of local_unbound doesn't work Product: Base System Version: CURRENT Hardware: powerpc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: sbr...@freebsd.org On the FreeBSD.ORG machines (archon and pylon) not to mention the ref12-ppc64.freebsd.org jail, the startup of local_unbound seems to work, but results in a machine that cannot lookup hosts. After booting up, restarting local_unbound solves the problem. -- 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 231923] [pci] AMD Ryzen X370 chipset PCIe bridge failed to allocate initial memory window
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231923 Mark Linimon changed: What|Removed |Added Keywords||regression -- 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 231859] ipoib datagram mode: unicast packets are received as multicast packets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231859 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- 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 231851] [patch] config: Error: device "atacard" is unknown, despite being described in sys/conf/NOTES
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231851 Mark Linimon changed: What|Removed |Added Keywords||patch -- 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 229473] support /etc/profile.d by default for sh environment snippets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229473 Mateusz Piotrowski <0...@freebsd.org> changed: What|Removed |Added Severity|Affects Only Me |Affects Many People CC||0...@freebsd.org -- 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 229473] support /etc/profile.d by default for sh environment snippets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229473 Jason W. Bacon changed: What|Removed |Added CC||j...@freebsd.org --- Comment #4 from Jason W. Bacon --- As someone who supports CentOS and FreeBSD in production, I'm potentially interested in this as well. It would simplify creating portable shell env customizations that work on both BSD and Linux. I wonder if there are security or stability concerns that someone might raise, though. A feature like this opens up the possibility of ports installing things that modify the default environment, unbeknownst to the sysadmin. If it goes forward, we would need checks in all the startup scripts, e.g. /etc/csh.cshrc, /etc/csh.login, /etc/profile, ... We might also want to check ${LOCALBASE}/etc/profile.d. -- 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 231296] smartpqi - kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231296 --- Comment #12 from Josh Gitlin --- (In reply to Andriy Gapon from comment #10) > it's quite possible that ARC contributes to the problem but > there is a bug in kmem_back / kmem_malloc. This is what I felt as well when reading the source. I didn't see any specific out of memory error, but rather a page fault which (to my untrained eye) looked like the kernel trying to access a KVA page that did not exist. But I was very unsure of my theory that it was a bug as opposed to a misconfiguration. What I found odd was that we had crashes on production systems where the config in place hadn't changed in years... -- 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 231296] smartpqi - kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231296 --- Comment #11 from rai...@ultra-secure.de --- Hi, I compiled a kernel myself with make buildkernel && make installkernel I had thought the debug kernel lived next to the kernel in /boot/kernel... (ewserv-log03-prod ) 0 # uname -a FreeBSD ewserv-log03-prod.everyware.zone 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Fri Sep 28 16:37:02 CEST 2018 r...@ewserv-log03-prod.everyware.zone:/usr/obj/usr/src/sys/GENERIC amd64 (ewserv-log03-prod ) 0 # ll /usr/lib/debug/boot/kernel/kernel.debug -r-xr-xr-x 1 root wheel 86179448 Sep 28 16:37 /usr/lib/debug/boot/kernel/kernel.debug (ewserv-log03-prod ) 0 # ll /boot/kernel/kernel -r-xr-xr-x 1 root wheel 27781528 Sep 28 16:37 /boot/kernel/kernel because I wasn't sure if the default kernel package contains a kernel with debug-symbols. What is the correct way to get a kernel with debug-symbols? I can reboot and run my tests again without the ARC reduction, to make sure this is the kernel that is producing the crashdump. It needed less than an hour to lock up. We would like to get this server back into production, but for now I can do whatever is necessary to solve this problem (apart from allowing direct logins - I'd have to wipe it) -- 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 229764] Default settings allow system to wire all ram
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229764 --- Comment #1 from Andriy Gapon --- First, ARC does not have any parallel or magic mechanism to wire memory. It uses uma(9) and those allocations go through the normal / common memory wiring mechanism. Second, vm.max_wired only affects memory wiring from userland (e.g. mlock(2) calls). It cannot deny kernel memory allocations. There is a different mechanism to stall kernel memory allocations (M_WAITOK) when the physical memory gets low. So, I am not sure if this proposal makes much sense. -- 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 231926] ldd can't operate on a segfaulting binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231926 --- Comment #5 from Ed Maste --- (In reply to Mark Johnston from comment #4) Proposed man page addition looks good to me. Maybe also .Xr readelf. -- 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 231926] ldd can't operate on a segfaulting binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231926 Mark Johnston changed: What|Removed |Added Resolution|FIXED |Not A Bug --- Comment #4 from Mark Johnston --- (In reply to Gleb Popov from comment #2) "Not a bug" makes more sense to me. (In reply to Ed Maste from comment #3) How about: diff --git a/usr.bin/ldd/ldd.1 b/usr.bin/ldd/ldd.1 index 5a06515ebd87..beff8450fdb6 100644 --- a/usr.bin/ldd/ldd.1 +++ b/usr.bin/ldd/ldd.1 @@ -57,6 +57,14 @@ option displays a verbose listing of the dynamic linking headers encoded in the executable. See the source code and include files for the definitive meaning of all the fields. +.Sh IMPLEMENTATION NOTES +.Nm +lists the dependencies of an executable by setting +.Xr rtld 1 +environment variables and running the executable in a child process. +If the executable is corrupt or invalid, +.Nm +may fail without providing any diagnostic error messages. .Sh EXAMPLES The following is an example of a shell pipeline which uses the .Fl f -- 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 231296] smartpqi - kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231296 --- Comment #10 from Andriy Gapon --- (In reply to rainer from comment #9) The problem might be similar but it is certainly different. In the other bug they are getting a panic (unfortunately the panic message is not shown), while you are getting a fatal trap / page fault. Also, in your case there is no ARC calls in the stack trace. It's straight from the ZIO code to the VM code. So, it's quite possible that ARC contributes to the problem (e.g., by creating a memory pressure or some such), but there is a bug in kmem_back / kmem_malloc. Finally, in comment #3 the stack trace recorded by ddb and the stack trace shown by kgdb do not match. I suspect that that is because you passed a wrong kernel to kgdb or /usr/lib/debug/boot/kernel does not match /boot/kernel. -- 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 231926] ldd can't operate on a segfaulting binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231926 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #3 from Ed Maste --- (In reply to Gleb Popov from comment #2) Perhaps we should have a note in ldd(1) though mentioning this issue, as it can be surprising. Aside, you can find first-level shared obj dependencies via readelf -d. -- 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 231296] smartpqi - kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231296 --- Comment #9 from rai...@ultra-secure.de --- Hi, Firmware revision is 1.60 (from HPE website). But it seems it is an ARC problem that just did not materialize on my other servers because ARC was limited there already, but is actually pretty widespread. Also, one of the first panics we got had the driver-name in the backtrace somewhere - but that was on the old firmware. I was notified of this PR privately: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231794 which seems to describe a similar problem. -- 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 231296] smartpqi - kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231296 Deepak Ukey changed: What|Removed |Added CC||deepak.u...@microsemi.com --- Comment #8 from Deepak Ukey --- Hi, Can you please tell me how to reproduce the issue or what are steps causing this panic. Also can you please provide me the what is firmware version you are using for E208i-p SR Gen10 / P408i-a SR Gen10 cards so that i can try reproducing this on my setup and help you to resolve this. Thanks. -- 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 231926] ldd can't operate on a segfaulting binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231926 Gleb Popov changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Gleb Popov --- Given I see nothing sensible in the backtrace, it is highly likely that the crash occurs before main. Should I close this PR with "Not a bug" then? -- 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 231296] smartpqi - kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231296 --- Comment #7 from rai...@ultra-secure.de --- At least, it ran through the night. -- 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 231296] smartpqi - kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231296 --- Comment #6 from rai...@ultra-secure.de --- OK. This is a setting that I have in my sysctl.conf.local but commented out by default (because not all hosts use ZFS and I somehow thought that it's only needed on hosts that do other stuff). I stumbled about this PR[1], too, a while ago and I have adjusted it on my ZFS hosts. Just not on this one because this one isn't supposed to run much else - other hosts run mysql and/or apache+php+nginx etc.pp. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229764 or rather, I took my settings from this one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163461 -- 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"