Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
Am 12.01.2018 um 00:03 schrieb Sean Bruno: > https://reviews.freebsd.org/D13832 <--- test this update > > I'd like to get some feedback from AMD cpu users on this update. I've > restructured and undone a few things that may have been keeping folks > using this port from getting their runtime cpu microcode updates. > > After installing the port, grab your microcode version via > sysutils/x86info. If you don't see an update, that only means there is > no update available for your system. > > x86info -a | grep Microcode > > Run the microcode_update and repeat. Check /var/log/messages for a > notification that the code was updated. You should be able to get > something like the following for your system if it executed an update: > > root@lab:/home/sbruno # x86info -a | grep "CPU Model" > CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2) > > root@lab:/home/sbruno # x86info -a | grep Microcode > Microcode patch level: 0x6000629 > > root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart > Updating CPU Microcode... > Done. > > root@lab:/home/sbruno # x86info -a | grep Microcode > Microcode patch level: 0x600063d > > root@lab:/home/sbruno # grep microcode_update /var/log/messages > Jan 10 16:52:26 lab microcode_update: > /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu > /dev/cpuctl0 to revision 0x600063d... done. > Just for the record, for an older Phenom with dmesg: CPU: AMD Phenom(tm) II X6 1090T Processor (3214.31-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x100fa0 Family=0x10 Model=0xa Stepping=0 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff SVM: NP,NRIP,NAsids=64 TSC: P-state invariant, performance statistics #x86info -a | grep "CPU Model" CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion (II)/Opteron (PH-E0) #x86info -a | grep Microcode Microcode patch level: 0x1bf #/usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. #x86info -a | grep Microcode Microcode patch level: 0x1bf #grep microcode_update /var/log/messages --- So no recent update and no log messages, as expected ;) Regards, Rainer Hurling ___ 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: ipfw: manpage: semantics of "receive" and "xmit" interfaces
On Tue, 9 Jan 2018 21:23:54 +0300 "Andrey V. Elsukov" wrote: > On 09.01.2018 12:28, O. Hartmann wrote: > > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > > also an example: > > > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > > > Can someone explain a bit more what the semantics of these is? I get > > especially confused by the subsequent blocks of text following the line I > > mentioned above. Since not everybody using FreeBSD is capable of studying > > the kernel sources, I have difficulties to put those statements in line > > with a visualization of the packet flow. A local host receiving a packets > > destined for the local host can not have xmit interface? If I imagine, that > > the recv interface might be the interface adjacent directly to the in/out > > port depicted in section PACKET FLOW it doesn't give me any idea why there > > is no xmit interface. > > When your system has two interfaces ed0 and ed1, and it acts as router, > a forwarded packet can be checked by firewall two times: > > 1. When a packet is received on ed0 interface, mbuf associated with this > packet gets a property "receiving interface". This packet is checked for > inbound direction and can be matched by "in" and "recv ed0" opcodes. > If it was not dropped by rules, it will go through IP stack and can be > forwarded according to routing table via interface ed1. > > 2. When the routing decision was made (i.e. outbound interface is > determined) a packet checked by firewall again, now for outbound > direction. And it can be matched by "out" and "xmit ed1" opcodes. The > opcode "recv ed0" still can be matched too, but "in" opcode will not > matched. > > A packet destined for local host is consumed by local IP stack and will > not forwarded. It is checked by firewall only one time (usually). Thus > it can not have xmit interface. > Thanks very much for the explanation. ___ 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: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>
On 4 January 2018 at 03:10, Michael Tuexen wrote: > > Not sure this helps: But we have seen this also after system panics > when having soft update journaling enabled. Having soft update journaling > disabled, we do not observed this after several panics. > Just to be clear: The panics are not related to this issue, > but to other network development we do. Both of my new co-op students have encountered this as well: after a panic (unrelated to the filesystem), SU+J fsck recovery runs at boot, and than many cylinder checksum warnings are emitted by the kernel. The students used the default installer configuration; it sounds like we should disable SU+J by default in the installer until this issue is addressed. ___ 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: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 1/11/2018 6:03 PM, Sean Bruno wrote: > https://reviews.freebsd.org/D13832 <--- test this update > > I'd like to get some feedback from AMD cpu users on this update. I've > restructured and undone a few things that may have been keeping folks > using this port from getting their runtime cpu microcode updates. Hi, I am trying out on RELENG_11 on a Ryzen CPU Without kib's commits at https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-January/005320.html I get root@testamd:/usr/ports/sysutils/devcpu-data # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Re-evalutation of CPU flags Failed. root@testamd:/usr/ports/sysutils/devcpu-data # with r327597, root@testamd:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@testamd:/home/mdtancsa # running x86info -a also generates this error / warning ? CPU0: local APIC error 0x80 root@testamd:/home/mdtancsa # x86info -a | grep -i microco Microcode patch level: 0x8001129 root@testamd:/home/mdtancsa # x86info -a | head -20 x86info v1.31pre Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 root@testamd:/home/mdtancsa # Also your diff is based on a previous version of the port. There was an update since, with new microcode from Intel that gets clobbered in your diffs. Thanks! ---Mike -- --- 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 https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>
On Fri, Jan 12, 2018 at 8:28 AM, Ed Maste wrote: > On 4 January 2018 at 03:10, Michael Tuexen wrote: > > > > Not sure this helps: But we have seen this also after system panics > > when having soft update journaling enabled. Having soft update journaling > > disabled, we do not observed this after several panics. > > Just to be clear: The panics are not related to this issue, > > but to other network development we do. > > Both of my new co-op students have encountered this as well: after a > panic (unrelated to the filesystem), SU+J fsck recovery runs at boot, > and than many cylinder checksum warnings are emitted by the kernel. > The students used the default installer configuration; it sounds like > we should disable SU+J by default in the installer until this issue is > addressed. > I've posted https://reviews.freebsd.org/D13884 as well to change fsck from silently fixing the cg checksum to one that's whiny about it as well. 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: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 01/12/18 08:38, Mike Tancsa wrote: > On 1/11/2018 6:03 PM, Sean Bruno wrote: >> https://reviews.freebsd.org/D13832 <--- test this update >> >> I'd like to get some feedback from AMD cpu users on this update. I've >> restructured and undone a few things that may have been keeping folks >> using this port from getting their runtime cpu microcode updates. > Hi, > I am trying out on RELENG_11 on a Ryzen CPU > > Without kib's commits at > > https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-January/005320.html > > I get > > root@testamd:/usr/ports/sysutils/devcpu-data # > /usr/local/etc/rc.d/microcode_update onestart > Updating CPU Microcode... > Re-evalutation of CPU flags Failed. > root@testamd:/usr/ports/sysutils/devcpu-data # Correct, this is expected. > > with r327597, > > root@testamd:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart > Updating CPU Microcode... > Done. > root@testamd:/home/mdtancsa # > > > > running x86info -a also generates this error / warning ? > > CPU0: local APIC error 0x80 > > Probably, update your port of x86info. I pushed an update for this and it might work better for you. > root@testamd:/home/mdtancsa # x86info -a | grep -i microco > Microcode patch level: 0x8001129 > root@testamd:/home/mdtancsa # x86info -a | head -20 > x86info v1.31pre > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Found 12 identical CPUs > Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 > CPU Model (x86info's best guess): > Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core > Processor > > Number of reporting banks : 7 > > root@testamd:/home/mdtancsa # > > > Also your diff is based on a previous version of the port. There was an > update since, with new microcode from Intel that gets clobbered in your > diffs. > > The update to Intel microcode was reverted. So, possibly the tree you are using is out of date? sean signature.asc Description: OpenPGP digital signature
Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 01/12/18 04:49, Rainer Hurling wrote: > Am 12.01.2018 um 00:03 schrieb Sean Bruno: >> https://reviews.freebsd.org/D13832 <--- test this update >> >> I'd like to get some feedback from AMD cpu users on this update. I've >> restructured and undone a few things that may have been keeping folks >> using this port from getting their runtime cpu microcode updates. >> >> After installing the port, grab your microcode version via >> sysutils/x86info. If you don't see an update, that only means there is >> no update available for your system. >> >> x86info -a | grep Microcode >> >> Run the microcode_update and repeat. Check /var/log/messages for a >> notification that the code was updated. You should be able to get >> something like the following for your system if it executed an update: >> >> root@lab:/home/sbruno # x86info -a | grep "CPU Model" >> CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2) >> >> root@lab:/home/sbruno # x86info -a | grep Microcode >> Microcode patch level: 0x6000629 >> >> root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart >> Updating CPU Microcode... >> Done. >> >> root@lab:/home/sbruno # x86info -a | grep Microcode >> Microcode patch level: 0x600063d >> >> root@lab:/home/sbruno # grep microcode_update /var/log/messages >> Jan 10 16:52:26 lab microcode_update: >> /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu >> /dev/cpuctl0 to revision 0x600063d... done. >> > > Just for the record, for an older Phenom with dmesg: > > CPU: AMD Phenom(tm) II X6 1090T Processor (3214.31-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x100fa0 Family=0x10 Model=0xa Stepping=0 > Features=0x178bfbff > Features2=0x802009 > AMD > Features=0xee500800 > AMD > Features2=0x37ff > SVM: NP,NRIP,NAsids=64 > TSC: P-state invariant, performance statistics > > > #x86info -a | grep "CPU Model" > CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion > (II)/Opteron (PH-E0) > > #x86info -a | grep Microcode > Microcode patch level: 0x1bf > > #/usr/local/etc/rc.d/microcode_update onestart > Updating CPU Microcode... > Done. > > #x86info -a | grep Microcode > Microcode patch level: 0x1bf > > #grep microcode_update /var/log/messages > --- > > So no recent update and no log messages, as expected ;) > > Regards, > Rainer Hurling > Thank you! sean signature.asc Description: OpenPGP digital signature
Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 1/12/2018 11:58 AM, Sean Bruno wrote: >> > > Probably, update your port of x86info. I pushed an update for this and > it might work better for you. Thanks, I tried it but still generates the error / warning. What does it mean ? (CPU0: local APIC error 0x80) It does however get rid of the "Unknown CPU family" error. root@testamd:/usr/ports/sysutils/devcpu-data # x86info -a | head x86info v1.31pre Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): AMD Zen Series Processor (ZP-B1) Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 MCG_CTL: Data cache check enabled root@testamd:/usr/ports/sysutils/devcpu-data # >> >> Also your diff is based on a previous version of the port. There was an >> update since, with new microcode from Intel that gets clobbered in your >> diffs. >> >> > > The update to Intel microcode was reverted. So, possibly the tree you > are using is out of date? Ahh, yes. I must have grabbed the ports just before you backed it out https://lists.freebsd.org/pipermail/svn-ports-all/2018-January/171209.html Thanks! ---Mike -- --- 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 https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On Fri, Jan 12, 2018 at 12:12:31PM -0500, Mike Tancsa wrote: > On 1/12/2018 11:58 AM, Sean Bruno wrote: > >> > > > > Probably, update your port of x86info. I pushed an update for this and > > it might work better for you. > > Thanks, I tried it but still generates the error / warning. What does it > mean ? (CPU0: local APIC error 0x80) It means that the x86info accessed not implemented LAPIC register. This warning is mostly harmless. ___ 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: USB stack
On Tue, Jan 9, 2018 at 10:09 AM, Mark Millard wrote: > > On 2018-Jan-8, at 1:15 AM, blubee blubeeme wrote: > > > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard > wrote: > >> [The involvement of sysutils/fusefs-simple-mtpfs > >> and sysutils/fusefs-libs and multimedia/libmtp > >> in order to use the Media Transfer Protocol (MTP) > >> against the LG v30 likely explains much of the > >> performance difference vs. local UFS file > >> systems. I provide some related notes.] > >> > >> blubee blubeeme gurenchan at gmail.com wrote on > >> Mon Jan 8 05:17:24 UTC 2018 : > >> > >> [Note: the original was in a reply to a Jon Brawn > >> post. I've merged it back with my post.] > >> > >> > On 2018-Jan-7, at 11:46 AM, Mark Millard > wrote: > >> > > >> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme > wrote: > >> >> > >> >> > >> >> > >> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard dsl-only.net> wrote: > >> >>> > >> On 2018-Jan-7, at 7:50 AM, blubee blubeeme > wrote: > >> > >> > I ran this test and here's some results. > >> > gstat -pd images: > >> > > >> > 18GB file from laptop to phone: https://imgur.com/a/7iHwv > >> > 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > >> > multiple small files from laptop to phone: > https://imgur.com/a/B4v4y > >> > multiple small files from laptop to ssd: > https://imgur.com/a/mDiMu > >> > > >> > The files are missing timestamps but the originals were taken > with scrot and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > >> > > >> > as far as why there's such high deletions? I can't say I'm only > using cp. > >> > >> I assume that md99 is for a file-based swap-space, such as > >> via /var/swap0 file. (As a side note I warn about bugzilla > >> 206048 for such contexts.) Otherwise please describe how > >> md99 is created. (Below I assume the swap-space usage of > >> md99.) > >> > >> The only other device that your pictures show is your > >> NVMe device nvd0. > >> > >> No picture shows a device for the LG v30 when it is mentioned > >> above as being copied to or from. How is it that there is no > >> mounted device shown for the LG v30? > >> > >> No picture shows a device for the SSD when it is mentioned > >> above as being copied to or from. How is it that there > >> is no mounted device shown for the SSD? > >> > >> Without a device displayed for the LG-v30/SSD there is nothing > >> displayed for its reads or writes. This makes the gstat -pd > >> useless. > >> > >> May be the p needs to be omitted for some reason? gstat -d > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > >> >>> > >> >>> You are correct that md99 is a file backed swap disk, I am aware of > the issues but I had to test some things out. > >> >>> > >> >>> Those tests earlier was a huge time sink. > >> >>> Here's the dmesg output from earlier: > >> >>> . . . > >> >>> -- > >> >>> > >> >>> I don't know why gstat isn't showing the info u are looking for. > >> >>> > >> >>> You said earlier that something was getting deleted, > >> >>> I don't know what could be causing that. > >> >> > >> >> Those "deletes" are more commonly called TRIM on SSD's. > >> >> FreeBSD called them, BIO_DELETE as I remember. > >> >> > >> >> Those deletes have nothing to do with umounting, deleteing > >> >> devices, etc. > >> >> > >> >>> I've provided tons of debug out, logs, pciconf, dmesg, etc... > >> >>> Even say forget the mobile device and go from > >> >>> zpool > >> >> > >> >> From which I've not been able to figure out the kind of > >> >> information that I'm looking for. > >> >> > >> >> Just because a device is present, does not mean that it > >> >> is available as a file system. I'm more interested in > >> >> how the file systems are made available --or if some > >> >> non-file system way of working is involved. > >> >> > >> >>> Are you saying that there's something misconfigured on my end? > >> >>> What other info do you need me to provide to try to figure out > >> >>> what's going on or why I'm getting these transfer rates? > >> >> > >> >> I'm saying I still can not tell how you make the SSD or the > >> >> LGv 30 available to FreeBSD (mount?). Or why no matching > >> >> mounted device shows up in gstat's display. > >> >> > >> >> If you wish to keep trying to help me help you, . . . > >> >> > >> >> Please show how you make the file system on the > >> >> SSD available to FreeBSD: what FreeBSD commands make > >> >> the device available for use. (I'd guess that mount > >> >> is used or that something like /etc/fstab is used > >> >> to do mounts more implicitly.) > >> >> > >> >> Please show how you make the LG v30 available to FreeBSD: > >> >> what FreeBSD commands make the device available for > >> >> use. (I'd guess that mount is used or that something like > >> >> /etc/
td_swvoltick
should_yield() compares thread::td_swvoltick to 'ticks' to determine whether a thread is hogging and should yield. Since td_swvoltick records 'ticks' /before/ the actual context switch, the calculation in should_yield() includes any time that the thread was switched out. It seems that should_yield() wants to know how long the thread has actually been running. Therefore, td_swvoltick should record 'ticks' /after/ sched_switch() returns. Does this make sense, or am I missing something? If this makes sense, I would probably keep the current assignment in mi_switch() and simply add a second assignment after the call to sched_switch(). That way, db_show_thread will still show useful data for sleeping threads. I would do the same for td_swinvolticks. I'll be happy to make the change myself. I just want a sanity check before I bother. Thanks in advance, Eric ___ 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: td_swvoltick
On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote: > should_yield() compares thread::td_swvoltick to 'ticks' to determine > whether a thread is hogging and should yield. Since td_swvoltick > records 'ticks' /before/ the actual context switch, the calculation in > should_yield() includes any time that the thread was switched out. It > seems that should_yield() wants to know how long the thread has actually > been running. Therefore, td_swvoltick should record 'ticks' /after/ > sched_switch() returns. > > Does this make sense, or am I missing something? Yes, it does make sense to me. > > If this makes sense, I would probably keep the current assignment in > mi_switch() and simply add a second assignment after the call to > sched_switch(). That way, db_show_thread will still show useful data > for sleeping threads. I would do the same for td_swinvolticks. > > I'll be happy to make the change myself. I just want a sanity check > before I bother. > > Thanks in advance, > > Eric > ___ > 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" ___ 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: td_swvoltick
On 01/12/2018 13:36, Konstantin Belousov wrote: > On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote: >> should_yield() compares thread::td_swvoltick to 'ticks' to determine >> whether a thread is hogging and should yield. Since td_swvoltick >> records 'ticks' /before/ the actual context switch, the calculation in >> should_yield() includes any time that the thread was switched out. It >> seems that should_yield() wants to know how long the thread has actually >> been running. Therefore, td_swvoltick should record 'ticks' /after/ >> sched_switch() returns. >> >> Does this make sense, or am I missing something? > Yes, it does make sense to me. Thanks, Kostik. If anyone else is interested: https://reviews.freebsd.org/D13892 >> >> If this makes sense, I would probably keep the current assignment in >> mi_switch() and simply add a second assignment after the call to >> sched_switch(). That way, db_show_thread will still show useful data >> for sleeping threads. I would do the same for td_swinvolticks. >> >> I'll be happy to make the change myself. I just want a sanity check >> before I bother. >> >> Thanks in advance, >> >> Eric ___ 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"
