Re: periodic script in base system to run csup
Alex Kozlov writes: > On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: >> Em 2010.07.16. 16:23, Alex Kozlov escreveu: >> > On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: >> > >> > Thousands pc simultaneously try to access cvsup servers? >> > Sound like a ddos to me. >> Yes, this was the only concern and that's why I started this discussion. > And because its periodic, We can't use portsnap solution (random delay > before csup start). It's not completely impossible; periodic could spin off a separate shell for it, with a random delay. It's not clear what the best way to deal with the output would be, although several approaches present themselves. It would be a lot more complicated than Gabor's approach, though. ___ 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: Clock not moving in virtual machine
On Fri, Jul 16, 2010 at 11:47:23PM +0300, Alexander Motin wrote: > > It is probably hard to see pattern due to to very high clock frequency. > But TSC timecounter is unreliable even on real SMP systems. What it > counts on virtual SMP - even bigger question. As system seems never uses > timecounters with negative quality - you've left with > kern.timecounter.hardware=dummy - that's why time is not going. As last > resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. I came across the same problem on rootbsd a few days ago, and set the TSC as the timecounter in /etc/sysctl.conf - I've since found it should be possible to also set kern.timecounter.smp_tsc=1 in /boot/loader.conf to let the TSC be chosen. The system's now been running for a day and I've not had any warnings about the clock going backward, and since the time has remained correct I guess Xen synchronises with the host? Should I still switch back to using the i8254? -- Bruce Cran ___ 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: [TESTING]: updated clang/LLVM needs testing in ClangBSD
On 15-07-2010 19:42, Roman Divacky wrote: > I updated clang/LLVM in clangbsd to a newer version which I believe > will fix thas. can you rene (and everyone else) please retest with > updated ClangBSD and report back? > The updated version builds and installs fine, I'm now running the clangbsd kernel. The clangbsd world (chrooted with "make distribution DESTDIR=/usr/clangbsd" and "mount -t devfs devfs /usr/clangbsd/dev") seems to work fine, some basic commands work. Using a clang kernel with gcc kernel modules also works fine :) Regards, Rene > > On Thu, Jul 15, 2010 at 01:33:04PM +0200, Ren? Ladan wrote: >> 2010/7/14 Roman Divacky : >>> hi, >>> >>> ClangBSD was updated to LLVM/clang revision r108243 which we plan to >>> merge into HEAD. We would like that revision to be tested as much as >>> possible >>> and therefore we ask you to test ClangBSD to assure that the revision >>> we are updating to does not have some really embarassing bugs. >>> >>> How to do it (on i386 and amd64): >>> >>> 0) install fresh devel/llvm-devel port >>> >>> 1) svn co http://svn.freebsd.org/base/projects/clangbsd src >>> >>> 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf >>> >>> 3) cd src && make buildworld >>> >> And here my buildworld fails with: >> >> ===> lib/clang/libclanglex (depend) >> tblgen >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex >> -I. >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic >> -gen-clang-diags-defs -clang-component=Common >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td >>> DiagnosticCommonKinds.inc.h >> tblgen >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex >> -I. >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic >> -gen-clang-diags-defs -clang-component=Lex >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td >>> DiagnosticLexKinds.inc.h >> rm -f .depend >> CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp >> -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ >> -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f >> .depend -a >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex >> -I. >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS >> -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" >> -DCLANG_VENDOR=\"FreeBSD\ \" -DSVN_REVISION=\"108243\" >> -DCLANG_VENDOR_SUFFIX=\"\ 20100713\" >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/cla
Re: Clock not moving in virtual machine
On Fri, Jul 16, 2010 at 2:05 PM, Bruce Cran wrote: > On Fri, Jul 16, 2010 at 11:47:23PM +0300, Alexander Motin wrote: >> >> It is probably hard to see pattern due to to very high clock frequency. >> But TSC timecounter is unreliable even on real SMP systems. What it >> counts on virtual SMP - even bigger question. As system seems never uses >> timecounters with negative quality - you've left with >> kern.timecounter.hardware=dummy - that's why time is not going. As last >> resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. > > I came across the same problem on rootbsd a few days ago, and set the TSC > as the timecounter in /etc/sysctl.conf - I've since found it should be > possible to also set kern.timecounter.smp_tsc=1 in /boot/loader.conf to let > the TSC be chosen. The system's now been running for a day and I've not had > any warnings about the clock going backward, and since the time has > remained correct I guess Xen synchronises with the host? Should I still > switch back to using the i8254? > > -- > Bruce Cran > Setting kern.timecounter.smp_tsc=1 works for me. I put it in /boot/loader.conf so it would automatically work for single user mode too. I don't think the host automatically synchronizes the clock - their website recommends running ntp and I saw the clock drift a fair amount before I started doing that. Thanks for the tip. -- Rob Farmer ___ 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: Clock not moving in virtual machine
Bruce Cran wrote: > On Fri, Jul 16, 2010 at 11:47:23PM +0300, Alexander Motin wrote: >> It is probably hard to see pattern due to to very high clock frequency. >> But TSC timecounter is unreliable even on real SMP systems. What it >> counts on virtual SMP - even bigger question. As system seems never uses >> timecounters with negative quality - you've left with >> kern.timecounter.hardware=dummy - that's why time is not going. As last >> resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. > > I came across the same problem on rootbsd a few days ago, and set the TSC > as the timecounter in /etc/sysctl.conf - I've since found it should be > possible to also set kern.timecounter.smp_tsc=1 in /boot/loader.conf to let > the TSC be chosen. The system's now been running for a day and I've not had > any warnings about the clock going backward, and since the time has > remained correct I guess Xen synchronises with the host? I have no idea about TSC in XEN, but QEMU just passes TSC from the physical CPU. So if host' TSCs are not synchronized - value may jump accidentally when QEMU process migrates between CPUs. > Should I still switch back to using the i8254? I would say it depends. i8254 frequency is always known, while TSC depends on calibration. Calibration on virtual machine I think much less precise then on physical. Same time, if i8254 also used as event timer, timestamp calculation algorithm is not very trivial there and I am not sure it is absolutely reliable. So I would probably used i8254 as time counter and LAPIC+RTC as event timers. -- Alexander Motin ___ 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: Clock not moving in virtual machine
Rob Farmer wrote: >>> @@ -81,7 +81,10 @@ >>> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >>> ppc0: [ITHREAD] >>> ppbus0: on ppc0 >>> -atrtc0: at port 0x70 irq 8 on isa0 >>> +atrtc0: at port 0x70 irq 8 on isa0 >>> +atrtc0: [FILTER] >>> +Event timer "RTC" frequency 32768 Hz quality 0 >>> +Starting kernel event timers: LAPIC @ 200Hz, RTC @ 128Hz >>> Timecounters tick every 5.000 msec >> Everything seems reasonable there. Try to collect more information: >> sysctl kern.timecounter >> sysctl kern.eventtimer >> vmstat -ia >> systat -vm 1 (presence and frequencies of interrupts) >> >> It could be a bug in emulation of some timers or bug in respective timer >> driver, which was not triggered before last changes. You may try switch >> to different timecounter by setting kern.timecounter.hardware, or >> different eventtimers by setting kern.eventtimer.timer1 and >> kern.eventtimer.timer2 sysctls. > > This is all on the new (not-working) kernel in single user mode: > > # sysctl kern.timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) dummy(-100) > kern.timecounter.hardware: dummy > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 205772785 > kern.timecounter.tc.TSC.frequency: 2261052646 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > > kern.timecounter.tc.TSC.counter changes everytime (205772785, > 3200717147, 1205899870, ...) but I can't see any pattern. It is probably hard to see pattern due to to very high clock frequency. But TSC timecounter is unreliable even on real SMP systems. What it counts on virtual SMP - even bigger question. As system seems never uses timecounters with negative quality - you've left with kern.timecounter.hardware=dummy - that's why time is not going. As last resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. Previously you were using i8254 timecounter, but now you lost it as your virtual machine PnP BIOS doesn't announce it. QEMU does the same, but instead it gives HPET which your emulator seems also doesn't. To force i8254 presence add to the /boot/device.hints lines: hint.attimer.0.at="isa" hint.attimer.0.port="0x40" hint.attimer.0.irq="0" -- Alexander Motin ___ 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: Clock not moving in virtual machine
On Thu, Jul 15, 2010 at 11:33 PM, Alexander Motin wrote: > Rob Farmer wrote: >> I have a VPS from rootbsd.net which is running current, though I don't >> update it very often. I just built and installed a new world and >> kernel and now the clock will not move from the time the system was >> booted, ie: >> # date >> Thu Jul 15 16:15:58 PDT 2010 >> >> # date >> Thu Jul 15 16:15:58 PDT 2010 >> >> I have an old kernel from May 27 which doesn't have this problem. I >> noticed some clock related stuff changing in current in the last >> couple of weeks and suspect that their VM setup doesn't play well with >> these changes (their site says they use Xen, but several boot messages >> refer to QEMU). Officially, I think they only support running 8.0 so I >> thought I would ask here if anyone has any ideas before putting in a >> support request. >> >> Here's a diff of the dmesgs - I can post full copies if needed but >> didn't want to start with a ridicously long message: > >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 0 package(s) x 16 core(s) x 2 SMT threads >> cpu0 (BSP): APIC ID: 0 > > Probably not related, but funny. :) So you have two CPUs? Yes, there's 2 CPUs. It also gives the non uniform processors warning, but it has been like that forever. > >> @@ -81,7 +81,10 @@ >> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >> ppc0: [ITHREAD] >> ppbus0: on ppc0 >> -atrtc0: at port 0x70 irq 8 on isa0 >> +atrtc0: at port 0x70 irq 8 on isa0 >> +atrtc0: [FILTER] >> +Event timer "RTC" frequency 32768 Hz quality 0 >> +Starting kernel event timers: LAPIC @ 200Hz, RTC @ 128Hz >> Timecounters tick every 5.000 msec > > Everything seems reasonable there. Try to collect more information: > sysctl kern.timecounter > sysctl kern.eventtimer > vmstat -ia > systat -vm 1 (presence and frequencies of interrupts) > > It could be a bug in emulation of some timers or bug in respective timer > driver, which was not triggered before last changes. You may try switch > to different timecounter by setting kern.timecounter.hardware, or > different eventtimers by setting kern.eventtimer.timer1 and > kern.eventtimer.timer2 sysctls. > > -- > Alexander Motin > This is all on the new (not-working) kernel in single user mode: # sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) dummy(-100) kern.timecounter.hardware: dummy kern.timecounter.stepwarnings: 0 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 205772785 kern.timecounter.tc.TSC.frequency: 2261052646 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.timecounter.tc.TSC.counter changes everytime (205772785, 3200717147, 1205899870, ...) but I can't see any pattern. # sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(500) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 50001404 kern.eventtimer.et.LAPIC.quality: 500 kern.eventtimer.et.RTC.flags: 1 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.timer2: RTC kern.eventtimer.timer1: LAPIC kern.eventtimer.singlemul: 4 # vmstat -ia interrupt total rate ???0 0 irq1: atkbd0 339339 stray irq1 0 0 irq0: 0 0 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 irq4: uart00 0 stray irq4 0 0 irq5: re0 0 0 stray irq5 0 0 irq6: 0 0 stray irq6 0 0 irq7: ppc0 0 0 stray irq7 0 0 irq8: atrtc0 24463 24463 stray irq8 0 0 irq9: 0 0 stray irq9 0 0 irq10: re1 0 0 stray irq100 0 irq11: 0 0 stray irq110 0 irq12: psm00 0 stray irq120 0 irq13: 0 0 stray irq130 0 irq14: ata0 224224 stray irq140 0 irq15: ata10 0 stray irq150 0 irq16: 0 0 stray irq160 0 irq17: 0
Re: periodic script in base system to run csup
On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: > Em 2010.07.16. 16:23, Alex Kozlov escreveu: > > On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: > > > > Thousands pc simultaneously try to access cvsup servers? > > Sound like a ddos to me. > Yes, this was the only concern and that's why I started this discussion. And because its periodic, We can't use portsnap solution (random delay before csup start). -- Adios ___ 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: periodic script in base system to run csup
Em 2010.07.16. 16:23, Alex Kozlov escreveu: On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: Thousands pc simultaneously try to access cvsup servers? Sound like a ddos to me. Yes, this was the only concern and that's why I started this discussion. Btw, if You have time, can You please check conf/124641? Thanks. Ok, looks interesting, will take a look. Gabor ___ 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: periodic script in base system to run csup
Em 2010.07.16. 16:15, Jilles Tjoelker escreveu: Hmm, /usr/src/Makefile has an 'update' target that can run csup and other updating tools. Perhaps it should call that instead? It is not just for updating your src tree but your ports tree, doc tree or eventually your local CVS repo. That's why you can specify multiple supfiles. Gabor ___ 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"
periodic script in base system to run csup
On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: Thousands pc simultaneously try to access cvsup servers? Sound like a ddos to me. Btw, if You have time, can You please check conf/124641? Thanks. -- Adios ___ 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: periodic script in base system to run csup
On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: > Steven Kreuzer wrote a periodic script to run csup updates with periodic > daily. I've reviewed it and added support for multiple supfiles. I'd > like to commit this to head. > http://kovesdan.org/files/600.csup > Is there any objection? Hmm, /usr/src/Makefile has an 'update' target that can run csup and other updating tools. Perhaps it should call that instead? -- Jilles Tjoelker ___ 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"
periodic script in base system to run csup
Hi folks, Steven Kreuzer wrote a periodic script to run csup updates with periodic daily. I've reviewed it and added support for multiple supfiles. I'd like to commit this to head. http://kovesdan.org/files/600.csup Is there any objection? Gabor ___ 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: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm
On 2010-07-15 at 19:52, Ståle Kristoffersen wrote: > On 2010-07-15 at 18:00, Marius Strobl wrote: > > On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: > > > Upgraded to from stable to current yesterday and very quickly received a > > > panic. It did however not dump it's core, so I was unable to debug it. > > > Today it did panic again, and I took a picture: (Sorry about the bad > > > quality) > > > > > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > > > > > And from the backtrace: > > > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > > > > > Both times I hade the mpt0: request timed out just before the panic. > > > > > > I'm not sure why it's not dumping it's core (It was working under stable, > > > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) > > > > What revision were you using? > > Not sure exactly what revision I was using, is there an easy way to figure > that out? I ran cvsupdate around 13:00 CEST yesterday. > > > Does using current as of r209598 make a difference? > > Downgrading now... And it crashed again, with current from r209598... -- Ståle Kristoffersen ___ 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: can't checkout svn on cygwin
On Fri, Jul 16, 2010 at 11:12 AM, Dan Nelson wrote: > > Are you doing this on a cygwin install on vista ? > > It works fine on *Unix > > > > > have you run svn cleanup ? > > of course > > > > Lets pretend I'm one of the admins of svn.apache.org -- I know how to > > use svn. > > Until the offending files get fixed, you can try enabling NTFS case > sensitivity on your Windows system: > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive > > I got bitten by the same thing a while ago and I was working on OS/X. So it is indeed the case-sensitivity issue. CW -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." ___ 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"
