How ignore the arp request
I want to establish a web-cluster.Now i face with the problem how to configure the virtual ip in back-end server and how to ignore the arp request to virtual ip of back-end server. who can tell me ? please detail it !thanks shiner - DO YOU YAHOO!? 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How ignore the arp request
On Fri, Jul 01, 2005 at 05:11:40PM +0800, shiner chen wrote: > I want to establish a web-cluster.Now i face with the problem how to > configure the virtual ip in back-end server and how to ignore the arp > request to virtual ip of back-end server. who can tell me ? please detail > it !thanks > ifconfig -arp? ipfw? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Malloc while freeing some object
On 2005-06-30 22:27, Roman Kurakin <[EMAIL PROTECTED]> wrote: >Dmitry Mityugov wrote: >>On 6/30/05, Roman Kurakin <[EMAIL PROTECTED]> wrote: >>> One simple question on programming style. Is it ok to call malloc >>> while we releasing some object? >> >> Are you releasing it in another thread? Is it a C++ object? How are >> you releasing it? > > This was general question. In fact I've found that ttyfree() function > from kernel code allocates tempory variables to free tty. I didn't > expect such behaviour. I always thought that deallocation of smth > should need other alloc. Not necessarily. This could be a problem if you are implementing the allocator itself, and start an infinite recursion or end up deadlocking against the allocator which waits the allocator to finish, which waits the allocator... etc. Users of a general purpose memory allocator don't generally have to worry about the same thing though ;-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How ignore the arp request
Vasil Dimov wrote: On Fri, Jul 01, 2005 at 05:11:40PM +0800, shiner chen wrote: I want to establish a web-cluster.Now i face with the problem how to configure the virtual ip in back-end server and how to ignore the arp request to virtual ip of back-end server. who can tell me ? please detail it !thanks ifconfig -arp? ipfw? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" I would go with something along the lines of: spread and wackamole with maybe a bit of mod_backhand thrown in for loadbalancing. -- Med venlig hilsen / Best Regards Laust Jespersen http://www.ust.dk == Viking Rule of Acquisition 1: Remember where you beached the long ship ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Help regarding panics within sb* (sbdrop) functions in FreeBSD 5
Hi,
I've been experiencing for some time now crashes of a few of my FreeBSD
systems wich seem to panic in the sbdrop functions, I have atleast two
dumps that point to this.
Both seem to happen because of an unexpected NULL value.
This is on a 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #6: Tue Jun 28 13:42:14 UTC
2005
And these crashes have been happening since early 5 series.
Every time one of these crashes occur there are entries in the system log:
Jun 21 14:21:38 bastet kernel: bge0: discard frame w/o packet header
Jun 21 14:23:39 bastet kernel: bge0: discard frame w/o packet header
Jun 21 14:23:59 bastet kernel: bge0: discard frame w/o packet header
Jun 21 14:24:33 bastet kernel: me w/o packet header
Jun 21 14:24:38 bastet kernel: bge0: discard frame w/o packet header
For instance, the last panic was in sbdrop_locked:
#0 doadump () at pcpu.h:159
#1 0xc060c5ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc060c915 in panic (fmt=0xc081c602 "sbdrop") at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc0647000 in sbdrop_locked (sb=0xc5620484, len=3793) at
/usr/src/sys/kern/uipc_socket2.c:1149
#4 0xc06a3957 in tcp_input (m=0xc39d4600, off0=20) at
/usr/src/sys/netinet/tcp_input.c:2195
#5 0xc069b2e5 in ip_input (m=0xc39d4600) at /usr/src/sys/netinet/ip_input.c:776
#6 0xc067e01b in netisr_processqueue (ni=0xc08da998) at
/usr/src/sys/net/netisr.c:233
#7 0xc067e216 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346
#8 0xc05f8599 in ithread_loop (arg=0xc351d400) at
/usr/src/sys/kern/kern_intr.c:547
#9 0xc05f7635 in fork_exit (callout=0xc05f8440 , arg=0xc351d400,
frame=0xe684dd48)
at /usr/src/sys/kern/kern_fork.c:791
#10 0xc079fe1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
#3 0xc0647000 in sbdrop_locked (sb=0xc5620484, len=3793) at
/usr/src/sys/kern/uipc_socket2.c:1149
1149panic("sbdrop");
(kgdb) list
1144
1145next = (m = sb->sb_mb) ? m->m_nextpkt : 0;
1146while (len > 0) {
1147if (m == 0) {
1148if (next == 0)
1149panic("sbdrop");
1150m = next;
1151next = m->m_nextpkt;
1152continue;
1153}
1154if (m->m_len > len) {
1155m->m_len -= len;
1156m->m_data += len;
1157sb->sb_cc -= len;
1158if (m->m_type != MT_DATA && m->m_type !=
MT_HEADER &&
1159m->m_type != MT_OOBDATA)
1160sb->sb_ctl -= len;
1161break;
1162}
1163len -= m->m_len;
1164sbfree(sb, m);
1165m = m_free(m);
1166}
My questions are these:
Is it not possible that m_nextpkt is NULL if the current is the last one in
the buffer?
Why does that require a panic, could it not drop the frames for a resend?
Another dump I have from earlier on this same machine panics in
sbappendaddr_locked:
#0 doadump () at pcpu.h:159
#1 0xc060560f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397
#2 0xc0605935 in panic (fmt=0xc080f8d8 "sbappendaddr_locked")
at /usr/src/sys/kern/kern_shutdown.c:553
#3 0xc063f6f9 in sbappendaddr_locked (sb=0xc923941c, asa=0xc086cd60,
m0=0xc9ca0100,
control=0xc9ca0100) at /usr/src/sys/kern/uipc_socket2.c:934
#4 0xc0696082 in raw_append (last=0x0, ip=0xc4054810, n=0xc9ca0100)
at /usr/src/sys/netinet/raw_ip.c:169
#5 0xc06962ed in rip_input (m=0xc9ca0100, off=20) at
/usr/src/sys/netinet/raw_ip.c:231
#6 0xc0692b71 in ip_input (m=0xc9ca0100) at /usr/src/sys/netinet/ip_input.c:739
#7 0xc06761ef in netisr_processqueue (ni=0xc08ccf38) at
/usr/src/sys/net/netisr.c:233
#8 0xc06763ea in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346
#9 0xc05f14fd in ithread_loop (arg=0xc3491d00) at
/usr/src/sys/kern/kern_intr.c:547
#10 0xc05f05ad in fork_exit (callout=0xc05f13a4 , arg=0xc3491d00,
frame=0xe680ad48)
at /usr/src/sys/kern/kern_fork.c:811
#11 0xc079558c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
#3 0xc063f6f9 in sbappendaddr_locked (sb=0xc923941c, asa=0xc086cd60,
m0=0xc9ca0100,
control=0xc9ca0100) at /usr/src/sys/kern/uipc_socket2.c:934
934 panic("sbappendaddr_locked");
(kgdb) list
929 int space = asa->sa_len;
930
931 SOCKBUF_LOCK_ASSERT(sb);
932
933 if (m0 && (m0->m_flags & M_PKTHDR) == 0)
934 panic("sbappendaddr_locked");
935 if (m0)
936 space += m0->m_pkthdr.len;
937 space += m_len
Re: what(1) on kernel binary
On Friday 01 July 2005 01:39 am, R. Imura wrote:
> Hi,
>
> On Mon, Jun 20, 2005 at 05:26:49PM +0200, Jilles Tjoelker wrote:
> > On FreeBSD 4.x, one could easily determine the version and compilation
> > date of a kernel binary like this:
> >
> > [EMAIL PROTECTED] /home/jilles% what /kernel
> > /kernel:
> > FreeBSD 4.11-STABLE #20: Mon May 9 18:43:52 CEST 2005
> >
> > On FreeBSD 5.x/6.x with GCC 3.x, this doesn't work anymore.
> >
> > The cause is that these two arrays (in /sys/conf/newvers.sh) are now both
> > aligned to a 32-byte boundary, so there are 28 null bytes between @(#)
> > and the version number:
> >
> > char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' };
> > char sccs[4] = { '@', '(', '#', ')' };
> >
> > A possible solution is to change the two arrays to a single one
> > containing 28 null bytes and @(#).
> >
> > char sccs[32] = { '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0',
> > '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0',
> > '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0', '\\0',
> > '\\0', '@', '(', '#', ')' };
>
> It works ok with the former option(A), but it doesn't with latter(B) with
> my FreeBSD box.
>
> (A) cc -c vers.c
>
> (B) cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
> -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys
> -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq
> -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf
> -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd
> -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -include
> opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100
> --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel
> -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow
> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror vers.c
>
> IMHO, the simplest solution is duplicate writing ${VERSION} like this,
> but this would let kernel be 20-30bytes bigger.
>
> ---
> cat << EOF > vers.c
> $COPYRIGHT
> char sccs[] = "@(#)${VERSION} #${v}: ${t}";
> char version[] = "${VERSION} #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n";
> char ostype[] = "${TYPE}";
> char osrelease[] = "${RELEASE}";
> int osreldate = ${RELDATE};
> char kern_ident[] = "${i}";
> EOF
> ---
Hmm, this is what I came up with when talking to bde@:
--- newvers.sh 15 Jan 2005 13:25:41 - 1.68
+++ newvers.sh 22 Jun 2005 14:40:48 -
@@ -83,15 +83,15 @@
touch version
v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
i=`${MAKE:-make} -V KERN_IDENT`
+fullversion="${VERSION} #${v}: ${t}\n[EMAIL PROTECTED]:${d}";
cat << EOF > vers.c
$COPYRIGHT
-char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' };
-char sccs[4] = { '@', '(', '#', ')' };
-char version[] = "${VERSION} #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n";
-char ostype[] = "${TYPE}";
-char osrelease[] = "${RELEASE}";
-int osreldate = ${RELDATE};
-char kern_ident[] = "${i}";
+const char sccs[] = "@(#)${fullversion}";
+const char version[] = "${fullversion}";
+const char ostype[] = "${TYPE}";
+const char osrelease[] = "${RELEASE}";
+const int osreldate = ${RELDATE};
+const char kern_ident[] = "${i}";
EOF
does sccs[] only need to include the version up to the first \n? bde@ noticed
that what seemed to stop once it hit \n.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what(1) on kernel binary
Hi, On Fri, Jul 01, 2005 at 09:40:12AM -0400, John Baldwin wrote: > does sccs[] only need to include the version up to the first \n? bde@ > noticed > that what seemed to stop once it hit \n. what.c says like this. while ((c = getchar()) != EOF && c && c != '"' && c != '>' && c != '\\' && c != '\n') putchar(c); According to cvs repo, \n is a terminater since 4.4BSD Lite. I don't know before 4.4BSD Lite. I don't know about sccs neither. Regards, - R. Imura ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Accurate/Fine-grained timing of latency in atheros drivers
Sam Pierson wrote: Hey guys, In a current project, I need to find out exactly how long it takes to send a 802.11 packet and how much time is spent in the following stages: send time - time spent constructing message, including context switches and other delays and the time it takes to transfer the message to the network card. You didn't provide enough info to really answer this but it sounds like it's time spent prior to handing the packet to the h/w in which case you need to augment the existing code. Atheros h/w uses dma so "time it takes to transfer the message to the network card" is kinda nebulous. If you want to know when the h/w starts dma then you can mark a tx descriptor to get an interrupt when it's processed but unless you poll the tx dma registers you cannot tell when dma has started and even then you can only get an approximation. The better thing to do is use a bus analyzer and watch for particular data patterns and/or addresses. access time - delay which we experience waiting to access the transmitting channel. Normally this would include the RTS and CTS queuing signals, but for this application, I have to disable them. Is it possible that no time is spent waiting here, if I have disabled the whole CSMA scheme on the hardware level? Depends. Regardless you'll need to monitor at the h/w level with an analyzer. propagation time - how long it takes to get to the receiver, once it has left our card You must monitor the medium unless sniffing for the ack is good enough. receive time - how long it takes for the receiving network card to get the message and notify the host that it has something to read. You need h/w monitoring. Am I going to have to put in hardware interrupts to time these events or are such tools already available? You need to expose the pci bus and use an analyzer for much of this. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nagios and threads
On Wed, 22 Jun 2005, I wrote: > Daniel Eischen wrote: > > On Tue, 21 Jun 2005, Michal Mertl wrote: > > > > > Dag-Erling Smrgrav wrote: > > > > Charles Sprickman <[EMAIL PROTECTED]> writes: > > > > > 1. FreeBSD and threads. On FreeBSD there's a native user-level > > > > > implementation of threads called 'pthread' and there's also an > > > > > optional ports collection 'linuxthreads' that uses kernel hooks. > > > > > > > > This is only the case for FreeBSD 4. FreeBSD 5 has native threads. > > > > > > Yes, the description on Nagios page is not precise but unfortunately > > > Nagios still has some problems even on 5.4. I wasn't able to find out > > > what was wrong and the problem dissappeared when I had to replace the > > > computer with single-processor one. The symptoms I observed were that > > > every several days one Nagios process was consuming all the CPU doing > > > hundreds of thousands of syscalls per second. It got always stuck around > > > the time when the the daily cron job run. > > > > > > I did a ktrace on the stuck process and tried to abort it to have the > > > core but I've lost the ktrace output and it never saved the core :-(. > > > > > > I'll install it on another machine and try to diagnose the problem some > > > more. > > > > You gotta try it on -stable. > > OK. I installed Nagios on a SMP computer with fresh -stable. I tried to > stress the disk but until now Nagios hasn't hung. > > Michal Just FYI - I really wasn't able to provoke the hang. I've no idea if the reason is my upgrade to STABLE or something else. I can only confirm what went on this thread - Nagios seems to have lots of short lived children (for the tests) which are probably created with fork and the main process is multithreaded. Michal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hot path optimizations in uma_zalloc() & uma_zfree()
> I ran ministat against your tests with 1000 sockets loop and there isn't a > lot > of difference in the user times: it was not supposed to be (the difference in the user times) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hot path optimizations in uma_zalloc() & uma_zfree()
> On Thursday 30 June 2005 10:35 am, Andriy Tkachuk wrote: > > I just checked the object code - you right, it almost the same: > > > > - bucket->ub_bucket[bucket->ub_cnt] = item; > > -22b9: 0f bf 43 08 movswl 0x8(%ebx),%eax > > -22bd: 8b 4d 0c mov0xc(%ebp),%ecx > > -22c0: 89 4c 83 0c mov%ecx,0xc(%ebx,%eax,4) > > - bucket->ub_cnt++; > > -22c4: 8d 42 01 lea0x1(%edx),%eax > > -22c7: 66 89 43 08 mov%ax,0x8(%ebx) > > + bucket->ub_bucket[bucket->ub_cnt++] = item; > > +22b9: 0f bf c2 movswl %dx,%eax > > +22bc: 8b 4d 0c mov0xc(%ebp),%ecx > > +22bf: 89 4c 83 0c mov%ecx,0xc(%ebx,%eax,4) > > +22c3: 8d 42 01 lea0x1(%edx),%eax > > +22c6: 66 89 43 08 mov%ax,0x8(%ebx) > > > > but still there is some minor difference in first line. > > I'm not familiar with assembler, can somebody explain > > whether this difference is assential or not? > > It just uses the stored value of the variable in %dx instead of loading it > from memory at 0x8(%ebx). When I compiled a simple test program here locally > I got identical object code though. Probaly this is the reason of throughput increasing. I want to note, that all tests where made on my home workstation. And each new test was made with new kernel just after rebooting in ttyv withoud X-server. I think the noise was not assential. Ministats against second & third optimization showed this results: (for different number of sockets created & destroyed in one iteration) > /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_1000 > sockloop_stat2_o2_sys_1000 x sockloop_stat2_o1_sys_1000 + sockloop_stat2_o2_sys_1000 +--+ |+ + + x x x| ||__A_||___M__A__| | +--+ N Min MaxMedian AvgStddev x 3 2.373 2.403 2.381 2.3856667 0.015534907 + 3 2.298 2.34 2.32 2.319 0.021007935 No difference proven at 99.5% confidence > /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_100 > sockloop_stat2_o2_sys_100 x sockloop_stat2_o1_sys_100 + sockloop_stat2_o2_sys_100 +--+ |+ + + xxx | | |___A__M___| |___AM_|| +--+ N Min MaxMedian AvgStddev x 3 2.158 2.182 2.174 2.171 0.012220202 + 3 2.062 2.126 2.102 2.097 0.032331615 No difference proven at 99.5% confidence > /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_10 > sockloop_stat2_o2_sys_10 x sockloop_stat2_o1_sys_10 + sockloop_stat2_o2_sys_10 +--+ | + | | + + x xx | ||_M_A| |A___M___|| +--+ N Min MaxMedian AvgStddev x 3 1.754 1.777 1.776 1.769 0.013 + 3 1.672 1.684 1.673 1.676 0.0066583281 Difference at 99.5% confidence -0.0926667 +/- 0.060488 -5.23836% +/- 3.41934% (Student's t, pooled s = 0.010328) > /usr/src/tools/tools/ministat/ministat -c 99.5 sockloop_stat2_o1_sys_1 > sockloop_stat2_o2_sys_1 x sockloop_stat2_o1_sys_1 + sockloop_stat2_o2_sys_1 +--+ |+ + +x x x| ||AM___| |M_A___| | +--+ N Min MaxMedian AvgStddev x 3 1.938 1.993 1.953 1.961 0.028431204 + 3 1.722 1.785 1.759 1.755 0.031659648 Difference at 99.5% confidence -0.206 +/- 0.176222 -10.5031% +/- 8.98479% (Student's t, pooled s = 0.0300888) and for default confidence (95%) this results: > /usr/src/tools/tools/ministat/ministat sockloop_stat2_o1_sys_1000 > sockloop_stat2_o2_sys_1000 x sockloop_stat2_o1_sys_1000
Re: hot path optimizations in uma_zalloc() & uma_zfree()
> if one will decide to commit first optimization (about buckets), > then there must some adjustments be made also > regarding correct statistics gathering. It seems that all is fine with statistics, i mistook. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ICH6R RAID
Hi! Thanks for the info. Thus to get ICH6R supported on 5.4 I need to load 5.4R onto one drive, apply the mk3 patch, recompile, reboot, build a release bootable CD, shutdown, reset the hardware to RAID1, and reload from the new CD. This ought to work like it does using 6.0-CURRENT-SNAP004 (which I am now happy with). The suggestion below to avoid sysinstall and craft the array by hand doesn't seem to use the hardware RAID1 supported by ICH6R. 1. How exactly do I know when a patch (mk3 in this case) is in a release? 2. If the above strategy makes sense, how can I get the latest mk3 for 5.4? 3. If I'm missing something, e.g. around sysinstall, what am I missing? (Sakurada-san suggested using atacontrol create.. to build ar0 with a degraded array (that I got to work), but if the above strategy works, I think this won't be necessary, unless again I'm missing something! 4. I'm leaning towards just using software RAID (gmirror) for this system, which must be a production system when it is up. Both 5.4 and 6.0 look hopeless for different reasons. Thoughts on this? Thanks for the help! -gayn > -Original Message- > From: "Dag-Erling Smørgrav" [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 30, 2005 4:03 AM > To: Gayn Winters > Cc: freebsd-hackers@freebsd.org > Subject: Re: ICH6R RAID > > > "Gayn Winters" <[EMAIL PROTECTED]> writes: > > Now man ata(4) indicates that only up to ICH5 is supported > in 5.4 while > > up to ICH6 is supported in 6.0, but the hardware archives > indicate that > > sos's MK3 patches made it into 5.4-RELEASE, and 6.0 "fully" > supports the > > ICH6R. However, I'm actually not sure the precise story here. > > 5.4 does not have MK3. > > > Has anyone out there actually booted FreeBSD using mirrored > SATA drives > > with an ICH6R? If so, how did you do it and what version > did you use? > > Nothing special. I started out with a hand-rolled bootable livecd of > -CURRENT with the MK3 patches when they first became available, and > did a manual install (no sysinstall, fdisk + disklabel + newfs + tar) > > DES > -- > Dag-Erling Smørgrav - [EMAIL PROTECTED] > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
