[Bug 255525] grep performance problem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255525 Duane changed: What|Removed |Added CC||parakl...@darkreality.org --- Comment #1 from Duane --- I see this was addressed here: https://cgit.freebsd.org/ports/commit/?id=ea62bacb8ac8978cd8f265cc385fd55cec051d1a I was wondering if it would be possible to please solve this using pcregrep instead of gnugrep. pcregrep uses the same engine as gnugrep and so has the same performance, but it is included as part of the pcre library which is much more likely to be required by other utilities, and also it doesn't replace any of the existing BSD commands. -- You are receiving this mail because: You are the assignee for the bug.
subscribe
Subscribe
[Bug 263278] boot(8) states mistakenly that a `?` at the end of the path lists directory contents
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263278 Bug ID: 263278 Summary: boot(8) states mistakenly that a `?` at the end of the path lists directory contents Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: gme...@mikroskosmos.gr Created attachment 233214 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=233214&action=edit Patch for boot(8) man page The man page for `boot` states: ? Give a short listing of the files in the root directory of the default boot device, as a hint about available boot files. (A ? may also be specified as the last segment of a path, in which case the listing will be of the relevant subdirectory.) It should be modified to: ? Give a short listing of the files in the root directory of the default boot device, as a hint about available boot files. (A ? may also be specified as the first segment of a path, in which case the listing will be of the relevant subdirectory.) i.e., the `last segment` should be changed to `first segment` -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255525] grep performance problem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255525 --- Comment #2 from Duane --- Created attachment 233215 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=233215&action=edit Replace gnugrep with pcregrep -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255525] grep performance problem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255525 --- Comment #3 from Duane --- Sorry, I've just realised that this bug relates to the performance of libc/regex in the base system, not the debootstrap port performance. I've come into this backwards through a search online. I'll resubmit against a separate bug request, please ignore my comments here. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263268] bsdgrep: support empty subexpressions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263268
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--- Comment #1 from Ed Maste ---
To address specific instances of this (before bsdgrep receives a change) one
could also translate (|foo) to (foo)? e.g. "^${user}([[:space:]]+.*)?$"
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 261728] If sh became a usable interactive shell, then why can't it tab-autocomplete file.(mine).1.txt and file.(mine).2.txt?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261728 --- Comment #13 from Piotr Pawel Stefaniak --- A fix for this (and another file name completion bug) just landed in main. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262590] [pf][patch] Anchor "blacklistd/*" not correctly shown in pfctl -a \* -s rules
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262590 --- Comment #15 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d86cf4435021d0abf3f3d65039583ee8cfde1be1 commit d86cf4435021d0abf3f3d65039583ee8cfde1be1 Author: Matteo Riondato AuthorDate: 2022-04-13 07:38:44 + Commit: Kristof Provost CommitDate: 2022-04-14 15:25:41 + pfctl: fix recursive printing of rules When asked to print rules recursively, correctly recurse for anchors included in pf.conf with "anchorname/*". PR: 262590 Reviewed by:kp MFC after: 3 weeks sbin/pfctl/pfctl.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262590] [pf][patch] Anchor "blacklistd/*" not correctly shown in pfctl -a \* -s rules
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262590 Matteo Riondato changed: What|Removed |Added Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263283] Packet drops on rock64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263283 Bug ID: 263283 Summary: Packet drops on rock64 Product: Base System Version: 13.0-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rich...@kojedz.in On a Rock64 board, I experience high packet drops: # ping -c 1000 -q -f -s 1472 172.16.47.254 PING 172.16.47.254 (172.16.47.254): 1472 data bytes --- 172.16.47.254 ping statistics --- 1000 packets transmitted, 845 packets received, 15.5% packet loss round-trip min/avg/max/stddev = 0.289/0.301/0.518/0.017 ms The errors are present in netstat: # netstat -n -I dwc0 NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll dwc0 1500 9e:c8:cb:a2:e2:c0 1141478 2982 0 1700981 0 0 This happens at gigabit speeds. If I limit the link speed to 100Mbit, no packet loss is present. Have checked all the cables, switch ports, etc. The same board works well with linux 5.15. Howewer, with linux 5.4 there were similar issues, but then it got fixed somehow. After some events (i.e. reboots, link up/down, port speed change) the situation changes, the nic enters into a more stable state, when packet loss is much lower, but still not zero. I cannot reliably reproduce this. After a reboot: # netstat -n -I dwc0 NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll dwc0 1500# ping -c 1000 -q -f -s 1472 172.16.47.254 PING 172.16.47.254 (172.16.47.254): 1472 data bytes --- 172.16.47.254 ping statistics --- 1000 packets transmitted, 1000 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.286/0.297/0.603/0.021 ms 9e:c8:cb:a2:e2:c0 82 0 0 83 0 0 # netstat -n -I dwc0 NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll dwc0 1500 9e:c8:cb:a2:e2:c0 2126 0 0 2113 0 0 How should I proceed debugging this? Richard -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263283] Packet drops on rock64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263283 Mark Linimon changed: What|Removed |Added Component|kern|arm Assignee|b...@freebsd.org|freebsd-...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263288] IPv6 system not responding to Neighbor Solicitation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263288 Bug ID: 263288 Summary: IPv6 system not responding to Neighbor Solicitation Product: Base System Version: 13.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: wcarson.bugzi...@disillusion.net Hello, recently after enabling ipv6_privacy in /etc/rc.conf and rebooting, I've been unable to get IPv6 connectivity to work in a hosted environment. (I don't know if this is a red herring or not.) I've tried disabling it, and even after rebooting, it still doesn't work. (Doesn't work meaning: I'm unable to ping6 hosts on the Internet that are reachable, e.g. ipv6.google.com.) I confirmed ipv6_privacy is actually disabled: # sysctl -a | grep tempaddr net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.prefer_tempaddr: 0 If I boot into a Linux environment (the provider has a Rescue mode), I'm able to reach IPv6 just fine. Furthermore, if I then reboot back into FreeBSD 13.0-RELEASE-p10 it will work for around ~5 minutes and then connections time out. Given the behavior and based on some tcpdumps, it looks like my system is not responding to the upstream router's Neighbor Solicitation messages. If I boot into Linux, it respond to the NS messages, the router caches the MAC address, and IPv6 works. If I'm fast enough and reboot into FreeBSD, IPv6 works until the the entry expires, and then I just see this: 13:24:58.901780 IP6 2600:3c00::f03c:91ff:feb0:a56f > 2605:6400:10:968:22:da15:28a6:c800: ICMP6, echo request, seq 40, length 16 13:24:59.277713 IP6 2600:3c00::8678:acff:fe1c:ec41 > ff02::1:ffb0:a56f: ICMP6, neighbor solicitation, who has 2600:3c00::f03c:91ff:feb0:a56f, length 32 13:24:59.277799 IP6 2600:3c00::8678:acff:fe1c:ec41 > ff02::1:ffb0:a56f: ICMP6, neighbor solicitation, who has 2600:3c00::f03c:91ff:feb0:a56f, length 32 3 packets, the echo request, then two NS requests, and no response -- and then it just repeats. I confirmed b0:a5:6f is the Device ID part of my MAC: # ifconfig em0 em0: flags=8863 metric 0 mtu 1500 options=481209b ether f2:3c:91:b0:a5:6f <--- inet6 fe80::f03c:91ff:feb0:a56f%em0 prefixlen 64 scopeid 0x1 inet6 2600:3c00::f03c:91ff:feb0:a56f prefixlen 64 autoconf inet6 2600:3c00:e000:137::1 prefixlen 128 inet6 2600:3c00:e000:137::1:1 prefixlen 128 inet6 2600:3c00:e000:137::2:1 prefixlen 128 inet6 2600:3c00:e000:137::3:1 prefixlen 128 inet6 2600:3c00:e000:137:cafe:8a2e:370:7334 prefixlen 128 inet 96.126.127.161 netmask 0xff00 broadcast 96.126.127.255 inet 173.255.203.45 netmask 0x broadcast 173.255.203.45 inet 96.126.122.129 netmask 0x broadcast 96.126.122.129 inet 50.116.26.213 netmask 0x broadcast 50.116.26.213 media: Ethernet autoselect (1000baseT ) status: active nd6 options=8023 Therefore the Solicited-node multicast address ff02::1:ffb0:a56f looks to be correct. I've also confirmed the router's address is within the assigned SLAAC network (Router: 2600:3c00::8678:acff:fe1c:ec41, SLAAC address: 2600:3c00::f03c:91ff:feb0:a56f/64).Furthermore, the multicast address does show up in `ifmcstat`: # ifmcstat em0: inet6 fe80::f03c:91ff:feb0:a56f%em0 scopeid 0x1 mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 group ff02::1:ff70:7334%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:ff:70:73:34 group ff02::1:ff03:1%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:ff:03:00:01 group ff02::1:ff02:1%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:ff:02:00:01 group ff02::1:ff01:1%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:ff:01:00:01 group ff02::1:ff00:1%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:ff:00:00:01 inet 96.126.127.161 igmpv3 rv 2 qi 125 qri 10 uri 3 group 224.0.0.1 mode exclude mcast-macaddr 01:00:5e:00:00:01 inet6 fe80::f03c:91ff:feb0:a56f%em0 scopeid 0x1 mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 group ff01::1%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:00:00:00:01 group ff02::2:bdc6:c84d%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:bd:c6:c8:4d group ff02::2:ffbd:c6c8%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:ff:bd:c6:c8 group ff02::1%em0 scopeid 0x1 mode exclude mcast-macaddr 33:33:00:00:00:01 group ff02::1:ffb0:a56f%em0 scopeid 0x1 mode exclude <
[Bug 262897] [ufs] [panic] Crash during chflags operation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262897 --- Comment #2 from Kirk McKusick --- Were you able to successfully do the operation after the system rebooted? Running `tunefs -p' on the affected filesystem might be useful. This is such a commonly used code path and with no likely locking races that it looks a lot like an undetected bit-flip in the hardware. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263289] [devfs] /bin/devfs usage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263289 Bug ID: 263289 Summary: [devfs] /bin/devfs usage Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: naito.yuich...@gmail.com When I type `devfs -s 1 rule show`, it fails by `illegal option -- s`. Because I see devfs usage as follows. ``` usage: devfs [-m mount-point] [-s ruleset] rule ... devfs [-m mount-point] ruleset ... ``` `devfs rule -s 1 show` succeeds and shows rules of ruleset 1. Is it mistake of usage? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255525] grep performance problem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255525 --- Comment #4 from Duane --- Just out of interest I had a look around at the available regex libraries and I think probably the way forward for base would be to update to the newer Henry Spencer regex library from within the TCL codebase. It's one of the smaller regex libraries around but uses NFA/DFA for speed. I would propose using https://github.com/garyhouston/hsrex as a starting point (this has been extracted from TCL by patching over the TCL dependencies). -- You are receiving this mail because: You are the assignee for the bug.
