Bug 30952

I'm getting kernel panics when running tcpdump when sniffing my
external link.  The traps almost always occur in xl_newbuf() (in
pci/if_xl.c) where it calls MCLGET(), which would indicate a corrupted,
thought to be free, mbuf cluster having been put on the free list.  In
about twenty crashes I saw the crash occur once in an mget call inside
one of the bpf routines, but I was never able to recreate that crash.

Here are the relevant facts:

* The ethernet signal is known to have bad traffic on it; another
  driver running under OpenBSD 2.9 (the de(4) driver, called dc(4) in
  FreeBSD) reports "bad crc" and "alignment problem" errors with
  received packets, at a rate of a couple of packets per second.

* It is not a particular packet that's doing it (two identical
  machines running identical software crash at different times).

* It takes 1-5 minutes on a lightly loaded network (~20Mbps) before
  the crash occurs, so not all (bad) packets are causing this problem.

* If I replay captured traffic (with a sort-of tcpundump program I
  wrote) in a controlled environment, no crash occurs, so the fault
  must lie with the bad packets that exist on the wire.

* The problem does not exist in other drivers (e.g., the dc(4)
  driver); I used another machine with that interface to capture the
  traffic for the experiment in the previous step.

* The problem occurs on machines with a variety of hardware speeds
  (300MHz - 1GHz), with four different motherboards by two different
  manufacturers (Tyan and Supermicro), and for both the 3c905B and
  3c905C versions of the card.

* The problem also manifests itself under OpenBSD 2.9 (I don't know
  about earlier versions).

I suspect that when the card is in promiscuous mode, it does something
improper when DMAing.  I hope there is a way of finding out what's
wrong without having to break out my PCI bus analyzer!

Fix: 

none yet
How-To-Repeat: 	good question. I don't know.