Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

[Rick Macklem]

NAGY Andreas wrote:
>attached the trace. If I see it correct it uses FORE_OR_BOTH. (bctsa_dir: 
>>CDFC4_FORE_OR_BOTH (0x0003))
Yes. The scary part is the ExchangeID before the BindConnectiontoSession.
(Normally that is only done at the beginning of a new mount to get a ClientID,
 followed immediately by a CreateSession. I don't know why it would do this?)

The attached patch might get BindConnectiontoSession to work. I have no way
to test it beyond seeing it compile. Hopefully it will apply cleanly.

>The trace is only with the first patch, have not compiled the wantdeleg 
>patches so >far.
That's fine. I don't think that matters much.

>I think this is related to the BIND_CONN_TO_SESSION; after a disconnect the 
>ESXi >cannot connect to the NFS also with this warning:
>2018-03-07T16:55:11.227Z cpu21:66484)WARNING: NFS41: NFS41_Bug:2361: >BUG - 
>Invalid BIND_CONN_TO_SESSION error: NFS4ERR_NOTSUPP
If the attached patch works, you'll find out what it fixes.

>Another thing I noticed today is that it is not possible to delete a folder 
>with the >ESXi datastorebrowser on the NFS mount. Maybe it is a VMWare bug, 
>but with >NFS3 it works.
>
>Here the vmkernel.log with only one connection contains mounting, trying to 
>>delete a folder and disconnect:
>
>2018-03-07T16:46:04.543Z cpu12:68008 opID=55bea165)World: 12235: VC opID 
>>c55dbe59 maps to vmkernel opID 55bea165
>2018-03-07T16:46:04.543Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41_VSIMountSet:423: Mount server: 10.0.0.225, port: 2049, path: /, label: 
>>nfsds1, security: 1 user: , options: 
>2018-03-07T16:46:04.543Z cpu12:68008 opID=55bea165)StorageApdHandler: >977: 
>APD Handle  Created with lock[StorageApd-0x43046e4c6d70]
>2018-03-07T16:46:04.544Z cpu11:66486)NFS41: 
>>NFS41ProcessClusterProbeResult:3873: Reclaiming state, cluster 0x43046e4c7ee0 
>>[7]
>2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41FSCompleteMount:3791: Lease time: 120
>2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41FSCompleteMount:3792: Max read xfer size: 0x2
>2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41FSCompleteMount:3793: Max write xfer size: 0x2
>2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41FSCompleteMount:3794: Max file size: 0x8000
>2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41FSCompleteMount:3795: Max file name: 255
>2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)WARNING: NFS41: 
>>NFS41FSCompleteMount:3800: The max file name size (255) of file system is 
>>larger than that of FSS (128)
>2018-03-07T16:46:04.546Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41FSAPDNotify:5960: Restored connection to the server 10.0.0.225 mount 
>>point nfsds1, mounted as 1a7893c8-eec764a7-- ("/")
>2018-03-07T16:46:04.546Z cpu12:68008 opID=55bea165)NFS41: 
>>NFS41_VSIMountSet:435: nfsds1 mounted successfully
>2018-03-07T16:47:19.869Z cpu21:67981 opID=e47706ec)World: 12235: VC opID 
>>c55dbe91 maps to vmkernel opID e47706ec
>2018-03-07T16:47:19.869Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
>>NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 0x43046e4c6
I have no idea if getting BindConnectiontoSession working will fix this or not?

rick



bindconn.patch
Description: bindconn.patch
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problem with USB <---> UPS management connection

[Glen Barber]

On Wed, Mar 07, 2018 at 08:04:47PM -0500, Mark Saad wrote:
> > On Mar 7, 2018, at 6:55 AM, wishmaster  wrote:
> > 
> > Hi, colleagues!
> > 
> > Something strange happens with a server. I am attempting to connect 
> > management interface of UPS with server via USB.
> > In console I see a lot of errors:
> > 
> > Mar  7 13:42:04 xxx kernel: ugen2.2:  at 
> > usbus2
> > Mar  7 13:42:05 xxx kernel: uhid0 on uhub6
> > Mar  7 13:42:05 xxx kernel: uhid0:  > 0/0, rev 1.10/0.02, addr 2> on usbus2
> > Mar  7 13:42:08 xxx kernel: ugen2.2:  at 
> > usbus2 (disconnected)
> > Mar  7 13:42:08 xxx kernel: uhid0: at uhub6, port 3, addr 2 (disconnected)
> > Mar  7 13:42:08 xxx kernel: uhid0: detached
> > Mar  7 13:42:12 xxx kernel: ugen2.2:  at 
> > usbus2
> > Mar  7 13:42:12 xxx kernel: uhid0 on uhub6
> > Mar  7 13:42:12 xxx kernel: uhid0:  > 0/0, rev 1.10/0.02, addr 2> on usbus2
> > Mar  7 13:42:16 xxx kernel: ugen2.2:  at 
> > usbus2 (disconnected)
> > Mar  7 13:42:16 xxx kernel: uhid0: at uhub6, port 3, addr 2 (disconnected)
> > Mar  7 13:42:16 xxx kernel: uhid0: detached
> > 
> > I have changed USB-cables, USB port on the server - without success.
> > On another server this problem is absent.
> > 
> > FreeBSD version: FreeBSD 11.1-STABLE #1 r329364M:
> > 
> > Any ideas?
> > 
> All
>  I lost power at home and noticed that nut didn’t work right . I
> had a similar dmesg . My box is running 11.1-stable amd64 built
> from svn 7-8 days ago . When I get power back I’ll post details .
> 

