Mellanox Technologies : ConnectX-3 VPI
I am wondering if FreeBSD 10-CURRNET could use Mellanox Technologies's ConnectX-3 VPI infiniband devices. Is there anyone who are using ConnectX-3 VPI with FreeBSD? -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: What is "Fast task queue"? (Was: How to understand what `swi5' kernel thread does?)
Hello, John. You wrote 27 августа 2012 г., 20:26:03: >> What "fast tasks" are performed via this queue? Under network load it >> is main consumer of CPU. JB> Certain NIC drivers perform much of their interrupt handling in that thread. Yep, I've found, that my if_vr uses it. One more question: does ipfw rules works in same thread? I have ``net.isr.dispatch="direct"'' set. -- // Black Lion AKA Lev Serebryakov ___ 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 on use of "deleted" route.
Hi I was wondering if anyone else is seeing this... I get a panic shortly after ppp(8) exits. I haven't been able to get a crashdump from a recent -CURRENT system, so in that absence, I'll include output from an older system. Interestingly, the route partially persists past the destruction of the interface. And the panic is triggered apparently by the use of the route. I've also been unable to delete routes added on the system. We're running a kernel compiled with options RADIX_MPATH. [root@pbx ~]# pppctl -p pass 3000 quit all Connection closed [root@pbx ~]# ifconfig tun0 ifconfig: interface tun0 does not exist [root@pbx ~]# netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire defaulttun0 US 04 Here's the crash from another system: KDB: stack backtrace: #0 0x8051ed16 at kdb_backtrace+0x66 #1 0x804e828e at panic+0x1ce #2 0x806dcff0 at trap_fatal+0x290 #3 0x806dd327 at trap_pfault+0x1e7 #4 0x806dd92e at trap+0x3be #5 0x806c792f at calltrap+0x8 #6 0x805a975c at rn_walktree+0x7c #7 0x805b085e at sysctl_rtsock+0x2ee #8 0x804f1bd8 at sysctl_root+0x128 #9 0x804f1eb5 at userland_sysctl+0x145 #10 0x804f23ea at sys___sysctl+0xaa #11 0x806dc910 at amd64_syscall+0x530 #12 0x806c7c17 at Xfast_syscall+0xf7 Uptime: 2d12h15m1s #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:229 #1 0x804e7d74 in kern_reboot (howto=260) at /usr/src.pflock/sys/kern/kern_shutdown.c:449 #2 0x804e8267 in panic (fmt=0x1 ) at /usr/src.pflock/sys/kern/kern_shutdown.c:637 #3 0x806dcff0 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src.pflock/sys/amd64/amd64/trap.c:853 #4 0x806dd327 in trap_pfault (frame=0xff82355bf6b0, usermode=0) at /usr/src.pflock/sys/amd64/amd64/trap.c:770 #5 0x806dd92e in trap (frame=0xff82355bf6b0) at /usr/src.pflock/sys/amd64/amd64/trap.c:458 #6 0x806c792f in calltrap () at /usr/src.pflock/sys/amd64/amd64/exception.S:228 #7 0x805ae525 in sysctl_dumpentry (rn=0xfe0007398e10, vw=Variable "vw" is not available. ) at /usr/src.pflock/sys/net/rtsock.c:1527 #8 0x805a975c in rn_walktree (h=Variable "h" is not available. ) at /usr/src.pflock/sys/net/radix.c:1112 #9 0x805b085e in sysctl_rtsock (oidp=Variable "oidp" is not available. ) at /usr/src.pflock/sys/net/rtsock.c:1888 #10 0x804f1bd8 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src.pflock/sys/kern/kern_sysctl.c:1513 #11 0x804f1eb5 in userland_sysctl (td=Variable "td" is not available. ) at /usr/src.pflock/sys/kern/kern_sysctl.c:1623 #12 0x804f23ea in sys___sysctl (td=0xfe0007189000, uap=0xff82355bfb70) at /usr/src.pflock/sys/kern/kern_sysctl.c:1549 #13 0x806dc910 in amd64_syscall (td=0xfe0007189000, traced=0) at subr_syscall.c:135 #14 0x806c7c17 in Xfast_syscall () at /usr/src.pflock/sys/amd64/amd64/exception.S:387 #15 0x000801debc6c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Ian Freislich ___ 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: What is "Fast task queue"? (Was: How to understand what `swi5' kernel thread does?)
On Monday, August 27, 2012 8:46:46 am Lev Serebryakov wrote: > Hello, Lev. > You wrote 27 августа 2012 г., 6:19:57: > > I've found (with help of debug printing added to kernel), that "swi5" > has only one handler "Fast task queue" (name is too long to be seen in > `top' output, may be, rename it to "fast tqueue"?) > > What "fast tasks" are performed via this queue? Under network load it > is main consumer of CPU. Certain NIC drivers perform much of their interrupt handling in that thread. -- 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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sunday, August 26, 2012 4:37:53 pm Doug Barton wrote: > The problem is that we don't really support the idea of things in the > base magically deleting themselves. > > As I have said in previous messages, the bootstrapping problem is being > overblown by several orders of magnitude. For newly installed systems > where pkg is the default, /usr/local/bin/pkg will be installed. So there > is no bootstrapping problem. > > For already-installed systems who wish to switch to pkg, they can > install from /usr/ports, or use the pkg bootstrap tool in the base. > Given that they will be intentionally making this change, and there will > be instructions written up on how to do this which include the > bootstrapping step, once again this is a non-issue. > > The whole idea of having every call to /usr/local/sbin/pkg pass through > /usr/sbin/pkg in order to help a tiny minority of users with a one-time > bootstrapping issue is just plain ludicrous. I agree. Even if we keep /usr/sbin/pkg, we will presumably want to remove it from the base in a year or so via 'make delete-old', etc. Given that, I'm not sure we need it there in the first place. -- 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: per file descriptor device callbacks ?
On Monday, August 27, 2012 3:55:47 am Andriy Gapon wrote: > on 27/08/2012 10:34 Luigi Rizzo said the following: > > This requires to track calls to open/ioctl/poll/mmap/close. > > The difficulty i have is with mmap() and close(), because FreeBSD > > seems to handle these calls per-cdev rather than per-file-descriptor > > (for instance, no 'struct file' argument is available in mmap(), and > > the d_close method is only called on the last close() on the device). > > devfs_set_cdevpriv(9), etc mmap() is still problematic, but if you have the freedom to create your own VM objects, then d_mmap_single() can let you handle that fairly easily. -- 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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory
On Mon, Aug 27, 2012 at 05:28:09PM +0200, Bernhard Fr?hlich wrote:
> On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov
> wrote:
> > On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote:
> >> On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle wrote:
> >> >
> >> > On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:
> >> >
> >> >> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle wrote:
> >> >>>
> >> >>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
> >> >>>
> >> Hi,
> >>
> >> I have a wrapper script that builds packages in a chroot environment
> >> which happily runs on release 6 thru 9 and earlier 10 but fails with:
> >>
> >> tar: getvfsbyname failed: No such file or directory
> >>
> >> on a recent -CURRENT.
> >> >>>
> >> >>> libarchive does do an initial getvfsbyname() when you ask it
> >> >>> to traverse a directory tree so that it can accurately handle later
> >> >>> requests about mountpoints and filesystem types. This code
> >> >>> is admittedly a little intricate.
> >> >>
> >> >>The problem most likely is the fact that all mountpoints are
> >> >> exposed via chroot, thus, if it's checking to see if a mountpoint
> >> >> exists, it may exist outside of the chroot.
> >> >>
> >> >
> >> > I reviewed the code to refresh my memory. Some
> >> > of what I said before was not quite right.
> >> >
> >> > Libarchive's directory traversal tracks information about
> >> > the filesystem type so that clients such as bsdtar can
> >> > efficiently skip synthetic filesystems (/dev or /proc) or
> >> > network filesystems (NFS or SMB mounts).
> >> >
> >> > The net effect is something like this:
> >> >
> >> >For each file:
> >> >stat() or lstat() or fstat() the file
> >> >look up dev number in an internal cache
> >> >if the dev number is new:
> >> > fstatfs() the open fd to get the FS name
> >> > getvfsbyname() to identify the FS type
> >> >
> >> > Unless there's a logic error in libarchive itself, this
> >> > would suggest that somehow fstatfs() is returning
> >> > a filesystem type that getvfsbyname() can't
> >> > identify.
> >> >
> >> > Paul:
> >> > What filesystem are you using?
> >> >
> >> > What does "mount" show?
> >> >
> >> > Does it work outside the chroot?
> >>
> >> I also see the same on the redports.org build machines.
> >> It builds within a jail there which is completely on a tmpfs.
> >> Interestinly everything is fine with a 10-CURRENT/amd64
> >> jail but it breaks in a 10-CURRENT/i386 jail. Both are
> >> running on the same 10-CURRENT/amd64 which is
> >> around 2 months old.
> >>
> >> https://redports.org/buildarchive/20120814130205-56327/
> >
> > Try this.
>
> I've seen that it was committed to head in the meantime so
> I gave that a try. The problem still persists.
>
> https://redports.org/~decke/20120827152217-19891-54992/expat-2.0.1_2.log
Are you sure that you tested the right kernel ?
You may use the following test program to verify. Compile it on 32bit
system. Run it like this:
./getvfsbyname devfs ufs nfs
On patched kernel, I get
sandy% ./getvfsbyname devfs ufs nfs ~
name devfs typenum 113 ref 2 flags 0x48
name ufs typenum 53 ref 1 flags 0x0
name nfs typenum 58 ref 4 flags 0x2
On unpatched machine, the result is
ooma32% ./getvfsbyname devfs ufs nfs ~/build/bsd/DEV/stuff/tests
getvfsbyname: getvfsbyname("devfs"): No such file or directory
getvfsbyname: getvfsbyname("ufs"): No such file or directory
getvfsbyname: getvfsbyname("nfs"): No such file or directory
pgpXfeXGh0K5M.pgp
Description: PGP signature
Re: make package fails in chroot: tar: getvfsbyname failed: No such file or directory
On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov wrote: > On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote: >> On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle wrote: >> > >> > On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote: >> > >> >> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle wrote: >> >>> >> >>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote: >> >>> >> Hi, >> >> I have a wrapper script that builds packages in a chroot environment >> which happily runs on release 6 thru 9 and earlier 10 but fails with: >> >> tar: getvfsbyname failed: No such file or directory >> >> on a recent -CURRENT. >> >>> >> >>> libarchive does do an initial getvfsbyname() when you ask it >> >>> to traverse a directory tree so that it can accurately handle later >> >>> requests about mountpoints and filesystem types. This code >> >>> is admittedly a little intricate. >> >> >> >>The problem most likely is the fact that all mountpoints are >> >> exposed via chroot, thus, if it's checking to see if a mountpoint >> >> exists, it may exist outside of the chroot. >> >> >> > >> > I reviewed the code to refresh my memory. Some >> > of what I said before was not quite right. >> > >> > Libarchive's directory traversal tracks information about >> > the filesystem type so that clients such as bsdtar can >> > efficiently skip synthetic filesystems (/dev or /proc) or >> > network filesystems (NFS or SMB mounts). >> > >> > The net effect is something like this: >> > >> >For each file: >> >stat() or lstat() or fstat() the file >> >look up dev number in an internal cache >> >if the dev number is new: >> > fstatfs() the open fd to get the FS name >> > getvfsbyname() to identify the FS type >> > >> > Unless there's a logic error in libarchive itself, this >> > would suggest that somehow fstatfs() is returning >> > a filesystem type that getvfsbyname() can't >> > identify. >> > >> > Paul: >> > What filesystem are you using? >> > >> > What does "mount" show? >> > >> > Does it work outside the chroot? >> >> I also see the same on the redports.org build machines. >> It builds within a jail there which is completely on a tmpfs. >> Interestinly everything is fine with a 10-CURRENT/amd64 >> jail but it breaks in a 10-CURRENT/i386 jail. Both are >> running on the same 10-CURRENT/amd64 which is >> around 2 months old. >> >> https://redports.org/buildarchive/20120814130205-56327/ > > Try this. I've seen that it was committed to head in the meantime so I gave that a try. The problem still persists. https://redports.org/~decke/20120827152217-19891-54992/expat-2.0.1_2.log -- Bernhard Froehlich 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"
What is "Fast task queue"? (Was: How to understand what `swi5' kernel thread does?)
Hello, Lev. You wrote 27 августа 2012 г., 6:19:57: I've found (with help of debug printing added to kernel), that "swi5" has only one handler "Fast task queue" (name is too long to be seen in `top' output, may be, rename it to "fast tqueue"?) What "fast tasks" are performed via this queue? Under network load it is main consumer of CPU. -- // Black Lion AKA Lev Serebryakov ___ 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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
2012/8/26 Baptiste Daroussin : > I received more feedback about keep pkg and changing it to > pkg-bootstrap, so what should I do, changing it because you are asking for it? So, just a "me too" for renaming pkg, for consistency. I don't mind the new name... -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ 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: less aggressive contigmalloc ?
On Mon, Aug 27, 2012 at 02:42:28AM -0500, Alan Cox wrote: ... > >this is dmesg when I add kdb_backtrace() at the start of vm_pageout_oom() > >The '... netmap_finalize_obj_allocator... are from my calls to > >contigmalloc, each one doing one-page allocations. > > These calls are made with M_WAITOK? no they are with M_NOWAIT: ... clust = contigmalloc(p->_clustsize, M_NETMAP, M_NOWAIT | M_ZERO, 0, -1UL, PAGE_SIZE, 0); ... p->_clustsize is 4096 in this particular set of calls. > >I get 7-8 'KDB: stack backtrace' blocks, then allocations > >restart successfully, then more failures... > >The reference to fork_exit() does not seem right, because i am > >in a block where i call contigmalloc, so the caller of > >vm_pageout_grow_cache() should be kmem_alloc_contig(). > > Try this instead. At the start of vm_pageout_oom(), print the value of > its parameter "shortage". That will uniquely identify the caller. it says "shortage is 1" which means that the call is from vm_pageout(). 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: Time to bump default VM_SWZONE_SIZE_MAX?
Dag-Erling Smørgrav writes: > (or we could increase the limit to 72351744 bytes, which is the precise > amount required to support 16 GB) Correction, 36175872 - there are actually 32 pages per entry, not 16. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: per file descriptor device callbacks ?
on 27/08/2012 10:34 Luigi Rizzo said the following: > This requires to track calls to open/ioctl/poll/mmap/close. > The difficulty i have is with mmap() and close(), because FreeBSD > seems to handle these calls per-cdev rather than per-file-descriptor > (for instance, no 'struct file' argument is available in mmap(), and > the d_close method is only called on the last close() on the device). devfs_set_cdevpriv(9), etc -- Andriy Gapon ___ 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: less aggressive contigmalloc ?
On 08/26/2012 12:11, Luigi Rizzo wrote: On Fri, Aug 24, 2012 at 11:56:06AM -0500, Alan Cox wrote: On 08/24/2012 11:54, Luigi Rizzo wrote: On Fri, Aug 24, 2012 at 11:12:51AM -0500, Alan Cox wrote: On 08/24/2012 09:57, Luigi Rizzo wrote: On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote: On 08/23/2012 12:45, Luigi Rizzo wrote: On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote: ... yes i do see that. Maybe less aggressive with M_NOWAIT but still kills processes. Are you compiling world with MALLOC_PRODUCTION? The latest version of whatever the default is. But: jemalloc uses significantly more memory when debugging options are enabled. This first came up in a thread titled "10-CURRENT and swap usage" back in June. Even at its most aggressive, M_WAITOK, contigmalloc() does not directly kill processes. If process death coincides with the use of contigmalloc(), then it is simply the result of earlier, successful contigmalloc() calls, or for that matter any other physical memory allocation calls, having depleted the pool of free pages to the point that the page daemon runs and invokes vm_pageout_oom(). does it mean that those previous allocations relied on memory overbooking ? Yes. Is there a way to avoid that, then ? I believe that malloc()'s default minimum allocation size is 4MB. You could reduce that. Alternatively, you can enable MALLOC_PRODUCTION. i tried this, and as others mentioned it makes life better and reduces the problem but contigmalloc still triggers random process kills. I would be curious to see a stack backtrace when vm_pageout_oom() is called. you mean a backtrace of the process(es) that get killed ? No, a backtrace showing who called vm_pageout_oom(). Simply add a kdb_backtrace() call at the start of vm_pageout_oom(). There are two possibilities. I want to know which it is. this is dmesg when I add kdb_backtrace() at the start of vm_pageout_oom() The '... netmap_finalize_obj_allocator... are from my calls to contigmalloc, each one doing one-page allocations. These calls are made with M_WAITOK? I get 7-8 'KDB: stack backtrace' blocks, then allocations restart successfully, then more failures... The reference to fork_exit() does not seem right, because i am in a block where i call contigmalloc, so the caller of vm_pageout_grow_cache() should be kmem_alloc_contig(). Try this instead. At the start of vm_pageout_oom(), print the value of its parameter "shortage". That will uniquely identify the caller. 630.004926 netmap_finalize_obj_allocator [593] cluster at 8910 ok 630.005563 netmap_finalize_obj_allocator [593] cluster at 8912 ok 630.006077 netmap_finalize_obj_allocator [593] cluster at 8914 ok KDB: stack backtrace: X_db_sym_numargs() at X_db_sym_numargs+0x1aa vm_pageout_oom() at vm_pageout_oom+0x19 vm_pageout_grow_cache() at vm_pageout_grow_cache+0xd01 fork_exit() at fork_exit+0x11c fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8005f12cb0, rbp = 0 --- KDB: stack backtrace: X_db_sym_numargs() at X_db_sym_numargs+0x1aa vm_pageout_oom() at vm_pageout_oom+0x19 vm_pageout_grow_cache() at vm_pageout_grow_cache+0xd01 fork_exit() at fork_exit+0x11c fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8005f12cb0, rbp = 0 --- ... Some of the processes must be 'getty' because i also find this line in dmesg: <118>Aug 26 16:47:11 init: getty repeating too quickly on port /dev/ttyv7, sleep ing 30 secs 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"
per file descriptor device callbacks ?
Hi, in netmap, i am using a single name (/dev/netmap) to create multiple independent file descriptors bound to different devices/queues, and eventually I would like to mmap() each file descriptor to a different kernel memory region. This requires to track calls to open/ioctl/poll/mmap/close. The difficulty i have is with mmap() and close(), because FreeBSD seems to handle these calls per-cdev rather than per-file-descriptor (for instance, no 'struct file' argument is available in mmap(), and the d_close method is only called on the last close() on the device). I definitely remember having a similar problem ~15 years ago when I was doing audio drivers. I do not remember a workaround at the time, though now the situation might be slightly different because /dev/audio does some kind of multiplexing, and probably even /dev/ptmx does something similar. So I would appreciate suggestions on how can I track per-file-descriptor calls to mmap and close (or at least achieve my goal to track which individual file descriptors are used for mmap, and when the descriptor is closed so the region is unmapped). >From what I can tell: + open(), ioctl() and poll() are easy because the 'struct file *' argument is available through one of the 'struct thread' fields, td->td_fpop; + mmap() is slightly trickier: if i use the d_mmap method (which is what I have now, used by the device pager), the kernel does a first pass on the mmap() syscall where td->td_fpop is available, but the mapping is not installed and only access rights are checked. Subsequently i get some anonymous calls where the only argument i have is a 'struct cdev *' and the td->td_fpop is explicitly set to NULL. I am not sure if i can use a workaround for this by writing my own d_mmap_single callback that also installs the mappings so that i never fault on those pages. + close(), here i have no clue. sys/fs/devfs/devfs_vnops.c::devfs_close() seems to intercept all but the last call, and i do not see any way to intercept it. thanks 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"
