Re: NFSv4 console messages (locks lost etc.)
Hi, I should have mentioned that the server is FreeBSD -STABLE running newnfs, and the network isn't partitioned (because I access the box over SSH at the same time I see these messages.) They only appear under heavy NFS load (portmaster build of math/R in this case.) Lars On Jun 29, 2013, at 2:32, Rick Macklem wrote: > Lars Eggert wrote: >> Hi, >> >> on a -CURRENT client, I get quite a number of console messages under >> heavy NFSv4 load, such as: >> >> nfsv4 expired locks lost > Means the lease expired on the NFSv4 server somehow. Lease > expiry is "bad news" and there is no way to recover locks > lost because of it. >> nfscl: never fnd open > Usually, opens can be recovered after a lease expiry, but it > might be broken. Since lease expiry should never happen during > normal operation (see below), it doesn't get a lot of testing. > >> nfscl: never fnd open >> nfscl: never fnd open >> nfsv4 expired locks lost >> nfscl: never fnd open >> nfscl: never fnd open >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfscl: never fnd open >> >> Can I ignore them? Can I turn them off? >> > Well, these should never happen during normal, correct operation. The > "nfsv4 expired locks lost" implies lease expiry. This should only happen > when the client is network partitioned from the server for more than > a lease duration (chosen by the server, but typically about 1minute). > The client does a Renew Op every 1/2 lease durations to avoid this. Also, > any state related operation (open/lock/locku/close/etc) is supposed to > renew the lease implicitly. > > If you are getting network partitions happening, then you really need > to fix the network. > > If not, then if you watch network traffic with something like wireshark > and see Renew Ops happening at regular intervals, then I can only suggest > that the server is somehow broken for NFSv4. You should also look for > NFS4ERR_EXPIRED error replies to operations related to state > (open/lock/locku/close). > That is the server reply which indicates the lease expiry. If the server is > never returning this, I have no idea how the client would generate the above > messages, but it does indicate a client NFSv4 bug if that is the case. > > Switching all mounts to NFSv3 will get rid of the above, although it is > not exactly a fix;-) > > rick > >> Thanks, >> Lars >> ___ >> 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" >> ___ 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: NFSv4 console messages (locks lost etc.)
Thanks Rick! I will check these Monday. Lars On Jun 29, 2013, at 2:45, Rick Macklem wrote: > Lars Eggert wrote: >> Hi, >> >> On Jun 28, 2013, at 16:37, "Eggert, Lars" wrote: >>> On Jun 28, 2013, at 16:14, "Eggert, Lars" wrote: on a -CURRENT client, I get quite a number of console messages under heavy NFSv4 load, such as: nfsv4 expired locks lost nfscl: never fnd open > The "never fnd open" message is generated by the NFSv4 client when > a close can't find an extant open to close. I suspect the "open" was > not recovered after lease expiry. Since Close Ops only matter to the > NFSv4 server, this doesn't imply a problem unless the NFSv4 server > thinks the client still has an Open (which would not be the case after > an NFSv4 server expires a lease, since it assumes all state such as opens > are lost when a lease is expired). > >>> >>> actually, not sure if the "nfscl" message is from an NFSv4 mount >>> point or not, because the box mounts root via BOOTP, so with NFSv3 >>> (or v2?) and some other mounts with NFSv4. >> >> and another data point: the "nfscl" messages seem to disappear when I >> remove the BOOTP_NFSV3 flag from the kernel. The client hangs that >> made me dig into these messages seem to also disappear, fingers >> crossed. >> > Hmm, weird, since NFSv3 should never generate these messages. I think > that a root fs is remounted using the "/" entry in the /etc/fstab in the > NFS mounted root fs. Did this entry specify "nfsv4" by any chance? > > Btw, a NFSv4 mounted root fs will not work correctly, because the client > name is generated from the host uuid, which isn't set when the root fs > is mounted. I'm not sure what the client would use as its client name, > but this will definitely break things badly if multiple clients use the > same name. (And this might explain the lease expiry problem.) > > If the root fs is mounted NFSv3 (or NFSv2) it shouldn't generate the > messages or have any effect on the NFSv4 client, so I have no idea > why removing BOOTP_NFSV3 would have any effect on this? > > Oh, and if you are using a pretty up to date system, you can "nfsstat -m" > to find out what mount options are actually in use. If "nfsv4" is listed > for your root fs, that is a serious problem that you need to fix. > > rick > >> (I still get a bunch of "nfsv4 expired locks lost" messages, but no >> hangs.) >> >> Lars >> ___ >> 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" >> ___ 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: panic: vm_page_alloc: pindex already allocated
On Tue, 25 Jun 2013, Gavin Atkinson wrote: > I've just managed to panic an amd64 host, running HEAD r252161 from June > 24th. Filesystem is fully ZFS, no UFS or NFS is involved. The panic is > fully reproducible, and is also reproduceable with r251861, so has not > been introduced in the last week. > > Within the jail, I ran "tail -f /var/log/httpd-access.log". The machine > immediately paniced: For the archives, this was fixed with r252337. Gavin > panic: vm_page_alloc: pindex already allocated > cpuid = 3 > KDB: enter: panic > [ thread pid 29345 tid 100408 ] > Stopped at kdb_enter+0x3b: movq$0,0xabcab2(%rip) > db> bt > Tracing pid 29345 tid 100408 td 0xfe00cd564000 > kdb_enter() at kdb_enter+0x3b/frame 0xff895d48e340 > vpanic() at vpanic+0xe1/frame 0xff895d48e380 > kassert_panic() at kassert_panic+0xd3/frame 0xff895d48e470 > vm_page_alloc() at vm_page_alloc+0x4ce/frame 0xff895d48e4b0 > zfs_freebsd_write() at zfs_freebsd_write+0x89c/frame 0xff895d48e6c0 > VOP_WRITE_APV() at VOP_WRITE_APV+0x113/frame 0xff895d48e7d0 > vn_write() at vn_write+0x281/frame 0xff895d48e860 > vn_io_fault() at vn_io_fault+0x94/frame 0xff895d48e9f0 > dofilewrite() at dofilewrite+0x85/frame 0xff895d48ea40 > kern_writev() at kern_writev+0x6c/frame 0xff895d48ea80 > sys_write() at sys_write+0x64/frame 0xff895d48ead0 > amd64_syscall() at amd64_syscall+0x389/frame 0xff895d48ebf0 > Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff895d48ebf0 > --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x8020cd7aa, rsp = > 0x7fffd798, rbp = 0x13 --- > > > Reproducing the panic is easy. While the machine is being accessed (and > so Apache is busy writing lots to /var/log/httpd-access.log), running > the following as root will panic the machine, usually within 10 seconds: > > #!/bin/sh > while [ 1 ] > do > tail /var/log/httpd-access.log > /dev/null > done > > I have core files available. I've also put a dump of the implicated > mpred and object structures at > https://svnmir.bme.freebsd.org/core.1.gdb.txt (gdb output) > https://svnmir.bme.freebsd.org/core.txt.1 (dumpinfo) > > Thanks, > > Gavin > > ___ > 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" > ___ 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: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
On Thu, 27 Jun 2013 23:58:33 +0200 Kristof Provost wrote: > On 2013-06-24 22:08:01 (+0200), Alexander Leidinger > wrote: > > On Mon, 24 Jun 2013 12:15:18 +0200 > > Kristof Provost wrote: > > > > > For what it's worth, I'm running into exactly the same problem. > > > (amd64, stable/9). I have no custom settings in /etc/make.conf > > > or /etc/src.conf > > > > I had a short discussion with the maintainer of our > > stress-test-suite, he was able to create a test-case which triggers > > the problem. > > > I've been bisecting for a little bit, and while I'm not 100% sure yet, > there is one likely culprit right now: r249643. > It's an MFC with a number of ZFS changes relating to a refactoring of > the ioctl() interface. > > It is, unfortunately, also a rather large commit. Martin, the issue here is that starting a jail with a recent -current panics, if the jail has a dataset assigned to it during start (and the rc.d zfs scripts kicks in). At least in my case the jail contains an userland from before the change and the jail host a current userland. Any ideas / suggestions? pho@ has a test case for this. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
On 2013-06-29 12:01, Alexander Leidinger wrote: > On Thu, 27 Jun 2013 23:58:33 +0200 > Kristof Provost wrote: > >> On 2013-06-24 22:08:01 (+0200), Alexander Leidinger >> wrote: >>> On Mon, 24 Jun 2013 12:15:18 +0200 >>> Kristof Provost wrote: >>> For what it's worth, I'm running into exactly the same problem. (amd64, stable/9). I have no custom settings in /etc/make.conf or /etc/src.conf >>> I had a short discussion with the maintainer of our >>> stress-test-suite, he was able to create a test-case which triggers >>> the problem. >>> >> I've been bisecting for a little bit, and while I'm not 100% sure yet, >> there is one likely culprit right now: r249643. >> It's an MFC with a number of ZFS changes relating to a refactoring of >> the ioctl() interface. >> >> It is, unfortunately, also a rather large commit. > Martin, the issue here is that starting a jail with a recent -current > panics, if the jail has a dataset assigned to it during start (and > the rc.d zfs scripts kicks in). At least in my case the jail contains an > userland from before the change and the jail host a current userland. > > Any ideas / suggestions? pho@ has a test case for this. > > Bye, > Alexander. > Hi Alexander, some input would be great (at least the panic message - ideally from a debug kernel). Cheers, mm ___ 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"
another -Wunsequenced topic
Here's a patch to fix several compilation errors coming from -Wunsequenced
warnings:
Index: bin/ed/re.c
===
--- bin/ed/re.c (revision 252372)
+++ bin/ed/re.c (working copy)
@@ -89,7 +89,7 @@
default:
break;
case '[':
- if ((nd = parse_char_class(++nd)) == NULL) {
+ if ((nd = parse_char_class(nd + 1)) == NULL) {
errmsg = "unbalanced brackets ([])";
return NULL;
}
Index: contrib/bmake/meta.c
===
--- contrib/bmake/meta.c(revision 252372)
+++ contrib/bmake/meta.c(working copy)
@@ -1249,7 +1249,7 @@
warnx("%s: %d: line truncated at %u", fname,
lineno, x);
break;
}
- cp = strchr(++cp, '\n');
+ cp = strchr(cp + 1, '\n');
} while (cp);
if (buf[x - 1] == '\n')
buf[x - 1] = '\0';
Index: lib/libfetch/fetch.c
===
--- lib/libfetch/fetch.c(revision 252372)
+++ lib/libfetch/fetch.c(working copy)
@@ -376,7 +376,7 @@
/* password */
if (*q == ':')
- q = fetch_pctdecode(u->pwd, ++q, URL_PWDLEN);
+ q = fetch_pctdecode(u->pwd, q + 1, URL_PWDLEN);
p++;
} else {
Index: lib/libutil/login_times.c
===
--- lib/libutil/login_times.c (revision 252372)
+++ lib/libutil/login_times.c (working copy)
@@ -96,7 +96,7 @@
else
m.lt_start = 0;
if (*p == '-')
- p = parse_time(++p, &m.lt_end);
+ p = parse_time(p + 1, &m.lt_end);
else
m.lt_end = 1440;
Index: usr.sbin/newsyslog/newsyslog.c
===
--- usr.sbin/newsyslog/newsyslog.c (revision 252372)
+++ usr.sbin/newsyslog/newsyslog.c (working copy)
@@ -1083,7 +1083,7 @@
* at any time, etc).
*/
if (strcasecmp(DEBUG_MARKER, q) == 0) {
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
warnx("debug line specifies no option:\n%s",
@@ -1096,7 +1096,7 @@
} else if (strcasecmp(INCLUDE_MARKER, q) == 0) {
if (verbose)
printf("Found: %s", errline);
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse) {
warnx("include line missing argument:\n%s",
@@ -1138,7 +1138,7 @@
defconf_p = working;
}
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, "malformed line (missing fields):\n%s",
@@ -1172,7 +1172,7 @@
} else
working->gid = (gid_t)-1;
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, "malformed line (missing fields):\n%s",
@@ -1187,7 +1187,7 @@
errx(1, "error in config file; bad permissions:\n%s",
errline);
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, "malformed line (missing fields):\n%s",
@@ -1197,7 +1197,7 @@
errx(1, "error in config file; bad value for count of logs
to save:\n%s",
errline);
- q = parse = missing_field(sob(++parse), errline);
+ q = parse = missing_field(sob(parse + 1), errline);
parse = son(parse);
if (!*parse)
errx(1, "malformed line (missing fields):\n%s",
@@ -1215,7 +1215,7 @@
working->flags = 0;
working->compress = COMPRESS_NONE;
- q = parse = missing_field(sob(++parse), errline);
+ q = p
compilation error regarding __cxa_call_terminate()
Using Clang head: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:44:1: error: conflicting types for '__cxa_call_terminate' __cxa_call_terminate(_Unwind_Exception* ue_header_) ^ /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:136:17: note: previous declaration is here extern "C" void __cxa_call_terminate (void*) __attribute__((noreturn)); ^ ___ 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"
Robert Noland's DRM patch
I'm tired of having a local patch to fix video card software. The patch was written by Robert Noland, and is supposed to fix cases where "DRM is doing a copyin() while holding a mutex, which is not allowed". Could someone commit the patch? If not, why? ___ 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: Robert Noland's DRM patch
Index: sys/dev/drm/r300_cmdbuf.c
===
--- sys/dev/drm/r300_cmdbuf.c (revision 252372)
+++ sys/dev/drm/r300_cmdbuf.c (working copy)
@@ -1043,6 +1043,8 @@
int emit_dispatch_age = 0;
int ret = 0;
+ DRM_UNLOCK();
+
DRM_DEBUG("\n");
/* pacify */
@@ -1205,5 +1207,7 @@
COMMIT_RING();
+ DRM_LOCK();
+
return ret;
}
Index: sys/dev/drm/radeon_irq.c
===
--- sys/dev/drm/radeon_irq.c (revision 252372)
+++ sys/dev/drm/radeon_irq.c (working copy)
@@ -338,10 +338,13 @@
result = radeon_emit_irq(dev);
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(emit->irq_seq, &result, sizeof(int))) {
DRM_ERROR("copy_to_user\n");
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_mem.c
===
--- sys/dev/drm/radeon_mem.c (revision 252372)
+++ sys/dev/drm/radeon_mem.c (working copy)
@@ -246,11 +246,14 @@
if (!block)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(alloc->region_offset, &block->start,
sizeof(int))) {
DRM_ERROR("copy_to_user\n");
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_state.c
===
--- sys/dev/drm/radeon_state.c (revision 252372)
+++ sys/dev/drm/radeon_state.c (working copy)
@@ -1773,8 +1773,13 @@
}
if (!buf) {
DRM_DEBUG("EAGAIN\n");
- if (DRM_COPY_TO_USER(tex->image, image, sizeof(*image)))
+ DRM_UNLOCK();
+ if (DRM_COPY_TO_USER(tex->image, image,
+ sizeof(*image))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
return -EAGAIN;
}
@@ -1786,10 +1791,13 @@
#define RADEON_COPY_MT(_buf, _data, _width) \
do { \
- if (DRM_COPY_FROM_USER(_buf, _data, (_width))) {\
+ DRM_UNLOCK(); \
+ if (DRM_COPY_FROM_USER(_buf, _data, (_width))) { \
DRM_ERROR("EFAULT on pad, %d bytes\n", (_width)); \
+ DRM_LOCK(); \
return -EFAULT; \
} \
+ DRM_LOCK(); \
} while(0)
if (microtile) {
@@ -2130,9 +2138,13 @@
if (sarea_priv->nbox > RADEON_NR_SAREA_CLIPRECTS)
sarea_priv->nbox = RADEON_NR_SAREA_CLIPRECTS;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(&depth_boxes, clear->depth_boxes,
- sarea_priv->nbox * sizeof(depth_boxes[0])))
+ sarea_priv->nbox * sizeof(depth_boxes[0]))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
radeon_cp_dispatch_clear(dev, clear, depth_boxes);
@@ -2394,10 +2406,13 @@
return -EINVAL;
}
- if (DRM_COPY_FROM_USER(&image,
- (drm_radeon_tex_image_t __user *) tex->image,
- sizeof(image)))
- return -EFAULT;
+ DRM_UNLOCK();
+ ret = -DRM_COPY_FROM_USER(&image,
+ (drm_radeon_tex_image_t __user *) tex->image,
+ sizeof(image));
+ DRM_LOCK();
+ if (ret)
+ return ret;
RING_SPACE_TEST_WITH_RETURN(dev_priv);
VB_AGE_TEST_WITH_RETURN(dev_priv);
@@ -2418,8 +2433,12 @@
LOCK_TEST_WITH_RETURN(dev, file_priv);
- if (DRM_COPY_FROM_USER(&mask, stipple->mask, 32 * sizeof(u32)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(&mask, stipple->mask, 32 * sizeof(u32))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
RING_SPACE_TEST_WITH_RETURN(dev_priv);
@@ -2546,16 +2565,24 @@
drm_radeon_prim_t prim;
drm_radeon_tcl_prim_t tclprim;
- if (DRM_COPY_FROM_USER(&prim, &vertex->prim[i], sizeof(prim)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(&prim, &vertex->prim[i], sizeof(prim))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (prim.stateidx != laststate) {
drm_radeon_state_t state;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(&state,
&vertex->state[prim.stateidx],
- sizeof(state)))
+ sizeof(state))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (radeon_emit_state2(dev_priv, file_priv, &state)) {
DRM_ERROR("radeon_emit_state2 failed\n");
@@ -2772,8 +2799,12 @@
do {
if (i < cmdbuf->nbox) {
- if (DRM_COPY_FROM_USER(&box, &boxes[i], sizeof(box)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(&box, &boxes[i], sizeof(box))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
/* FIXME The second and subsequent times round
* this loop, send a WAIT_UNTIL_3D_IDLE before
* calling emit_clip_rect(). This fixes a
@@ -2866,11 +2897,14 @@
kbuf = drm_alloc(cmdbuf->bufsz, DRM_MEM_DRIVER);
if (kbuf == NULL)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(kbuf, (void __user *)cmdbuf->buf,
cmdbuf->bufsz)) {
+ DRM_LOCK();
drm_free(kbuf, orig_bufsz, DRM_MEM_DRIVER);
return -EFAULT;
}
+ DRM_LOCK();
cmdbuf->buf = kbuf;
}
@@ -3089,10 +3123,13 @@
return -EINVAL;
}
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(param->value, &value, sizeof(int))) {
DRM_ERROR("copy_to_user\n");
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
_
Re: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
On Sat, 29 Jun 2013 14:02:35 +0200
Martin Matuska wrote:
> some input would be great (at least the panic message - ideally from a
> debug kernel).
The bt in the minidump is useless, but I made a bt directly
in the kernel debugger:
---snip---
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x0
fault code = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer = 0x28:0xff839e79d930
frame pointer = 0x28:0xff839e79d9e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2183 (zfs)
db> bt
Tracing pid 2356
uart_sab82532_class() at 0
devfs_ioctl_f() at devfs_ioctl_f+0xf0
kern_ioctl() at kern_ioctl+0x1d7
sys_ioctl() at sys_ioctl+0x142
---snip---
The test case is easy, create a dataset for a jail, add something like
this to /etc/devfs.rules:
---snip---
[devfsrules_unhide_zfs=12]
add path zfs unhide
[devfsrules_jail_withzfs=17]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_zfs
---snip---
Attach the dataset to the jail and see the box panicing on the use of
the zfs command in the jail (maybe you don't even need to attach the
dataset to the jail, maybe just the above devfs stuff is enough).
The default jail scripts don't attach a ZFS dataset to a jail, the
corresponding ezjail-script code is
# Attach ZFS-datasets to the jail
for zfs in ${ezjail_zfs_datasets}; do
/sbin/zfs jail ${ezjail_id} ${zfs} || echo -n "Error: ${zfs} could not
be configured"
done
Bye,
Alexander.
--
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: another -Wunsequenced topic
Thanks! I've committed all of these except the change
to contrib/bmake/ which should probably be submitted
upstream first.
Tim
On Jun 29, 2013, at 7:16 AM, d...@gmx.com wrote:
> Here's a patch to fix several compilation errors coming from -Wunsequenced
> warnings:
>
> Index: bin/ed/re.c
> ===
> --- bin/ed/re.c (revision 252372)
> +++ bin/ed/re.c (working copy)
> @@ -89,7 +89,7 @@
> default:
> break;
> case '[':
> - if ((nd = parse_char_class(++nd)) == NULL) {
> + if ((nd = parse_char_class(nd + 1)) == NULL) {
> errmsg = "unbalanced brackets ([])";
> return NULL;
> }
> Index: contrib/bmake/meta.c
> ===
> --- contrib/bmake/meta.c (revision 252372)
> +++ contrib/bmake/meta.c (working copy)
> @@ -1249,7 +1249,7 @@
> warnx("%s: %d: line truncated at %u", fname,
> lineno, x);
> break;
> }
> - cp = strchr(++cp, '\n');
> + cp = strchr(cp + 1, '\n');
> } while (cp);
> if (buf[x - 1] == '\n')
> buf[x - 1] = '\0';
> Index: lib/libfetch/fetch.c
> ===
> --- lib/libfetch/fetch.c (revision 252372)
> +++ lib/libfetch/fetch.c (working copy)
> @@ -376,7 +376,7 @@
> /* password */
> if (*q == ':')
> - q = fetch_pctdecode(u->pwd, ++q, URL_PWDLEN);
> + q = fetch_pctdecode(u->pwd, q + 1, URL_PWDLEN);
> p++;
> } else {
> Index: lib/libutil/login_times.c
> ===
> --- lib/libutil/login_times.c (revision 252372)
> +++ lib/libutil/login_times.c (working copy)
> @@ -96,7 +96,7 @@
> else
> m.lt_start = 0;
> if (*p == '-')
> - p = parse_time(++p, &m.lt_end);
> + p = parse_time(p + 1, &m.lt_end);
> else
> m.lt_end = 1440;
> Index: usr.sbin/newsyslog/newsyslog.c
> ===
> --- usr.sbin/newsyslog/newsyslog.c(revision 252372)
> +++ usr.sbin/newsyslog/newsyslog.c(working copy)
> @@ -1083,7 +1083,7 @@
>* at any time, etc).
>*/
> if (strcasecmp(DEBUG_MARKER, q) == 0) {
> - q = parse = missing_field(sob(++parse), errline);
> + q = parse = missing_field(sob(parse + 1), errline);
> parse = son(parse);
> if (!*parse)
> warnx("debug line specifies no option:\n%s",
> @@ -1096,7 +1096,7 @@
> } else if (strcasecmp(INCLUDE_MARKER, q) == 0) {
> if (verbose)
> printf("Found: %s", errline);
> - q = parse = missing_field(sob(++parse), errline);
> + q = parse = missing_field(sob(parse + 1), errline);
> parse = son(parse);
> if (!*parse) {
> warnx("include line missing argument:\n%s",
> @@ -1138,7 +1138,7 @@
> defconf_p = working;
> }
> - q = parse = missing_field(sob(++parse), errline);
> + q = parse = missing_field(sob(parse + 1), errline);
> parse = son(parse);
> if (!*parse)
> errx(1, "malformed line (missing fields):\n%s",
> @@ -1172,7 +1172,7 @@
> } else
> working->gid = (gid_t)-1;
> - q = parse = missing_field(sob(++parse), errline);
> + q = parse = missing_field(sob(parse + 1), errline);
> parse = son(parse);
> if (!*parse)
> errx(1, "malformed line (missing fields):\n%s",
> @@ -1187,7 +1187,7 @@
> errx(1, "error in config file; bad permissions:\n%s",
> errline);
> - q = parse = missing_field(sob(++parse), errline);
> + q = parse = missing_field(sob(parse + 1), errline);
> parse = son(parse);
> if (!*parse)
> errx(1, "malformed line (missing fields):\n%s",
> @@ -1197,7 +1197,7 @@
> errx(1, "error in config file; bad value for count of
> logs to save:\n%s",
> errline);
> - q = parse = missing_field(sob(++parse), errline);
> + q = parse = missing_field(sob(parse + 1), errline);
>
Re: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
This was an obvious error by me - I forgot to register zfs_ioc_jail and
zfs_ioc_unjail using the new functions.
Amazing noone noticed this by now until it got merged down to stable/8.
In addition, I see no need to log these operations to the zpool history
as they cause no on-disk changes, so I have disabled logging for these
calls.
Please test the patch from current in r252380.
http://svnweb.freebsd.org/base?view=revision&revision=252380
On 29.6.2013 17:00, Alexander Leidinger wrote:
> On Sat, 29 Jun 2013 14:02:35 +0200
> Martin Matuska wrote:
>
>> some input would be great (at least the panic message - ideally from a
>> debug kernel).
> The bt in the minidump is useless, but I made a bt directly
> in the kernel debugger:
> ---snip---
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address = 0x0
> fault code = supervisor read instruction, page not present
> instruction pointer = 0x20:0x0
> stack pointer = 0x28:0xff839e79d930
> frame pointer = 0x28:0xff839e79d9e0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 2183 (zfs)
>
> db> bt
> Tracing pid 2356
> uart_sab82532_class() at 0
> devfs_ioctl_f() at devfs_ioctl_f+0xf0
> kern_ioctl() at kern_ioctl+0x1d7
> sys_ioctl() at sys_ioctl+0x142
> ---snip---
>
> The test case is easy, create a dataset for a jail, add something like
> this to /etc/devfs.rules:
> ---snip---
> [devfsrules_unhide_zfs=12]
> add path zfs unhide
>
> [devfsrules_jail_withzfs=17]
> add include $devfsrules_hide_all
> add include $devfsrules_unhide_basic
> add include $devfsrules_unhide_login
> add include $devfsrules_unhide_zfs
> ---snip---
>
> Attach the dataset to the jail and see the box panicing on the use of
> the zfs command in the jail (maybe you don't even need to attach the
> dataset to the jail, maybe just the above devfs stuff is enough).
>
> The default jail scripts don't attach a ZFS dataset to a jail, the
> corresponding ezjail-script code is
>
> # Attach ZFS-datasets to the jail
> for zfs in ${ezjail_zfs_datasets}; do
> /sbin/zfs jail ${ezjail_id} ${zfs} || echo -n "Error: ${zfs} could
> not be configured"
> done
>
> Bye,
> Alexander.
>
--
Martin Matuska
FreeBSD committer
http://blog.vx.sk
___
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: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
On Sat, 29 Jun 2013 18:49:16 +0200 Martin Matuska wrote: > Please test the patch from current in r252380. Buildworld+kernel in progress, expect feedback soon. FYI: you misspelled my FreeBSD address in the commit. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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"
panic: Unrecoverable machine check exception
I'm trying to get my server to a stable build of current so I can run a current poudriere jail alongside my 9.1 and 8.4 environments for testing package building. This server runs several other jails that host all the other services on my server. Coredump, etc can be found here: http://feld.me/freebsd/r251046/ Any suggestions on how to work around this so I can stabilize my build server would be appreciated. ___ 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"
usb sound module loading
Hi, I have sound modules commented out in kernel config : # Sound support #device sound # Generic sound driver (required) #device snd_cmi # CMedia CMI8338/CMI8738 #device snd_csa # Crystal Semiconductor CS461x/428x #device snd_emu10kx # Creative SoundBlaster Live! and Audigy #device snd_es137x # Ensoniq AudioPCI ES137x #device snd_hda # Intel High Definition Audio #device snd_ich # Intel, NVidia and other ICH AC'97 Audio #device snd_via8233 # VIA VT8233x Audio #device snd_uaudio # USB Audio However, if i plug in a USB mic the following kernel modules are loaded automatically: 81 0x81e44000 f344 snd_uaudio.ko 92 0x81e54000 3dfdfsound.ko I do not seem to have any sound related options active in /boot/loader.conf or /etc/rc.conf This causes a problem when using ossv4.2 in ports, actually when a USB mic is plugged in ... (when using the oss v4.2 drivers, and you have them loaded into the kernel, ie 143 0x82086000 7b581osscore.ko 151 0x81e44000 4360 oss_cmpci.ko 161 0x81e49000 214a0oss_hdaudio.ko ) ... the machine instantly reboots. It would be good to either prevent sound.ko from loading, or have the machine use the oss4.2 driver instead. Any hints or suggestions appreciated. Thanks, -- Waitman Gobble San Jose California USA +1.5108307875 ___ 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: usb sound module loading
On Sat, Jun 29, 2013 at 12:03:20PM -0700, Waitman Gobble wrote: > > Hi, > > > I have sound modules commented out in kernel config : > # Sound support > #device sound # Generic sound driver (required) > #device snd_cmi # CMedia CMI8338/CMI8738 > #device snd_csa # Crystal Semiconductor CS461x/428x > #device snd_emu10kx # Creative SoundBlaster Live! and Audigy > #device snd_es137x # Ensoniq AudioPCI ES137x > #device snd_hda # Intel High Definition Audio > #device snd_ich # Intel, NVidia and other ICH AC'97 Audio > #device snd_via8233 # VIA VT8233x Audio > #device snd_uaudio # USB Audio > > However, if i plug in a USB mic the following kernel modules are loaded > automatically: > > 81 0x81e44000 f344 snd_uaudio.ko > 92 0x81e54000 3dfdfsound.ko > > I do not seem to have any sound related options active in /boot/loader.conf or > /etc/rc.conf > > This causes a problem when using ossv4.2 in ports, actually when a USB mic is > plugged in ... > (when using the oss v4.2 drivers, and you have them loaded into the kernel, > ie > 143 0x82086000 7b581osscore.ko > 151 0x81e44000 4360 oss_cmpci.ko > 161 0x81e49000 214a0oss_hdaudio.ko > ) > ... the machine instantly reboots. It would be good to either prevent sound.ko > from loading, or have the machine use the oss4.2 driver instead. > > Any hints or suggestions appreciated. > > Thanks, Check /etc/devd/usb.conf You don't mention which release you are using, but I suspect the USB config file for devd is autoloading the snd_uaudio module for you. Regards, Gary ___ 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: usb sound module loading
On Sat, 29 Jun 2013 15:20:13 -0400, Gary Palmer wrote: >Check /etc/devd/usb.conf > >You don't mention which release you are using, but I suspect the USB >config file for devd is autoloading the snd_uaudio module for you. > >Regards, > >Gary > Thanks Gary. BTW I'm running FreeBSD 10.0-CURRENT #0 r252355 That /etc/devd/usb.conf file is the ticket! -- Waitman Gobble San Jose California USA +1.5108307875 ___ 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: compilation error regarding __cxa_call_terminate()
On Jun 29, 2013, at 16:14, d...@gmx.com wrote: > Using Clang head: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:44:1: > error: > conflicting types for '__cxa_call_terminate' > __cxa_call_terminate(_Unwind_Exception* ue_header_) > ^ > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:136:17: > note: > previous declaration is here > extern "C" void __cxa_call_terminate (void*) __attribute__((noreturn)); >^ Thanks, this should be fixed with r252387. ___ 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: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
On 2013-06-29 18:49:16 (+0200), Martin Matuska wrote: > This was an obvious error by me - I forgot to register zfs_ioc_jail and > zfs_ioc_unjail using the new functions. > Amazing noone noticed this by now until it got merged down to stable/8. > > In addition, I see no need to log these operations to the zpool history > as they cause no on-disk changes, so I have disabled logging for these > calls. > Please test the patch from current in r252380. > > http://svnweb.freebsd.org/base?view=revision&revision=252380 > This fixes the panic for me (on stable/9). Thanks, Kristof ___ 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: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
On Sat, 29 Jun 2013 23:05:20 +0200 Kristof Provost wrote: > On 2013-06-29 18:49:16 (+0200), Martin Matuska wrote: > > This was an obvious error by me - I forgot to register zfs_ioc_jail > > and zfs_ioc_unjail using the new functions. > > Amazing noone noticed this by now until it got merged down to > > stable/8. > > > > In addition, I see no need to log these operations to the zpool > > history as they cause no on-disk changes, so I have disabled > > logging for these calls. > > Please test the patch from current in r252380. > > > > http://svnweb.freebsd.org/base?view=revision&revision=252380 > > > This fixes the panic for me (on stable/9). I confirm for -current. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: NFSv4 console messages (locks lost etc.)
Lars Eggert wrote: > Hi, > > I should have mentioned that the server is FreeBSD -STABLE running > newnfs, and the network isn't partitioned (because I access the box > over SSH at the same time I see these messages.) > > They only appear under heavy NFS load (portmaster build of math/R in > this case.) > All I can think of that the server gets overloaded to the point where it doesn't process Renews within a reasonable timeframe. One thing you could try is the drc4 patch which wollman@ has had pretty good luck with for reducing CPU overhead and mutex contention in the server. The patch can be found at: http://people.freebsd.org/~rmacklem/drc4.patch Someday I'll get together with ivoras@ and come up with a version of this for head, rick > Lars > > On Jun 29, 2013, at 2:32, Rick Macklem wrote: > > > Lars Eggert wrote: > >> Hi, > >> > >> on a -CURRENT client, I get quite a number of console messages > >> under > >> heavy NFSv4 load, such as: > >> > >> nfsv4 expired locks lost > > Means the lease expired on the NFSv4 server somehow. Lease > > expiry is "bad news" and there is no way to recover locks > > lost because of it. > >> nfscl: never fnd open > > Usually, opens can be recovered after a lease expiry, but it > > might be broken. Since lease expiry should never happen during > > normal operation (see below), it doesn't get a lot of testing. > > > >> nfscl: never fnd open > >> nfscl: never fnd open > >> nfsv4 expired locks lost > >> nfscl: never fnd open > >> nfscl: never fnd open > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfscl: never fnd open > >> > >> Can I ignore them? Can I turn them off? > >> > > Well, these should never happen during normal, correct operation. > > The > > "nfsv4 expired locks lost" implies lease expiry. This should only > > happen > > when the client is network partitioned from the server for more > > than > > a lease duration (chosen by the server, but typically about > > 1minute). > > The client does a Renew Op every 1/2 lease durations to avoid this. > > Also, > > any state related operation (open/lock/locku/close/etc) is supposed > > to > > renew the lease implicitly. > > > > If you are getting network partitions happening, then you really > > need > > to fix the network. > > > > If not, then if you watch network traffic with something like > > wireshark > > and see Renew Ops happening at regular intervals, then I can only > > suggest > > that the server is somehow broken for NFSv4. You should also look > > for > > NFS4ERR_EXPIRED error replies to operations related to state > > (open/lock/locku/close). > > That is the server reply which indicates the lease expiry. If the > > server is > > never returning this, I have no idea how the client would generate > > the above > > messages, but it does indicate a client NFSv4 bug if that is the > > case. > > > > Switching all mounts to NFSv3 will get rid of the above, although > > it is > > not exactly a fix;-) > > > > rick > > > >> Thanks, > >> Lars > >> ___ > >> 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" > >> > > ___ > 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" > ___ 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: NFSv4 console messages (locks lost etc.)
Lars Eggert wrote: > Hi, > > I should have mentioned that the server is FreeBSD -STABLE running > newnfs, and the network isn't partitioned (because I access the box > over SSH at the same time I see these messages.) > > They only appear under heavy NFS load (portmaster build of math/R in > this case.) > Oh, one more thing. If the server hits NFSRV_V4STATELIMIT for a total count of opens and locks (defined in sys/fs/nfs/nfsport.h) it will stop doing opens and pretty well come to a grinding halt. The default of 50 seems pretty generous, but since it was chosen to avoid resource exhaustion on a single core PIII with 256Mbytes of RAM, increasing it is probably safe for more modern server hardware. (You'll need to edit sys/fs/nfs/nfsport.h and rebuild a kernel. It isn't a sysctl.) rick > Lars > > On Jun 29, 2013, at 2:32, Rick Macklem wrote: > > > Lars Eggert wrote: > >> Hi, > >> > >> on a -CURRENT client, I get quite a number of console messages > >> under > >> heavy NFSv4 load, such as: > >> > >> nfsv4 expired locks lost > > Means the lease expired on the NFSv4 server somehow. Lease > > expiry is "bad news" and there is no way to recover locks > > lost because of it. > >> nfscl: never fnd open > > Usually, opens can be recovered after a lease expiry, but it > > might be broken. Since lease expiry should never happen during > > normal operation (see below), it doesn't get a lot of testing. > > > >> nfscl: never fnd open > >> nfscl: never fnd open > >> nfsv4 expired locks lost > >> nfscl: never fnd open > >> nfscl: never fnd open > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfsv4 expired locks lost > >> nfscl: never fnd open > >> > >> Can I ignore them? Can I turn them off? > >> > > Well, these should never happen during normal, correct operation. > > The > > "nfsv4 expired locks lost" implies lease expiry. This should only > > happen > > when the client is network partitioned from the server for more > > than > > a lease duration (chosen by the server, but typically about > > 1minute). > > The client does a Renew Op every 1/2 lease durations to avoid this. > > Also, > > any state related operation (open/lock/locku/close/etc) is supposed > > to > > renew the lease implicitly. > > > > If you are getting network partitions happening, then you really > > need > > to fix the network. > > > > If not, then if you watch network traffic with something like > > wireshark > > and see Renew Ops happening at regular intervals, then I can only > > suggest > > that the server is somehow broken for NFSv4. You should also look > > for > > NFS4ERR_EXPIRED error replies to operations related to state > > (open/lock/locku/close). > > That is the server reply which indicates the lease expiry. If the > > server is > > never returning this, I have no idea how the client would generate > > the above > > messages, but it does indicate a client NFSv4 bug if that is the > > case. > > > > Switching all mounts to NFSv3 will get rid of the above, although > > it is > > not exactly a fix;-) > > > > rick > > > >> Thanks, > >> Lars > >> ___ > >> 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" > >> > > ___ > 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" > ___ 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"
VFCF_JAIL
Hi! Why needed the VFCF_JAIL flag in this commit? And why not reflected this change in the commit message? https://github.com/freebsd/freebsd/commit/b08615c213db4d34132dea8c42770d1635e903fc PS.: the svnweb.freebsd.org is out of sync.. ___ 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: VFCF_JAIL
Sorry for the noise, I found this revert: https://github.com/freebsd/freebsd/commit/51861f0c71f2b3945937dbef2e27efaf6e19fe92 On 6/30/13, Oliver Pinter wrote: > Hi! > > Why needed the VFCF_JAIL flag in this commit? And why not reflected > this change in the commit message? > > https://github.com/freebsd/freebsd/commit/b08615c213db4d34132dea8c42770d1635e903fc > > PS.: > the svnweb.freebsd.org is out of sync.. > ___ 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"