This seems suspiciously similar to an issue I am seeing with a USB mouse
on both stable/11 a patched build of releng/11.1.  In my case, the dmesg
shows:

ugen1.3:  at usbus1 (disconnected)
ugen1.3:  at usbus1
ugen1.3:  at usbus1 (disconnected)
ugen1.3:  at usbus1

What struck me as "suspiciously similar" is the 'ugen' reference.
Unfortunately, I do not have more information yet, but have been
pounding my head on my desk throughout the day.  Then, I saw this
thread.

Anyone else seeing at least USB mouse-related issues?  It could entirely
be a red herring.

Glen



signature.asc
Description: PGP signature

Re: Problem with USB <---> UPS management connection

[Mark Saad]

All
 I lost power at home and noticed that nut didn’t work right . I had a similar 
dmesg . My box is running 11.1-stable amd64 built from svn 7-8 days ago . When 
I get power back I’ll post details . 

---
Mark Saad | nones...@longcount.org

> On Mar 7, 2018, at 6:55 AM, wishmaster  wrote:
> 
> Hi, colleagues!
> 
> Something strange happens with a server. I am attempting to connect 
> management interface of UPS with server via USB.
> In console I see a lot of errors:
> 
> Mar  7 13:42:04 xxx kernel: ugen2.2:  at 
> usbus2
> Mar  7 13:42:05 xxx kernel: uhid0 on uhub6
> Mar  7 13:42:05 xxx kernel: uhid0:  0/0, rev 1.10/0.02, addr 2> on usbus2
> Mar  7 13:42:08 xxx kernel: ugen2.2:  at 
> usbus2 (disconnected)
> Mar  7 13:42:08 xxx kernel: uhid0: at uhub6, port 3, addr 2 (disconnected)
> Mar  7 13:42:08 xxx kernel: uhid0: detached
> Mar  7 13:42:12 xxx kernel: ugen2.2:  at 
> usbus2
> Mar  7 13:42:12 xxx kernel: uhid0 on uhub6
> Mar  7 13:42:12 xxx kernel: uhid0:  0/0, rev 1.10/0.02, addr 2> on usbus2
> Mar  7 13:42:16 xxx kernel: ugen2.2:  at 
> usbus2 (disconnected)
> Mar  7 13:42:16 xxx kernel: uhid0: at uhub6, port 3, addr 2 (disconnected)
> Mar  7 13:42:16 xxx kernel: uhid0: detached
> 
> I have changed USB-cables, USB port on the server - without success.
> On another server this problem is absent.
> 
> FreeBSD version: FreeBSD 11.1-STABLE #1 r329364M:
> 
> Any ideas?
> 
> --
> Vitaliy
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

F5 Networks Users List.

[Amy Hodge]

Hi,

I would like to know if you are interested in acquiring F5 Networks Users List.



We have also new technology like: Juniper Networks, Cisco, Citrix, Check Point, 
Fortinet, VMware, Palo Alto Networks, NetApp, Brocade Communications Systems, 
Blue Coat Systems, Brocade Communications Systems, Riverbed Technology, 
Radware, Symantec, and Infoblox.



Information fields: Names, Title, Email, Phone, Company Name, Company URL, 
Company physical address, SIC Code, Industry, Company Size (Revenue and 
Employee).



Let me know if you are interested and I will get back to you with the counts 
and price list.

Regards,

Amy Hodge
Data Consultant



To opt out, please reply with Leave Out in the Subject Line.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re[2]: Problem with USB <---> UPS management connection

[wishmaster]

  

 --- Original message ---
From: "tech-lists" 
Date: 7 March 2018, 20:12:13

 
> On 07/03/2018 11:55, wishmaster wrote:
> > I have changed USB-cables, USB port on the server - without success.
> > On another server this problem is absent.
> 
> It looks like a broken or shorting connection but you say you've tried
> different ports on the machine and changed cables. I dunno, maybe the
> usb subsystem/circuitry in that machine is at fault? The way I'd test is
> to install a usb card known to be good and test again.

