Re: [PATCH] Toggle display of the kernel idle process (per-CPU idle threads) in top
On Fri May 27 11, Sergey Kandaurov wrote:
On 27 May 2011 18:46, John Baldwin j...@freebsd.org wrote:
Some times in top, I don't want to see all the per-CPU idle threads but
instead focus on the non-idle threads that are running. Especially on a
system with a lot of CPUs, the idle threads can push all the interesting
threads off of the list. This patch adds a new 'z' flag (gratuitously
chosen
letter) and interactive command to toggle the display of the system idle
process. Patch is tested against 8, but should work fine on HEAD too:
Works on HEAD as well. I like this idea.
works well for me, too. another thing i'd love to see is the -P flag becomming
interactive. also i think the -H option should really be documented along with
the other flags. i've seen quite a lot of people not finding the right section.
documenting a flag after the BUGS section is really non intuitive, no matter,
if the -H flag is freebsd specific or not. it should really be added to the
OPTIONS and INTERACTIVE MODE sections.
cheers.
alex
Perhaps it could be combined with i key?
@@ -1075,7 +1081,13 @@
reset_display();
putchar('\r');
break;
-
+ case CMD_kidletog:
+ ps.kidle = !ps.kidle;
+ new_message(MT_standout | MT_delayed,
+ %sisplaying kernel idle process.,
+ ps.idle ? D : Not d);
^^
typo: s/idle/kidle/
--
wbr,
pluknet
--
a13x
___
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 new nfs and VIMAGE
--On Friday, May 27, 2011 7:03 PM -0400 Rick Macklem rmack...@uoguelph.ca
wrote:
And the attached core.txt got eaten.
http://people.hidden-powers.com/~glz/core.txt.3
/glz
--On May 27, 2011 10:37:32 +0200 Goran Lowkrantz
g...@hidden-powers.com
wrote:
I have been testing VIMAGE a lot lately to see how it works an all
my
test cases works as expected except when I use NFSv4 from an NFS
client
with a kerrel with VIMAGE enabled.
All other permutations work and this error is very specific. All
crashes
occurs when trying to read or write to an NFS v4 volume. I have seen
it
on both i386 and amd64.
# 12 0xc0a73c15 in rt_tables_get_rnh (table=0, fam=2)
at /usr/src/sys/net/route.c:153
static __inline struct radix_node_head **
rt_tables_get_rnh_ptr(int table, int fam)
{
struct radix_node_head **rnh;
KASSERT(table = 0 table rt_numfibs, (%s: table out of
bounds.,
__func__));
KASSERT(fam = 0 fam (AF_MAX+1), (%s: fam out of
bounds.,
__func__));
/* rnh is [fib=0][af=0]. */
--- rnh = (struct radix_node_head **)V_rt_tables;
/* Get the offset to the requested table and fam. */
rnh += table * (AF_MAX+1) + fam;
return (rnh);
}
Any ideas?
Cores and dumps are available plus a vmware player setup to test and
debug.
I know diddly about VIMAGE, but you could try the attached patch which
imitates what is done other places.
If the patch isn't attached, you can find it at:
http://people.freebsd.org/~rmacklem/vnet.patch
rick
It worked when I added CURVNET_SET/CURVNET_RESTORE around the RTFREE_LOCKED
macro too. Attached a complete patch.
Thank you.
/glz
--- fs/nfsclient/nfs_clport.c.orig 2011-05-19 03:35:52.0 +0200
+++ fs/nfsclient/nfs_clport.c 2011-05-28 11:03:16.563178326 +0200
@@ -943,7 +943,9 @@ nfscl_getmyip(struct nfsmount *nmp, int
sad.sin_family = AF_INET;
sad.sin_len = sizeof (struct sockaddr_in);
sad.sin_addr.s_addr = sin-sin_addr.s_addr;
+ CURVNET_SET(TD_TO_VNET(curthread));
rt = rtalloc1((struct sockaddr *)sad, 0, 0UL);
+ CURVNET_RESTORE();
if (rt != NULL) {
if (rt-rt_ifp != NULL
rt-rt_ifa != NULL
@@ -954,7 +956,9 @@ nfscl_getmyip(struct nfsmount *nmp, int
laddr.s_addr = sin-sin_addr.s_addr;
retp = (u_int8_t *)laddr;
}
+ CURVNET_SET(TD_TO_VNET(curthread));
RTFREE_LOCKED(rt);
+ CURVNET_RESTORE();
}
#ifdef INET6
} else if (nmp-nm_nam-sa_family == AF_INET6) {
@@ -966,7 +970,9 @@ nfscl_getmyip(struct nfsmount *nmp, int
sad6.sin6_family = AF_INET6;
sad6.sin6_len = sizeof (struct sockaddr_in6);
sad6.sin6_addr = sin6-sin6_addr;
+ CURVNET_SET(TD_TO_VNET(curthread));
rt = rtalloc1((struct sockaddr *)sad6, 0, 0UL);
+ CURVNET_RESTORE();
if (rt != NULL) {
if (rt-rt_ifp != NULL
rt-rt_ifa != NULL
@@ -978,7 +984,9 @@ nfscl_getmyip(struct nfsmount *nmp, int
retp = (u_int8_t *)laddr6;
*isinet6p = 1;
}
+ CURVNET_SET(TD_TO_VNET(curthread));
RTFREE_LOCKED(rt);
+ CURVNET_RESTORE();
}
#endif
}
___
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: snd_hda : sometimes sound sometimes not
On 12/05/2011 08:47, David Demelier wrote: Hello, I don't know if there is a lot of changes in the snd_hda driver in the -STABLE branch but since I upgraded to it sometimes I have sound and sometimes not. The mixer are exactly the same when these event occurs. This happened this morning. After booting I do not have any sound. I rebooted and suddenly I've got sound again... I only tweak snd_hda(4) for a pin sense on the front panel (it has no sound neither) So I added in /boot/devices.hints : hint.hdac.1.cad0.nid27.config=as=1 seq=15 And there's the both dmesg ok.txt when sound is here and not.txt when there isn't as you can see there is no difference related to the hda driver. http://markand.malikania.fr/ok.txt http://markand.malikania.fr/nok.txt I'm guessing something. My laptop has a mute shortcut, if I press it at the BIOS stage I will not have sound neither thus is it possible that my chipset is muted from anything? Cheers, Sorry to cross-post again, but I just wanted to tell you that the problem disappeared in -CURRENT so now I just how the unknown bogus code will be MFC before 8.3-RELEASE Cheers, -- David Demelier ___ 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: snd_hda : sometimes sound sometimes not
On Sat, May 28, 2011 at 03:30:26PM +0200, David Demelier wrote: On 12/05/2011 08:47, David Demelier wrote: Hello, I don't know if there is a lot of changes in the snd_hda driver in the -STABLE branch but since I upgraded to it sometimes I have sound and sometimes not. The mixer are exactly the same when these event occurs. This happened this morning. After booting I do not have any sound. I rebooted and suddenly I've got sound again... I only tweak snd_hda(4) for a pin sense on the front panel (it has no sound neither) So I added in /boot/devices.hints : hint.hdac.1.cad0.nid27.config=as=1 seq=15 And there's the both dmesg ok.txt when sound is here and not.txt when there isn't as you can see there is no difference related to the hda driver. http://markand.malikania.fr/ok.txt http://markand.malikania.fr/nok.txt I'm guessing something. My laptop has a mute shortcut, if I press it at the BIOS stage I will not have sound neither thus is it possible that my chipset is muted from anything? Cheers, Sorry to cross-post again, but I just wanted to tell you that the problem disappeared in -CURRENT so now I just how the unknown bogus code will be MFC before 8.3-RELEASE Unless someone can chime in with details of the commits which changed, assuming the magic change will be MFC'd is a bad one. It's safe to say that when 8.3-RELEASE comes out if this problem haunts you again, you will be mailing the list about it, and this cycle will continue until 9.0-RELEASE comes out. Does any developer/committer have familiarity with this issue and have some ideas as to what may have changed in CURRENT that addresses David's issue? And if so, can that code be MFC'd safely or patches provided to David for RELENG_8 that he can try out? I'm CC'ing mav@ here (snd_hda(4) says he's one of the authors), although he may not have any knowledge of the code which may need to be MFC'd. He may be able to point us to who has a better idea though. -- | Jeremy Chadwick j...@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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2011-05-28 13:40:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-28 13:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-05-28 13:40:00 - cleaning the object tree TB --- 2011-05-28 13:40:30 - cvsupping the source tree TB --- 2011-05-28 13:40:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-05-28 13:40:43 - building world TB --- 2011-05-28 13:40:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-28 13:40:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-28 13:40:43 - TARGET=amd64 TB --- 2011-05-28 13:40:43 - TARGET_ARCH=amd64 TB --- 2011-05-28 13:40:43 - TZ=UTC TB --- 2011-05-28 13:40:43 - __MAKE_CONF=/dev/null TB --- 2011-05-28 13:40:43 - cd /src TB --- 2011-05-28 13:40:43 - /usr/bin/make -B buildworld World build started on Sat May 28 13:40:49 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libllvmcore/../../../contrib/llvm/include -I/src/lib/clang/libllvmcore/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore -I. -I/src/lib/clang/libllvmcore/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -c /src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore/AsmWriter.cpp c++ -O2 -pipe -I/src/lib/clang/libllvmcore/../../../contrib/llvm/include -I/src/lib/clang/libllvmcore/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore -I. -I/src/lib/clang/libllvmcore/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -c /src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore/Attributes.cpp c++ -O2 -pipe -I/src/lib/clang/libllvmcore/../../../contrib/llvm/include -I/src/lib/clang/libllvmcore/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore -I. -I/src/lib/clang/libllvmcore/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -c /src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore/AutoUpgrade.cpp /src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore/AutoUpgrade.cpp: In function 'bool UpgradeIntrinsicFunction1(llvm::Function*, llvm::Function*)': /src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore/AutoUpgrade.cpp:28: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /src/lib/clang/libllvmcore. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-28 14:44:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-28 14:44:47 - ERROR: failed to build world TB --- 2011-05-28 14:44:47 - 3136.34 user 524.55 system 3887.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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
Regression with nfe interface since r219740
Hello list, Running FreeBSD 9 amd64, I have found a regression, after r219740 assigning a ip address to my nfe interface will completely hard lock the entire machine. both static and dhclient lock the machine. I have spent some time to bisect the kernel and everything works as expected with a r219739 kernel , r219740 breaks it. here is some information about my system http://www.puffybsd.com/FreeBSDinfo.txt -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ 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: message buffer scrambling fix
On 5/27/11 3:45 PM, Kenneth D. Merry wrote: Hey folks, I have attached some patches to the kernel message buffer code (this affects dmesg(8) output as well as kernel messages that go to the syslog) to address log scrambling. This fixes the same issue that 'options PRINTF_BUFR_SIZE=128' fixes for the console. The problem is that you can have multiple kernel threads writing to the message buffer at the same time, and so their characters will get interleaved. All of the characters will get in there, because they're written with atomic operations, but the output might looked scrambled. So the fix is to use the same stack buffer that is used for the console output (so the stack size doesn't increase), and use a spin lock instead of atomic operations to insert the string into the message buffer. The result is that dmesg and syslog output should look the same as the console output. As long as individual kernel prints fit in the printf buffer size, they will be put into the message buffer atomically. I also fixed a couple of other long-standing issues. putcons() (in subr_prf.c) was adding a carriage return before calling cnputs(). But cnputs() calls cnputc(), which adds a carriage return before every newline. So much of the console output (the part that came from putcons() at least) had two carriage returns at the end. The other issue was that log_console() was inserting a newline for any console write that didn't already have one at the end. The issue with that can be seen if you do a 'dmesg -a' and compare that to the console output. You'll see something like this on the console: Updating motd:. But this in dmesg -a: Updating motd: . That is because Updating motd: is written first, log_console() appends a newline, and then .\n is written. I added a loader tunable and sysctl to turn the old behavior back on (kern.log_console_add_linefeed) if you want the old behavior, but I think we should be able to safely remove it. Also, the new msgbuf_addstr() function allows the caller to optionally ask for carriage returns to be stripped out. However, in my testing I haven't seen any carriage returns to strip. Let me know if you have any comments. I'm planning to check this into head next week. looks good.. as long as we don't end up with the behaviour that I think I see on Linux (it's hard to tell sometimes) where the last message (the one you really want to see) doesn't make it out. Thanks, Ken ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ZFS install from -CURRENT snapshot
Ok, I think I've figured this out, but I want some confirmation before I start playing with actual hardware... The install steps on http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot no longer appear to apply. The /dist/ directory doesn't exist on any of the current snapshots, so the actual install process given in that page can't work. Am I correct in guessing that the /usr/freebsd_dist/ directory has replaced it in some form? Also, instead of sub-folders with install scripts, there are tarballs, which I assume are extracted over the new filesystem? Then any necessary pre-boot configuration would be done. (Anything special need mention beyond what is on the page above?) If there's a doc someplace on this, feel free to point me to it. I just want a sanity-check before I dive in headfirst... Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ 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: pcib allocation failure
On Thu, May 26, 2011 at 3:40 PM, John Baldwin j...@freebsd.org wrote:
Ohh, you have two devices behind this bridge that have prefetch ranges.
As a hack, can you try this:
Index: pci_pci.c
===
--- pci_pci.c (revision 85)
+++ pci_pci.c (working copy)
@@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
{
device_t dev;
uint32_t val;
+ uint16_t cmd;
dev = sc-dev;
+ cmd = pci_read_config(dev, PCIR_COMMAND, 2);
+ if (cmd (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
+ pci_write_config(dev, PCIR_COMMAND,
+ cmd ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
if (sc-io.valid mask WIN_IO) {
val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
if ((val PCIM_BRIO_MASK) == PCIM_BRIO_32) {
@@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
pci_write_config(dev, PCIR_PMBASEL_1, sc-pmem.base 16, 2);
pci_write_config(dev, PCIR_PMLIMITL_1, sc-pmem.limit 16,
2);
}
+ if (cmd (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
+ pci_write_config(dev, PCIR_COMMAND, cmd, 2);
}
static void
@@ -337,6 +344,9 @@ pcib_probe_windows(struct pcib_softc *sc)
pci_read_config(dev, PCIR_PMLIMITL_1, 2));
max = 0x;
}
+ /* XXX: Testing hack */
+ if (device_get_unit(sc-sc_dev) == 1)
i'm assuming that sc-sc_dev should be dev (this fixes a compilation error).
+ sc-pmem.limit = 0xefff;
pcib_alloc_window(sc, sc-pmem, SYS_RES_MEMORY,
RF_PREFETCHABLE, max);
}
that seems to work!
btw, is my machine a test-pig for an upcoming change to the PCI bus driver?
___
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: [rfc] remove hlt_cpus et al sysctls and related code
2011/5/25 Andriy Gapon a...@freebsd.org: on 23/05/2011 19:28 Andriy Gapon said the following: I propose the following path for moving forward. - use hint.lapic.X.disabled to disable individual CPUs by their APIC ID - use machdep.hyperthreading_allowed tunable to disable second logical CPU on each real core The above should already work as expected. One thing is that currently we have handling of machdep.hyperthreading_allowed tunable under SCHED_ULE. I plan to make it unconditional. Things to remove: - all the related sysctls for dynamic onlining/offlining - machdep.hlt_logical_cpus tunable (it duplicates hint.lapic.X.disabled) It's possible to keep machdep.hlt_logical_cpus and just add some code to convert hlt_logical_cpus mask to a set of individual hint.lapic.X.disabled, but I don't see very much value in that. But if there is a good reason to keep that tunable, I am prepared to jump through this hoop. If no one objects to this proposal, I will provide a patch soon. The patch is here: http://people.freebsd.org/~avg/cpu-offline-sysctl.diff It should implement the strategy described above. I don't see the point in keeping alive mp_grab_cpu_hlt() and supporting, actually. On the top of your patch I made some modifies that use directly ap_watchdog() in cpu_idle() which I think is better for the time being: http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff If you are happy with it, just commit as long as Garrett tests that. On a second round of changes we can discuss mp_watchdog and eventual removal / improvements to it. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: [rfc] remove hlt_cpus et al sysctls and related code
2011/5/28 Attilio Rao atti...@freebsd.org: 2011/5/25 Andriy Gapon a...@freebsd.org: on 23/05/2011 19:28 Andriy Gapon said the following: I propose the following path for moving forward. - use hint.lapic.X.disabled to disable individual CPUs by their APIC ID - use machdep.hyperthreading_allowed tunable to disable second logical CPU on each real core The above should already work as expected. One thing is that currently we have handling of machdep.hyperthreading_allowed tunable under SCHED_ULE. I plan to make it unconditional. Things to remove: - all the related sysctls for dynamic onlining/offlining - machdep.hlt_logical_cpus tunable (it duplicates hint.lapic.X.disabled) It's possible to keep machdep.hlt_logical_cpus and just add some code to convert hlt_logical_cpus mask to a set of individual hint.lapic.X.disabled, but I don't see very much value in that. But if there is a good reason to keep that tunable, I am prepared to jump through this hoop. If no one objects to this proposal, I will provide a patch soon. The patch is here: http://people.freebsd.org/~avg/cpu-offline-sysctl.diff It should implement the strategy described above. I don't see the point in keeping alive mp_grab_cpu_hlt() and supporting, actually. On the top of your patch I made some modifies that use directly ap_watchdog() in cpu_idle() which I think is better for the time being: http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff If you are happy with it, just commit as long as Garrett tests that. On a second round of changes we can discuss mp_watchdog and eventual removal / improvements to it. I almost forgot: this change would also require an UPDATE entry, where you explicitly mention the new way to deal with CPUs. Use your prefer wording. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS install from -CURRENT snapshot
On Sat, May 28, 2011 at 08:16:37PM -0400, Daniel Staal wrote: Ok, I think I've figured this out, but I want some confirmation before I start playing with actual hardware... The install steps on http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot no longer appear to apply. The /dist/ directory doesn't exist on any of the current snapshots, so the actual install process given in that page can't work. snip If there's a doc someplace on this, feel free to point me to it. I just want a sanity-check before I dive in headfirst... If you want to end up with a mirrored ZFS only setup, have you seen ? http://blogs.freebsdish.org/pjd/2010/08/06/from-sysinstall-to-zfs-only-configuration/ That one was pretty straight-forward for me. You get to use sysinstall and don't have to manually install the OS. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
