#20 delay after stop rx/tx

[Don Law]

Delay after telling chip to stop and before changing
any ring values. This fixes a rare but nasty problem
when the tulip chip performs a portion of a DMA in
progress to the wrong location in memory. The symptom
is that apparently random areas of memory in the kernel
get corrupted with a portion of the payload of an
incoming packet when the chip is stopped (ifconfig ethx
down). If debugging is enabled (DEBUG) in the kernel,
it often appears as a BUG panic in
kmem_cache_alloc_one_tail. If debugging is off, it
often appears as a panic with a message like "Unable to
handle kernel paging request at virtual address 1eee6464"

In my testing, the problem showed up about 1% of the
time during an ifconfig down with a 21143 chip on an
i386 system.

According to the 21143 hardware reference manual rev.
1.0, in the description of bit 1 of the CSR6 register:
"When cleared, the receive process enters the stopped
state after completing the reception of the current
frame." This patch adds a delay of 1500 microseconds
after clearing bit 1, which is ample time for a
1536-byte frame to be received on a 10BT connection and
then be DMA'ed over a 33Mhz PCI bus.

[Don Law]

patch to tulip driver that fixes rare memory corruption