Re: A question about max_uid
Note that you have to be careful to avoid the value of VNOVAL (-1) for a uid or a gid, or you'll run into trouble with the VFS layer; this is arguably due to poor design of VFS. NFSv2 also had problems with reserved values (as the NFSv2 interface greatly resembles the VFS interface, for the obvious reasons), but NFSv3 correct most of these. I'd really like to get VFS's overloading of vop_setattr() un-overloaded someday, perhaps by introducing an EXTATTR_NAMESPACE_UFS and having the changes be submitted via vop_setextattr(), but there's probably some non-atomicity concerns there that would have to be addressed. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Tue, 1 May 2001, Sheldon Hearn wrote: On Tue, 01 May 2001 06:56:56 +0900, Yoshihiro Koya wrote: Hello, chpass: updating the database... pwd_mkdb: 2147483647 recommended max uid value (65535) Gee, that message looks familiar. ;-) The warning was a concession that I implemented after discussions with BDE. The way we want to go for now is to have the entire system uid_t-clean (currently unsigned 32-bit) but to issue warnings from appropriate utilities when values that can't be represented by an unsigned short. Added to this, the above pwd_mkdb commands tells me that the recommended max uid value is 65535, which is a 16-bit UID, and this value 65535 differs from the restricted value of pw command. It might be better to unify such a recommended UID value on the system. Absolutely. If you have the time, that'd be great! Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Strangeness with newsyslog/wtmp
I notice that my /var/log/wtmp has strange renewal times. I don't know when it was not like this. newsyslog.conf is set to renew this once per week. What is causing this? # ls -l /var/log/wtmp* -rw-rw-r-- 1 root wheel0 Apr 29 12:00 /var/log/wtmp -rw-rw-r-- 1 root wheel 27 Apr 27 16:00 /var/log/wtmp.0.gz -rw-rw-r-- 1 root wheel 27 Apr 22 12:00 /var/log/wtmp.1.gz -rw-rw-r-- 1 root wheel 27 Apr 20 16:00 /var/log/wtmp.2.gz -rw-rw-r-- 1 root wheel 27 Apr 15 12:00 /var/log/wtmp.3.gz -rw-rw-r-- 1 root wheel 244 Apr 13 15:52 /var/log/wtmp.4.gz -rw-rw-r-- 1 root wheel 176 Apr 8 12:12 /var/log/wtmp.5.gz -rw-rw-r-- 1 root wheel 148 Apr 3 10:51 /var/log/wtmp.6.gz -rw-rw-r-- 1 root wheel 280 Mar 30 21:16 /var/log/wtmp.7.gz It looks like there are several cycles of renewal, Apr 8, 15, 22, 29 Apr 13, 20, 27. # grep wtmp /etc/newsyslog.conf /var/log/wtmp 644 7 *168 ZB # uptime 8:57AM up 17 days, 17:06, 5 users, load averages: 0.07, 0.05, 0.02 I am running -current of April 12. # uname -a FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #0:\ Thu Apr 12 19:30:44 PDT 2001\ root@celebris:/usr/src/sys/compile/CELEBRIS i386 tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: camcontrol stop / restart broken
On Mon, Apr 30, 2001 at 21:22:01 +0300, Tomi Vainio - Sun Finland - wrote: Kenneth D. Merry writes: This should be fixed as of rev 1.22 of scsi_all.c. There was an errant search and replace that caused the 'start' bit in the start/stop unit to always be set to 0 (stop). So automatic spinups wouldn't work, and 'camcontrol start' wouldn't work. Thanks, I'll test this soon. I'd still like to know when these messages are cropping up. I scanned messages files and it seems to start ~2 hours after I have tried to spin up the disk first time. Apr 28 23:01:40 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack Apr 28 23:08:10 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack Apr 29 00:49:42 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't allocate CCB, can't continue Apr 29 14:40:00 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack Apr 29 14:44:31 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack Apr 29 16:34:04 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't allocate path, can't continue Hmm. Well, I definitely haven't seen this before. The only thing I can figure is that we got into some sort of infinite rescan loop. I don't know how spinning up the disk (or trying to) would trigger a rescan. If it happens again, could you try to drop into the debugger and get a stack trace? If the stack trace doesn't show anything, perhaps setting a breakpoint in xpt_scan_lun would work. (You may want to have remote gdb setup for that.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: camcontrol stop / restart broken
Kenneth D. Merry writes: Hmm. Well, I definitely haven't seen this before. The only thing I can figure is that we got into some sort of infinite rescan loop. I don't know how spinning up the disk (or trying to) would trigger a rescan. My system has been up and running 21 hours since world rebuild and reboot. During this time I have stopped and started disk multiple times and these errors are history now. Tomppa -- SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: [EMAIL PROTECTED]+358 9 52556252 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: camcontrol stop / restart broken
On Tue, May 01, 2001 at 22:03:37 +0300, Tomi Vainio - Sun Finland - wrote: Kenneth D. Merry writes: Hmm. Well, I definitely haven't seen this before. The only thing I can figure is that we got into some sort of infinite rescan loop. I don't know how spinning up the disk (or trying to) would trigger a rescan. My system has been up and running 21 hours since world rebuild and reboot. During this time I have stopped and started disk multiple times and these errors are history now. Ahh, cool. Well, if you see them again, let me know. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! bad bug in -current.
Any -current kernel built over the weekend is a likely victim of this bug. In a nutshell, it will eat your root filesystem at the very least, leaving you with maybe one or two files in /lost+found. spec_vnops.c rev 1.156 is should be avoided at all costs. BEWARE: there are some snapshots on current.freebsd.org with this bug. They will self destruct after install. --- Forwarded Messages phk 2001/04/29 04:48:42 PDT Modified files: ...[other files in commit trimmed] sys/miscfs/specfsspec_vnops.c Log: Add a vop_stdbmap(), and make it part of the default vop vector. Make 7 filesystems which don't really know about VOP_BMAP rely on the default vector, rather than more or less complete local vop_nopbmap() implementations. Revision ChangesPath 1.156 +1 -2 src/sys/miscfs/specfs/spec_vnops.c --- Message 2 bde 2001/04/30 07:35:37 PDT Modified files: sys/miscfs/specfsspec_vnops.c Log: Backed out previous commit. It cause massive filesystem corruption, not to mention a compile-time warning about the critical function becoming unused, by replacing spec_bmap() with vop_stdbmap(). ntfs seems to have the same bug. The factor for converting specfs block numbers to physical block numbers is 1, but vop_stdbmap() uses the bogus factor btodb(ap-a_vp-v_mount-mnt_stat.f_iosize), which is 16 for ffs with the default block size of 8K. This factor is bogus even for vop_stdbmap() -- the correct factor is related to the filesystem blocksize which is not necessarily the same to the optimal i/o size. vop_stdbmap() was apparently cloned from nfs where these sizes happen to be the same. There may also be a problem with a_vp-v_mount being null. spec_bmap() still checks for this, but I think the checks in specfs are dead code which used to support block devices. Revision ChangesPath 1.157 +2 -1 src/sys/miscfs/specfs/spec_vnops.c --- End of Forwarded Messages To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Strangeness with newsyslog/wtmp
In message [EMAIL PROTECTED], Thomas D. Dean write s: I notice that my /var/log/wtmp has strange renewal times. I don't know when it was not like this. newsyslog.conf is set to renew this once per week. What is causing this? -rw-rw-r-- 1 root wheel 27 Apr 15 12:00 /var/log/wtmp.3.gz -rw-rw-r-- 1 root wheel 244 Apr 13 15:52 /var/log/wtmp.4.gz -rw-rw-r-- 1 root wheel 176 Apr 8 12:12 /var/log/wtmp.5.gz -rw-rw-r-- 1 root wheel 148 Apr 3 10:51 /var/log/wtmp.6.gz -rw-rw-r-- 1 root wheel 280 Mar 30 21:16 /var/log/wtmp.7.gz Gzip by default preserves the last-modified time of a file when gzipping, so these times are actually the times at which the wtmp file was previously modified before being rotated. Try ls -lc, which will show up the rotation time. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic in fxp driver
I'm updating a machine (Pentium II 350, 128MB RAM) to -current, and ran
into this panic in the fxp driver. Sources are from today (5/1/2001).
I believe the chip is an 82557.
I compiled and installed a kernel, rebooted and started running an
installworld over NFS. The installworld stopped here:
=== usr.bin/basename
install -c -s -o root -g wheel -m 555 basename /usr/bin
install -c -o root -g wheel -m 444 basename.1.gz /usr/share/man/man1
/usr/share/man/man1/dirname.1.gz - /usr/share/man/man1/basename.1.gz
=== usr.bin/biff
install -c -s -o root -g wheel -m 555 biff /usr/bin
install -c -o root -g wheel -m 444 biff.1.gz /usr/share/man/man1
=== usr.bin/brandelf
install -c -s -o root -g wheel -m 555 brandelf /usr/bin
The stack trace:
(kgdb) where
#0 m_freem (m=0xc0b84d00) at ../../kern/uipc_mbuf.c:572
#1 0xc018ef76 in fxp_intr (xsc=0xc1372800) at ../../dev/fxp/if_fxp.c:993
#2 0xc01fe533 in ithread_loop (arg=0xc136be80) at ../../kern/kern_intr.c:517
#3 0xc01fd0e0 in fork_exit (callout=0xc01fe1c8 ithread_loop,
arg=0xc136be80, frame=0xc926ffa8) at ../../kern/kern_fork.c:731
It blew up on line 572 of uipc_mbuf:
(kgdb) list
567 /*
568 * we do need to check non-first mbuf, since some of existing
569 * code does not call M_PREPEND properly.
570 * (example: call to bpf_mtap from drivers)
571 */
572 if ((m-m_flags M_PKTHDR) != 0 m-m_pkthdr.aux) {
573 m_freem(m-m_pkthdr.aux);
574 m-m_pkthdr.aux = NULL;
575 }
576 MFREE(m, n);
It looks like the mbuf pointer is bogus:
(kgdb) print m
$2 = (struct mbuf *) 0xf0006b00
(kgdb) print *m
Cannot access memory at address 0xf0006b00.
Although in the next frame up the stack, the mbuf pointer looks okay:
(kgdb) up
#1 0xc018ef76 in fxp_intr (xsc=0xc1372800) at ../../dev/fxp/if_fxp.c:993
(kgdb) print txp-mb_head
$3 = (struct mbuf *) 0xc0b84d00
(kgdb) print *txp-mb_head
$4 = {m_hdr = {mh_next = 0xc0b8ea00, mh_nextpkt = 0x0,
mh_data = 0xc0b84dd6 , mh_len = 42, mh_type = 0, mh_flags = 2}, M_dat = {
MH = {MH_pkthdr = {rcvif = 0x0, len = 178, header = 0xcb90adb,
csum_flags = 0, csum_data = 6, aux = 0x0}, MH_dat = {MH_ext = {
ext_buf = 0x1f943403 Address 0x1f943403 out of bounds,
ext_free = 0, ext_args = 0x200, ext_size = 2743468288,
ref_cnt = 0x300, ext_type = 50331648},
MH_databuf =
\0034\224\037\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\,
'\000' repeats 19 times,
\a\000\000\000\000\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\005\000\000\000\024\000\000\000\037\000\000\000\000\000\000\000\000C\235(J¡àaëÏ\220V¦ý\037\002#¹Î3+\005\233üñôç\036D\a\212wõRW\0034\224\036\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\,
'\000' repeats 15 times,
°Ð{Ñ\036\000 ɳ¼G\b\000E\000\000¤¸\233\000\000@\021RÅ¢\2256¢\2255\003õ\b\001\000\220ÜC}},
M_databuf =
\000\000\000\000²\000\000\000Û\n¹\f\000\000\000\000\006\000\000\000\000\000\000\000\0034\224\037\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\,
'\000' repeats 19 times,
\a\000\000\000\000\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\005\000\000\000\024\000\000\000\037\000\000\000\000\000\000\000\000C\235(J¡àaëÏ\220V¦ý\037\002#¹Î3+\005\233üñôç\036D\a\212wõRW\0034\224\036\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\,
'\000' repeats 15 times, °Ð{Ñ\036\000 ɳ¼G\b\000E\000\000¤¸\233...}}
(kgdb) list
988
989 for (txp = sc-cbl_first; sc-tx_queued
990 (txp-cb_status FXP_CB_STATUS_C) != 0;
991 txp = txp-next) {
992 if (txp-mb_head != NULL) {
993 m_freem(txp-mb_head);
994 txp-mb_head = NULL;
995 }
996 sc-tx_queued--;
997 }
(kgdb)
So I'm not sure what's going on here.
Anyone seen anything like this recently?
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
Kenneth D. Merry wrote: It looks like the mbuf pointer is bogus: (kgdb) print m $2 = (struct mbuf *) 0xf0006b00 (kgdb) print *m Cannot access memory at address 0xf0006b00. Although in the next frame up the stack, the mbuf pointer looks okay: (kgdb) up #1 0xc018ef76 in fxp_intr (xsc=0xc1372800) at ../../dev/fxp/if_fxp.c:993 (kgdb) print txp-mb_head This is a well known problem, and a real gotcha. kgdb does not know how and when variables are stored in registers. It *always* reads the stack values, not the registers. You can disassemble the code and find out what register is currently holding 'm' and either look at the current registers or the trap frame if there is one. I suspect we are missing some magic in our kernel interface code for gdb and it is not running in 'gcc generated .stabs' mode. On the other hand, you might try using dwarf2 debugging, that is pretty complete. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
On Tue, May 01, 2001 at 02:16:33PM -0700, Peter Wemm wrote: On the other hand, you might try using dwarf2 debugging, that is pretty complete. And what we'll be using when GCC 3.0 is imported. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Rfork'd threads, signals, and LDTs
Why are %fs and %gs set back to default (_udata_sel) when posting signals? I am planning on using %fs for TSD/KSD and want it to be valid in signal handlers. A test program is at: http://people.freebsd.org/~deischen/test_tsd.c Compile it with -DDEBUG on an unpatched kernel to show more details. This following seems to fix it. Any reason it would cause problems? Index: machdep.c === RCS file: /opt/FreeBSD/cvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.447 diff -u -r1.447 machdep.c --- machdep.c 2001/04/27 19:28:19 1.447 +++ machdep.c 2001/05/01 22:20:52 @@ -745,8 +745,6 @@ regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; regs-tf_es = _udatasel; - regs-tf_fs = _udatasel; - load_gs(_udatasel); regs-tf_ss = _udatasel; } -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
On Tue, May 01, 2001 at 12:15:34PM -0700, some SMTP stream spewed forth: Any -current kernel built over the weekend is a likely victim of this bug. In a nutshell, it will eat your root filesystem at the very least, leaving you with maybe one or two files in /lost+found. spec_vnops.c rev 1.156 is should be avoided at all costs. BEWARE: there are some snapshots on current.freebsd.org with this bug. They will self destruct after install. --- Forwarded Messages *snip* Say, FreeBSD is usually pretty safe, even in CURRENT. Has something near this magnitude of Really Bad Stuffage snuck into the codebase before? (This is just for my personal knowledge. I don't remeber anything this bad in recent times.) gh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
Say, FreeBSD is usually pretty safe, even in CURRENT. Has something near this magnitude of Really Bad Stuffage snuck into the codebase before? No, it's not common, and it generally takes a Dane swinging something sharp to inflict quite this much damage on our user base. ;-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
It was almost like that dirpref problem I ran into a few weeks ago, I upgraded from -stable to -current and I had to reinstall because of it, but this usually doesn't happen. - Original Message - From: Jordan Hubbard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, May 01, 2001 6:56 PM Subject: Re: HEADS UP! bad bug in -current. Say, FreeBSD is usually pretty safe, even in CURRENT. Has something near this magnitude of Really Bad Stuffage snuck into the codebase before? No, it's not common, and it generally takes a Dane swinging something sharp to inflict quite this much damage on our user base. ;-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
On 01-May-01 Jordan Hubbard wrote: Say, FreeBSD is usually pretty safe, even in CURRENT. Has something near this magnitude of Really Bad Stuffage snuck into the codebase before? No, it's not common, and it generally takes a Dane swinging something sharp to inflict quite this much damage on our user base. ;-) - Jordan I dunno, certain Berkeley professors have pretty close as well. ;) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
On Tue, May 01, 2001 at 06:23:59PM -0500, GH wrote: On Tue, May 01, 2001 at 12:15:34PM -0700, some SMTP stream spewed forth: Any -current kernel built over the weekend is a likely victim of this bug. In a nutshell, it will eat your root filesystem at the very least, leaving you with maybe one or two files in /lost+found. spec_vnops.c rev 1.156 is should be avoided at all costs. BEWARE: there are some snapshots on current.freebsd.org with this bug. They will self destruct after install. --- Forwarded Messages *snip* Say, FreeBSD is usually pretty safe, even in CURRENT. Has something near this magnitude of Really Bad Stuffage snuck into the codebase before? (This is just for my personal knowledge. I don't remeber anything this bad in recent times.) It happens from time to time. VM was really unstable for a period a few years ago (3.0-CURRENT timeframe) when John Dyson was dinking with it. This is why you need to be extra-careful when running -current on systems with data you care about :-) Kris PGP signature
Re: Experiences with new dir allocation on FFS?
On Sun, Apr 29, 2001 at 12:50:08AM -0300, Rik van Riel wrote: For the people wanting to turn on write caching ... it WILL break the write ordering needed by softupdates and journaling filesystems, so don't do it unless you know what you're doing. I guess it would be better to do this kind of write caching at the kernel level, because the OS has a much better idea of when to write which data to platter than a harddisk can ever have. However, on ATA without tagged queuing, turning off write caching (on my own UDMA33 system) reduces write performance by a factor of two. From 12MB/s to 6MB/s on my system. That is almost certainly because (a) ATA limits individual transfers to 64k, and (b) you can't get the next 64k into the drive before you miss the opportunity to stream the data into the next sector, so you lose a revolution _every_ write. I think I'll rely on the power system and my nightly backups, and leave .wc=1, thanks. Sure, on my next system I'll either go back to SCSI or find some ATA tagged queuing drives, but at the moment, I have to use what I've got... -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
No Subject
unsubscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
On Tue, 1 May 2001, Daniel Eischen wrote: Why are %fs and %gs set back to default (_udata_sel) when posting signals? All segment registers are set to a default state so that signal handlers have some chance of running when they interrupt code that has changed the segment registers to unusual values. I am planning on using %fs for TSD/KSD and want it to be valid in signal handlers. Imagine doing the same thing with %ds, or better yet, %ss. %ss must be set to the default for the kernel to even provide a normal stack for the signal handler. Similarly for %ds, except it is possible for signal handlers to set up their own %ds as necessary provided both the user code and the signal trampoline is written to avoid using %ds before initializing it. This following seems to fix it. Any reason it would cause problems? Index: machdep.c === RCS file: /opt/FreeBSD/cvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.447 diff -u -r1.447 machdep.c --- machdep.c 2001/04/27 19:28:19 1.447 +++ machdep.c 2001/05/01 22:20:52 @@ -745,8 +745,6 @@ regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; regs-tf_es = _udatasel; - regs-tf_fs = _udatasel; - load_gs(_udatasel); regs-tf_ss = _udatasel; } There is also the osendsig() case, and corresponding code in several emulators. The problem has some similarites to ones for handling floating point state. We should be setting the FPU to a clean state so that signal handlers can use floating point. (We don't do this on i386's because signal handlers rarely use floating point and it is difficiult to do without pessimizing delivery of all signals.) OTOH, I believe C99 says that the floating point environment (things like rounding control) is inherited by signal handlers. This seems to be even more difficult to implement on i386's. Changes in the enviroment made by fesetenv() should apply to signal handlers, but temporary ones made by the compiler and library functions should not. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