3G USB modem is connected in another USB port on this server and works fine. 
The problem I described was appeared after a new MB had been installed into the 
server with fresh OS.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problem with USB <---> UPS management connection

[tech-lists]

On 07/03/2018 11:55, wishmaster wrote:
> I have changed USB-cables, USB port on the server - without success.
> On another server this problem is absent.

It looks like a broken or shorting connection but you say you've tried
different ports on the machine and changed cables. I dunno, maybe the
usb subsystem/circuitry in that machine is at fault? The way I'd test is
to install a usb card known to be good and test again.
-- 
J.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

[NAGY Andreas]

Hi,

attached the trace. If I see it correct it uses FORE_OR_BOTH. (bctsa_dir: 
CDFC4_FORE_OR_BOTH (0x0003))

The trace is only with the first patch, have not compiled the wantdeleg patches 
so far.

I think this is related to the BIND_CONN_TO_SESSION; after a disconnect the 
ESXi cannot connect to the NFS also with this warning:
2018-03-07T16:55:11.227Z cpu21:66484)WARNING: NFS41: NFS41_Bug:2361: BUG - 
Invalid BIND_CONN_TO_SESSION error: NFS4ERR_NOTSUPP

Another thing I noticed today is that it is not possible to delete a folder 
with the ESXi datastorebrowser on the NFS mount. Maybe it is a VMWare bug, but 
with NFS3 it works.

Here the vmkernel.log with only one connection contains mounting, trying to 
delete a folder and disconnect:

2018-03-07T16:46:04.543Z cpu12:68008 opID=55bea165)World: 12235: VC opID 
c55dbe59 maps to vmkernel opID 55bea165
2018-03-07T16:46:04.543Z cpu12:68008 opID=55bea165)NFS41: 
NFS41_VSIMountSet:423: Mount server: 10.0.0.225, port: 2049, path: /, label: 
nfsds1, security: 1 user: , options: 
2018-03-07T16:46:04.543Z cpu12:68008 opID=55bea165)StorageApdHandler: 977: APD 
Handle  Created with lock[StorageApd-0x43046e4c6d70]
2018-03-07T16:46:04.544Z cpu11:66486)NFS41: 
NFS41ProcessClusterProbeResult:3873: Reclaiming state, cluster 0x43046e4c7ee0 
[7]
2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
NFS41FSCompleteMount:3791: Lease time: 120
2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
NFS41FSCompleteMount:3792: Max read xfer size: 0x2
2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
NFS41FSCompleteMount:3793: Max write xfer size: 0x2
2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
NFS41FSCompleteMount:3794: Max file size: 0x8000
2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)NFS41: 
NFS41FSCompleteMount:3795: Max file name: 255
2018-03-07T16:46:04.545Z cpu12:68008 opID=55bea165)WARNING: NFS41: 
NFS41FSCompleteMount:3800: The max file name size (255) of file system is 
larger than that of FSS (128)
2018-03-07T16:46:04.546Z cpu12:68008 opID=55bea165)NFS41: 
NFS41FSAPDNotify:5960: Restored connection to the server 10.0.0.225 mount point 
nfsds1, mounted as 1a7893c8-eec764a7-- ("/")
2018-03-07T16:46:04.546Z cpu12:68008 opID=55bea165)NFS41: 
NFS41_VSIMountSet:435: nfsds1 mounted successfully
2018-03-07T16:47:19.869Z cpu21:67981 opID=e47706ec)World: 12235: VC opID 
c55dbe91 maps to vmkernel opID e47706ec
2018-03-07T16:47:19.869Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.870Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.870Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.870Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.870Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.871Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.871Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.871Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.871Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.872Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.872Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry
2018-03-07T16:47:19.872Z cpu21:67981 opID=e47706ec)WARNING: UserFile: 2155: 
hostd-worker: Directory changing too often to perform readdir operation (11 
retries), returning busy
2018-03-07T16:47:19.874Z cpu21:67981 opID=e47706ec)WARNING: NFS41: 
NFS41FileOpReaddir:4728: Failed to process READDIR result for fh 
0x43046e4c6398: Transient file system condition, suggest retry

Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with ESXi client

[Rick Macklem]

NAGY Andreas wrote:
>Okay, that was the main reason for using NFS 4.1.
>Is it planned to implement it, or is the focus on pNFS?
I took a quick look and implementing this for some cases will be pretty
easy. Binding a FORE channel is implied, so for that case all the server
does is reply OK to the BIND_CONN_TO_SESSION.

To know if the ESXi client case is a simple one, I need to see what the
BIND_CONN_TO_SESSION arguments look like.
If you can capture packets for when this second connection is done and
email it to me as an attachment, I can look at what the BIND_CONN_TO_SESSION 
args are.
# tcpdump -s 0 -w  host 
run on the FreeBSD server should get the  I need.

