Re: ttydev_cdevsw has no d_purge
2012/8/3 Julian Elischer jul...@freebsd.org: they would only do that if they were refering to the node BY NAME. Which is exactly what a lot of software does when interacting with TTYs. -- Ed Schouten e...@80386.nl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
2012/8/1 Hans Petter Selasky hsela...@c2i.net: I think the problem is like this, that in order to re-use the unit numbers for USB serial tty devices, the USB stack needs to wait until a TTY is actually freed, right? Else you will have a panic on creating devfs entries having the same name. Indeed. So the USB code could simply pick a different unit number. -- Ed Schouten e...@80386.nl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rtld dropping core on recent -current
On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote:
It is weird that program tries to dlopen what appears to be the binary
(itself?), but that did uncover the issue. Please try attached patch,
I only very lightly tested it here.
Also available here:
http://people.freebsd.org/~kan/rtld-digest-notes.diff
--
Alexander Kabaev
diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c
index 509a64f..350d437 100644
--- a/libexec/rtld-elf/map_object.c
+++ b/libexec/rtld-elf/map_object.c
@@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct stat *sb)
break;
note_start = (Elf_Addr)(char *)hdr + phdr-p_offset;
note_end = note_start + phdr-p_filesz;
- digest_notes(obj, note_start, note_end);
break;
}
@@ -292,6 +291,11 @@ map_object(int fd, const char *path, const struct stat *sb)
obj-relro_page = obj-relocbase + trunc_page(relro_page);
obj-relro_size = round_page(relro_size);
+if (note_start note_end)
+{
+ digest_notes(obj, note_start, note_end);
+}
+
munmap(hdr, PAGE_SIZE);
return (obj);
This is the right fix.
Why do you need the '{}' there ?
pgpAEVwMe9uIw.pgp
Description: PGP signature
Re: rtld dropping core on recent -current
On Fri, 3 Aug 2012 11:59:37 +0300
Konstantin Belousov kostik...@gmail.com wrote:
On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote:
It is weird that program tries to dlopen what appears to be the
binary (itself?), but that did uncover the issue. Please try
attached patch, I only very lightly tested it here.
Also available here:
http://people.freebsd.org/~kan/rtld-digest-notes.diff
--
Alexander Kabaev
diff --git a/libexec/rtld-elf/map_object.c
b/libexec/rtld-elf/map_object.c index 509a64f..350d437 100644
--- a/libexec/rtld-elf/map_object.c
+++ b/libexec/rtld-elf/map_object.c
@@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct
stat *sb) break;
note_start = (Elf_Addr)(char *)hdr + phdr-p_offset;
note_end = note_start + phdr-p_filesz;
- digest_notes(obj, note_start, note_end);
break;
}
@@ -292,6 +291,11 @@ map_object(int fd, const char *path, const
struct stat *sb) obj-relro_page = obj-relocbase +
trunc_page(relro_page); obj-relro_size = round_page(relro_size);
+if (note_start note_end)
+{
+ digest_notes(obj, note_start, note_end);
+}
+
munmap(hdr, PAGE_SIZE);
return (obj);
This is the right fix.
Why do you need the '{}' there ?
I do not. I just automatically followed style used at work. I'll
FreeBSD-fy this before commit.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: VirtualBox: Eating up 100% CPU, freezing Windows 7
On Fr., 3. Aug. 2012 06:18:33 CEST, Kevin Oberman kob6...@gmail.com wrote: On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 for more than a minute. For a minute or so, I can work, then, the freeze occurs again. I can't see this behaviour with a Ubuntu Guest on the same box. Is there Windows 7 specifica to be aware of? I am seeing the same thing. Also Win7 guest with Windows showing idle process at 99%, but my system is showing VB at 100%. The VM is only running a single CPU, so FreeBSD is still running OK, but the Win7 system seems to freeze up periodically. 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way since VB was updated to 4.1.18. Guest additions for 4.1.18 installed.All ports current. I'm thinking of backing off to 4.1.16. Can someone confirm that this is a regression in 4.1.18? Then I could talk to upstream and see if I can get that adressed. -- http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: VirtualBox: Eating up 100% CPU, freezing Windows 7
On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote: On Fr.,?? 3. Aug. 2012 06:18:33 CEST, Kevin Oberman kob6...@gmail.com wrote: On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 for more than a minute. For a minute or so, I can work, then, the freeze occurs again. I can't see this behaviour with a Ubuntu Guest on the same box. Is there Windows 7 specifica to be aware of? I am seeing the same thing. Also Win7 guest with Windows showing idle process at 99%, but my system is showing VB at 100%. The VM is only running a single CPU, so FreeBSD is still running OK, but the Win7 system seems to freeze up periodically. 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way since VB was updated to 4.1.18. Guest additions for 4.1.18 installed.All ports current. I'm thinking of backing off to 4.1.16. Can someone confirm that this is a regression in 4.1.18? Then I could talk to upstream and see if I can get that adressed. Could it be a case of kernel and virtualbox modules out of sync ? I do see occasional crashes with virtualbox in both the host and guest, but a reinstall of in-sync kernel and modules usually fixes them. cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Thu, Aug 2, 2012 at 5:14 PM, Kevin Oberman kob6...@gmail.com wrote: On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer jul...@freebsd.org wrote: On 8/2/12 9:53 AM, Doug Barton wrote: On 08/02/2012 09:44, Garrett Cooper wrote: The Watson/Losh connection worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for the right people, even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. bandwidth was limited and a single 1:1 skype connection was all we really could do. I did broadcast sessions a few years ago using the apple quicktime server but it was a lot of work and I think one person looked at part of one session. Doug First, too many of these posts assume way too much. I don't think anyone should be thinking of any sort of what is commonly called teleconferencing. That would be nice, but is far more complex and expensive, both in bandwidth and equipment, then should be considered as a starting point. I suggest the starting point is a webpage with a link to the slides being presented and a simple audio stream. This is trivially possible with a FreeBSD system and open-source software. A bandwidth of only about 70kbps would be needed. Less with reasonable codec choice. Several streams could be broadcast via a single, unicast stream to a well connected server which woild then stream to end users It might be augmented with jabber other open IM technology with someone at the meeting if procedures for this could be agreed to. (Some vetting is desirable, but will result in calls of censorship.) For small rooms, microphones are fairly easy to handle and one-way streams don't require echo cancellation. As costs for video come down, that might be something to think about some day, but is not required to allow remote attendance. Of course, unless this is publicized, no one will come (which eliminates any technical issues). :-) Nail - head. Everything that Kevin just said. With so much collective technical experience and intelligence available, we can work out the minor kinks in a solved problem (one-to-many audio and slide sharing). Getting the word out is also a solved problem. Both are very high-leverage -- and very good for the project. If we think about live BSDCan streaming as a fun project with classic hack value, instead of an amorphous cloud of undoability, things will just come together naturally. The next action I see is calling for boots-on-the-ground volunteers to coordinate the local setup, and maybe a wiki page to capture the state of the project. Royce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] Add locking to twe(4) so it no longer uses Giant
We only have a few storage drivers left that use Giant and twe(4) is one of them. I don't have any hardware to test with, however. I have verified the patch compiles, but I'd appreciate it if some folks with twe(4) hardware could test it. The patch is at http://www.FreeBSD.org/~jhb/patches/twe_locking.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
I'll try to find time to try it later today, but I'm in the middle of budget wrangling and I can't make any promises. Before I try, will these patches apply to the twe driver in 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. I really don't have time to install current right now. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com On Fri, Aug 3, 2012 at 11:18 AM, John Baldwin j...@freebsd.org wrote: We only have a few storage drivers left that use Giant and twe(4) is one of them. I don't have any hardware to test with, however. I have verified the patch compiles, but I'd appreciate it if some folks with twe(4) hardware could test it. The patch is at http://www.FreeBSD.org/~jhb/patches/twe_locking.patch ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: I'll try to find time to try it later today, but I'm in the middle of budget wrangling and I can't make any promises. Before I try, will these patches apply to the twe driver in 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. I really don't have time to install current right now. I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for initial testing. Thanks! -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com On Fri, Aug 3, 2012 at 11:18 AM, John Baldwin j...@freebsd.org wrote: We only have a few storage drivers left that use Giant and twe(4) is one of them. I don't have any hardware to test with, however. I have verified the patch compiles, but I'd appreciate it if some folks with twe(4) hardware could test it. The patch is at http://www.FreeBSD.org/~jhb/patches/twe_locking.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/3/2012 3:39 PM, John Baldwin wrote:
On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote:
I'll try to find time to try it later today, but I'm in the middle of
budget wrangling and I can't make any promises.
Before I try, will these patches apply to the twe driver in
9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18.
I really don't have time to install current right now.
I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9
please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for
initial testing. Thanks!
Seems to apply to RELENG_9 just fine. Are there any stress tests you
suggest I run that might expose some bugs ? The machine is not
production yet, so its ok to crash it.
{offsite2}# patch -p9 twe_locking.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twe.c 2009-12-25
17:35:14.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twe.c 2012-08-03
04:00:49.0
--
Patching file twe.c using Plan A...
Hunk #1 succeeded at 151.
Hunk #2 succeeded at 167.
Hunk #3 succeeded at 189.
Hunk #4 succeeded at 208.
Hunk #5 succeeded at 226.
Hunk #6 succeeded at 234.
Hunk #7 succeeded at 271.
Hunk #8 succeeded at 288.
Hunk #9 succeeded at 310.
Hunk #10 succeeded at 337.
Hunk #11 succeeded at 349.
Hunk #12 succeeded at 405.
Hunk #13 succeeded at 521.
Hunk #14 succeeded at 557.
Hunk #15 succeeded at 580.
Hunk #16 succeeded at 595.
Hunk #17 succeeded at 608.
Hunk #18 succeeded at 646.
Hunk #19 succeeded at 769.
Hunk #20 succeeded at 863.
Hunk #21 succeeded at 921.
Hunk #22 succeeded at 952.
Hunk #23 succeeded at 1038.
Hunk #24 succeeded at 1051.
Hunk #25 succeeded at 1082.
Hunk #26 succeeded at 1104.
Hunk #27 succeeded at 1140.
Hunk #28 succeeded at 1151.
Hunk #29 succeeded at 1177.
Hunk #30 succeeded at 1206.
Hunk #31 succeeded at 1309.
Hunk #32 succeeded at 1447.
Hunk #33 succeeded at 1469.
Hunk #34 succeeded at 1499.
Hunk #35 succeeded at 1513.
Hunk #36 succeeded at 1531.
Hunk #37 succeeded at 1554.
Hunk #38 succeeded at 1589.
Hunk #39 succeeded at 1618.
Hunk #40 succeeded at 1644.
Hunk #41 succeeded at 1696.
Hunk #42 succeeded at 1778.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twe_compat.h
2005-05-29 04:45:51.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_compat.h 2012-08-03
03:58:12.0
--
Patching file twe_compat.h using Plan A...
Hunk #1 succeeded at 43.
Hunk #2 succeeded at 68.
Hunk #3 succeeded at 82.
Hunk #4 succeeded at 92.
Hunk #5 succeeded at 108.
Hunk #6 succeeded at 128.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twe_freebsd.c
2012-03-12 08:05:24.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03
18:10:04.0
--
Patching file twe_freebsd.c using Plan A...
Hunk #1 succeeded at 69.
Hunk #2 succeeded at 83.
Hunk #3 succeeded at 101.
Hunk #4 succeeded at 180.
Hunk #5 succeeded at 188.
Hunk #6 succeeded at 211.
Hunk #7 succeeded at 241.
Hunk #8 succeeded at 292.
Hunk #9 succeeded at 414.
Hunk #10 succeeded at 425.
Hunk #11 succeeded at 461.
Hunk #12 succeeded at 496.
Hunk #13 succeeded at 518.
Hunk #14 succeeded at 533.
Hunk #15 succeeded at 566.
Hunk #16 succeeded at 585.
Hunk #17 succeeded at 604.
Hunk #18 succeeded at 680.
Hunk #19 succeeded at 729.
Hunk #20 succeeded at 834.
Hunk #21 succeeded at 857.
Hunk #22 succeeded at 876.
Hunk #23 succeeded at 1038.
Hunk #24 succeeded at 1097.
Hunk #25 succeeded at 1151.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|--- //depot/vendor/freebsd/src/sys/dev/twe/twevar.h2009-12-25
17:35:14.0
|+++ //depot/user/jhb/cleanup/sys/dev/twe/twevar.h 2012-08-03
04:00:49.0
--
Patching file twevar.h using Plan A...
Hunk #1 succeeded at 134.
Hunk #2 succeeded at 210.
Hunk #3 succeeded at 255.
done
0{offsite2}#
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote: On 8/3/2012 3:39 PM, John Baldwin wrote: On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: I'll try to find time to try it later today, but I'm in the middle of budget wrangling and I can't make any promises. Before I try, will these patches apply to the twe driver in 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. I really don't have time to install current right now. I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for initial testing. Thanks! Seems to apply to RELENG_9 just fine. Are there any stress tests you suggest I run that might expose some bugs ? The machine is not production yet, so its ok to crash it. Looking really quickly at the patch, it looks like most of the locking changes are made around management pieces, and not data handling pieces (but I might have missed something). If there's a tool for poking at the drives/controller, I would use that, plus camcontrol. Of course you want a data intensive workload (iometer/iozone/xdd with async and sync mode, random reads and sequential reads, etc), and maybe resort to manual testing like pulling drives (power, data) if you don't mind creating failures. If you have some failed/failing drives kicking around, that would be a good test as well (see that all/some of the failure paths are properly stimulated). Any variance or combining of these tests will help build confidence in the change being proposed. HTH, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On Friday, August 03, 2012 4:42:59 pm Mike Tancsa wrote: On 8/3/2012 3:39 PM, John Baldwin wrote: On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: I'll try to find time to try it later today, but I'm in the middle of budget wrangling and I can't make any promises. Before I try, will these patches apply to the twe driver in 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. I really don't have time to install current right now. I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for initial testing. Thanks! Seems to apply to RELENG_9 just fine. Are there any stress tests you suggest I run that might expose some bugs ? The machine is not production yet, so its ok to crash it. Probably pho's stress2 stuff. Thinks like dbench might be a good start as well for initial testing. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On Friday, August 03, 2012 5:17:09 pm Garrett Cooper wrote: On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote: On 8/3/2012 3:39 PM, John Baldwin wrote: On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: I'll try to find time to try it later today, but I'm in the middle of budget wrangling and I can't make any promises. Before I try, will these patches apply to the twe driver in 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. I really don't have time to install current right now. I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for initial testing. Thanks! Seems to apply to RELENG_9 just fine. Are there any stress tests you suggest I run that might expose some bugs ? The machine is not production yet, so its ok to crash it. Looking really quickly at the patch, it looks like most of the locking changes are made around management pieces, and not data handling pieces (but I might have missed something). No, it changes those paths, too. There just aren't many of them. All the data enters through twed_strategy() and leaves via twed_intr() (invoked from twe_intr()). If there's a tool for poking at the drives/controller, I would use that, plus camcontrol. Of course you want a data intensive workload (iometer/iozone/xdd with async and sync mode, random reads and sequential reads, etc), and maybe resort to manual testing like pulling drives (power, data) if you don't mind creating failures. If you have some failed/failing drives kicking around, that would be a good test as well (see that all/some of the failure paths are properly stimulated). 3dm2 testing would be good for the ioctl handling, but the most critical tests are basic I/O. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: VirtualBox: Eating up 100% CPU, freezing Windows 7
On Fri, Aug 3, 2012 at 6:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote: On Fr.,?? 3. Aug. 2012 06:18:33 CEST, Kevin Oberman kob6...@gmail.com wrote: On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 for more than a minute. For a minute or so, I can work, then, the freeze occurs again. I can't see this behaviour with a Ubuntu Guest on the same box. Is there Windows 7 specifica to be aware of? I am seeing the same thing. Also Win7 guest with Windows showing idle process at 99%, but my system is showing VB at 100%. The VM is only running a single CPU, so FreeBSD is still running OK, but the Win7 system seems to freeze up periodically. 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way since VB was updated to 4.1.18. Guest additions for 4.1.18 installed.All ports current. I'm thinking of backing off to 4.1.16. Can someone confirm that this is a regression in 4.1.18? Then I could talk to upstream and see if I can get that adressed. Could it be a case of kernel and virtualbox modules out of sync ? I do see occasional crashes with virtualbox in both the host and guest, but a reinstall of in-sync kernel and modules usually fixes them. Nope. To be really, really sure I just re-built the module and rebooted. VB still eats 100% CPU (out of 400%) continually. Thanks for the suggestion, though. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
