Re: Question about cvsup...
On Sun, Nov 18, 2007 at 04:56:08PM -0800, Darren Reed wrote: > Nearly every time I run cvsup from the command line (as root), > I see large amounts of output like this for every file: > > SetAttrs src/contrib/amd/fsinfo/wr_fstab.c,v > > Is cvsup actually doing anything? > Have I done something wrong in my config? > (I run in with "cvsup -l lockfile -g -L 1 ncvs-supfile") Maybe there is a umask difference between your interactive env and your cron env. I use this line in my cvsup config file to make sure the file permissions are the way I want them: *default umask=002 John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem compiling RELENG_6
On Sun, Nov 18, 2007 at 04:48:40PM -0800, Darren Reed wrote: > My apologies > > I forgot to do a "cvs commit" of sbin/ipf in addition to contrib/ipfilter > and sys/contrib/ipfilter. I've just done a commit that should fix this. >... It did: g1-18(6.3-P)[1] uname -a FreeBSD g1-18.catwhisker.org. 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #538: Sun Nov 18 18:57:23 PST 2007 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/CANARY i386 g1-18(6.3-P)[2] Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Proprietary data formats obfuscate, rather than disseminate, information. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgppGNPxBIthJ.pgp Description: PGP signature
Question about cvsup...
Nearly every time I run cvsup from the command line (as root), I see large amounts of output like this for every file: SetAttrs src/contrib/amd/fsinfo/wr_fstab.c,v Is cvsup actually doing anything? Have I done something wrong in my config? (I run in with "cvsup -l lockfile -g -L 1 ncvs-supfile") Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get filename of an open file descriptor
Robert Watson wrote: > On Sun, 18 Nov 2007, Skip Ford wrote: >> >>As for the procstat(1) code itself, I've found one bug and have two >>sugestions: >> >>1) procstat_args() doesn't use a local variable and the buffer doesn't >>get cleared between calls: >> >>$ procstat -a 797 >> PID ARGS >> 797 audacious >>$ procstat -a 795 797 >> PID ARGS >> 795 xterm -xtsessionID 11c0a801030001185368263000768 >> 797 audacious essionID 11c0a801030001185368263000768 >>$ >> >>Other option's functions are not similarly affected. >> >>2) I think it should handle requests for information about pid 0 instead >>of requiring at least pid 1 as it currently does. Solaris suggests >>'/proc/*' to see all processes. If we use `ps axopid=` then it aborts on >>the swapper (pid 0) immediately. >> >>3) Similarly, I think all of the sysctl(3) calls within the individual >>option functions (procstat_bin(), procstat_args(), etc.) should just go >>ahead and print the header and pid, then print any sysctl(3) error in the >>PID's row instead of erroring out. We're either about to finish executing >>anyway if that was the only pid requested, or we're moving on to another >>pid that has nothing to do with the previous pid. There's not really any >>reason to stop processing further pids. This also affects attempting to >>list all pids since it currently stops processing pids as soon as one >>doesn't exist. A global error variable could just be incremented with >>every call and returned at process exit, that way it'd still be meaningful >>for single PIDs. > > Actually, I think I've fixed all of the above in p4 with some changes > yesterday; I'll do a new code drop for you to try: > > http://www.watson.org/~robert/freebsd/20071118-procstat.tgz Yes, I like it. We must be thinking alike, which is ultimately bad news for you, I'm afraid. The bug mentioned first above is still present, and the other bug I mentioned outside of this thread also is, AFAIK. Other than those, I like it. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem compiling RELENG_6
My apologies I forgot to do a "cvs commit" of sbin/ipf in addition to contrib/ipfilter and sys/contrib/ipfilter. I've just done a commit that should fix this. Cheers, Darren Jeremy Chadwick wrote: On Sun, Nov 18, 2007 at 01:03:28PM -0300, Daniel Molina Wegener wrote: > I've downloaded the RELENG_6 through csup. While compiling the > source with make buildworld I get the next error: > > -8<--8<--8<--8<--8<- > ===> sbin/ipf/libipf (depend) > make: don't know how to make extras.c. Stop > *** Error code 2 > -8<--8<--8<--8<--8<- > > Same problem with genmask.c, getline.c, hexdump.c and other > files. This probably should've gone to freebsd-stable instead. A recent commit from the IPFilter author may have induced this; I can't check for you because the webserver on www.freebsd.org (where cvsweb lives) is presently irritated in some way. Anyways, see Darren's mail below: >> From: Darren Reed <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> Date: Sun, 18 Nov 2007 03:06:09 -0800 >> Subject: RELENG_6 IPFilter MFC >> >> I've just completed an MFC of IPFIilter in the FreeBSD 6 branch (RELENG_6) >> from HEAD. This brings the code used for IPFilter in FreeBSD into sync >> on each of HEAD, RELENG_6 and RELENG_7. Hopefully I can close one or >> two bug reports now ;) >> >> If you encounter any problems, please let me know. >> >> Cheers, >> Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: double panic, and whats apic_cmd? (kqemu crash...)
On Sun, Nov 18, 2007 at 03:05:33AM +0100, Juergen Lock wrote:
> Ok I finally have an amd64 smp box here that i can play with, and tried
> to reproduce http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 - and I got
> the following crash:
>[...]
Ok, the crashes seem to be pretty random, I got a few more:
(btw I disabled -DSMP in the kqemu build since it doesn't seem to help,
and it doesn't seem to be used anywhere else. Also I forgot to say
I also have KDB_TRACE and KDB_UNATTENDED in the kernel config. Oh and
I had a few hangs too, and never could get into ddb in those cases...)
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x246
fault code = supervisor read instruction, page not present
instruction pointer = 0x8:0x246
stack pointer = 0x10:0x9fae4b50
frame pointer = 0x10:0x9fae4b80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle: cpu1)
trap number = 12
<0>
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xc011dbfb
fault code = supervisor read instruction, page not present
instruction pointer = 0x8:0xc011dbfb
stack pointer = 0x10:0x9fae47d0
frame pointer = 0x10:0x801de4000
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= trace trap, interrupt enabled, nested task, IOPL = 3
current process = 11 (idle: cpu1)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x17a
trap_fatal() at trap_fatal+0x29f
trap_pfault() at trap_pfault+0x294
trap() at trap+0x2ea
sendsig() at sendsig+0x2aa
sched_choose() at sched_choose+0x8c
choosethread() at choosethread+0x2b
sched_switch() at sched_switch+0x184
mi_switch() at mi_switch+0x189
ast() at ast+0x1e8
doreti_ast() at doreti_ast+0x1f
Uptime: 37m8s
Physical memory: 986 MB
Dumping 152 MB: 137 121 105 89 73 57 41 25 9
#0 doadump () at pcpu.h:194
194 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:194
#1 0x80484b18 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0x80484f77 in panic (fmt=Variable "fmt" is not available.
) at ../../../kern/kern_shutdown.c:563
#3 0x8070de6f in trap_fatal (frame=0xc, eva=Variable "eva" is not
available.
)
at ../../../amd64/amd64/trap.c:697
#4 0x8070e254 in trap_pfault (frame=0x9fae4720, usermode=0)
at ../../../amd64/amd64/trap.c:614
#5 0x8070ec0a in trap (frame=0x9fae4720)
at ../../../amd64/amd64/trap.c:383
#6 0x806fcd4a in sendsig (catcher=0x405460, ksi=Variable "ksi" is not
available.
)
at ../../../amd64/amd64/machdep.c:326
#7 0x804a16ec in sched_choose () at ../../../kern/sched_4bsd.c:1256
#8 0x804a174b in choosethread () at kern_switch.c:137
#9 0x804a2984 in sched_switch (td=0xff000209b680,
newtd=0xff00021a18c0, flags=13) at ../../../kern/sched_4bsd.c:907
#10 0x8048cc99 in mi_switch (flags=2, newtd=0x0)
at ../../../kern/kern_synch.c:442
#11 0x804b7068 in ast (framep=0x9fae4c70)
at ../../../kern/subr_trap.c:239
#12 0x806f4999 in doreti_ast () at ../../../amd64/amd64/exception.S:468
#13 0x000811d87d74 in ?? ()
#14 0x0005 in ?? ()
#15 0x10e0 in ?? ()
---Type to continue, or q to quit---
#16 0x000811d87d8c in ?? ()
#17 0x000801de4000 in ?? ()
#18 0x000741e0 in ?? ()
#19 0x0215dd30 in ?? ()
#20 0x00d49160 in ?? ()
#21 0xc016fdf0 in ?? ()
#22 0x in ?? ()
#23 0x000801de84d0 in ?? ()
#24 0xbfff in ?? ()
#25 0x00063fff in ?? ()
#26 0x000801de4000 in ?? ()
#27 0x00063fff in ?? ()
#28 0x0016 in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x0215dd0c in ?? ()
#33 0x002b in ?? ()
#34 0x0286 in ?? ()
#35 0x7fffb608 in ?? ()
#36 0x0023 in ??
Re: Multiple IP Jail's patch for FreeBSD 6.2
Andre Oppermann wrote: Ed Schouten wrote: Hello, It may be interesting to mention that yesterday there was a presentation at the NLUUG (Netherlands UNIX Users Group) conference by Marco Zec, who once wrote a patchset for FreeBSD 4.11 (and is in the process of porting it to FreeBSD 7.x) that gives each jail its own networking stack. You can hook up physical interfaces to jails or perform bridging between jails through netgraph bridging code. That way you can create virtual network topologies on a single box. This will allow you to use multiple IPv4 and IPv6 addresses on each instance. You can even use (I)PF(W) inside jails. I'm working on a "light" variant of multi-IPv[46] per jail. It doesn't create an entirely new network instance per jail and probably is more suitable for low- to mid-end (virtual) hosting. In those cases you normally want the host administrator to excercise full control over IP address and firewall configuration of the individual jails. For high-end stuff where you offer jail based virtual machines or network and routing simulations Marco's work is more appropriate. Any of this available in 7.x at the moment? I have a patched 6.2-STABLE running with 7 jails with multiple IP addresses. Would not be able to upgrade that box unless this becomes available or unless I port it to 7.x... Thanks! Jan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get filename of an open file descriptor
On Sun, 18 Nov 2007, Skip Ford wrote: Thomas Hurst wrote: * Skip Ford ([EMAIL PROTECTED]) wrote: It would be interesting to know for sure, though, if Solaris uses hardlinks and, if so, what their utility is called. Nope. They *do* use hardlinks in that they have 32bit wrappers in /usr/bin etc which dispatch to the relevent architecture, but the commands themselves are all seperate. Indeed, and each utility is quite complex as compared to what ours would be if split. I would just rename procstat(1) to pargs(1) then hardlink the others since ours are much less complex, but I'll take anything at this point. As for the procstat(1) code itself, I've found one bug and have two sugestions: 1) procstat_args() doesn't use a local variable and the buffer doesn't get cleared between calls: $ procstat -a 797 PID ARGS 797 audacious $ procstat -a 795 797 PID ARGS 795 xterm -xtsessionID 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ Other option's functions are not similarly affected. 2) I think it should handle requests for information about pid 0 instead of requiring at least pid 1 as it currently does. Solaris suggests '/proc/*' to see all processes. If we use `ps axopid=` then it aborts on the swapper (pid 0) immediately. 3) Similarly, I think all of the sysctl(3) calls within the individual option functions (procstat_bin(), procstat_args(), etc.) should just go ahead and print the header and pid, then print any sysctl(3) error in the PID's row instead of erroring out. We're either about to finish executing anyway if that was the only pid requested, or we're moving on to another pid that has nothing to do with the previous pid. There's not really any reason to stop processing further pids. This also affects attempting to list all pids since it currently stops processing pids as soon as one doesn't exist. A global error variable could just be incremented with every call and returned at process exit, that way it'd still be meaningful for single PIDs. Actually, I think I've fixed all of the above in p4 with some changes yesterday; I'll do a new code drop for you to try: http://www.watson.org/~robert/freebsd/20071118-procstat.tgz The kernel patch is identical, so you can just rebuild procstat. Since this is a per-process tool, I think it needs to complete "procstat -c `ps axopid=`" if at all possible. Yes, I agree. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get filename of an open file descriptor
Thomas Hurst wrote: > * Skip Ford ([EMAIL PROTECTED]) wrote: > > > It would be interesting to know for sure, though, if Solaris uses > > hardlinks and, if so, what their utility is called. > > Nope. They *do* use hardlinks in that they have 32bit wrappers in > /usr/bin etc which dispatch to the relevent architecture, but the > commands themselves are all seperate. Indeed, and each utility is quite complex as compared to what ours would be if split. I would just rename procstat(1) to pargs(1) then hardlink the others since ours are much less complex, but I'll take anything at this point. As for the procstat(1) code itself, I've found one bug and have two sugestions: 1) procstat_args() doesn't use a local variable and the buffer doesn't get cleared between calls: $ procstat -a 797 PID ARGS 797 audacious $ procstat -a 795 797 PID ARGS 795 xterm -xtsessionID 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ Other option's functions are not similarly affected. 2) I think it should handle requests for information about pid 0 instead of requiring at least pid 1 as it currently does. Solaris suggests '/proc/*' to see all processes. If we use `ps axopid=` then it aborts on the swapper (pid 0) immediately. 3) Similarly, I think all of the sysctl(3) calls within the individual option functions (procstat_bin(), procstat_args(), etc.) should just go ahead and print the header and pid, then print any sysctl(3) error in the PID's row instead of erroring out. We're either about to finish executing anyway if that was the only pid requested, or we're moving on to another pid that has nothing to do with the previous pid. There's not really any reason to stop processing further pids. This also affects attempting to list all pids since it currently stops processing pids as soon as one doesn't exist. A global error variable could just be incremented with every call and returned at process exit, that way it'd still be meaningful for single PIDs. Since this is a per-process tool, I think it needs to complete "procstat -c `ps axopid=`" if at all possible. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem compiling RELENG_6
On Sun, Nov 18, 2007 at 01:03:28PM -0300, Daniel Molina Wegener wrote: > I've downloaded the RELENG_6 through csup. While compiling the > source with make buildworld I get the next error: > > -8<--8<--8<--8<--8<- > ===> sbin/ipf/libipf (depend) > make: don't know how to make extras.c. Stop > *** Error code 2 > -8<--8<--8<--8<--8<- > > Same problem with genmask.c, getline.c, hexdump.c and other > files. This probably should've gone to freebsd-stable instead. A recent commit from the IPFilter author may have induced this; I can't check for you because the webserver on www.freebsd.org (where cvsweb lives) is presently irritated in some way. Anyways, see Darren's mail below: >> From: Darren Reed <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> Date: Sun, 18 Nov 2007 03:06:09 -0800 >> Subject: RELENG_6 IPFilter MFC >> >> I've just completed an MFC of IPFIilter in the FreeBSD 6 branch (RELENG_6) >> from HEAD. This brings the code used for IPFilter in FreeBSD into sync >> on each of HEAD, RELENG_6 and RELENG_7. Hopefully I can close one or >> two bug reports now ;) >> >> If you encounter any problems, please let me know. >> >> Cheers, >> Darren -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
problem compiling RELENG_6
Hello, I've downloaded the RELENG_6 through csup. While compiling the source with make buildworld I get the next error: -8<--8<--8<--8<--8<- ===> sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 -8<--8<--8<--8<--8<- Same problem with genmask.c, getline.c, hexdump.c and other files. Thanks, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | FreeBSD & Linux User| Standards Rocks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: need help with sigaction and siginfo_t
On Saturday 17 November 2007 17:03:51 nikita kozlov wrote:
> I'm a student and we are working on FreeBSD.
> My problem is i don't understand how to use SA_SIGINFO and siginfo_t.
> The following code caught my SIGUSR1 with a "kill -30 my_server_pid"
> from my shell.
> but siginfo_t is empty when i'm debugging my program with gdb.
> my output is :
> > pid 0
> and in gdb i have :
> {
> si_signo = 30,
> si_errno = 0,
> si_code = 0,
> si_pid = 0,
> si_uid = 0,
> si_status = 0,
> si_addr = 0x2,
> si_value = {sigval_int = 0,sigval_ptr = 0x0},
> si_band = 0,
> __spare__ = {0, 0, 0, 0, 0, 0, 0}
> }
>
> anyone have an idea why my siginfo_t is empty please ?
Well, it isn't empty. It's just that the si_pid field usually isn't
set. It probably should be, but either way, your code should work if
you send signals with sigqueue(2) instead of kill(2).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: need help with sigaction and siginfo_t
On Sunday 18 November 2007 14:39:41 [EMAIL PROTECTED] wrote:
> Tijl Coosemans <[EMAIL PROTECTED]> a écrit :
>> On Saturday 17 November 2007 17:03:51 nikita kozlov wrote:
>>> I'm a student and we are working on FreeBSD.
>>> My problem is i don't understand how to use SA_SIGINFO and
>>> siginfo_t. The following code caught my SIGUSR1 with a "kill -30
>>> my_server_pid" from my shell.
>>> but siginfo_t is empty when i'm debugging my program with gdb.
>>> my output is :
>>> > pid 0
>>> and in gdb i have :
>>> {
>>> si_signo = 30,
>>> si_errno = 0,
>>> si_code = 0,
>>> si_pid = 0,
>>> si_uid = 0,
>>> si_status = 0,
>>> si_addr = 0x2,
>>> si_value = {sigval_int = 0,sigval_ptr = 0x0},
>>> si_band = 0,
>>> __spare__ = {0, 0, 0, 0, 0, 0, 0}
>>> }
>>>
>>> anyone have an idea why my siginfo_t is empty please ?
>>
>> Well, it isn't empty. It's just that the si_pid field usually isn't
>> set. It probably should be, but either way, your code should work if
>> you send signals with sigqueue(2) instead of kill(2).
>
> Thank you for the reply,
> i have tried to use sigqueue but after a "undefined reference to
> `sigqueue'" compilation error i have opened signal.h and found this
> define :
>
> #if 0
> /*
> * PR: 35924
> * XXX we don't actually have these. We set _POSIX_REALTIME_SIGNALS to
> * -1 to show that we don't have them, but this symbol is not necessarily
> * in scope (in the current implementation), so we can't use it here.
> */
> int sigqueue(__pid_t, int, const union sigval);
> #endif
>
> I'm working on FreeBSD 5.5-RELEASE-p14, do you have any idea ?
Hmm, looks like it has only been added in FreeBSD 7. If you can't
upgrade, you'll have to use some more advanced IPC mechanism I'm
afraid.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get filename of an open file descriptor
* Skip Ford ([EMAIL PROTECTED]) wrote: > It would be interesting to know for sure, though, if Solaris uses > hardlinks and, if so, what their utility is called. Nope. They *do* use hardlinks in that they have 32bit wrappers in /usr/bin etc which dispatch to the relevent architecture, but the commands themselves are all seperate. A quick glance at the OpenSolaris source repository finds: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ptools/ i.e. they're just a bunch of losely related commands under the ptools banner. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would like some simple volunteer work
On 16/11/2007, Fred Bertram <[EMAIL PROTECTED]> wrote: > Hi, > > I'm a cs student from Australia. Perth eh? Wow, its nice to see someone else interested in FreeBSD out here. > Just want to enhance my skills and hopefully benefit this online software > community in some way. I enjoy C programming in particular, havn't really > mastered it or other languages. I'd like to practice by doing whatever though > if anybody understands where i'm coming from. > > Is this a good place to do this? Its as good a place as any. You're more than welcome to email me over the next few days; I know a thing or two about FreeBSD. I'd be glad to help - just supply beer. :) -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