Alternately, if you have wireshark handy, you can just use it to look
for the BIND_CONN_TO_SESSION request and see if it specifies
(FORE, BACK, FORE_OR_BOTH or BACK_OR_BOTH) in it.
FORE or FORE_OR_BOTH means it is easy to do and I can probably have
a patch for testing in a day or two.

rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Targeted Companies Emails List

[cathy . pearson]

Hi,

This is Cheryl from pre-sales team. Hope this email finds well.

I am wondering if you would be interested in reaching your targeted  
PeopleSoft/SuccessFactors Users for your Marketing Approach Strategy.


We can provide you with 100% opt in emails.

You may also be interested in database of: Adobe, Dassault Systemes, SAP,  
Bentley, PTC, Ansys, AutoCAD, Vault, SolidWorks, Siemens, Oracle, VARs,  
VADs and more.


Kindly let me know your interest to provide you with detailed information  
for the same.


Thanks,
Cathy

If see no interest please reply “Delete”
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Problem with USB <---> UPS management connection

[wishmaster]

Hi, colleagues!

Something strange happens with a server. I am attempting to connect management 
interface of UPS with server via USB.
In console I see a lot of errors:

Mar  7 13:42:04 xxx kernel: ugen2.2:  at 
usbus2
Mar  7 13:42:05 xxx kernel: uhid0 on uhub6
Mar  7 13:42:05 xxx kernel: uhid0:  on usbus2
Mar  7 13:42:08 xxx kernel: ugen2.2:  at 
usbus2 (disconnected)
Mar  7 13:42:08 xxx kernel: uhid0: at uhub6, port 3, addr 2 (disconnected)
Mar  7 13:42:08 xxx kernel: uhid0: detached
Mar  7 13:42:12 xxx kernel: ugen2.2:  at 
usbus2
Mar  7 13:42:12 xxx kernel: uhid0 on uhub6
Mar  7 13:42:12 xxx kernel: uhid0:  on usbus2
Mar  7 13:42:16 xxx kernel: ugen2.2:  at 
usbus2 (disconnected)
Mar  7 13:42:16 xxx kernel: uhid0: at uhub6, port 3, addr 2 (disconnected)
Mar  7 13:42:16 xxx kernel: uhid0: detached

I have changed USB-cables, USB port on the server - without success.
On another server this problem is absent.

FreeBSD version: FreeBSD 11.1-STABLE #1 r329364M:

Any ideas?

--
Vitaliy
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE

[Jan Bramkamp]

On 28.02.18 18:03, Hadi Rezaee wrote:

Hello there,
My laptop is running FreeBSD-12 CURRENT, and i hadnt any problem with my 
graphic before upgrading drm-next (g20180117_3 -> 4.11.g20180224). But 
now it getting failed. Tried to build from source, but same result.

Laptop model: Lenovo E470


I just updated both the 12-current base system and the 
graphics/drm-next-kmod port on my Thinkpad T470s. The resulting system 
works except for the already documented regression in the VA API 
affecting hardware accelerated video playback in mpv.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: "Cross" building for same architecture, different CPUTYPE

[Christian Ullrich]

* Marek Zarychta wrote:


* Warner Losh wrote:



I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do
these sorts of things. CPUTYPE is known to only work on native builds



Maybe you should try to build using different make.conf(5) files for
each build? It can be improved WITH_META_MODE=YES enabled in
src-env.conf (requires loading filemon(4) first) and two differnt object


Thanks for the hint. While experimenting with it, I found the -- 
somewhat obvious, in hind sight -- solution.


The source of the trouble is the build system's installed 
/usr/lib/libc.a, which the /usr/src/tmp binaries are linked against, as 
well as some few other things.


The fix is to have a world on the build system that is built without any 
CPUTYPE setting, so that the compiler only uses the original amd64 
instruction set; that goes up to SSE2. An actual "distribution" 
buildworld can then use any CPUTYPE that the intended target supports.


A workaround, at least for upgrading from 11.1 to stable/11, is to 
remove the /usr/obj/usr/src/tmp directory entirely, so that 
installkernel and installworld use the tools on the target system. It 
worked for me, but is probably not entirely reliable.


I still think there is an argument to be made for avoiding this kind of 
potential breakage in "near cross" builds, but it is probably not worth 
the extra effort during buildworld (rebuild, or at least relink, 
/usr/src/tmp etc. against the freshly made libc.a).


The "few other things" above are, by the way:

- usr.bin/mkesdb_static
- usr.bin/mkcsmapper_static
- rescue

The first two are not installworld'ed, so I wonder why they are where 
they are, and the last one is a cruel, cruel thing to do.


Thanks for your help!

--
Christian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"