[Bug 265463] sh crashes during fuzz testing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265463 --- Comment #1 from Evgeniy --- Created attachment 235502 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235502&action=edit Forgot to put db -- You are receiving this mail because: You are the assignee for the bug.
[Bug 229745] ahcich: CAM status: Command timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745 Daniel Menelkir changed: What|Removed |Added CC||dmenel...@gmail.com --- Comment #66 from Daniel Menelkir --- (In reply to Chris from comment #64) Try smartctl with a USB (archlinux ISO have smartmontools afaik), or even Hirens BootCD (it's a mini windows with some tools if you're not familiar). (In reply to Andriy Gapon from comment #65) I don't think it's TRIM since I have the issues with two HDDs with different brands/speeds. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 229745] ahcich: CAM status: Command timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745 --- Comment #67 from Chris --- In reply to Daniel (comment #66) Smartmontools are available on FreeBSD. The drives show no issue with the smartmontools. I believe there is a compatibility issue between the drives and the motherboard. I updated the BIOS and firmware on the server which didn't help. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056 Keith White changed: What|Removed |Added Attachment #235480|0 |1 is obsolete|| Attachment #235481|0 |1 is obsolete|| --- Comment #18 from Keith White --- Created attachment 235506 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235506&action=edit lang/go118 special case /dev/fuse on FreeBSD As suspected by asomers last year, go itself makes assumptions about what it can do with opened files. The attached patch makes "/dev/fuse" unpollable, and is probably much closer to "the right thing" to do. This go patch returns "rclone mount" functionality. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056 --- Comment #19 from Alan Somers --- The whole point of 7b8622fa220b9c08041102f638f848c48e022644 was to make /dev/fuse pollable. It is pollable now, in other languages. So there's probably still a bug somewhere in the Go code. Does Go wrongly assume that the file is ready to read if it polls ready to write? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 229745] ahcich: CAM status: Command timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745 --- Comment #68 from Daniel Menelkir --- (In reply to Chris from comment #67) I know, I mean to try different platforms. And to mention, this is an specific issue with 13.1+ZFS, I don't think it's something of the motherboard itself, since this issue is only happens (for now) on FreeBSD 13.1 with ZFS, since I had it in two different machines. If I use the disk for anything else, this doesn't happens. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056 --- Comment #20 from Keith White --- Not an issue for you! I think the issue is how go itself "thinks" kqueue works with a file or device. The comments in src/os/file_unix.go would seem to indicate that files that are always ready to write are a problem for go's poll code. It already special cases regular files: // Don't try to use kqueue with regular files on *BSDs. // On FreeBSD a regular file is always // reported as ready for writing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265466] Shutdown Causes System Reboot on FreeBSD 13
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265466 Bug ID: 265466 Summary: Shutdown Causes System Reboot on FreeBSD 13 Product: Base System Version: 13.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: njm...@gmail.com On FreeBSD 13.0, when I try to shut down one of my servers using the Web UI and/or console, the server reboots 5 - 10 seconds after it powers off. This behavior was/is not present in FreeBSD 12. Furthermore, this same issue occurs in TrueNAS Core 13, but not TrueNAS Core 12. The server specs are as follows: Intel R2000 Chasis Intel S2600GZ Motherboard 2 x Intel Xeon E5-2630L v2 2 x 16GB (32GB Total) ECC DDR3 Intel RMS25JB080 (LSI 2008) Flashed to IT Boot Pool: 2 x Intel DC S3610 SSDs (Mirrored) Storage Pool: 12 x 4TB HGST HUS724040ALS640 (6 drives per vdev, RaidZ2) I originally created a thread about this in the TrueNAS community forum, and another user (also running an Ivy Bridge CPU) posted they had experienced the same problem. https://www.truenas.com/community/threads/shutdown-causes-reboot-on-truenas-core-13-0-u1.102752/#post-706976 I have also reported this issue to iXSystems/TrueNAS: https://ixsystems.atlassian.net/browse/NAS-117384 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 229745] ahcich: CAM status: Command timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745 --- Comment #69 from Chris --- (In reply to Daniel Menelkir from comment #68) The issue happens with 12 as well and requires vfs.zfs.cache_flush_disable=1 and a power cycle to clear. I don't think it's a just a ZFS issue since a reboot just doesn't clear it. The system runs great with different disks. Using another OS or a different file system isn't an option for me and I don't have another system to replace it to continue running tests. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258056] sys/fs/fuse: commit 7b8622fa22 breaks net/rclone mount
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056 --- Comment #21 from Keith White --- (In reply to Keith White from comment #20) For more background reading. It looks like the go bug report 19093 (referenced in src/os/file_unix.go) gives more detail as to what go "assumes" and why regular BSD files were removed from polling. https://github.com/golang/go/issues/19093 Polling was added in change 36800 which explains, somewhat, what's expected and why go's polling doesn't work on all filetypes on all OSes? https://go-review.googlesource.com/c/go/+/36800/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258056] lang/go118: musn't poll /dev/fuse
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056 Alan Somers changed: What|Removed |Added Summary|sys/fs/fuse: commit |lang/go118: musn't poll |7b8622fa22 breaks |/dev/fuse |net/rclone mount| --- Comment #22 from Alan Somers --- So it sounds like they assume that regular files will always poll readable (not true for /dev/fuse) and anything that isn't a socket or a pipe will fail when you try to register it with kqueue/epoll (true for /dev/fuse until commit 7b8622fa220b9c08041102f638f848c48e022644). And since regular files are special cased on *BSD and fail to register with epoll, the poller code never worked for them. In that case I'd say that your change is the correct one. The change looks correct to me, though I haven't tested it. Please submit it upstream too. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262743] Memory leak in security/strongswan's charon daemon when communicating over vici socket.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262743 --- Comment #5 from Michał Skalski --- Thank you very much for the clues (In reply to Mark Millard from comment #4) Yes, using default value 12 (I used stock qemu VM image): # sysctl vm.pageout_oom_seq vm.pageout_oom_seq: 12 (In reply to Kubilay Kocak from comment #3) Result of `uname -a` (vm image FreeBSD-13.1-RELEASE)| FreeBSD freebsd 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64 and the same is for: FreeBSD freebsd 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64 Indeed, the packaged version (strongswan-5.9.6_2, either installed from binary package or built from ports) behaves different. Still memory usage increases, but only RSS one (VMS does not change in observable period) and in much lower scale, raise is rather logarithmic than linear. I compared then configure options for strongswan port and among other differences `--with-printf-hooks=builtin` option is specified by default for the port version. So I tested again sources of strongswan 5.9.6 - the same as used for ports and when the strongswan is configured with: ./configure --disable-kernel-netlink --enable-kernel-pfroute --enable-kernel-pfkey --disable-gmp --enable-openssl \ --enable-mediation --disable-scripts --with-group=wheel --enable-gcm --enable-ccm --enable-pkcs11 \ --with-printf-hooks=builtin (only `--with-printf-hooks=builtin` is added) the memory usage is similar to packaged version even for unpatched original sources. Without this option (or when port version is compiled with `libc` printf-hook which I believe is default one) memory usage raises quickly as in this bug report. I must have missed that on previous tests, I didn't notice that VMS does not rise, and RSS raises on much smaller scale. Also checked for `printf-hooks=vstr` and it is memory usage increase is slightly bigger than for `builtin`, but still VMS is constant. I'm still not sure if for `printf-hooks=builtin` memory does not raise too much, I will check it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253445] bectl: does not function in two-level zfs datasets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 --- Comment #38 from Jonathan Vasquez --- I've converted my existing one layer set up to a two layer one so I now have the option of either using bectl or doing the snapshotting/cloning myself, and still be compatible with the boot environment feature in the loader. I've also updated my guide recommendation accordingly: https://xyinn.org/md/freebsd/zfs_manual_partition_encrypted previous layout (all 'canmount' options were 'on'): tank tank/os <- this would have a mountpoint set to / tank/home <- /home new layout tank tank/os <- canmount=off, mountpoint=none tank/os/main <- main / dataset, canmount=noauto, mountpoint=none tank/home <- /home I can now either manually do a: zfs snapshot tank/os/main@test zfs clone tank/os/main@test tank/os/test and reboot and select "tank/os/test" in the bootloader's boot environment selection, and if it's good I can do a promotion and a deletion and set 'bootfs' on my pool accordingly if needed or I can do 'bectl create test' and 'bectl activate test'. I still think this feature is useful but not as high priority for me anymore.. I do prefer my new slightly modified layout :). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 262743] Memory leak in security/strongswan's charon daemon when communicating over vici socket.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262743 --- Comment #6 from Mark Millard --- (In reply to Michał Skalski from comment #5) Use of the likes of vm.pageout_oom_seq=120 should delay any kills for failures to reclaim enough memory to reach FreeBSD's target figure for free RAM. This can get extra time to inspect/investigate evidence about the on-going memory/RAM usage. Note: Using an increased vm.pageout_oom_seq is useful for avoiding failed-to-reclaim kills only for bounded-duration "stays running" activities. This can allow buildworld buildkernel -j4 on Small Board Computers with 4 cores and only 2 GiBytes of RAM, for example, when using the default tends to suffer failed-to-reclaim kills.) Note: In sufficiently modern variants of FreeBSD the messages about kills were improved and no longer always report being out of available swap space as the reason for the kill. The messaging about reclaim failures is an example of the improved messaging. Reclaim failures can happen even with a swap space being configured but little/none of the swap space being put to use. All it takes is one process (or m ore) that stays runnable while keeping nearly all the RAM pages in the active state (so: unable to be reclaimed). Even now, if a FreeBSD is modern enough to have the failed-to-reclaim message, if the message reports "out of swap" as the reason for a kill, the message is somewhat of a misnomer, in that kernel data structures for managing the swap areas ran out of space (internal fragmentation?), not the swap media. Note: My references to "stays running" presume leaving the kernel configured to allow process kernel stacks to be swapped out when a process has not stayed runnable. FreeBSD does not do such swap outs for processes that are runnable at the time. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258056] lang/go118: musn't poll /dev/fuse
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056 --- Comment #23 from Keith White --- Added upstream as https://github.com/golang/go/issues/54100 Assuming it gets noticed and incorporated, this FreeBSD bug could be "closed" or changed to "not an issue..." Thanks asomers for all your hints, support, etc.! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265471] loader: /boot/lua/menu.lua boots kernel from original bootenv when bootenv is changed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265471 Bug ID: 265471 Summary: loader: /boot/lua/menu.lua boots kernel from original bootenv when bootenv is changed Product: Base System Version: 13.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: crah...@gmail.com Created attachment 235516 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235516&action=edit Unload any previously loaded kernel when changing boot environment. Related to a bug fixed by Kyle Evans in commit e414851f3eb7a9dd2af8209eac4ada307cb6ff8e, if a password is set for the loader, when the boot environment is changed in the lua menu, the kernel originally loaded before the menu was brought up is booted in the new boot environment. Since the kernel directory isn't mounted, this prevents modules from being loaded during boot. In addition, if the reason for using the boot environment is to provide a known good kernel and environment, well... I've attached a patch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265472] /boot/loader: lua autoboot timer restarts if menu password is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265472 Bug ID: 265472 Summary: /boot/loader: lua autoboot timer restarts if menu password is set Product: Base System Version: 13.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: crah...@gmail.com Created attachment 235517 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235517&action=edit After interrupting the autoboot timeout, prevent it from restarting. In the lua loader, if one sets a password in loader.conf, the autoboot_delay timer will start before the menu is displayed. One can interrupt the autoboot and bring up the menu by entering a keyboard character before the timer expires. If this is done a prompt for the password is displayed. Entering the password will bring up the menu, but the timer will again start and another keyboard character must be entered or autoboot will abort the menu and boot the system. This is unexpected and not useful. A patch to correct the problem is attached. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265471] loader: /boot/lua/menu.lua boots kernel from original bootenv when bootenv is changed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265471 crah...@gmail.com changed: What|Removed |Added Attachment #235516|0 |1 is obsolete|| --- Comment #1 from crah...@gmail.com --- Created attachment 235518 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235518&action=edit Unload any previously loaded kernel when changing boot environment. Too much C, not enough Lua. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 229745] ahcich: CAM status: Command timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745 --- Comment #70 from Daniel Menelkir --- (In reply to Chris from comment #69) A zpool error isn't supposed to clear with a reboot. The test I've mentioned can be done with a live USB. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 229745] ahcich: CAM status: Command timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745 --- Comment #71 from Chris --- (In reply to Daniel Menelkir from comment #70) I didn't get any zpool errors. The system was hanging with cam status timeouts. Since I changed the disks the performance of the system improved considerably. -- You are receiving this mail because: You are the assignee for the bug.