[Bug 282073] newsyslog(8): options in /etc/defaults/rc.conf not consistent with /etc/crontab
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282073 --- Comment #3 from Michael Osipov --- (In reply to Ed Maste from comment #2) Darn, I thnk you are totally right. I have missed that out. Both runs are logically decoupled. Only the cronjob performs actual rotations. I think we can close this one out. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282073] newsyslog(8): options in /etc/defaults/rc.conf not consistent with /etc/crontab
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282073 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #2 from Ed Maste --- What is the actual issue here? This looks expected to me, and using the same flags in the crontab would be an error (newsyslog would be broken with -N in crontab). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282096] Makefile.inc1 never sets MK_CLEAN to "yes"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282096 Bug ID: 282096 Summary: Makefile.inc1 never sets MK_CLEAN to "yes" Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: truck...@freebsd.org CC: ema...@freebsd.org Makefile.inc1 sets MK_CLEAN to "no" under certain conditions when the clean step should be skipped, but it never sets MK_CLEAN to "yes". This causes the clean step to be skipped when it really should be executed. This seems to have been broken for >4 years, since git:75766799863334570acf7a65510361f470ce3b3e. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282075] ipfw: -n switch is broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282075 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|i...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282095] enic breaks when changing MTU on interfaces with fib other than 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282095 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.
[Bug 282095] enic breaks when changing MTU on interfaces with fib other than 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282095 Bug ID: 282095 Summary: enic breaks when changing MTU on interfaces with fib other than 0 Product: Base System Version: 14.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: freebsd-bugzi...@thismonkey.com I'm running a Cisco UCS C220M4 with an MLOM card (2 x 10Gb). I wanted to test the enic driver for throughput, so I plugged a DAC cable between the ports, installed a fresh version of 14.1-RELEASE and ran the following: sysctl net.fibs=3 ifconfig enic0 inet 172.12.1.1/24 fib 1 ifconfig enic1 inet 172.12.2.1/24 fib 2 route add 172.12.2.0/24 -iface enic0 -fib 1 route add 172.12.1.0/24 -iface enic1 -fib 2 I could then ping/iper3 between the interfaces no problem (with setfib 1 ...) As soon as I alter the MTU of either interface to 9000 bytes, I can no longer ping, all IP breaks. PS. The reason I wanted to bump the MTU was I could only get ~3.7Gb/s of UDP across the interfaces: [ 5] 0.00-10.00 sec 4.27 GBytes 3.67 Gbits/sec 0.001 ms 1142296/4280693 (27%) receiver You can see 27% from the sender's side was dropped. Packets were 1460 bytes. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282073] newsyslog(8): options in /etc/defaults/rc.conf not consistent with /etc/crontab
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282073 Bug ID: 282073 Summary: newsyslog(8): options in /etc/defaults/rc.conf not consistent with /etc/crontab Product: Base System Version: 13.4-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: micha...@freebsd.org /etc/crontab says: > # Rotate log files every hour, if necessary. > 0 * * * * rootnewsyslog but /etc/defaults/rc.conf says: > newsyslog_enable="YES" # Run newsyslog at startup. > newsyslog_flags="-CN" # Newsyslog flags to create marked files This means that the behavior is different in the default setup and there is no comment that the admin is supposed to sync them. There are several ways to solve that: * Add default flags to crontab and add comment that the admin needs to sync (ugly) * Run "service newsyslog onestart" (in case it has been disabled) from crontab to have it consistent with "> /dev/null" to omit the message hourly or remove the message altogether -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282073] newsyslog(8): options in /etc/defaults/rc.conf not consistent with /etc/crontab
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282073 Michael Osipov changed: What|Removed |Added CC||j...@freebsd.org, ||micha...@freebsd.org --- Comment #1 from Michael Osipov --- jrm@, I'd like to work on this, but want to agree first which direction should we take here. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 256594] AMD Ryzen CPU stutter (responsiveness lag)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 --- Comment #14 from Jack --- It looks like the stuttering is gone with the hacks removed now. Will reply if issue comes back, thanks! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 246514] w(1) truncates output before passing to libxo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246514 Baptiste Daroussin changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #9 from Baptiste Daroussin --- This has been fixed since -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282075] ipfw: -n switch is broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282075 Bug ID: 282075 Summary: ipfw: -n switch is broken Product: Base System Version: 14.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rx5...@gmail.com Hello. I upgraded from 13.3 to 14.1-p5. [root@vt ~]# uname -a FreeBSD ven-t.todes.by 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64 [root@vt ~]# [root@vt ~]# freebsd-version -kru 14.1-RELEASE-p5 14.1-RELEASE-p5 14.1-RELEASE-p5 [root@vt ~]# I try this: [root@vt ~]# ipfw table 19 destroy [root@vt ~]# ipfw -n table 19 create [root@vt ~]# ipfw table 19 create [root@vt ~]# ipfw -n table 19 add 10.10.10.10 ipfw: DEPRECATED: inserting data into non-existent table 19. (auto-created) ignored: 10.10.10.10/32 0 [root@vt ~]# ipfw -S list 65520-65535 65531 set 0 deny log ip from any to any 65535 set 31 deny ip from any to any [root@vt ~]# [root@vt ~]# ipfw -n add 65530 deny ip from any to any 65530 deny ip from any to any [root@vt ~]# [root@vt ~]# ipfw add 65530 deny ip from any to any 65530 deny ip from any to any [root@vt ~]# [root@vt ~]# ipfw -S list 65520-65535 65530 set 0 deny ip from any to any 65531 set 0 deny log ip from any to any 65535 set 31 deny ip from any to any [root@vt ~]# [root@vt ~]# ipfw -n delete 65530 ipfw: rule 65530 not found [root@vt ~]# [root@vt ~]# ipfw delete 65530 [root@vt ~]# [root@vt ~]# [root@vt ~]# ipfw -S list 65520-65535 65531 set 0 deny log ip from any to any 65535 set 31 deny ip from any to any [root@vt ~]# -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276304] w(1) with --libxo=json produces invalid JSON output parameter on Croatian locale
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276304 --- Comment #7 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bd490be57438a82c22d1274bc58d51142b63f4a0 commit bd490be57438a82c22d1274bc58d51142b63f4a0 Author: Baptiste Daroussin AuthorDate: 2024-10-14 07:37:46 + Commit: Baptiste Daroussin CommitDate: 2024-10-14 08:43:38 + w(1): fix libxo output being locale dependant by being locale dependant the json export is invalid in locales where the separator for float is a comma. The Json and the XML are invalid for login-time when days contains contains characters which are not unicode. Forcing locale to be C, makes this json and xml output valid and also identical accross locales, so reliable for parsers PR: 276304 Reported by:Vedran Miletic usr.bin/w/w.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 Mark Johnston changed: What|Removed |Added Attachment #253995|0 |1 is obsolete|| Attachment #254020|0 |1 is obsolete|| --- Comment #38 from Mark Johnston --- Created attachment 254221 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254221&action=edit accounting patch The main symptom which made me suspect a kernel bug was the accounting problem in top. Do you recall whether this problem occurred when swap was enabled? If so, then we probably do indeed have a kernel bug. In any case, I attached a patch which fixes the accounting problem that occurs with swap disabled. It would be useful to test that on top of the existing patches. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282075] ipfw: -n switch is broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282075 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #1 from Andrey V. Elsukov --- So what exactly is broken? I just tested all commands that you did with '-n' argument and all commands did not modify firewall rules. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #39 from Henrich Hartzer --- (In reply to Mark Johnston from comment #38) I'm not certain about the accounting bug with swap, but the "a thread waited too long to allocate a page" behavior was happening with swap. The swap was setup in the default manner by the installer for a ZFS + geli + encrypted swap configuration. I'll give that patch a try. I consolidated all patches into one that applies on 14.1. Hopefully it looks correct. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #40 from Henrich Hartzer --- Created attachment 254227 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254227&action=edit Three patches in one for 14.1-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 243177] open(2): Add O_CREATFIFO flag
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243177 --- Comment #4 from Brooks Davis --- I've thought about this some more (and returned from last week's travel). Consider the following code: -- char path[] = "/some/path"; int fd; mode_t = 0600; struct stat sb; assert(mkfifo(path, mode) == 0); /* (1) A fifo was created at "/some/path". */ assert((fd = open(path, O_RDWR)) != -1); /* * (2) Some file existed at "/some/path" and was opened. * It might or might not be a fifo. */ assert(fstat(fd, &sb) == 0 && (sb.st_mode & S_IFMT) == S_IFIFO); /* * (3) The file we opened in (2) was a fifo. * "/some/path" might still exist. * "/some/path" might be a fifo. * "/some/path" might even be the fifo we created. */ -- With the proposed O_CREATFIFO flag, this would be equivalent to: -- char path[] = "/some/path"; int fd; mode_t = 0600; assert((fd = open(path, O_RDWR|O_CREATFIFO|O_EXCL, mode)) != -1); /* * A fifo was created at "/some/path" and we opened it. * "/some/path" might still exist. * "/some/path" might be a fifo. * "/some/path" might even be the fifo we created. */ -- Closing the race between mkfifo(2) and open(2) saves one or two syscalls in an uncommon path, but nothing more. At the end of either snippet, there's no assurance that some client who opens "/some/path" will open the other end of the file referred by `fd` because AFACT we can do nothing to guarantee that. I can see a symmetry argument for the flag (or a dedicated syscall), but it would take a real world example or three to convince me there's an interesting race to close. -- You are receiving this mail because: You are the assignee for the bug.
