Re: power supplies
It seems Jim Bryant wrote: > Kent Stewart wrote: > > > There are problems with PSes when you use NICs with wake up > > capability. The NIC may exceed the capability of one of your low > > amperage voltages. > > How much current can wake-on-LAN take? I wouldn't think it would be enough to >overload a power supply unless it overloaded the -12V > line which is usually only rated in the mils. What is the average 12V rating? 5-8 >amps? and even more for 5V? I forget what the > average -5V line is rated. The problem is the +5 standby supply. In a modern ATX evironment lots of stuff pull power on that rail when the machine is switched off, and most ATX supplies only can delive .5-.7 amps here which can easily be overwhelmed. BTW you all know that you ATX machine use about 25W even when switched off right ? This gets into real money if you have a handfull of machines, and you get absolutly nothing for it :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
In message <[EMAIL PROTECTED]>, "Louis A. Mamakos" writes: >The paper that someone mentioned earlier in this thread had some >statistics on various classes of errors. In a nutshell, they put >packet sniffers on 4 different networks, and collected traffic. For >each back packet (where the checksum and ethernet CRC differed), they >then looked for retransmissions of the same data, and tried to characterize >the different failure modes they observed. > >It's very interesting reading. Absolutely. We have a pretty big FreeBSD concentration at one of my customers and I was actually considering running their collector (if I can get my hands on it) just to see what the error rate is... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
Jim Bryant wrote: > > Kent Stewart wrote: > > > There are problems with PSes when you use NICs with wake up > > capability. The NIC may exceed the capability of one of your low > > amperage voltages. > > > > Kent > > How much current can wake-on-LAN take? I wouldn't think it would be enough to >overload a power supply unless it overloaded the -12V > line which is usually only rated in the mils. What is the average 12V rating? 5-8 >amps? and even more for 5V? I forget what the > average -5V line is rated. I don't remember which one it is. The -12v sounds likely. It was the one in the milliamp range. The NICs came with a warning that the typical AT power supplies were insufficient. I haven't bought one in a box for quite a while and that was where I saw the warning. Kent > > jim > -- > ET has one helluva sense of humor! > He's always anal-probing right-wing schizos! > - > POWER TO THE PEOPLE! > - > "Religious fundamentalism is the biggest threat to > international security that exists today." > United Nations Secretary General B.B.Ghali > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] Carl Sagan quote on Seti@home http://setiathome.ssl.berkeley.edu/pale_blue_dot.html It is hard to believe you are soaring with Eagles (las águilas) when you accept SPAM like a mouse (el ratón). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
calling open() from inside kernel
ehlo. I'm creating a patch to kernel that requires to create a set of files; names of files are generated inside kernel, i.e., strings belong to kernel address space. Initially, I tried to use open(), but failed with EFAULT: open() expects filename string is in userspace, and passes UIO_USERSPACE to NDINIT. Well, I copied a portion of code from kern/vfs_syscalls, and it works fine. But, the length and complexity of the code is too far beyond I could expect from such a basic operation as file opening, and all this just because single string is in wrong space. So, is there any way to call open() in simple way? Something like remapping string into curproc space, or telling open() that string is not in userspace, or smth else? Or, may be, I do something completely wrong? I'm new in kernel programming. -- dozen @ home To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
Kent Stewart wrote: > There are problems with PSes when you use NICs with wake up > capability. The NIC may exceed the capability of one of your low > amperage voltages. > > Kent How much current can wake-on-LAN take? I wouldn't think it would be enough to overload a power supply unless it overloaded the -12V line which is usually only rated in the mils. What is the average 12V rating? 5-8 amps? and even more for 5V? I forget what the average -5V line is rated. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - "Religious fundamentalism is the biggest threat to international security that exists today." United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Dan Nelson wrote: > > Something to do would be to enable hardware checksumming on 1/2 your > machines, and compare the bad packet counts at reported by netstat on > the unchanged machines for (say) a 1-month period before and after the > change. That should tell you whether you're gaining or losing > reliability. It'll be really easy for me, as my current (software > cksum) stats show no errors at all: the trouble is that if you are trying to find errors between RAM and WIRE then the checksums will be correct regardless of whether there is an error.. so the counts you are checking would be no use.. you need to know what the correct packet contents should be.. > -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
In the last episode (Sep 27), Louis A. Mamakos said: > And I don't disagree with you, it's wonderful work. > > What I guess I'm trying to get across is that like any tool, it ought to > be used properly and in an informed way. For instance, you can mount a > file system async or with soft updates, and each of these choices have > their own trade-offs. > > Folks ought to consider the likelyhood of this class of data > corruption, unlikely as it is, and weigh it along with the impact on > your application, and the differences in performance and loading. Something to do would be to enable hardware checksumming on 1/2 your machines, and compare the bad packet counts at reported by netstat on the unchanged machines for (say) a 1-month period before and after the change. That should tell you whether you're gaining or losing reliability. It'll be really easy for me, as my current (software cksum) stats show no errors at all: 11:41PM up 11 days, 11:17, 18 users, load averages: 0.08, 0.04, 0.01 Name Mtu NetworkAddressIpkts IerrsOpkts Oerrs Coll ti0 1500 00:02:e3:00:17:00 510130554 0 624290928 0 0 tcp: 300848337 packets received 0 discarded for bad checksums udp: 127972686 datagrams received 0 with bad checksum ip: 26765 total packets received 0 bad header checksums Each counter has probably rolled over at least 5 times (I have to ask, why aren't these 64 bit counters?) -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> On Thu, 27 Sep 2001, Andrew Gallatin wrote: > > > Geez. All I wanted to do was pat Jonathan on the back for coming up > > with what is apparently the most flexible and well though out > > mechanism out there. > > it's great work. I was mainly curious to see if anyone had measured this > kind of problem. > > Thanks The paper that someone mentioned earlier in this thread had some statistics on various classes of errors. In a nutshell, they put packet sniffers on 4 different networks, and collected traffic. For each back packet (where the checksum and ethernet CRC differed), they then looked for retransmissions of the same data, and tried to characterize the different failure modes they observed. It's very interesting reading. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
no, it worked when i put it in a different machine that was exactly the same. On Thu, 27 Sep 2001, Kris Kennaway wrote: > Date: Thu, 27 Sep 2001 19:59:05 -0700 > From: Kris Kennaway <[EMAIL PROTECTED]> > To: Dan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: power supplies > > On Thu, Sep 27, 2001 at 08:04:40PM -0700, Dan wrote: > > > > ya but even putting the old nic back in the machine does not still boot > > up. I don't think this has to do with the nic but you never know. > > fxp1: > > You overloaded and burned out the power supply? > > Kris > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
On Thu, Sep 27, 2001 at 08:04:40PM -0700, Dan wrote: > > ya but even putting the old nic back in the machine does not still boot > up. I don't think this has to do with the nic but you never know. > fxp1: You overloaded and burned out the power supply? Kris msg28792/pgp0.pgp Description: PGP signature
Re: power supplies
ya but even putting the old nic back in the machine does not still boot up. I don't think this has to do with the nic but you never know. fxp1: On Thu, 27 Sep 2001, Kent Stewart wrote: > Date: Thu, 27 Sep 2001 19:38:55 -0700 > From: Kent Stewart <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: Dan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: power supplies > > > > Dan wrote: > > > > I had the stangest situation today where a new nic card was put into a > > machine and then the machine did not start up. Placed the old nic card > > back in the box and it still did not start up. Switched power supplies > > with an exactly equal box and both machine booted up fine. This has > > happened twice since we started replacing nic cards today with ones with > > more buffer space available on them out of about 8 machines now. > > > > Does this make any sense to anyone? > > There are problems with PSes when you use NICs with wake up > capability. The NIC may exceed the capability of one of your low > amperage voltages. > > Kent > > > > > -- > > Dan > > > > +--+ > > | BRAVENET WEB SERVICES | > > | [EMAIL PROTECTED] | > > | screen;cd /usr/src;make buildworld;cd ~ | > > | cp MYKERNEL /sys/i386/conf;cd /usr/src | > > |make buildkernel KERNCONF=MYKERNEL| > > |make installkernel KERNCONF=MYKERNEL;make installworld| > > +__+ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Kent Stewart > Richland, WA > > mailto:[EMAIL PROTECTED] > http://kstewart.urx.com/kstewart/index.html > FreeBSD News http://daily.daemonnews.org/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: power supplies
Dan wrote: > > I had the stangest situation today where a new nic card was put into a > machine and then the machine did not start up. Placed the old nic card > back in the box and it still did not start up. Switched power supplies > with an exactly equal box and both machine booted up fine. This has > happened twice since we started replacing nic cards today with ones with > more buffer space available on them out of about 8 machines now. > > Does this make any sense to anyone? There are problems with PSes when you use NICs with wake up capability. The NIC may exceed the capability of one of your low amperage voltages. Kent > > -- > Dan > > +--+ > | BRAVENET WEB SERVICES | > | [EMAIL PROTECTED] | > | screen;cd /usr/src;make buildworld;cd ~ | > | cp MYKERNEL /sys/i386/conf;cd /usr/src | > |make buildkernel KERNCONF=MYKERNEL| > |make installkernel KERNCONF=MYKERNEL;make installworld| > +__+ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: power supplies
On 28-Sep-2001 Dan wrote: > > I had the stangest situation today where a new nic card was put into a > machine and then the machine did not start up. Placed the old nic card > back in the box and it still did not start up. Switched power supplies > with an exactly equal box and both machine booted up fine. This has > happened twice since we started replacing nic cards today with ones with > more buffer space available on them out of about 8 machines now. > > Does this make any sense to anyone? The PSU might have just been on the border of delivering enough current.. I have found slightly over spec'ing the PSU is a good idea when using a UPS, because if another device powered by the UPS draws a big load the computer tends to reset :( (250w vs 300w) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
power supplies
I had the stangest situation today where a new nic card was put into a machine and then the machine did not start up. Placed the old nic card back in the box and it still did not start up. Switched power supplies with an exactly equal box and both machine booted up fine. This has happened twice since we started replacing nic cards today with ones with more buffer space available on them out of about 8 machines now. Does this make any sense to anyone? -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ng_bridge
BRIDGE/DUMMYNET/net.link.ether.bridge=1/net.link.ether.bridge_ipfw=1 is one set of bridging code ng_bridge is a completely separate (in my opinion, better, but I'm biased) setr of code. they might interract if you turn them both on at the same time On Thu, 27 Sep 2001, Robert Hough wrote: > On Thu, Sep 27, 2001, Julian Elischer wrote: > > > well, maybe if you told us what you modified, and what happenned. > > $ diff /usr/share/examples/netgraph/ether.bridge ~/eth_bridge.sh > 41,42c41,42 > < BRIDGE_IFACES="ed0 fxp0 fxp1" > < LOCAL_IFACE="fxp0" > --- > > BRIDGE_IFACES="vx0 vx1" > > LOCAL_IFACE="" > > As far as what happened, it basically made everything connected to that > hub unreachable by everything else. Other settings are to follow: > > > # kernel config > options BRIDGE > options DUMMYNET > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > > # /etc/sysctl.conf > net.link.ether.bridge=1 > net.link.ether.bridge_ipfw=1 > > No interface was configured with an IP address on the box at the time. > The only ipfirewall rule in use was the default_accept. Thanks. > > -- > Robert Hough ([EMAIL PROTECTED]) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ng_bridge
On Thu, Sep 27, 2001, Julian Elischer wrote: > well, maybe if you told us what you modified, and what happenned. $ diff /usr/share/examples/netgraph/ether.bridge ~/eth_bridge.sh 41,42c41,42 < BRIDGE_IFACES="ed0 fxp0 fxp1" < LOCAL_IFACE="fxp0" --- > BRIDGE_IFACES="vx0 vx1" > LOCAL_IFACE="" As far as what happened, it basically made everything connected to that hub unreachable by everything else. Other settings are to follow: # kernel config options BRIDGE options DUMMYNET options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT # /etc/sysctl.conf net.link.ether.bridge=1 net.link.ether.bridge_ipfw=1 No interface was configured with an IP address on the box at the time. The only ipfirewall rule in use was the default_accept. Thanks. -- Robert Hough ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ng_bridge
well, maybe if you told us what you modified, and what happenned. On Thu, 27 Sep 2001, Robert Hough wrote: > Yesterday, I used a script on my bridge that pretty much brought down > the entire network segment it was connected to. The script in question, > was found in /usr/share/examples/netgraph -- called 'ether.bridge'. I > modified the script, and ran it -- boom. Problems galore! > > At the time, the bridge did *not* function correctly. I was using a > couple of cards that didn't support bridging. I have since corrected > this, and on a smaller network repeated the same steps. This time, > everything is working correctly. > > My question, is really this. Does anyone have an idea as to why this > caused so much trouble to begin with, and how can I protect my network > from allowing this to happen again? > > -- > Robert Hough ([EMAIL PROTECTED]) > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ng_bridge
Yesterday, I used a script on my bridge that pretty much brought down the entire network segment it was connected to. The script in question, was found in /usr/share/examples/netgraph -- called 'ether.bridge'. I modified the script, and ran it -- boom. Problems galore! At the time, the bridge did *not* function correctly. I was using a couple of cards that didn't support bridging. I have since corrected this, and on a smaller network repeated the same steps. This time, everything is working correctly. My question, is really this. Does anyone have an idea as to why this caused so much trouble to begin with, and how can I protect my network from allowing this to happen again? -- Robert Hough ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more on Re: Please review: bugfix for vinvalbuf()
I totally forgot about that one. Your fix looks good, I'll start testing
it.
The bigger picture here is that vinvalbuf() is not typically called
while a vnode is still active. NFS calls it on active vnodes in order
to invalidate the cache when the client detects that the file mtime
has been changed by someone else (ugly ugly ugly). So this sort of
crash can occur if one client is mmap()ing a file another another
client (or the server) writes to the file.
-Matt
:I recently mentioned on freebsd-stable in message
:
: <[EMAIL PROTECTED]>
:
:a recurring rslock panic which I believe has been caused by the below
:mentioned problem in vinvalbuf(). I have worked up a patch for -STABLE
:(which should also apply to -CURRENT if there have not been major changes
:to this code). The patch is appended to this message for review.
:
:Data from the crash dump revealed the following:
:
:SMP 2 cpus
:IdlePTD 3555328
:initial pcb at 2cf280
:panicstr: rslock: cpu: 0, addr: 0xd7be66ec, lock: 0x0001
:panic messages:
:---
:panic: rslock: cpu: 0, addr: 0xd7be66ec, lock: 0x0001
:mp_lock = 0001; cpuid = 0; lapic.id = 0100
:boot() called on cpu#0
:
:---
:
:#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473
:#1 0xc016cf8f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:313
:#2 0xc016d3a9 in panic (fmt=0xc025bcce "rslock: cpu: %d, addr: 0x%08x, lock: 0x%08x")
:at /usr/src/sys/kern/kern_shutdown.c:581
:#3 0xc025bcce in bsl1 ()
:#4 0xc021eeac in _unlock_things (fs=0xd7a6dec4, dealloc=0)
:at /usr/src/sys/vm/vm_fault.c:147
:#5 0xc021f8c7 in vm_fault (map=0xd7a6bf40, vaddr=673968128, fault_type=1 '\001',
: fault_flags=0) at /usr/src/sys/vm/vm_fault.c:826
:#6 0xc025d016 in trap_pfault (frame=0xd7a6dfa8, usermode=1, eva=673972223)
:at /usr/src/sys/i386/i386/trap.c:829
:#7 0xc025ca8b in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 99049,
: tf_esi = 0, tf_ebp = -1077937884, tf_isp = -676929580, tf_ebx = 48110729,
: tf_edx = 0, tf_ecx = 1835007, tf_eax = 672137216, tf_trapno = 12, tf_err = 4,
: tf_eip = 134517190, tf_cs = 31, tf_eflags = 66070, tf_esp = -1077937940,
: tf_ss = 47})
:at /usr/src/sys/i386/i386/trap.c:359
:#8 0x80491c6 in ?? ()
:#9 0x8048d9e in ?? ()
:#10 0x804a078 in ?? ()
:#11 0x8048b45 in ?? ()
:
:---
:
:A quick review of processes revealed a process stuck in vmopar:
:
:(kgdb) ps
:...
:46479 d7ffc560 d806e000 235886 1 46394 004006 3 tail vmopar c09120c8
:...
:
:which was sleeping in vm_object_page_remove() in vinvalbuf():
:
:(kgdb) btp 46479
: frame 0 at 0xd806fc8c: ebp d806fcb8, eip 0xc0170051 : mov
:0x141(%ebx),%al
: frame 1 at 0xd806fcb8: ebp d806fce0, eip 0xc02262e8 :
: add$0x10,%esp
: frame 2 at 0xd806fce0: ebp d806fd2c, eip 0xc019a667 : add
:$0x10,%esp
: frame 3 at 0xd806fd2c: ebp d806fd60, eip 0xc01d0aa0 : add
: $0x18,%esp
: frame 4 at 0xd806fd60: ebp d806fe2c, eip 0xc01cf5d8 : mov
:%eax,0xff74(%ebp)
: frame 5 at 0xd806fe2c: ebp d806fe44, eip 0xc01f6842 : jmp
:0xc01f6849
: frame 6 at 0xd806fe44: ebp d806fe78, eip 0xc01a22cc : mov
:%eax,0xffe8(%ebp)
: frame 7 at 0xd806fe78: ebp d806fef4, eip 0xc017b690 : mov
:%eax,%esi
: frame 8 at 0xd806fef4: ebp d806ff28, eip 0xc017b556 : mov%eax,%esi
: frame 9 at 0xd806ff28: ebp d806ffa0, eip 0xc025d745 :mov
:%eax,0xffb8(%ebp)
:
:
:The patch is below, against vfs_subr.c 1.249.2.11 2001/09/11
:
:--- vfs_subr.c Tue Sep 11 04:49:53 2001
:+++ vfs_subr.c.new Wed Sep 26 15:23:09 2001
:@@ -721,9 +721,9 @@
: }
: }
:
:- while (vp->v_numoutput > 0) {
:- vp->v_flag |= VBWAIT;
:- tsleep(&vp->v_numoutput, PVM, "vnvlbv", 0);
:+ if (VOP_GETVOBJECT(vp, &object) == 0) {
:+ while (object->paging_in_progress)
:+ vm_object_pip_sleep(object, "vnvlbv");
: }
:
: splx(s);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Conclusions on... was Re: More on the cache_purgeleafdirs() routine
: :On Sunday, 23rd September 2001, Poul-Henning Kamp wrote: : :>Things to look out for: :> :>1. !ufs filesystems : :I am irredeemably slack for not testing this a lot but... : :I believe I saw bad interactions between vmiodirenable and isofs on 4.3-R. : :I mounted a CD, looked at stuff on it, did a lot of other work, went back :to the CD and files were screwy (files contained the contents of other :files, files were zero size). I unmounted and remounted the CD and :everything was fine. The machine is a reliable old workhorse, and has :no hardware errors. : :Since then, I've not had a chance to go back and check. It's only because :you are making vmiodirenable the default that I'm mentioning it. Sorry :for not making a proper bug report containing actual facts. :-( : :Stephen. Hmm. Well, if someone can reproduce the problem it sounds like it ought to be easy to track down. I am somewhat skeptical that vmiodirenable could cause that but I suppose it's possible. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Cash Prizes Win!
To all our fans!! Welsh Fantasy Football has paid your entrance fee to the WELSH FANTASY FOOTBALL GAME 2001 Go to www.welshfantasyfootball.com you have to be in it to WIN it!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Cash Prizes Win!
To all our fans!! Welsh Fantasy Football has paid your entrance fee to the WELSH FANTASY FOOTBALL GAME 2001 Go to www.welshfantasyfootball.com you have to be in it to WIN it!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
closing down the squid22/23 ports?
Hi all, Pardon the cross-posting. :-) I'd like to look at closing down / making inactive the squid22 and squid23 ports. The squid-2.2 and squid-2.3 codebases have been inactive and largely unsupported by the squid developers (read: myself inclusive here) for some time now, and I'd like to point users at the actively developed/maintained squid branch. Squid-2.5 is also in the pipeline for release soon, and I don't think there is a point in having 4 squid ports. What do people think? (please CC me, I'm currently not on the ports/hackers list for various time-related reasons..) Thanks! Adrian -- Adrian Chadd"Programming is like sex: <[EMAIL PROTECTED]> One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: > Geez. All I wanted to do was pat Jonathan on the back for coming up > with what is apparently the most flexible and well though out > mechanism out there. it's great work. I was mainly curious to see if anyone had measured this kind of problem. Thanks ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Louis A. Mamakos writes: > > Folks ought to consider the likelyhood of this class of data > corruption, unlikely as it is, and weigh it along with the impact on > your application, and the differences in performance and loading. > Agreed. Very well said, by the way.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> > Louis A. Mamakos writes: > > > I was referring to the case on the transmit side where the wrong > > data get's gathered up by the DMA engine because of software related > > errors. You get a valid checksum, but for the wrong data. You might > > have the wrong data because a drive screwed up setting the DMA descriptors, > > or some other I/O transfer splatted over the buffer waiting in a > > transmit queue. > > What happens if that same i/o transfer splatted over the buffer > waiting in user space prior to the copyin, or sitting in > the socket buffer prior to a software checksum being done? > Software checksums are not quite the panacea you make them out to be. > And they're very expensive. > > Geez. All I wanted to do was pat Jonathan on the back for coming up > with what is apparently the most flexible and well though out > mechanism out there. And I don't disagree with you, it's wonderful work. What I guess I'm trying to get across is that like any tool, it ought to be used properly and in an informed way. For instance, you can mount a file system async or with soft updates, and each of these choices have their own trade-offs. Folks ought to consider the likelyhood of this class of data corruption, unlikely as it is, and weigh it along with the impact on your application, and the differences in performance and loading. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Louis A. Mamakos writes: > I was referring to the case on the transmit side where the wrong > data get's gathered up by the DMA engine because of software related > errors. You get a valid checksum, but for the wrong data. You might > have the wrong data because a drive screwed up setting the DMA descriptors, > or some other I/O transfer splatted over the buffer waiting in a > transmit queue. What happens if that same i/o transfer splatted over the buffer waiting in user space prior to the copyin, or sitting in the socket buffer prior to a software checksum being done? Software checksums are not quite the panacea you make them out to be. And they're very expensive. Geez. All I wanted to do was pat Jonathan on the back for coming up with what is apparently the most flexible and well though out mechanism out there. These issues have been argued to death; I don't feel like arguing with you. I'm satisified that I'm not going to convince you & you're not going to convince me. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> > Louis A. Mamakos writes: > > The other type of failure you might not catch are software errors; that > > is, where a packet is produced by the network stack and then is > > subsequently stomped on by a random store from some other code. Or > > a mis-programmed I/O card with scatter/gather capability doesn't pick > > up what was intended, etc. The Internet checksum is useful for > > detecting this class of error. > > > > No, you're missing the point almost entirely. The checksum is not > skipped. It is calculated by the DMA engine based on the data that's > transferred across the I/O bus on the receiver (and / or the sender). > If the data is incorrect as seen by the receiving nic, the checksum > will be wrong and the packet will be dropped. I was referring to the case on the transmit side where the wrong data get's gathered up by the DMA engine because of software related errors. You get a valid checksum, but for the wrong data. You might have the wrong data because a drive screwed up setting the DMA descriptors, or some other I/O transfer splatted over the buffer waiting in a transmit queue. > If the packet lands in the wrong place, you have much worse problems. Sure you do; a software checksum at least gives you an opportunity to detect these failures. While these are improbable failures, I know that I've experienced the class I described in my years of hacking on network platforms, and Ron has experienced the one he described. These are not impossible occurances; it's a matter of weighing the additional cost of the software checksum vs. the likelyhood (and cost/impact) of undetected corruption of the data. If you're running IPSEC or SSL up above all this, there's another mechanism to detect these types of failures. I just think back 10 or 15 years at the impact of Sun's decision to not compute UDP checksums on their NFS traffic, because the network adapter had a much stronger Ethernet CRC. It was a trade-off not worth making even then, with CPUs in the single-digit MIPS performance. We ought to at least consider the previous experience. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Ronald G Minnich writes: > On Thu, 27 Sep 2001, Andrew Gallatin wrote: > > > At this level, you're basically screwed. A sofware checksum isn't > > even an option on other PCI users, like disk controllers. If you > > don't trust your PCI chipset, what do you do about things like that? > > > > I'm rather curious -- what was the problematic hardware combination? > > Can't say yet :-( > > But it is one of the fancy network interfaces that essentially runs an > RTOS on the NIC so it can "help you". Actually fancy $5000 network > interfaces are in general less reliable than your average garden-variety > $2 IDE chip. Partly because they have so much capability. > > So we don't worry a lot about lossage with IDE. But it's a big problem on > expensive, high end, high performance network interfaces. But SCSI isn't immune either. We had some data corruption problems with early adaptec Ultra-2 scsi controllers too, before Justin fixed it by working around it in the driver. Basically, anything that uses a PCI chipset harder or in different ways than its designers expected can end up being a problem. Low volume hardware is somtimes worse, but not always... Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Oh, yeah- I forgot about this. Jonathon is a pretty good NetBSD hacker.. On Thu, 27 Sep 2001, Sandeep Joshi wrote: > > Ron, > > This may be of interest... > > http://citeseer.nj.nec.com/stone00when.html > > When The CRC and TCP Checksum Disagree > Jonathan Stone, Craig Partridge SIGCOMM > > -Sandeep > > On Thu, 27 Sep 2001, Ronald G Minnich wrote: > > > > I have a question on the checksum offloading. Has anyone measured any > > incidence of data corruption between the PCI card and memory. In other > > words, when you offload checksums the end-to-end checking becomes > > card-to-card checking, and the possibility exists that what goes in memory > > at the destination end is not what was sent at the source. Very remote > > possibility, of course, but ... > > > > It's not that the data gets corrupted (usually). It's that > > once-in-a-100-trillion errors could result in the occasional dropped > > half-packet or missed word (i.e. overflow). The missed word problem is > > usual a miscommunication between card and PCI chipset about how a PCI > > ABORT is supposed to work ... which we've seen on some very recent > > just-released chipset/network card combinations,. > > > > Does this happen? Yes. We've seen it on, to name just two, HIPPI800 and > > Myrinet cards. In each case it was not actual data corruption, it was > > "can't happen" DMA scenarios that once in a very long while (1 in 10^14 or > > so) resulted in bits of packets getting corrupted. Each of these cards > > has a very high-quality end-end CRC for the data, and Myrinet has flow > > control. We're not the only place that has seen this problem, and I've > > been told that many commerical Myrinet clients run IP over Myrinet because > > of these types of problems (of course FreeBSD has the fastest IP over > > Myrinet anyway, so it's not like that's a huge problem). > > > > Is it likely? Well, on one cluster here, with 48 machines and 12 > > interfaces per machine, it's not only likely, it's a given. Without > > software checksums you are going to get data corruption. > > > > What I don't know is whether offloaded checksums on commodity ethernet > > cards have seen anything similar. > > > > I assume that checksums across all the frags are done by the kernel (i.e. > > NFS would checksum the full UDP packet)? Has anyone measured to see if > > there is corruption occuring on the frags, ever? Of course it would > > probably take a while ... > > > > Thanks in advance for any information you might have. > > > > ron > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: > At this level, you're basically screwed. A sofware checksum isn't > even an option on other PCI users, like disk controllers. If you > don't trust your PCI chipset, what do you do about things like that? > > I'm rather curious -- what was the problematic hardware combination? Can't say yet :-( But it is one of the fancy network interfaces that essentially runs an RTOS on the NIC so it can "help you". Actually fancy $5000 network interfaces are in general less reliable than your average garden-variety $2 IDE chip. Partly because they have so much capability. So we don't worry a lot about lossage with IDE. But it's a big problem on expensive, high end, high performance network interfaces. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Ron, This may be of interest... http://citeseer.nj.nec.com/stone00when.html When The CRC and TCP Checksum Disagree Jonathan Stone, Craig Partridge SIGCOMM -Sandeep On Thu, 27 Sep 2001, Ronald G Minnich wrote: > > I have a question on the checksum offloading. Has anyone measured any > incidence of data corruption between the PCI card and memory. In other > words, when you offload checksums the end-to-end checking becomes > card-to-card checking, and the possibility exists that what goes in memory > at the destination end is not what was sent at the source. Very remote > possibility, of course, but ... > > It's not that the data gets corrupted (usually). It's that > once-in-a-100-trillion errors could result in the occasional dropped > half-packet or missed word (i.e. overflow). The missed word problem is > usual a miscommunication between card and PCI chipset about how a PCI > ABORT is supposed to work ... which we've seen on some very recent > just-released chipset/network card combinations,. > > Does this happen? Yes. We've seen it on, to name just two, HIPPI800 and > Myrinet cards. In each case it was not actual data corruption, it was > "can't happen" DMA scenarios that once in a very long while (1 in 10^14 or > so) resulted in bits of packets getting corrupted. Each of these cards > has a very high-quality end-end CRC for the data, and Myrinet has flow > control. We're not the only place that has seen this problem, and I've > been told that many commerical Myrinet clients run IP over Myrinet because > of these types of problems (of course FreeBSD has the fastest IP over > Myrinet anyway, so it's not like that's a huge problem). > > Is it likely? Well, on one cluster here, with 48 machines and 12 > interfaces per machine, it's not only likely, it's a given. Without > software checksums you are going to get data corruption. > > What I don't know is whether offloaded checksums on commodity ethernet > cards have seen anything similar. > > I assume that checksums across all the frags are done by the kernel (i.e. > NFS would checksum the full UDP packet)? Has anyone measured to see if > there is corruption occuring on the frags, ever? Of course it would > probably take a while ... > > Thanks in advance for any information you might have. > > ron > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Ronald G Minnich writes: > > you still have a potential problem here with variance in chipsets, namely > the case of broken ABORT or other unusual PCI cycle handling (missed word > problem). I agree it's a low probability. But we've seen it, just a week > or two ago on a brand new box. > > But then we tend to see things here nobody else sees due to our scale. > > ron At this level, you're basically screwed. A sofware checksum isn't even an option on other PCI users, like disk controllers. If you don't trust your PCI chipset, what do you do about things like that? I'm rather curious -- what was the problematic hardware combination? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
It certainly occurs at a rate to worry one. Alan Poston found definite cases of corruption when doing heavy IDE testing. It varies, motherboard to motherboard. On Thu, 27 Sep 2001, Ronald G Minnich wrote: > On Thu, 27 Sep 2001, Andrew Gallatin wrote: > > > I just wanted to say that you did a hell of a job with the csum > > offload stuff in FreeBSD. FreeBSD is the only OS that I'm aware of > > which allows a driver to choose not to handle csum'ing IP frags on > > transmit. Having the option to not handle frags is very, very handy. > > I wish other platforms had it. > > I have a question on the checksum offloading. Has anyone measured any > incidence of data corruption between the PCI card and memory. In other > words, when you offload checksums the end-to-end checking becomes > card-to-card checking, and the possibility exists that what goes in memory > at the destination end is not what was sent at the source. Very remote > possibility, of course, but ... > > It's not that the data gets corrupted (usually). It's that > once-in-a-100-trillion errors could result in the occasional dropped > half-packet or missed word (i.e. overflow). The missed word problem is > usual a miscommunication between card and PCI chipset about how a PCI > ABORT is supposed to work ... which we've seen on some very recent > just-released chipset/network card combinations,. > > Does this happen? Yes. We've seen it on, to name just two, HIPPI800 and > Myrinet cards. In each case it was not actual data corruption, it was > "can't happen" DMA scenarios that once in a very long while (1 in 10^14 or > so) resulted in bits of packets getting corrupted. Each of these cards > has a very high-quality end-end CRC for the data, and Myrinet has flow > control. We're not the only place that has seen this problem, and I've > been told that many commerical Myrinet clients run IP over Myrinet because > of these types of problems (of course FreeBSD has the fastest IP over > Myrinet anyway, so it's not like that's a huge problem). > > Is it likely? Well, on one cluster here, with 48 machines and 12 > interfaces per machine, it's not only likely, it's a given. Without > software checksums you are going to get data corruption. > > What I don't know is whether offloaded checksums on commodity ethernet > cards have seen anything similar. > > I assume that checksums across all the frags are done by the kernel (i.e. > NFS would checksum the full UDP packet)? Has anyone measured to see if > there is corruption occuring on the frags, ever? Of course it would > probably take a while ... > > Thanks in advance for any information you might have. > > ron > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: > No, you're missing the point almost entirely. The checksum is not > skipped. It is calculated by the DMA engine based on the data that's > transferred across the I/O bus on the receiver (and / or the sender). > If the data is incorrect as seen by the receiving nic, the checksum > will be wrong and the packet will be dropped. you still have a potential problem here with variance in chipsets, namely the case of broken ABORT or other unusual PCI cycle handling (missed word problem). I agree it's a low probability. But we've seen it, just a week or two ago on a brand new box. But then we tend to see things here nobody else sees due to our scale. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Planet
On Thu, Sep 27, 2001 at 04:44:31PM +0200, Martin Vana wrote: > Hi, I tried to rebuilt my kernel with device rl0 (NIC PLANET ENW-9503A based on >REALTEK 8139 chip) it has collapsed during make phase. It cannot find files starting >with mii* but they are present. Is it that it cannot find the files, or functions from those files? If it's functions that it cannot find, try adding 'device miibus' to your kernel, like the comments in LINT say (rl is listed under 'PCI Ethernet NICs that use the common MII bus controller code'). If it is the files themselves - are you sure you have re-run config(8) after changing your kernel configuration file? To be absolutely certain, run config with the -r flag to remove any old directories. To be *really* certain, use the buildworld/buildkernel way. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Planet
Hi, I tried to rebuilt my kernel with device rl0 (NIC PLANET ENW-9503A based on REALTEK 8139 chip) it has collapsed during make phase. It cannot find files starting with mii* but they are present. Thank you Im runnign FreeBSD 4.4(Amnesiac)
Planet
Hi, I tried to rebuilt my kernel with device rl0 (NIC PLANET ENW-9503A based on REALTEK 8139 chip) it has collapsed during make phase. It cannot find files starting with mii* but they are present. Thank you Im runnign FreeBSD 4.4(Amnesiac)
Re: TCP&IP cksum offload on FreeBSD 4.2
Louis A. Mamakos writes: > The other type of failure you might not catch are software errors; that > is, where a packet is produced by the network stack and then is > subsequently stomped on by a random store from some other code. Or > a mis-programmed I/O card with scatter/gather capability doesn't pick > up what was intended, etc. The Internet checksum is useful for > detecting this class of error. > No, you're missing the point almost entirely. The checksum is not skipped. It is calculated by the DMA engine based on the data that's transferred across the I/O bus on the receiver (and / or the sender). If the data is incorrect as seen by the receiving nic, the checksum will be wrong and the packet will be dropped. If the packet lands in the wrong place, you have much worse problems. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
Ronald G Minnich writes: > I have a question on the checksum offloading. Has anyone measured any > incidence of data corruption between the PCI card and memory. In other > words, when you offload checksums the end-to-end checking becomes > card-to-card checking, and the possibility exists that what goes in memory > at the destination end is not what was sent at the source. Very remote > possibility, of course, but ... We used to see occasional data corruption at Duke with 440BX based motherboards with non-ecc ram. We never saw it on higher-quality hosts (alphas or serverworks based pc motherboards) with ecc memory. It would manifest itself as bad TCP checksums (no csum offload at the time). > of these types of problems (of course FreeBSD has the fastest IP over > Myrinet anyway, so it's not like that's a huge problem). > Not any more. A 2.4 linux kernel will do a bit better than FreeBSD on an SMP box because it is able to use both processors. Speaking of which -- who is working on making the network stack SMP capable in -current? Anything I can do to help? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
The other type of failure you might not catch are software errors; that is, where a packet is produced by the network stack and then is subsequently stomped on by a random store from some other code. Or a mis-programmed I/O card with scatter/gather capability doesn't pick up what was intended, etc. The Internet checksum is useful for detecting this class of error. Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Conclusions on... was Re: More on the cache_purgeleafdirs() routine
On Sunday, 23rd September 2001, Poul-Henning Kamp wrote: >Things to look out for: > >1. !ufs filesystems I am irredeemably slack for not testing this a lot but... I believe I saw bad interactions between vmiodirenable and isofs on 4.3-R. I mounted a CD, looked at stuff on it, did a lot of other work, went back to the CD and files were screwy (files contained the contents of other files, files were zero size). I unmounted and remounted the CD and everything was fine. The machine is a reliable old workhorse, and has no hardware errors. Since then, I've not had a chance to go back and check. It's only because you are making vmiodirenable the default that I'm mentioning it. Sorry for not making a proper bug report containing actual facts. :-( Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: arcnet support for FreeBSD (request for review)
> On Wed, Sep 26, 2001 at 12:59:01PM -0500, mark tinguely wrote: > > > There is nothing like raising a topic that was last seen several months > > ago, but ... > > > > Has there been any serious consideration to committing the arcnet code > > that mentioned on 20 Jul 2001 (http://iclub.nsu.ru/~fjoe/arcnet/)? > > yes, I am working on this I noticed that the hooks for the netgraph and BRIDGE code is missing. I guess this is why I would like to see it committed so that there is not a constant catchup of new features. I also noticed that the outputed packet get bpf_mtap in two places, once for the complete packet arc_output(), and again in the outputting of the fragments (in the device driver). I wonder if the bpf_mtap in the arc_output() should be removed. I am not able to test yet, but I am willing to help. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: > I just wanted to say that you did a hell of a job with the csum > offload stuff in FreeBSD. FreeBSD is the only OS that I'm aware of > which allows a driver to choose not to handle csum'ing IP frags on > transmit. Having the option to not handle frags is very, very handy. > I wish other platforms had it. I have a question on the checksum offloading. Has anyone measured any incidence of data corruption between the PCI card and memory. In other words, when you offload checksums the end-to-end checking becomes card-to-card checking, and the possibility exists that what goes in memory at the destination end is not what was sent at the source. Very remote possibility, of course, but ... It's not that the data gets corrupted (usually). It's that once-in-a-100-trillion errors could result in the occasional dropped half-packet or missed word (i.e. overflow). The missed word problem is usual a miscommunication between card and PCI chipset about how a PCI ABORT is supposed to work ... which we've seen on some very recent just-released chipset/network card combinations,. Does this happen? Yes. We've seen it on, to name just two, HIPPI800 and Myrinet cards. In each case it was not actual data corruption, it was "can't happen" DMA scenarios that once in a very long while (1 in 10^14 or so) resulted in bits of packets getting corrupted. Each of these cards has a very high-quality end-end CRC for the data, and Myrinet has flow control. We're not the only place that has seen this problem, and I've been told that many commerical Myrinet clients run IP over Myrinet because of these types of problems (of course FreeBSD has the fastest IP over Myrinet anyway, so it's not like that's a huge problem). Is it likely? Well, on one cluster here, with 48 machines and 12 interfaces per machine, it's not only likely, it's a given. Without software checksums you are going to get data corruption. What I don't know is whether offloaded checksums on commodity ethernet cards have seen anything similar. I assume that checksums across all the frags are done by the kernel (i.e. NFS would checksum the full UDP packet)? Has anyone measured to see if there is corruption occuring on the frags, ever? Of course it would probably take a while ... Thanks in advance for any information you might have. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: arcnet support for FreeBSD (request for review)
hi, there! On Wed, Sep 26, 2001 at 12:59:01PM -0500, mark tinguely wrote: > There is nothing like raising a topic that was last seen several months > ago, but ... > > Has there been any serious consideration to committing the arcnet code > that mentioned on 20 Jul 2001 (http://iclub.nsu.ru/~fjoe/arcnet/)? yes, I am working on this /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
