Tx timed out! Resetting card (with OpenAP)

[earl]

Hi,

I'm doing some development with the OpenAP (Eumitcom WL-11000) hardware:

http://tools.collegeterrace.net/openap-ct
This is basically a AMD Elan SC400 (486 class system-on-a-chip) with a
Prism2-based card plugged into the PCMCIA.

Currently i'm using CVS hostap (as of Jan 3), pcmcia 3.2.3, and kernel
2.4.20.

I have two of these units set up with bridging between their wireless
and ethernet interfaces, with a WDS link between the two units.
(wds_type=2)  I am testing the WDS link by transferring data from a PC
connected to the ethernet interface of one unit to a PC connected to the
interface of the other.  Generally, it works for a while but eventually
one unit will die with the message:
NETDEV WATCHDOG: wlan0: transmit timed out
wlan0 Tx timed out! Resetting card
wlan0: CMD=010b EVSTAT=8099 OFFSET0=0000 OFFSET1=0000 SWSUPPORT0=8a32
which repeats forever.  It's easy to reproduce this by ping-flooding,
which will trigger this failure within a minute or two at the most.
Transferring large files also causes this to kick in reliably after a
few mintues.

The failure behavior is slightly different if i use use standard WDS by
first using prism2_srec to do a nonvolatile update of the firmware then
use wds_type=4.  In this case when it fails i get the message:
NETDEV WATCHDOG: wlan0: transmit timed out
wlan0 Tx timed out! Resetting card
wlan0: CMD=010b EVSTAT=0019 OFFSET0=0000 OFFSET1=0000 SWSUPPORT0=8a32
which is only printed out once.  After that, the link is completely dead
so apparently the card reset failed to make things work again.

I did verify that, before the failure occurs and while data is still
flowing normally, the interrupt count in /proc/interrupts is
incrementing for hostap_cs.  Does this indicate that this isn't
something that would be fixed with an irq_mode setting?

Just for fun i tried changing the value of TX_TIMEOUT in hostap.c from 2
* HZ to 200 * HZ to see whether the timeout was in fact a brief glitch
that could be safely ignored, i.e. an empirical timing parameter that is
being set too strictly.  In this case no timeout was reported but the
link would die anyway, which i assume means things were broken already
regardless of whether the card reset is attempted.  That is, the fact
that prism2_tx_timeout() is getting called is a symptom of a bug that's
already occurred.  The fact that the reset fails to put things right may
or may not be related to the bug that already occurred.

Any ideas what's happening?  Can i put in more printk's to give some
better tracing info?

Here are some possibly relevant startup messages (for the first case):

Linux Kernel Card Services 3.1.22
  options:  none
Intel PCIC probe:
  Intel i82365sl A step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 1 socket
    host opts [0]: none
    ISA irqs (default) = 3,4,5,7,9,10,11,12,15 polling interval = 1000
ms
Starting wireless: cardmgr[23]: watcs: IO port probe 0x0c00-0x0cff:ching
1 socke
 clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: clean.
Jan  1 00:00:06 cs: memory probe 0x0d0000-0x0dffff:cardmgr[24]:
starting, version i clean.
s 3.2.3
Jan  1 00:00:06 cardmgr[24]: socket 0: Longshine LCR-8531 11Mbps WLAN
PCMCIA CARD
Jan  1 00:00:06 cardmgr[24]: executing: 'insmod
/lib/modules/preferred/pcmcia/ho
stap_crypt.o'
Jan  1 00:00:07 cardmgr[24]: + Using
/lib/modules/preferred/pcmcia/hostap_crypt.o
Jan  1 00:00:07 cardmgr[24]: executing: 'insmod
/lib/modules/preferred/pcmcia/hostap.o'
Jan  1 00:00:08 cardmgr[24]: + Using
/lib/modules/preferred/pcmcia/hostap.o
Jan  1 00:00:08 cardmgr[24]: executing: 'insmod
/lib/modules/preferred/pcmcia/hostap_cs.o ignore_cis_vcc=1'
hostap_cs: 0.0.0 CVS (Jouni Malinen <jkmaline at cc.hut.fi>)
Jan  1 00:00:08 cardmgr[24]: + Using
/lib/modules/preferred/pcmchostap_cs: index
, irq 3Vcc 5.0ia/hostap_cs.o
       , io 0x0100-0x013f
hostap_cs: Registered netdevice wlan0
wlan0: NIC: id=0x8002 v1.0.0
wlan0: PRI: id=0x15 v0.3.0
wlan0: STA: id=0x1f v0.7.5
Jan  1 00:00:09 cardmgr[24]: executing: './network start wlan0'
Jan  1 00:00:10 cardmgr[24]: + wlan0     Link encap:Ethernet  HWaddr
00:90:D1:00:C4:88
Jan  1 00:00:10 cardmgr[24]: +           BROADCAST MULTICAST  MTU:1500
Metric:1
Jan  1 00:00:10 cardmgr[24]: +           RX packets:0 errors:0 dropped:0
overruns:0 frame:0
Jan  1 00:00:10 cardmgr[24]: +           TX packets:0 errors:0 dropped:0
overruns:0 carrier:0
Jan  1 00:00:10 cardmgr[24]: +           collisions:0 txqueuelen:100
Jan  1 00:00:10 cardmgr[24]: +           RX bytes:0 (0.0 iB)  TX bytes:0
(0.0 iB)
Jan  1 00:00:10 cardmgr[24]: +           Interrupt:3 Base address:0x100

thanks
earl