[Bug 271062] [PATCH] add support for 28xx based device to isp(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271062 Bug ID: 271062 Summary: [PATCH] add support for 28xx based device to isp(4) Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: joerg.p...@frm2.tum.de Flags: mfc-stable13? Created attachment 241735 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241735&action=edit patch for CURRENT and RELENG-13.2 Add support for QLogic devices based on 28xx to isp(4) namely: ISP2812-based 64/32G Fibre Channel to PCIe Controller: QLE2770 Single Port 32GFC PCIe Gen4 x8 Adapter QLE2772 Dual Port 32GFC PCIe Gen4 x8 Adapter QLE2870 Single Port 64GFC PCIe Gen4 x8 Adapter QLE2872 Dual Port 64GFC PCIe Gen4 x8 Adapter ISP2814-based 64/32G Fibre Channel to PCIe Controller: QLE2774 Quad Port 32GFC PCIe Gen4 x16 Adapter QLE2874 Quad Port 64GFC PCIe Gen4 x16 Adapter The attached patch enables device detection and adds support for 64GB FC. Sample dmesg(8) output of an ISP2812-based "QLE2772 Dual Port 32GFC PCIe Gen4 x8 Adapter" with an 16GBit/s storage attached: - isp0: mem 0xeea05000-0xeea05fff,0xeea02000-0xeea03fff,0xee90-0xee9f at device 0.0 numa-domain 1 on pci13 isp0: Board Type 2800, Chip Revision 0x2, resident F/W Revision 9.4.1 isp0: Attributes: Class2 MultiID T10CRC MQ MSIX VP0_Decoupling HotFW EXMOFF NPMOFF DIFCHOP ASICTMP ATIOMQ (unknown 0x16207802) isp0: 2048 max I/O command limit set isp0: invalid NVRAM header (ff ff ff) isp0: invalid NVRAM header (ff ff ff) isp0: Chan 0 0x40007f00/0x41007f00 Role Initiator isp0: bad frame length (0) from NVRAM - using 2048 isp1: mem 0xeea04000-0xeea04fff,0xeea0-0xeea01fff,0xee80-0xee8f at device 0.1 numa-domain 1 on pci13 isp1: invalid NVRAM header (ff ff ff) isp1: invalid NVRAM header (ff ff ff) isp1: bad frame length (0) from NVRAM - using 2048 isp0: Chan 0 LIP Received isp0: Chan 0 LIP Received isp0: Chan 0 LOOP Up isp0: Chan 0 Port Database Changed (nphdl 0x state 0x6 reason 0x0) isp0: Chan 0 Firmware state Ready> isp0: Chan 0 WWPN 41007f00 WWNN 40007f00 isp0: Chan 0 16Gb Point-to-Point (N_Port) PortID 0xe8 LoopID 0x00 isp0: Chan 0 [0] WWPN 0x50e0dc8ac220 PortID 0xef handle 0x0 (REC,TGT,RdXfrDis) arrived da1 at isp0 bus 0 scbus18 target 0 lun 0 da1: <> Fixed Direct Access SPC-4 SCSI device da1: Serial Number XX da1: 1600.000MB/s transfers WWNN 0x50e0dc8ac200 WWPN 0x50e0dc8ac220 PortID 0xef da1: Command Queueing enabled da1: 14931722MB (30580166656 512 byte sectors) - Some notes on the "invalid NVRAM header" and "bad frame length (0) from NVRAM": They do not harm and one will get the same messages with already supported ISP27xx (QLE2690/2692) devices. Looking at the linux driver code the NVRAM access is done somehow different. I'm currently further investigating this but it maybe related to the added "Firmware Integrity Protection with Hardware Root of Trust" and primary/secondary firmware images. A note to the default frame size: I haven't seen a single FC HBA or other FC device with a pre-configured default frame size lower than 2048. Therefor I decided to set it to 2048 as default for ISP28xx based HBAs as long as there is no way to read it from NVRAM. I would have changed this also for ISP27xx based HBAs (there is no NVRAM access too) but kept it for now on those and all others at 1024 just to not break any existing setups. Build and runtime tested on CURRENT and RELENG-13.2 on amd64. Probably a very good candidate for an MFC -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271063] setfacl(1) "trailing comma" should be "trailing colon"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271063 Bug ID: 271063 Summary: setfacl(1) "trailing comma" should be "trailing colon" Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: r...@rdd.nu CC: d...@freebsd.org In the setfacl(1) manual page under "NFSv4 ACL ENTRIES" > "ACL qualifier", I believe "including the trailing comma" i should be "including the trailing colon". -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269663] bmake: Interrupted phony target removes a file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269663 Mateusz Piotrowski <0...@freebsd.org> changed: What|Removed |Added Status|Open|Closed Resolution|--- |FIXED Assignee|b...@freebsd.org|s...@freebsd.org --- Comment #4 from Mateusz Piotrowski <0...@freebsd.org> --- The newest import of bmake into 14.0-CURRENT (bmake-20230414) seems to fix the reported issue. Thank you! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269418] ice(4): strips VLAN headers with netmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269418 Brian Poole changed: What|Removed |Added Keywords||IntelNetworking -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271065] Kernel FUSE limits read() size by 64k/128k
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271065 Bug ID: 271065 Summary: Kernel FUSE limits read() size by 64k/128k Product: Base System Version: 13.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rozhuk...@gmail.com I am trying to increase sshfs file read speed from remote mount with RTT ~70+ms and I need some help with kernel FUSE. Read speed is limited by RTT and read chunk size, RTT can not be fixed by code but we can increase read chunk size. sshfs -o remember=30 -o auto_cache -o cache=yes -o kernel_cache -o compression=yes -o max_write=67108864 -o max_read=67108864 -o dir_cache=yes -o noatime root@somehost:/ /mnt/tmp -d -v -o debug --debug + dd if='/mnt/tmp/some_big.file' of=/dev/null bs=4m status=progress produces: unique: 14130, opcode: READ (15), nodeid: 850, insize: 80, pid: 4468 [01249] READ [01250] READ [01247] DATA 131076bytes (95ms) [01248] DATA 22bytes (95ms) unique: 14130, success, outsize: 131088 If "sysctl vfs.maxbcachebuf=128k" then "unique: 14130, success, outsize: 131088" -> "unique: 14130, success, outsize: 262144". (sshfs hacked for read ahead) This increase read speed ~twice, but not enough to utilize 100m link. vfs.maxbcachebuf=512k or 1024k is ok for remote mount @ 100m link but if may be too big for other FS mounted locally. I found 64k limit in fuse_vfsop_mount(): "mp->mnt_stat.f_iosize = maxbcachebuf;". Then I try to change it to "maxphys" - system panics or hang on read() from sshfs mount. Looks like more changes required due to "fuse_iosize() { return mp->mnt_stat.f_iosize; }" used in many places, probably some of them expect only "maxbcachebuf". IMHO mp->mnt_stat.f_iosize = maxphys or maxphys/2 will be better default. Also if "max_read" is set and "maxbcachebuf < max_read < maxphys" then it can be used. Can some one help with this? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271065] Kernel FUSE limits read() size by 64k/128k
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271065 --- Comment #1 from Alan Somers --- If your userland program opens the file with O_DIRECT and tries to do large reads, what size of read does the server see? That should bypass the cache. I'm not saying that it's a permanent solution, but it might be a good experiment. The clustering and readahead code happens above the file system, up in the VFS. It enters fuse in fuse_vnop_strategy. I'm a little rusty in that area, but I think that you'll want to tweak settings so as to maximize the value of bp->b_bcount that the VFS sends in VOP_STRATEGY, rather than try to increase the size that we read from within there. You could try setting F_READAHEAD with fcntl, though I think it will still be limited by maxphys. By doing that, I'm able to get sizes of 1 MB in VOP_STRATEGY. And you should certainly be setting -o async_read in the sshfs process. If you're planning to change the clustering code itself, you should definitely talk to mckusick. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271065] Kernel FUSE limits read() size by 64k/128k
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271065 --- Comment #2 from Ivan Rozhuk --- There is no special user space program, this sshfs share used as usual disk share for home pc. mpv, thunar, pc-fm, image viewer and etc. After add "oflag=direct" to dd: unique: 18788, opcode: READ (15), nodeid: 868, insize: 80, pid: 84280 [03770] READ [03769] DATA 131085bytes (75ms) unique: 18788, success, outsize: 131088 It have same limit. fuse: unknown option(s): `-o async_read' looks like it was not handled. I do not see code to handle it in sshfs and in kernel FUSE. Read ahead is work. There is comment in kernel FUSE code that it read one block ahead, so this is why I got 64+64=128k read request. I have found that "mp->mnt_stat.f_iosize" first limit and "mp->mnt_iosize_max = maxphys;" is second limit for read size request that fuse server receive from kernel. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271066] netlink: nooptions NETLINK build fails after base 089104e0e01f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271066 Bug ID: 271066 Summary: netlink: nooptions NETLINK build fails after base 089104e0e01f Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: throwaway_vthg...@protonmail.com # cp sys/amd64/conf/GENERIC sys/amd64/conf/GENERIC-NONETLINK # echo "nooptions NETLINK" >> sys/amd64/conf/GENERIC-NONETLINK # make KERNCONF=GENERIC-NONETLINK WITHOUT_MODULES=yes -j$(nproc) buildkernel [...] --- netlink_generic_kpi.o --- ctfconvert -L VERSION -g netlink_generic_kpi.o --- netlink_glue.o --- /usr/src/sys/netlink/netlink_glue.c:285:15: error: no member named 'nl_modify_ifp' in 'struct nl_function_wrapper' return (_nl->nl_modify_ifp(ifp, lattrs, bm, npt)); ~~~ ^ /usr/src/sys/netlink/netlink_glue.c:282:1: error: no previous prototype for function 'nl_modify_ifp_generic' [-Werror,-Wmissing-prototypes] nl_modify_ifp_generic(struct ifnet *ifp, struct nl_parsed_link *lattrs, ^ /usr/src/sys/netlink/netlink_glue.c:281:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int ^ static /usr/src/sys/netlink/netlink_glue.c:289:1: error: redefinition of 'nl_store_ifp_cookie_stub' nl_store_ifp_cookie_stub(struct nl_pstate *npt, struct ifnet *ifp) ^ /usr/src/sys/netlink/netlink_glue.c:189:1: note: previous definition is here nl_store_ifp_cookie_stub(struct nl_pstate *npt __unused, struct ifnet *ifp __unused) ^ 3 errors generated. *** [netlink_glue.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NONETLINK -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271065] Kernel FUSE limits read() size by 64k/128k
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271065 --- Comment #3 from Ivan Rozhuk --- sshfs with "-o direct_io" unique: 15320, opcode: READ (15), nodeid: 865, insize: 80, pid: 24714 [01398] READ [01399] READ [01400] READ [01401] READ [01402] READ [01403] READ [01404] READ [01405] READ [01406] READ [01407] READ [01408] READ [01409] READ [01410] READ [01411] READ [01412] READ [01413] READ [01414] READ [01398] DATA 261133bytes (83ms) [01399] DATA 261133bytes (108ms) [01400] DATA 261133bytes (211ms) [01401] DATA 261133bytes (211ms) [01402] DATA 261133bytes (212ms) [01403] DATA 261133bytes (219ms) [01404] DATA 261133bytes (239ms) [01405] DATA 261133bytes (266ms) [01406] DATA 261133bytes (294ms) [01407] DATA 261133bytes (321ms) [01408] DATA 261133bytes (347ms) [01409] DATA 261133bytes (373ms) [01410] DATA 261133bytes (396ms) [01411] DATA 261133bytes (420ms) [01412] DATA 261133bytes (446ms) [01413] DATA 261133bytes (464ms) [01414] DATA 157bytes (464ms) unique: 15320, success, outsize: 261136 This looks broken, like prev output. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271062] [PATCH] add support for 28xx based device to isp(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271062 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #1 from Warner Losh --- I generally like this patch... however... - isp_prt(isp, ISP_LOGERR, "bad frame length (%d) from NVRAM- using %d", DEFAULT_FRAMESIZE(isp), ICB_DFLT_FRMLEN); - icbp->icb_maxfrmlen = ICB_DFLT_FRMLEN; + if (IS_28XX(isp)) { + isp_prt(isp, ISP_LOGERR, "bad frame length (%d) from NVRAM - using %d", DEFAULT_FRAMESIZE(isp), ICB_DFLT_FRMLEN_28XX); + icbp->icb_maxfrmlen = ICB_DFLT_FRMLEN_28XX; + } else { + isp_prt(isp, ISP_LOGERR, "bad frame length (%d) from NVRAM - using %d", DEFAULT_FRAMESIZE(isp), ICB_DFLT_FRMLEN); + icbp->icb_maxfrmlen = ICB_DFLT_FRMLEN; + } looks a little ugly to me. I'd be tempted to add a icbp->icb_dflt_frmlen field where we detect the 2800, set a different value. That way, we'd not need the if here with the code duplication. Other than that, the patch looks very good. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262950] 13.1-BETA3: weird top SWAP output
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262950 Thomas Hurst changed: What|Removed |Added CC||t...@hur.st --- Comment #1 from Thomas Hurst --- Indeed, running out of swap gets you: Swap: 8192M Total, 8192M Used, K Free, 100% Inuse Looking at display.c:summary_format(), if the value were zero it would just skip that field, but if it becomes negative it displays the field name without a value: if (num > 0) .. /* ignore negative numbers, but display corresponding string */ else if (num < 0) { p = stpcpy(p, thisname); } Seems a bit arbitrary. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271065] Kernel FUSE limits read() size by 64k/128k
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271065 --- Comment #4 from Alan Somers --- (In reply to Ivan Rozhuk from comment #2) > fuse: unknown option(s): `-o async_read' > looks like it was not handled. > I do not see code to handle it in sshfs and in kernel FUSE. Annoying, because it's mentioned in the sshfs man page: https://linux.die.net/man/1/sshfs . > Read ahead is work. There is comment in kernel FUSE code that it read one > block ahead, so this is why I got 64+64=128k read request. Where do you see that comment? It's definitely possible to read ahead more than that. For example: $ cd /usr/tests/sys/fs/fusefs $ sudo sysctl vfs.usermount=1 $ sudo kldload fusefs $ mkdir mountpoint $ sudo chmod 1777 mountpoint $ ./read --gtest_filter=RA/ReadAhead.readahead/3 -v Note: Google Test filter = RA/ReadAhead.readahead/3 [==] Running 1 test from 1 test case. [--] Global test environment set-up. [--] 1 test from RA/ReadAhead [ RUN ] RA/ReadAhead.readahead/3 INITino= 0 ACCESS ino= 1 mask=0x1 LOOKUP ino= 1 some_file.txt OPENino=42 flags=0 BMAPino=42 block=0 blocksize=0x1 READino=42 offset=0 size=262144 [ OK ] RA/ReadAhead.readahead/3 (2 ms) [--] 1 test from RA/ReadAhead (2 ms total) [--] Global test environment tear-down [==] 1 test from 1 test case ran. (2 ms total) [ PASSED ] 1 test. That shows a 256kB read. By tweaking the test's source a bit, I can make it read up to 1 MB. I haven't tried higher. The FUSE server can limit the amount of readahead at mount time. Looking at the source, it seems that sshfs sets the limit to UINT_MAX. However, I see a discrepancy between what libfuse does and what the fusefs test suite does. Could you please try this patch and tell me what you find? diff --git a/sys/fs/fuse/fuse_internal.c b/sys/fs/fuse/fuse_internal.c index 6ac7b4432e23..173fe7a71234 100644 --- a/sys/fs/fuse/fuse_internal.c +++ b/sys/fs/fuse/fuse_internal.c @@ -1096,7 +1096,7 @@ fuse_internal_send_init(struct fuse_data *data, struct thread *td) * fusefs currently reads ahead no more than one cache block at a time. * See fuse_read_biobackend */ - fiii->max_readahead = maxbcachebuf; + fiii->max_readahead = maxphys; /* * Unsupported features: * FUSE_FILE_OPS: No known FUSE server or client supports it -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271066] netlink: nooptions NETLINK build fails after base 089104e0e01f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271066 Marek Zarychta changed: What|Removed |Added CC||zarych...@plan-b.pwste.edu. ||pl --- Comment #1 from Marek Zarychta --- (In reply to throwaway_vthgwq4 from comment #0) You are probably missing WITHOUT_NETLINK_SUPPORT in make.conf -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271066] netlink: nooptions NETLINK build fails after base 089104e0e01f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271066 --- Comment #2 from throwaway_vthg...@protonmail.com --- (In reply to Marek Zarychta from comment #1) No difference with and without {make,src}.conf. I started using WITHOUT_NETLINK_SUPPORT in src.conf after it was introduced. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271065] Kernel FUSE limits read() size by 64k/128k
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271065 --- Comment #5 from Ivan Rozhuk --- > Annoying, because it's mentioned in the sshfs man page: > https://linux.die.net/man/1/sshfs . It is opposite to "sync" option that handled by sshfs. I will fix that. > Where do you see that comment? * fusefs currently reads ahead no more than one cache block at a time. > Could you please try this patch and tell me what you find? unique: 318, opcode: READ (15), nodeid: 5, insize: 80, pid: 63228 [02387] READ [02388] READ [02389] READ [02390] READ [02391] READ [02392] READ [02393] READ [02394] READ [02395] READ [02378] DATA 131076bytes (186ms) [02379] DATA 131076bytes (208ms) [02380] DATA 131076bytes (208ms) [02381] DATA 131076bytes (209ms) [02382] DATA 131076bytes (209ms) [02383] DATA 131076bytes (226ms) [02384] DATA 131076bytes (264ms) [02385] DATA 131076bytes (275ms) [02386] DATA 85bytes (275ms) unique: 318, success, outsize: 1048592 This is work. Hover I set "conn->max_readahead = (1024 * 1024 * 64); /* 64mb. */" inside sshfs and got only 1 cacheblock. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271066] netlink: nooptions NETLINK build fails after base 089104e0e01f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271066 Alexander V. Chernikov changed: What|Removed |Added Assignee|b...@freebsd.org|melif...@freebsd.org Status|New |Open --- Comment #3 from Alexander V. Chernikov --- Thanks for reporting! Will fix tomorrow. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271062] [PATCH] add support for 28xx based device to isp(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271062 Mina Galić changed: What|Removed |Added CC||free...@igalic.co --- Comment #2 from Mina Galić --- (In reply to Joerg Pulz from comment #0) hi Joerg (Jörg?), may i suggest submitting that patch as GitHub pull request: https://docs.freebsd.org/en/articles/contributing/#contrib-how -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268393] system always reboots once from a powered off state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268393 --- Comment #44 from John Grafton --- (In reply to Jonathan Vasquez from comment #43) Huh, likely a driver problem then. Have you tested booting a 13.0 or 12.x kernel on this system? I'm wondering if the problem was introduced in 13.1. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271062] [PATCH] add support for 28xx based device to isp(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271062 Joerg Pulz changed: What|Removed |Added Attachment #241735|0 |1 is obsolete|| --- Comment #3 from Joerg Pulz --- Created attachment 241743 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241743&action=edit patch v2 for CURRENT and RELENG-13.2 Attached is a new patch that addresses Warner's remarks about code duplication. I should have done this like it is now at the first try. There is also documentation now that was totally missing in the first version. isp(4) Add all new supported devices ispfw(4) Add BUGS section to mention that firmware is only included for 24xx and 25xx based cards. As I've never used/done git pull requests before, I would like to skip this for now until I get used to it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271069] syslogd service inside client jail requires restart before server jail receives logs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271069 Bug ID: 271069 Summary: syslogd service inside client jail requires restart before server jail receives logs Product: Base System Version: 13.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: m...@svmhdvn.name I'm not sure if this is an actual bug or an issue with my system configuration: PROBLEM: In a centralized logging configuration with one client jail (sending logs) and one server jail (receiving logs and writing them to local files), syslogd inside the *client* jail requires a restart before I can observe on the *server* jail that the logs are successfully received. This is observed on a fresh start of the *server* jail, followed by a fresh start of the *client* jail. Is there a race condition or order of operations problem somewhere? Let me know if I need to supply more info about the configuration. DETAILS: I have a simple configuration of two standard thick jails (named 'ssh' and 'logs') with this configuration: = /etc/jail.conf = mount.devfs; allow.raw_sockets; exec.clean; exec.timeout = 30; stop.timeout = 30; path = "/usr/jail/guests/${name}"; host.hostname = "${name}.my.domain"; exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; logs { ip6.addr = "re0|fdac:::201/64"; } ssh { ip6.addr = "re0|fdac:::202/64"; depend = "logs"; } == Each jail has the same content in their host files and no DNS servers (i.e. name resolution is available through hosts files only): = /etc/hosts = [...] fdac:::201logs.my.domain logs fdac:::202ssh.my.domain ssh [...] == In the client jail ssh.my.domain: = /etc/syslog.conf *.*@logs.my.domain === = /etc/rc.conf syslogd_flags="-8 -O syslog -s -v -v" === In the server jail logs.my.domain: = /etc/syslog.conf +ssh.my.domain *.*/var/log/ssh.my.domain.log === = /etc/rc.conf syslogd_flags="-8 -O syslog -a '*.my.domain' -v -v" === Steps to repro (as root): 1. in the jailhost: # service jail onestart logs # service jail onestart ssh 2. inside logs.my.domain (for observing received logs): # tail -f /var/log/ssh.my.domain.log [...] follow the log 3. inside ssh.my.domain: # logger "hello from ssh" <--- *NOT* observed on the log server # service syslogd restart # logger "hello from ssh" <--- SUCCESS visible in log server -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271069] syslogd service inside client jail requires restart before server jail receives logs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271069 cr...@rlwinm.de changed: What|Removed |Added CC||cr...@rlwinm.de --- Comment #1 from cr...@rlwinm.de --- Can you please run `sockstat -l46` on the host and both jails? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271069] syslogd service inside client jail requires restart before server jail receives logs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271069 Siva Mahadevan changed: What|Removed |Added CC||m...@svmhdvn.name --- Comment #2 from Siva Mahadevan --- I'm just going to use `sockstat -l6` since this is an IPv6-only setup. I tried something simpler and noticed something interesting. After running `service jail onestart logs` on the jailhost, `sockstat -l6` on both the jailhost and inside the logs jail does *NOT* show `syslogd`. However, once I run `service syslogd restart` inside the jail, `sockstat -l6` shows syslogd successfully. I think this is a simpler repro and showcases the same problem, since on the client side, failure to bind to the address and port will be the root cause of the problem. Let me know if you still need the full syslog output (and at which point in time in the repro?). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271063] setfacl(1) "trailing comma" should be "trailing colon"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271063 Ceri Davies changed: What|Removed |Added Assignee|b...@freebsd.org|c...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271063] setfacl(1) "trailing comma" should be "trailing colon"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271063 Ceri Davies changed: What|Removed |Added Status|New |Open CC||c...@freebsd.org --- Comment #1 from Ceri Davies --- You're correct. Will take this. -- 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 #15 from Oleg --- Why is it not possible to use tab-autocompletion for the export command? I type exp, press tab, and don't see export in the list of commands available for tab-autocompletion. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271071] mpr (LSI SAS3808) only finds 53 out of 70 disks in external HP D6020 enclosure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271071 Bug ID: 271071 Summary: mpr (LSI SAS3808) only finds 53 out of 70 disks in external HP D6020 enclosure Product: Base System Version: 12.4-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: p...@lysator.liu.se Created attachment 241748 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241748&action=edit camcontrol devlist output In an attempt in fixing a problem where the HP ciss driver/HBA would go into a deadlock (probably due to a bad disk) I tried to replace the HP HBA with a LSI SAS3808 controller instead. It mostly works - only problem is that it only creates mappings for 53 och the 70 disks in the enclosure... (so the zpool import fails) # camcontrol devlist | fgrep scbus0 | fgrep da|wc -l 53 # mprutil show devices|fgrep SAS |wc -l 71 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271071] mpr (LSI SAS3808) only finds 53 out of 70 disks in external HP D6020 enclosure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271071 --- Comment #1 from Peter Eriksson --- Created attachment 241749 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241749&action=edit mprutil show devices output -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264145] Resume fails randomly on T480 (again on 13.1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264145 --- Comment #6 from brtastic@gmail.com --- I have updated to recently released 13.2-RELEASE. Been using the laptop heavily for the last two weeks (must've been well over 20 suspends) and haven't encountered this problem. So seems like even if it is still an issue in 13.2, it is rare enough to be tolerable. -- You are receiving this mail because: You are the assignee for the bug.