Re: nagios and freebsd threads issue : help please ...
Daniel, But i am in stable '5.4-STABLE FreeBSD 5.4-STABLE #4: Tue Jul 5 11:18:14 CEST 2005' and i have again the problem ... The post is from Jun 22... I don't understant why i have again the problem ? Could u help me, please ? Thanks. Daniel Eischen wrote: On Fri, 19 Aug 2005, Christophe Yayon wrote: Hi all You should know about freebsd and nagios 2.0b threads issues (100% cpu use by a forked process, lost check result, some pause of nagios main process in certains obscursives conditions...). Some Nagios developpers says that the problem is in FreeBSD and some other says that the problem is in nagios pthreads implementation, here a resume of our discussions : From http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html It is suggested that programs that use fork() call an exec function very soon afterwards in the child process, thus resetting all states. In the meantime, only a short list of async-signal-safe library routines are promised to be available. Note *suggested*. This is a recommendation to protect against a shoddy pthread-implementation. The thread specifications rule that only the thread calling fork() is duplicated, which initially leads to the recommendation (other threads holding locks aren't around to release them in the new execution context). They choose to quote a weak reference to the actual requirement. The standard says (in the fork() section): A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
On Fri, 19 Aug 2005, Doug Ambrisko wrote: Flash is nice but it has some issues. Atleast dropping it isn't one! Doug A. I'd be really happy if I could get a USB flash drive to last more than 8 months. Luckily, I started weekly backups after the first failure. That helped a lot when the second failure happened. The weird ways flash goes bad really makes me want to run something with full checksums (like ZFS) on it. Alas, even if I hacked up UFS to support such features, I suspect the W2K machines at work would be unhappy with it. :) I wonder if I should hack together a script that does MD5s during the backup process and notifies me if untouched files start changing... Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pthread functions swallowing stdout, and stderr?
Howdy, I'm working on my SoC project, where one of the important, yet broken, functions is being called from pthread_once() I have printf()'s before the pthread_once() call to help me debug, and printf()'s after the pthread_once() call, but the function that is called in pthread_once() has printf()'s inside it that never output to stdout :/ Here are some links in case I'm not making sense: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/ soc2005/launchd/liblaunch.cREV=7 The function that calls pthread_once() is launch_msg() on line 692, the pthread_once() calls launch_client_init() on line 119. Nothing from within launch_client_init() gets output to the terminal, while the printfs in launch_msg() before and after the launch_client_init() call are both output Any tips? :/ Cheers, -R. Tyler Ballance ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pthread functions swallowing stdout, and stderr?
Sorry everybody for the extra crap in your inboxes; I was forgetting to add -lpthread to the LDFLAGS in the Makefile for the launchctl client Shouldn't gcc warn me against this? Oh well, false alarm, thanks reffie! Cheers, -R. Tyler Ballance On Aug 20, 2005, at 3:23 AM, R. Tyler Ballance wrote: Howdy, I'm working on my SoC project, where one of the important, yet broken, functions is being called from pthread_once() I have printf()'s before the pthread_once() call to help me debug, and printf()'s after the pthread_once() call, but the function that is called in pthread_once() has printf()'s inside it that never output to stdout :/ Here are some links in case I'm not making sense: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/ soc2005/launchd/liblaunch.cREV=7 The function that calls pthread_once() is launch_msg() on line 692, the pthread_once() calls launch_client_init() on line 119. Nothing from within launch_client_init() gets output to the terminal, while the printfs in launch_msg() before and after the launch_client_init() call are both output Any tips? :/ Cheers, -R. Tyler Ballance ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Test - Ignore
___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Project BSDVISION Wants To Develop Native *BSD Console Desktop
For many people who spend a lot of time on the *BSD console and would love to have a desktop environment comparable to KDE/GNOME, I'm starting a project called BSDVISION to develop such an environment. Please don't ask if such an environment is really needed or not; the important thing is that some people like me need it badly enough to want to develop it. As a matter of fact, it has been in development for some time now and I think it's getting to the point where it makes sense to ask for community involvement. But I'm not looking for developers because development will continue to be done by myself with the assistance of paid contractors. What I'm looking for is people to maintain a community infrastructure (web site, mailing list, online forum, webcvs/svn, etc) which a community project like this needs in order to appeal to as many people as possible. So if you love the BSD console and would like to see it sport a complete desktop environment, the bsdvision project can really use your support. And since this project developed from an attempt to do a cleanroom implementation of libh, we'll be using the old libh mailing list until we have another one. Come help us make *BSD a truly complete platform with the best console desktop environment in the universe :-) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
On Saturday 20 August 2005 10:18, Mike Silbersack wrote: On Fri, 19 Aug 2005, Doug Ambrisko wrote: Flash is nice but it has some issues. Atleast dropping it isn't one! Doug A. I'd be really happy if I could get a USB flash drive to last more than 8 months. Luckily, I started weekly backups after the first failure. That helped a lot when the second failure happened. Flash drives does usually not last more than 1 writes, per bit, from what I know. Probably you need some kind of special file-system that moves the files around as the write quoute gets used up! Eventually the size of the disk will reach zero, and you have to move the files elsewhere :-) But this is probably off topic. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Project BSDVISION Wants To Develop Native *BSD Console Desktop
Mike Adewole wrote: cc: freebsd-hackers@freebsd.org, [EMAIL PROTECTED] I reduced to freebsd-hackers@freebsd.org tp avoid cross posting (OK, libh might be more appropriate, but I'm not sub'd to that) I'm looking for is people to maintain a community infrastructure (web site, mailing list, online forum, webcvs/svn, etc) which a community project like this needs in order to appeal to as many people as possible. implementation of libh, we'll be using the old libh mailing list until we have another one. Come help us make *BSD a truly complete platform with the best console desktop environment in the universe :-) [EMAIL PROTECTED] would be best to approach if you just need another mail list. If for some reason that's not appropriate I could host a list under [EMAIL PROTECTED] (sometime I'll convert to mailman). I could later also perhaps host CVS, I've got the space, traffic config I'd need to think about. -- Julian Stacey Consultant Systems Engineer, Munich. http://berklix.com Mail in Ascii (Html = Spam). Ihr Rauch = mein allergischer Kopfschmerz. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange (null) in cc -print-search-dirs
Hi, I tried building lcc from the quake3 arena sources today, and it failed when doing cc -print-search-dirs. On my FreeBSD -CURRENT I got: install: /usr/libexec/(null) On DragonflyBSD guys from #dragonflybsd also got (null) there, except on very recent DF. Linux(RH9) has: install: /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/ I changed contrib/gcc/gcc.c so that the (null) does no longer show, can someone please look at the attached patch for correctness? Thanks, -- Andreas -- TalisA was macht man eigentlich auf einer linux-gamer lan ? hl server aufsetzen und freuen ? *duck* ^^ Index: contrib/gcc/gcc.c === RCS file: /storage/freebsd/cvs/src/contrib/gcc/gcc.c,v retrieving revision 1.40 diff -u -r1.40 gcc.c --- contrib/gcc/gcc.c 3 Jun 2005 04:02:20 - 1.40 +++ contrib/gcc/gcc.c 20 Aug 2005 13:02:49 - @@ -6095,6 +6095,7 @@ /* Read specs from a file if there is one. */ #ifdef FREEBSD_NATIVE + machine_suffix = ; just_machine_suffix = ; #else /* FREEBSD_NATIVE */ machine_suffix = concat (spec_machine, dir_separator_str, signature.asc Description: This is a digitally signed message part
Re: Project BSDVISION Wants To Develop Native *BSD Console Desktop
Hi, I am just wondering, but will you be using QT 4.0 for this project? I might be interrested, though I am very comfortable with blackbox, it might be nice with some icons, as long as it doesn't take forever to start. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Project BSDVISION Wants To Develop Native *BSD Console Desktop
Sorry, this was meant for Mike Adewole [EMAIL PROTECTED] only. On Saturday 20 August 2005 16:38, Hans Petter Selasky wrote: Hi, I am just wondering, but will you be using QT 4.0 for this project? I might be interrested, though I am very comfortable with blackbox, it might be nice with some icons, as long as it doesn't take forever to start. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [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: Project BSDVISION Wants To Develop Native *BSD Console Desktop
I am just wondering, but will you be using QT 4.0 for this project? I might be interrested, though I am very comfortable with blackbox, it might be nice with some icons, as long as it doesn't take forever to start. --HPS We'll be reimplementing TurboVision (C++) for the project so we can release under a BSD compatible license. It's almost done and it looks quite nice with overlapping windows and drag n drop. Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Project BSDVISION Wants To Develop Native *BSD Console Desktop
So if you love the BSD console and would like to see it sport a complete desktop environment, the bsdvision project can really use your support. And since this project developed from an attempt to do a cleanroom implementation of libh, we'll be using the old libh mailing list until we have another one. Come help us make *BSD a truly complete platform with the best console desktop environment in the universe :-) I would be willing to test that out and I might be able to help with code. (School starting again, and I have a feeling there's going to be a LOT of work coming from my physics classes) - Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
On 2005-08-20T09:50:53+0400, Dmitry Mityugov wrote: On 8/10/05, Julien Gabel [EMAIL PROTECTED] wrote: Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. Yes, i know it simply works for a lot of users. It doesn't mean that it is the case for all users... i am of those. Just realized that with ACPI disabled, this card does not work with FreeBSD 5.4 (at least in my machine), with ACPI enabled - it does. Hope this information will help somebody. I have RTL8169S in my laptop, and have seen the same up/down/up/down etc. behavior that is noted in PR 80005. I am running 7-CURRENT about a day old. I switched from my custom kernel back to GENERIC and the problem went away, so I started adding things from my custom config file into GENERIC to see what finally broke it, and it turned out to be: options ACPI_DEBUG Just thought that I would mention it... re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1000 re0: RealTek 8169S Single-chip Gigabit Ethernet port 0x1000-0x10ff mem 0xd0008800-0xd00088ff irq 19 at device 8.0 on pci0 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S media interface on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:90:f5:32:35:9f re0: [GIANT-LOCKED] -- Mike Oliver [see complete headers for contact information] pgpYlryu57Wjo.pgp Description: PGP signature
Re: Parking disk drive heads
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Saturday 20 August 2005 10:18, Mike Silbersack wrote: : On Fri, 19 Aug 2005, Doug Ambrisko wrote: : Flash is nice but it has some issues. Atleast dropping it isn't one! : : Doug A. : : I'd be really happy if I could get a USB flash drive to last more than 8 : months. Luckily, I started weekly backups after the first failure. That : helped a lot when the second failure happened. : : : Flash drives does usually not last more than 1 writes, per bit, from what : I know. Probably you need some kind of special file-system that moves the : files around as the write quoute gets used up! Eventually the size of the : disk will reach zero, and you have to move the files elsewhere :-) But this : is probably off topic. Actually, 10,000 writes per bit is one or two orders of magnitude too low these days. It was more typical for the Linear Flash PCMCIA cards from 10 years ago. Today, typically flash devices are good for more like 100,000 or 500,000 writes per cell, and all the fobs you'd buy these days have built-in wear averaging. I've tried three times now to wear out a flash by writing an incrementing counter to a single location only to give up after weeks of hammering due to external factors (power failure, network failure, etc). Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Project BSDVISION Wants To Develop Native *BSD Console Desktop
On Saturday 20 August 2005 17:29, Mike Adewole wrote: I am just wondering, but will you be using QT 4.0 for this project? I might be interrested, though I am very comfortable with blackbox, it might be nice with some icons, as long as it doesn't take forever to start. --HPS We'll be reimplementing TurboVision (C++) for the project so we can release under a BSD compatible license. It's almost done and it looks quite nice with overlapping windows and drag n drop. Maybe I misunderstood you, but will this be running under X or in some text terminal? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Saturday 20 August 2005 10:18, Mike Silbersack wrote: : On Fri, 19 Aug 2005, Doug Ambrisko wrote: : Flash is nice but it has some issues. Atleast dropping it isn't one! : : Doug A. : : I'd be really happy if I could get a USB flash drive to last more than 8 : months. Luckily, I started weekly backups after the first failure. That : helped a lot when the second failure happened. : : : Flash drives does usually not last more than 1 writes, per bit, from what : I know. Probably you need some kind of special file-system that moves the : files around as the write quoute gets used up! Eventually the size of the : disk will reach zero, and you have to move the files elsewhere :-) But this : is probably off topic. Actually, 10,000 writes per bit is one or two orders of magnitude too low these days. It was more typical for the Linear Flash PCMCIA cards from 10 years ago. Today, typically flash devices are good for more like 100,000 or 500,000 writes per cell, and all the fobs you'd buy these days have built-in wear averaging. I've tried three times now to wear out a flash by writing an incrementing counter to a single location only to give up after weeks of hammering due to external factors (power failure, network failure, etc). As a data point, I've been using 64mb compact flash cards (rated at 100k writes) in about 100 Soekris boxes (running FreeBSD) for about 4 years, and they are all still working, except for one. Now, most compact flash cards are rated at 1 million writes. And yes, I'm logging to the card and everything.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
In message: [EMAIL PROTECTED] Eric Anderson [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Hans Petter Selasky [EMAIL PROTECTED] writes: : : On Saturday 20 August 2005 10:18, Mike Silbersack wrote: : : On Fri, 19 Aug 2005, Doug Ambrisko wrote: : : Flash is nice but it has some issues. Atleast dropping it isn't one! : : : : Doug A. : : : : I'd be really happy if I could get a USB flash drive to last more than 8 : : months. Luckily, I started weekly backups after the first failure. That : : helped a lot when the second failure happened. : : : : : : Flash drives does usually not last more than 1 writes, per bit, from what : : I know. Probably you need some kind of special file-system that moves the : : files around as the write quoute gets used up! Eventually the size of the : : disk will reach zero, and you have to move the files elsewhere :-) But this : : is probably off topic. : : Actually, 10,000 writes per bit is one or two orders of magnitude too : low these days. It was more typical for the Linear Flash PCMCIA cards : from 10 years ago. Today, typically flash devices are good for more : like 100,000 or 500,000 writes per cell, and all the fobs you'd buy : these days have built-in wear averaging. I've tried three times now : to wear out a flash by writing an incrementing counter to a single : location only to give up after weeks of hammering due to external : factors (power failure, network failure, etc). : : As a data point, I've been using 64mb compact flash cards (rated at 100k : writes) in about 100 Soekris boxes (running FreeBSD) for about 4 years, : and they are all still working, except for one. Now, most compact flash : cards are rated at 1 million writes. : : And yes, I'm logging to the card and everything.. The biggest failure mode of CF cards that we've seen in our boxes is static zapage. We get more CF cards back that didn't fsck due to a power failure, etc than we do worn out cards, or even static zapped ones. The static zapping usually happens when we're popping the old one out and a new one in... We think we may have seen one power surge related failure, but we're unsure. We've fielded about 1000 CF cards over the past 6 years... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Eric Anderson [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Hans Petter Selasky [EMAIL PROTECTED] writes: : : On Saturday 20 August 2005 10:18, Mike Silbersack wrote: : : On Fri, 19 Aug 2005, Doug Ambrisko wrote: : : Flash is nice but it has some issues. Atleast dropping it isn't one! : : : : Doug A. : : : : I'd be really happy if I could get a USB flash drive to last more than 8 : : months. Luckily, I started weekly backups after the first failure. That : : helped a lot when the second failure happened. : : : : : : Flash drives does usually not last more than 1 writes, per bit, from what : : I know. Probably you need some kind of special file-system that moves the : : files around as the write quoute gets used up! Eventually the size of the : : disk will reach zero, and you have to move the files elsewhere :-) But this : : is probably off topic. : : Actually, 10,000 writes per bit is one or two orders of magnitude too : low these days. It was more typical for the Linear Flash PCMCIA cards : from 10 years ago. Today, typically flash devices are good for more : like 100,000 or 500,000 writes per cell, and all the fobs you'd buy : these days have built-in wear averaging. I've tried three times now : to wear out a flash by writing an incrementing counter to a single : location only to give up after weeks of hammering due to external : factors (power failure, network failure, etc). : : As a data point, I've been using 64mb compact flash cards (rated at 100k : writes) in about 100 Soekris boxes (running FreeBSD) for about 4 years, : and they are all still working, except for one. Now, most compact flash : cards are rated at 1 million writes. : : And yes, I'm logging to the card and everything.. The biggest failure mode of CF cards that we've seen in our boxes is static zapage. We get more CF cards back that didn't fsck due to a power failure, etc than we do worn out cards, or even static zapped ones. The static zapping usually happens when we're popping the old one out and a new one in... We think we may have seen one power surge related failure, but we're unsure. We've fielded about 1000 CF cards over the past 6 years... Cool, great info - thanks. If I may, what are these cards doing? (anything cool?) - or at least, what company are you working for that uses this many for some purpose? (simply curiousity) Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
On 20 Aug, Eric Anderson wrote: As a data point, I've been using 64mb compact flash cards (rated at 100k writes) in about 100 Soekris boxes (running FreeBSD) for about 4 years, and they are all still working, except for one. Now, most compact flash cards are rated at 1 million writes. And yes, I'm logging to the card and everything.. I've been using a laptop drive in my firewall and mail relay box for noise and power consumption reasons. The drive specs only give an expected lifetime of a few years when running 24x7, and I just had to replace a drive that had been in service about four years. I've given some thought to using flash, but I'm concerned about the number of writes, especially since a mail relay (maybe 1K messages/day) is going to be somewhat write intensive. What would be nice is a flash-backed md device that would flush its contents to flash on power fail. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
Don Lewis wrote: On 20 Aug, Eric Anderson wrote: As a data point, I've been using 64mb compact flash cards (rated at 100k writes) in about 100 Soekris boxes (running FreeBSD) for about 4 years, and they are all still working, except for one. Now, most compact flash cards are rated at 1 million writes. And yes, I'm logging to the card and everything.. I've been using a laptop drive in my firewall and mail relay box for noise and power consumption reasons. The drive specs only give an expected lifetime of a few years when running 24x7, and I just had to replace a drive that had been in service about four years. I've given some thought to using flash, but I'm concerned about the number of writes, especially since a mail relay (maybe 1K messages/day) is going to be somewhat write intensive. What would be nice is a flash-backed md device that would flush its contents to flash on power fail. If you are running 6.0 or 7.0-CURRENT, you should check out gjournal recently released from a SoC project. It can do some of this. Maybe another possible solution would be a memory backed md device unioned over a flash device? Anyhow, a cheap solution would be 2 flash devices mirrored with gmirror. By the time it burns up, you'll be able to swap it with the same size for half the price, and if you put them on different IDE channels or use usb, you can do it live. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
