[Bug 271062] [PATCH] add support for 28xx based device to isp(4)

2023-04-25 Thread bugzilla-noreply
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"

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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)

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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)

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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)

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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"

2023-04-25 Thread bugzilla-noreply
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"

2023-04-25 Thread bugzilla-noreply
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?

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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

2023-04-25 Thread bugzilla-noreply
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)

2023-04-25 Thread bugzilla-noreply
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.