Orinoco driver lockups

[Robert Hardy]

Back on Linux Kernel 2.2.x I used the Lucent binary drivers for my Orinoco
wireless NIC on my firewall and it was rock solid. Getting a fucntional
stable driver under a 2.4.x kernel is proving to be a challenge. Since the
Lucent binary drivers don't work under 2.4.x (they transmit one packet and
then unload the driver!?), I'm forced to use Orinoco.o. Your help debugging
what seems to be a problem with the Orinoco driver would be appreciated.

I started using the Orinoco driver when I upgraded to 2.4.x. Historically
it has worked however it required a pcmcia restart for every 3-4 hours of
use. That is annoying but is also good exercise (my server is two floors
away.) Recently however my firewall has started locking up solid while using
the wireless NIC.

I've tried to isolate the problem, I'm pretty sure it has something to do
with orinoco_reset() function however debugging it is proving to be very
nasty.

I've tested kernels using 2.4.13 to 15 including various pre kernels. I've
tried orinoco 0.08a and 0.08b.

My colleague and I are not new to the Linux scene. The problem exists on
both our firewalls. Both of which are well pamped UPS protected stable
systems (no overclocking etc.)

My colleague has a different carbus bridge, a single slot one which Lucent
sold him. Mine is a third party two slot.

There seem to be two failure modes:
1. System locks solid with no warning
2. System gets a kernel oops in an unrelated process "Unable to handle
   kernel paging request". I've seen the following processes listed in kernel
   oops: swapper, tail (from me tailing debug & messages)

Common symptoms:
 -All lockups happened while the wireless NIC is in use.
 -More traffic means increased chance of lockup

Testing environment:
  I've got a pair of Orinoco 802.11b Wireless NICs. One
  is in a Sager notebook running Windoze 98 and the other is a Linux 2.4.x
  based box on a Abit BP6 with a pair of Celeron CPU & 512M of RAM.
  The card-bus bridge in use is a PCI based two slot id'ed as:
    PCI bus 0x0 cardnum 0x11 function 0x0001: vendor 0x104c device 0xac1c
    Texas Instruments PCI1225.

Simple process to reproduce the problem:
 1. Recompile the driver with ORINOCO_DEBUG >= 4

 2. cd /var/log; tail -f debug -f messages

 3. Start a large file transfer from the Linux box to the Windows box.
    I have been using a drivers folder which contains about 800 files totaling 250M.

 4. On the server console: ping -f notebook

 5. Within a minute the server will be locked solid. Everything will die
    including sys-request key.

I've got these modules loaded:
  orinoco_cs              4320   1
  orinoco                29664   0 [orinoco_cs]
  hermes                  3184   0 [orinoco_cs orinoco]
  ds                      6432   2 [orinoco_cs]
  yenta_socket            8368   2
  pcmcia_core            37088   0 [orinoco_cs ds yenta_socket]

Here is a hand transcribed kernel oops with max ORINOCO_DEBUG:
  Code: 8b 43 08 8b 80 90 00 00 00 85 c0 74 11 8b 40 34 85 c0 74 0a
   <1>Unable to handle kernel paging request at virtual address 80008024
    printing eip:
  	c0131dd9
  *pde = 00000000
  Oops: 0000
  CPU:    1
  EIP:    0010:[<c0131dd9>]      Not tainted
  EFLAGS: 00010286
  eax: 80008000   ebx: cd5add60   ecx: dfbde640    edx:  cd5add60
  esi: 00000003   edi: 00000000   ebp: 00000001    esp:  cfefde7c
  ds: 0018   es: 0018  ss:  0018
  Process tail (pid: 2420, stackpage=cfefd000)
  Stack: 00000003 00000003 cc7428c0 c0119028 cd5add60 cc7428c0 ccdffaa0 cfefc000
         0000000b 80008008 cc7429e0 c01197b5 cc7428c0 00000000 ccdffaa0 00000000
  			 c01072cf 0000000b 00000000 c0113298 c02199be cfefdf80 00000000 cfefc000
  Call Trace: [<c0119028>] [<c01197b5>] [<c01072cf>][<c0113298>][<c0112f2c>]
     [<c0113e83>] [<c0106e64>] [<c0110018>] [<c0138a8a>] [<c0106d73>]
  Code: 83 78 24 00 74 4c be 00 e0 ff ff 21 e6 8b 46 1c 8d 50 01 89
   <6>NETDEV WATCHDOG: eth2: transmit timed out
  eth2: Tx timeout! Resetting card.
  eth2: -> orinoco_reset()
   Then the system locks solid, keyboard dead etc...

Again any assistance debugging this would be appreciated.

Regards,
Rob

-- 
---------------------"Happiness is understanding."----------------------
Robert Hardy                                          C.E.O. Webcon Inc.