#20 delay after stop rx/tx

open
Bug fix (12)
5
2004-08-17
2004-03-19
Don Law
No

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.

Discussion

  • Don Law

    Don Law - 2004-03-19

    patch to tulip driver that fixes rare memory corruption

     
  • Jeff Garzik

    Jeff Garzik - 2004-08-17
    • assigned_to: nobody --> jgarzik
     

Log in to post a comment.