L. V. Lammert wrote:
> Had a NIC fail last Monday at a remote site, after a local storm. We have 
> had problems with this site before - apparently the building was built on 
> the 'cheap' and they didn't do a lot of nice electrical stuff like 
> grounding the structure!

there are other things that can do it, too...
Had a client who was in the electrical business, their building was
pretty well assembled, from all I could see.  However, they were under
the intersection of several big power lines, and they seemed to collect
near-by lightning strikes.

Replaced MANY NICs and hubs in their building on at least two
occassions.  They had all kinds of protection devices on
everything..except the network cables.  Well...running through the
ceiling 50 ft. under a lightning strike picked up enough juice to blow
out NICs.

> When I got there and looked at the server, I found this type of message at 
> the start:
> 
> Nov 25 16:57:07 Mainserver /bsd: WARNING: mclpool limit reached; increase 
> kern.m
> axclusters
> Nov 25 16:57:07 Mainserver /bsd: dc0: no memory for tx list
> Nov 25 16:57:07 Mainserver /bsd: dc0: no memory for tx listdc0:
> 
> and finally:
> 
> Nov 25 16:59:07 Mainserver /bsd: WARNING: mclpool limit reached; increase 
> kern.maxclusters
> 
> [Yeah, I know it's a cheap NIC, but we've been using them for years and had 
> no problems.]
> 
>  > Since swapping the NIC fixed the problem, does it make sense this was a 
> hardware problem?

did swapping the NIC fix the probem, or did rebooting the machine fix
the problem?

Sounds more like two separate problems:
  1) Chatty NIC (Davicom chips aren't the greatest of the dc(4)
compatable devices)
  2) kern.maxclusters problem

I think both of these have got better since 3.6.  I'd *highly* suggest
starting with an upgrade.  Hmmm...bit of googling indicates that there
was a big improvement here for 3.6, but I think there was more since
then.  My comments on this are HIGHLY unauthoritative, btw.

>  > If so, can anyone recommend a NIC available here in the states that 
> might be opto-isolated?

Even if it could be done (I don't think it could be, practically), it
wouldn't help, as it would just blow out the isolation parts (which will
be soldered on the NIC).

Ethernet NICs are already basically DC isolated through a transformer.
'course, transformers do a good job of passing high voltage, high
frequency spikes, but low frequency and DC is pretty well blocked.

If you want to see how this is done, I think the Realtek website had
some interesting reference designs for the download.  Ok, *I* thought
they were interesting, but then, I consider solder a valid programming
language and debugging tool. :)

Nick.


> DMESG
> ======
> -bash-3.00$ cat dmesg.boot
> OpenBSD 3.6 (SITE-Mainserver) #0: Thu Dec  9 10:10:48 CST 2004
>      [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/SITE-Mainserver
...
> dc0 at pci0 dev 14 function 0 "Davicom DM9102" rev 0x40: irq 3, address 
> 00:08:a1:75:83:74
> amphy0 at dc0 phy 1: Am79C873 10/100 media interface, rev. 1
> pciide0 at pci0 dev 15 function 0 "VIA VT8237 SATA" rev 0x80: DMA
> pciide0: using irq 10 for native-PCI interrupt
...

Reply via email to