[Bug 201953] Auditdistd does not recover from TLS errors and just stops
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201953 --- Comment #3 from commit-h...@freebsd.org --- A commit references this bug: Author: pjd Date: Thu Oct 4 05:54:58 UTC 2018 New revision: 339177 URL: https://svnweb.freebsd.org/changeset/base/339177 Log: When the adist_free list is empty and we lose connection to the receiver we move all elements from the adist_send and adist_recv lists back onto the adist_free list, but we don't wake consumers waitings for the adist_free list to become non-empty. This can lead to the sender process stopping audit trail files distribution and waiting forever. Fix the problem by adding the missing wakeup. While here slow down spinning on CPU in case of a short race in sender_disconnect() and add an explaination when it can occur. PR: 201953 Reported by: peter Approved by: re (kib) Changes: head/contrib/openbsm/bin/auditdistd/auditdistd.h head/contrib/openbsm/bin/auditdistd/sender.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 200139] Auditdistd suddenly stops working and leaves untransmitted files.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200139 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: pjd Date: Thu Oct 4 05:48:10 UTC 2018 New revision: 339176 URL: https://svnweb.freebsd.org/changeset/base/339176 Log: When we look for a new trail file there might be a race between find trail file name and opening it. This race was not properly handled, because we were copying new name before checking for openat(2) error and when we were trying again we were starting with the next trail file. This could result in skipping distribution of such a trail file. Fix this problem by checking for ENOENT first (only for .not_terminated files) and then updating (or not) tr_filename before restarting the search. PR: 200139 Reported by: peter Approved by: re (kib) Changes: head/contrib/openbsm/bin/auditdistd/trail.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 231933] bc hanging and leaving zombie of dc when being called by process with SIGCHLD blocked
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231933 Bug ID: 231933 Summary: bc hanging and leaving zombie of dc when being called by process with SIGCHLD blocked Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: vladim...@ixsystems.com Created attachment 197768 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=197768=edit Patch that fixes described issue In our system (http://www.freenas.org/) uwsgi application server calls a python program that calls a shell script that calls a shell script that calls bc and it hangs leaving us with hanging process tree like this: ``` 3135 |-- /usr/local/bin/uwsgi <...long text cut> 4435 | `-- /usr/local/bin/uwsgi <...long text cut> 8952 | |-- /bin/sh /usr/sbin/service smartd-daemon status 9087 | | `-- /bin/sh /usr/sbin/service smartd-daemon status 9088 | | `-- /bin/sh /usr/sbin/service smartd-daemon status 9090 | | `-- /usr/bin/bc 9091 | | `-- ``` This happens because bc relies on SIGCHLD to determine that dc has completed, wait for it and exit on it's own. SIGCHLD is blocked by uwsgi and this blocking is inherited by each it's subprocess. Our shell scripts are rather complicated and call a lot of other programs and bc was the only one that has this issue, so, despite no specification defines who should clear process signal mask, caller or callee, I think this should be fixed with simple patch attached. -- 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 197161] [patch] usr.bin/resizewin: Add program to query terminal size from emulator and update kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197161 dar...@dons.net.au changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #2 from dar...@dons.net.au --- This was committed at r297897 and I forgot to close this bug. -- 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 155163] [patch] Add Recursive Functionality to setfacl(1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155163 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2299 ||30 -- 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 231027] [META] FreeBSD-Foundation sponsored issues for FreeBSD 13-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231027 Ed Maste changed: What|Removed |Added Depends on||194974 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194974 [Bug 194974] Limit /dev/mem access to addresses in phys_avail[] - i.e. actual memory -- 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 231027] [META] FreeBSD-Foundation sponsored issues for FreeBSD 13-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231027 Ed Maste changed: What|Removed |Added Depends on||58 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=58 [Bug 58] renameat(2) capability error with absolute path names outside of a sandbox -- 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 206017] mips binary has segments with different permissions in same page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206017 Ed Maste changed: What|Removed |Added Assignee|ema...@freebsd.org |b...@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 192097] zpool status -x reports wrong information
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192097 Allan Jude changed: What|Removed |Added Status|New |Closed Resolution|--- |Works As Intended --- Comment #1 from Allan Jude --- It is a configuration error however. Using 512b for 4k devices will cause performance degradation because of the read-modify-write that the hardware will have to do for every 512b write. I don't think it makes sense to locally modify the behaviour of ZFS in this instance. Hopefully we will eventually get the "Time Variable Geometry" feature for ZFS that will allow all future allocations to be made 4k aligned, even in the face of pools created on older versions of FreeBSD where we didn't have quirks in place on some disks that lie about their sector size. Video and Slides about the feature. "Oh Shift!" https://www.youtube.com/watch?v=_-QAnKtIbGc https://drive.google.com/file/d/0B5fzqkw_-diCZFVTZlpua3hjNWs/view?usp=sharing -- 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 CC||ma...@freebsd.org --- Comment #1 from Mark Johnston --- ldd is very simple: it sets some magic rtld flags and exec()s the specified executable (or uses dlopen(RTLD_TRACE) for shared libs). For an executable, rtld will then print the dependencies and exit without actually calling into the executable. So a bug in the executable's code which causes a segfault should not be triggered when run by ldd, but if the executable itself is corrupted or invalid in some way, rtld may crash. This may or may not be a bug in rtld, depending on the nature of the corruption. In other words, if the executable is segfaulting before main() gets invoked, then the behaviour you're seeing is probably expected. To say for sure, we need to see exactly where the segfault is occurring. -- 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 230172] FreeBSD 11.2 fails to boot on Celeron J1900 after upgrade from 11.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172 r...@thiagoc.net changed: What|Removed |Added CC||r...@thiagoc.net --- Comment #15 from r...@thiagoc.net --- I can confirm this bug. Adding "kern.vty=sc" works. The system is an ASRock D1800B-ITX. -- 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 Bug ID: 231926 Summary: ldd can't operate on a segfaulting binary Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: arr...@freebsd.org When compiling lang/ghc port on FreeBSD 12, an executable named ghc-iserv-prof gets corrupted by some unrelated bug and segfaults when being launched. During `make stage-qa` the following command is called by qa.sh: env LD_LIBMAP_DISABLE=1 ldd -a /wrkdirs/usr/ports/lang/ghc/work/stage/usr/local/lib/ghc-8.4.3/bin/ghc-iserv-prof This command also results in a segfault with the same message: /wrkdirs/usr/ports/lang/ghc/work/stage/usr/local/lib/ghc-8.4.3/bin/ghc-iserv-prof: signal 11 I'm not sure if this is a bug in ldd, but I've got an impression that it shouldn't segfault even when given a broken executable. To reproduce on FreeBSD 12: # pkg install ghc # env LD_LIBMAP_DISABLE=1 ldd -a /usr/local/lib/ghc-8.4.3/bin/ghc-iserv-prof -- 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 211702] FreeBSD-11.0-BETA4-amd64 installation interface torn, illegible, after the FreeBSD boot loader menu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211702 Ed Maste changed: What|Removed |Added Hardware|ia64|amd64 CC||ema...@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 231923] [pci] AMD Ryzen X370 chipset PCIe bridge failed to allocate initial memory window
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231923 Bug ID: 231923 Summary: [pci] AMD Ryzen X370 chipset PCIe bridge failed to allocate initial memory window Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: greg@unrelenting.technology Running fairly recent modified CURRENT (actually ALPHA7) from September 26. (Haven't noticed PCIe related changes in the commits since then.) Moved the system from a SATA SSD to an NVMe one. The Mellanox network card that was installed in the bottom (connected to the X370 chipset) PCIe slot stopped working: pcib8: irq 32 at device 4.0 on pci3 pcib3: attempting to grow memory window for (0xfdf0-0xfe0f,0x20) front candidate range: 0xfdf0-0xfe0f pcib8: failed to allocate initial memory window: 0xfdf0-0xfe0f pcib3: allocated prefetch range (0xf080-0xf0ff) for rid 24 of pcib8 pcib8: domain0 pcib8: secondary bus 36 pcib8: subordinate bus 36 pcib8: prefetched decode 0xf080-0xf0ff pcib8: could not get PCI interrupt routing table for \134_SB_.PCI0.GPP2.PT02.PT24 - AE_NOT_FOUND pci8: on pcib8 pcib8: allocated bus range (36-36) for rid 0 of pci8 pci8: domain=0, physical bus=36 pcib3: attempting to grow memory window for (0xfe00-0xfe0f,0x10) front candidate range: 0xfe00-0xfe0f pcib8: failed to allocate initial memory window (0xfe00-0xfe0f,0x10) pci8: pci0:36:0:0 bar 0x10 failed to allocate map[18]: type Prefetchable Memory, range 64, base 0xf080, size 23, memory disabled pcib8: allocated prefetch range (0xf080-0xf0ff) for rid 18 of pci0:36:0:0 pcib2: matched entry for 3.0.INTA pcib2: slot 0 INTA hardwired to IRQ 32 pcib3: slot 4 INTA is routed to irq 32 pcib8: slot 0 INTA is routed to irq 32 pci8: at device 0.0 (no driver attached) [...] mlx4_core0: mem 0xf080-0xf0ff irq 32 at device 0.0 on pci8 mlx4_core: Mellanox ConnectX core driver v3.4.1 (October 2017) mlx4_core: Initializing mlx4_core pcib3: attempting to grow memory window for (0-0x,0x10) front candidate range: 0xfe10-0xfe1f back candidate range: 0xfe30-0xfe3f pcib8: failed to allocate initial memory window (0-0x,0x10) mlx4_core0: 0x10 bytes of rid 0x10 res 3 failed (0, 0x). mlx4_core0: Couldn't get PCI resources, aborting device_attach: mlx4_core0 attach returned 22 The same thing is happening to pcib9, which has one of the XHCI controllers on it (so some USB3 ports aren't working), but that's been happening even before the NVMe drive: xhci2: irq 32 at device 0.0 on pci9 pcib3: attempting to grow memory window for (0-0x,0x10) front candidate range: 0xfe10-0xfe1f back candidate range: 0xfe30-0xfe3f pcib9: failed to allocate initial memory window (0-0x,0x8000) xhci2: 0x8000 bytes of rid 0x10 res 3 failed (0, 0x). xhci2: Could not map memory device_attach: xhci2 attach returned 12 pciconf looks like this: pcib8@pci0:22:4:0: class=0x060400 card=0x33061b21 chip=0x43b41022 rev=0x02 hdr=0x01 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = '300 Series Chipset PCIe Port' class = bridge subclass = PCI-PCI bus range = 36-36 window[1c] = type I/O Port, range 32, addr 0xfff000-0xfff, disabled window[20] = type Memory, range 32, addr 0xfff0-0xf, disabled window[24] = type Prefetchable Memory, range 64, addr 0xf080-0xf0ff, enabled cap 05[50] = MSI supports 1 message, 64 bit cap 01[78] = powerspec 3 supports D0 D3 current D0 cap 10[80] = PCI-Express 2 downstream port max data 128(512) RO NS link x4(x4) speed 5.0(5.0) ASPM disabled(L0s/L1) slot 1 power limit 26000 mW cap 0d[c0] = PCI Bridge card=0x33061b21 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0019[200] = PCIe Sec 1 lane errors 0 ecap 001e[400] = unknown 1 Corrected = Receiver Error none1@pci0:36:0:0: class=0x02 card=0x002115b3 chip=0x675015b3 rev=0xb0 hdr=0x00 vendor = 'Mellanox Technologies' device = 'MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s]' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfe00, size 1048576, disabled bar [18] = type Prefetchable Memory, range 64, base 0xf080, size 8388608, disabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 03[48] = VPD cap 11[9c] = MSI-X supports 128 messages Table in map 0x10[0x7c000], PBA in map 0x10[0x7d000] cap 10[60] = PCI-Express 2 endpoint max data 128(256) FLR
[Bug 231897] kernel panic when xorg starts with legacy nvidia-drivers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231897 --- Comment #1 from core.dumped...@gmail.com --- gzipped core dump: https://goo.gl/ahYRp2 -- 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 231810] [build] release always fails with "mkimg: partition 2: No space left on device"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231810 l...@ratnaling.org changed: What|Removed |Added Version|CURRENT |11.2-RELEASE --- Comment #13 from l...@ratnaling.org --- Sorry, I had increased the size of the partition that /usr/src and /usr/obj were on, but forgot /tmp was on my root partition. They are all UFS. The src and obj are nullfs mounts. I suppose a sparse file would act differently if it were piped vs. stored? That's the only difference that patch makes. The only reason I did that was to better isolate my debug output, but it didn't help in that respect. -- 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 Josh Gitlin changed: What|Removed |Added CC||jgitlin+freebsd@goboomtown. ||com --- Comment #5 from Josh Gitlin --- I have experienced nearly the same issue, and requested help from the freebsd-fs list as I thought it might have been related to a kernel change or misconfiguration (even though the config we were using had not changed) See: https://lists.freebsd.org/pipermail/freebsd-fs/2018-September/026725.html Panic stack trace we saw was the exact same, happened under ZFS load (but not unusually high load, not higher than we've seen in production before) -- 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 231897] kernel panic when xorg starts with legacy nvidia-drivers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231897 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 231810] [build] release always fails with "mkimg: partition 2: No space left on device"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231810 --- Comment #12 from Matthias Apitz --- (In reply to leeb from comment #10) How is this possible, a 219G file in a 10G partition? What type of file is this? -- 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 187015] [panic] make_dev_credv: bad si_name (error=17, si_name=agpgart)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187015 --- Comment #16 from Tatsuki Makino --- By the way, how many PCs are affected by this bug in the whole world? My 855GME will no longer boot. orz -- 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"
