top -m io Segmentation fault(core dumped) on fresh r335360
top -m io Segmentation fault(core dumped) FreeBSD alex.super 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r335360: Tue Jun 19 14:53:20 +07 2018 alex@alex.super:/usr/obj/usr/src/amd64.amd64/sys/IOSCHED amd64 -- - Alex. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On Mon, 18 Jun 2018 22:44:13 -0700 Eitan Adler wrote: > On 13 June 2018 at 04:16, Eitan Adler wrote: > > On 13 June 2018 at 03:35, Konstantin Belousov wrote: > >> Today I noted that AMD published the public errata document for Ryzens, > >> https://developer.amd.com/wp-content/resources/55449_1.12.pdf > >> > >> Some of the issues listed there looks quite relevant to the potential > >> hangs that some people still experience with the machines. I wrote > >> a script which should apply the recommended workarounds to the erratas > >> that I find interesting. > >> > >> To run it, kldload cpuctl, then apply the latest firmware update to your > >> CPU, then run the following shell script. Comments indicate the errata > >> number for the workarounds. > >> > >> Please report the results. If the script helps, I will code the kernel > >> change to apply the workarounds. > >> > >> #!/bin/sh > >> > >> # Enable workarounds for erratas listed in > >> # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > >> > >> # 1057, 1109 > >> sysctl machdep.idle_mwait=0 > >> sysctl machdep.idle=hlt > > > > > > Is this needed if it was previously machdep.idle: acpi ? > > This might explain why I've never seen the lockup issues mentioned by > other people. What would cause my machine to differ from others? > I had sysctl machdep.idle_mwait=1 and machdep.idle=acpi before applying the shell script. I had multiple lockups every week, sometimes multiple lockups per day. With the idle settings from the script it still locks up, but not as often. I suspect I also need to update the CPU firmware, although I expect that the new BIOS version I installed last week would have done that already. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: review of nfsd rc.d script patch
Don Lewis wrote: >On 15 Jun, Rick Macklem wrote: >> Hi, >> >> For the pNFS service MDS machine, the nfsd can't be started until all nfs >> mounts >> in /etc/fstab are done. >> I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient >> to do this? >> >> I don't think delaying the startup of the nfsd daemon until after any NFS >> mounts >> are done will do any harm, but if others think it would be a POLA violation, >> I could make this dependent on the pNFS service being enabled. >> Does anyone think this would cause a POLA violation? > >Sounds like that would break cross mounts. Back in the olden days >before the automounter, I would set up workstation clusters with hosta >exporting local filesystem /home/hosta, and hostb exporting /home/hostb. >In addition, hosta would do a bg NFS mount of /home/hostb and hostb >would do a bg NFS mount of /home/hosta. That way everybody would have a >consistent view of everything. If a power failure took down everything, >the first system up would export its local filesystem and even though it >wouldn't be able to mount any remote filesystems, mount would background >itself at the boot would complete. As the remaining machines came up, >they would be able to mount the remote filesystems of the machine that >came up earlier, and the early machines would mount the filesystems from >the later machines as they became available. > >If nfsd is delayed until all the NFS filesystems are mounted, the above >setup would deadlock. I think you would have used the "bg" mount option on the NFS mounts to get the above to work? (That is what makes the mount go "background" if it can't contact the NFS server.) If so, this would still behave the same after this patch. The patch forces "mountcritremote" to complete before nfsd is run (to be honest, since "m" comes before "n", I think that happens anyhow? This patch just tries to ensure that). It does not force waiting for mount completion if "bg" is specified. (Put another way, "bg" can't be used for mounts of DSs for the pNFS server setup.) rick ps: I recall a small company that only had a few SGI workstations and did a setup like the above. However, they weren't very good at configuring it and, as such, everyone would run around for a half hour after a power failure, trying to get the workstations back up;-) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ESXi NFSv4.1 client id is nasty
Steve Wills wrote: On 06/18/18 17:42, Rick Macklem wrote: >> Steve Wills wrote: >>> Would it be possible or reasonable to use the client ID to log a message >>> telling the admin to enable a sysctl to enable the hacks? >> Yes. However, this client implementation id is only seen by the server >> when the client makes a mount attempt. >> >> I suppose it could log the message and fail the mount, if the "hack" sysctl >> isn't >> set? > >I hadn't thought of failing the mount, just defaulting not enabling the >hacks unless the admin chooses to enable them. But at the same time >being proactive about telling the admin to enable them. > >I.E. keep the implementation RFC compliant since we wouldn't be changing >the behavior based on the implementation ID, only based upon the admin >setting the sysctl, which we told them to do based on the implementation ID. Well, without one of the hacks (as head currently is) the mounts always fail, so ESXi mounts failing is a feature of the "unhacked" server. (The ReclaimComplete failure fails the mount.) >Just an idea, maybe Warner's suggestion is a better one. Yes, I think Warner has the right idea, although logging a message w.r.t. the ReclaimComplete failure (which fails these mounts) when the hacks are turned off sounds like a good one to me. >Steve rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ESXi NFSv4.1 client id is nasty
On Tue, Jun 19, 2018 at 5:11 AM, Rick Macklem wrote: > Steve Wills wrote: > On 06/18/18 17:42, Rick Macklem wrote: > >> Steve Wills wrote: > >>> Would it be possible or reasonable to use the client ID to log a > message > >>> telling the admin to enable a sysctl to enable the hacks? > >> Yes. However, this client implementation id is only seen by the server > >> when the client makes a mount attempt. > >> > >> I suppose it could log the message and fail the mount, if the "hack" > sysctl isn't > >> set? > > > >I hadn't thought of failing the mount, just defaulting not enabling the > >hacks unless the admin chooses to enable them. But at the same time > >being proactive about telling the admin to enable them. > > > >I.E. keep the implementation RFC compliant since we wouldn't be changing > >the behavior based on the implementation ID, only based upon the admin > >setting the sysctl, which we told them to do based on the implementation > ID. > Well, without one of the hacks (as head currently is) the mounts always > fail, > so ESXi mounts failing is a feature of the "unhacked" server. > (The ReclaimComplete failure fails the mount.) > > >Just an idea, maybe Warner's suggestion is a better one. > Yes, I think Warner has the right idea, although logging a message w.r.t. > the > ReclaimComplete failure (which fails these mounts) when the hacks are > turned > off sounds like a good one to me. > I think so too, rate limited, with an invitation to turn on the hack :) Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A head buildworld race visible in the ci.freebsd.org build history
On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: > Li-Wen reported that the build is done in a 11.1-rel jail though, so > the libarchive (or any userland) change shouldn't be responsible. > > Can we update a canary builder to somewhere between r328278 and r88? butler1.nyi.freebsd.org is running r331373 now. -- Li-Wen Hsu https://lwhsu.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Current @ r335314 not bootable with Geli and ZFS
On 2018-06-18 12:42, Thomas Laus wrote: > Something changed in /boot/gptzfsboot between r334610 and r335314. I > built current this morning and my system is un-bootable. I am using > redundant ZFS disks and only copied the updated /boot/gptzfsboot file to > my ada0 drive. I was able to boot the ada1 drive that still had the > gptzfsboot file from r334610. > > I had a similar issue a few months ago with the upgrades to the Geli + > ZFS booting process. These were resolved and operation has been fine > since the last 'hick-up' in the testing process. I might not be the > only person running the combination of Geli encryption and using a ZFS > filesystem, but it should not be that much uncommon setup that I am the > first to report the problem. > > Let me know far back I need to revert my sources to identify the commit > that broke gptzfsboot. My system goes into a continuous reboot loop > before presenting the password prompt. It is very early in the startup > process. > > Tom > We tested all of the changes with the setup in tools/boot/rootgen.sh, it will be interesting to figure out what went wrong with your setup, and add it as a test case to prevent this in the future. The recent changes are: r335245 (reading the size of the disk) r335254 (reading past the end of the disk) r335276 (enable the serial console sooner so the password prompt can be used over serial) There is also one outstanding fix: https://reviews.freebsd.org/D15847 -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Current @ r335314 not bootable with Geli and ZFS
On 06/19/18 12:09, Allan Jude wrote: > > We tested all of the changes with the setup in tools/boot/rootgen.sh, it > will be interesting to figure out what went wrong with your setup, and > add it as a test case to prevent this in the future. > > The recent changes are: > > r335245 (reading the size of the disk) > r335254 (reading past the end of the disk) > r335276 (enable the serial console sooner so the password prompt can be > used over serial) > > There is also one outstanding fix: https://reviews.freebsd.org/D15847 > I don't think that my issue is related to the fix described in the review. I am using ~256G SSD's. They are slightly different sizes but are both >200M. I will try backing out the commits starting with r335276 and work backward from there. I will review the changes made to gptzfsboot to get the date that it was last touched. When I replace only gptzfsboot with one made 2 weeks ago (r334610) everything boots OK and I get a password prompt for the geli password. If the gptzfs bootcode after r335314 is copied to the boot record, the computer goes into a continuous reboot loop and only a part of the password prompt is shown before the reboot. The filesize on the bad gptzfsboot file is 121922 bytes and the good one is 121634 bytes. The filesize on that file has not changed in a few months. I keep old versions of this file since imp fixed things for me a few months ago when he made changes for loader code migration from Forth that caused a similar issue. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Current @ r335314 not bootable with Geli and ZFS
On 06/19/18 14:22, Thomas Laus wrote: > On 06/19/18 12:09, Allan Jude wrote: >> >> We tested all of the changes with the setup in tools/boot/rootgen.sh, it >> will be interesting to figure out what went wrong with your setup, and >> add it as a test case to prevent this in the future. >> >> The recent changes are: >> >> r335245 (reading the size of the disk) >> r335254 (reading past the end of the disk) >> r335276 (enable the serial console sooner so the password prompt can be >> used over serial) >> Allan: It looks like the problem is with r335276. I reverted back to that revision and built stand, my boot problem was still there. I reverted further back to r335254 and everything worked fine. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Current @ r335314 not bootable with Geli and ZFS
> On 19 Jun 2018, at 21:51, Thomas Laus wrote: > > On 06/19/18 14:22, Thomas Laus wrote: >> On 06/19/18 12:09, Allan Jude wrote: >>> >>> We tested all of the changes with the setup in tools/boot/rootgen.sh, it >>> will be interesting to figure out what went wrong with your setup, and >>> add it as a test case to prevent this in the future. >>> >>> The recent changes are: >>> >>> r335245 (reading the size of the disk) >>> r335254 (reading past the end of the disk) >>> r335276 (enable the serial console sooner so the password prompt can be >>> used over serial) >>> > Allan: > > It looks like the problem is with r335276. I reverted back to that > revision and built stand, my boot problem was still there. I reverted > further back to r335254 and everything worked fine. > ou, in illumos side there was an idea of having early boot printouts mirrored to serial, but it got turned down because there is no way to tell if any system has some bad side effects from it… (either directly or indirectly by having some weird device connected to the serial). rgds, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: top -m io Segmentation fault(core dumped) on fresh r335360
On 19 June 2018 at 02:28, Alex V. Petrov wrote: > top -m io > Segmentation fault(core dumped) > FreeBSD alex.super 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r335360: Tue > Jun 19 14:53:20 +07 2018 > alex@alex.super:/usr/obj/usr/src/amd64.amd64/sys/IOSCHED amd64 r335390 should fix it. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ci.freebsd.org's FreeBSD-head-amd64-gcc broken by -r335338 and/or -r335339 (-r335389 still broken)
>From https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6190/consoleText and https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6213/ as examples: --- ixl_pf_qmgr.o --- In file included from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl_pf.h:339:6: error: redundant redeclaration of 'ixl_set_queue_rx_itr' [-Werror=redundant-decls] void ixl_set_queue_rx_itr(struct ixl_rx_queue *); ^~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl.h:545:8: note: previous declaration of 'ixl_set_queue_rx_itr' was here void ixl_set_queue_rx_itr(struct ixl_rx_queue *que); ^~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl_pf.h:404:5: error: redundant redeclaration of 'ixl_max_aq_speed_to_value' [-Werror=redundant-decls] u64 ixl_max_aq_speed_to_value(u8); ^ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.c:36: /workspace/src/sys/dev/ixl/ixl.h:549:6: note: previous declaration of 'ixl_max_aq_speed_to_value' was here u64 ixl_max_aq_speed_to_value(u8); ^ and: --- all_subdir_ixl --- In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36:0: /workspace/src/sys/dev/ixl/ixl_pf.h:339:6: error: redundant redeclaration of 'ixl_set_queue_rx_itr' [-Werror=redundant-decls] void ixl_set_queue_rx_itr(struct ixl_rx_queue *); ^~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36: /workspace/src/sys/dev/ixl/ixl.h:545:8: note: previous declaration of 'ixl_set_queue_rx_itr' was here void ixl_set_queue_rx_itr(struct ixl_rx_queue *que); ^~~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36:0: /workspace/src/sys/dev/ixl/ixl_pf.h:404:5: error: redundant redeclaration of 'ixl_max_aq_speed_to_value' [-Werror=redundant-decls] u64 ixl_max_aq_speed_to_value(u8); ^ In file included from /workspace/src/sys/dev/ixl/ixl_pf.h:39:0, from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36: /workspace/src/sys/dev/ixl/ixl.h:549:6: note: previous declaration of 'ixl_max_aq_speed_to_value' was here u64 ixl_max_aq_speed_to_value(u8); ^ In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:39:0: /workspace/src/sys/dev/ixl/ixl_pf_iov.h:60:7: error: redundant redeclaration of 'ixl_handle_vflr' [-Werror=redundant-decls] void ixl_handle_vflr(void *arg, int pending); ^~~ In file included from /workspace/src/sys/dev/ixl/ixl_pf_main.c:36:0: /workspace/src/sys/dev/ixl/ixl_pf.h:405:6: note: previous declaration of 'ixl_handle_vflr' was here void ixl_handle_vflr(void *, int); ^~~ === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A head buildworld race visible in the ci.freebsd.org build history
On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote: > On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: >> Li-Wen reported that the build is done in a 11.1-rel jail though, so >> the libarchive (or any userland) change shouldn't be responsible. >> >> Can we update a canary builder to somewhere between r328278 and r88? > > butler1.nyi.freebsd.org is running r331373 now. But there seems to be another of the ar -> ranlib failures after that on butler1.nyi.freebsd.org : https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/6321/ shows: 22:12:05 --- _bootstrap-tools-lib/liby --- 22:12:05 ranlib -D liby.a 22:12:05 ranlib: fatal: Failed to open 'liby.a' 22:12:05 *** [liby.a] Error code 70 with: NODE_LABELS bhyve_host butler1.nyi.freebsd.org jailer jailer_fast NODE_NAME butler1.nyi.freebsd.org And in fact there is at least one more: https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8291/consoleText shows: --- all_subdir_lib/libipsec --- ranlib -D libipsec_p.a ranlib: fatal: Failed to open 'libipsec_p.a' *** [libipsec_p.a] Error code 70 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
svn commit: r335399: . . . head/sys/security/mac_veriexec/ . . . breaks ci.freebsg.org builds of FreeBSD-head-{armv6,ar,m7,i386,mips,powerpc,powerpcspe}-build
Stephen J. Kiernan stevek at FreeBSD.org
Wed Jun 20 00:41:33 UTC 2018
Author: stevek
Date: Wed Jun 20 00:41:30 2018
New Revision: 335399
URL:
https://svnweb.freebsd.org/changeset/base/335399
Log:
MAC/veriexec implements a verified execution environment using the MAC
framework.
. . .
But the logs on ci.freebsd.prg show for -r335399 and later for
FreeBSD-head-{armv6,ar,m7,i386,mips,powerpc,powerpcspe}-build
messages like:
--- all_subdir_mac_veriexec ---
cc1: warnings being treated as errors
/usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c: In function
'identify_error':
/usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c:115: warning: format
'%lu' expects type 'long unsigned int', but argument 5 has type 'dev_t'
[-Wformat]
/usr/src/sys/security/mac_veriexec/veriexec_fingerprint.c:115: warning: format
'%lu' expects type 'long unsigned int', but argument 6 has type 'ino_t'
[-Wformat]
. . .
--- all_subdir_mac_veriexec ---
*** [veriexec_fingerprint.o] Error code 1
And, as a result, those builds fail on ci.freebsd.org .
Basically the 32-bit architectures fail and the 64-bit
ones do not (for the same code).
I've not checked the later *veriex* related check-ins:
-r335400
-r335401
-r335402
for possible similar problems.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A head buildworld race visible in the ci.freebsd.org build history
On Tue, Jun 19, 2018 at 9:24 PM Mark Millard wrote: > > On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote: > > > On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: > >> Li-Wen reported that the build is done in a 11.1-rel jail though, so > >> the libarchive (or any userland) change shouldn't be responsible. > >> > >> Can we update a canary builder to somewhere between r328278 and r88? > > > > butler1.nyi.freebsd.org is running r331373 now. > > > But there seems to be another of the ar -> ranlib failures > after that on butler1.nyi.freebsd.org : Yes I was trying to narrow down the cause, now it seems between r328278 and r330304. butler1.nyi.freebsd.org is back to run r328278. And I'll try to reproduce this in elsewhere. -- Li-Wen Hsu https://lwhsu.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A head buildworld race visible in the ci.freebsd.org build history
On 2018-Jun-19, at 9:14 PM, Li-Wen Hsu wrote: > On Tue, Jun 19, 2018 at 9:24 PM Mark Millard wrote: >> >> On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote: >> >>> On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote: Li-Wen reported that the build is done in a 11.1-rel jail though, so the libarchive (or any userland) change shouldn't be responsible. Can we update a canary builder to somewhere between r328278 and r88? >>> >>> butler1.nyi.freebsd.org is running r331373 now. >> >> >> But there seems to be another of the ar -> ranlib failures >> after that on butler1.nyi.freebsd.org : > > Yes I was trying to narrow down the cause, now it seems between > r328278 and r330304. > > butler1.nyi.freebsd.org is back to run r328278. And I'll try to > reproduce this in elsewhere. Okay. Then I'll quit looking to report which way butler1.nyi.freebsd.org is working (implicitly: search direction information). I will report if I see any new examples. (Seems unlikely.) Side note . . . It took me a while to find what to look to find the head version and jail version involved. For what I reported (powerpc): 22:12:03 uname: 22:12:03 FreeBSD FreeBSD-head-powerpc-build.jail.ci.FreeBSD.org 11.1-RELEASE FreeBSD 12.0-CURRENT #0 r330304M: Sat Mar 3 02:23:02 UTC 2018 pe...@build-12.freebsd.org:/usr/obj/usr/src/sys/CLUSTER12 amd64 Now I know. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
