[Prism54-users] WG511 loses connection to AP and dies

[Claas Hilbrecht]

--Am Montag, 12. Juli 2004 22:17 +0200 Max <spamhole at gmx.at> schrieb:

> A friend yesterday told me that his wlan connection (also with a WG511)
> is very unstable and that he has to turn off WEP to keep it working. I
> tried that and it worked! If I turn off WEP I can transfer GBs of data
> again without having to restart the card. The transfer speed sometimes
> drops to 0 for a second, but it doesn't lose it's connection to the AP
> like it does when WEP is enabled.

I tried your suggestions. I can confirm the behaviour with the transfer 
speed but at my setup the link still gets lost.

After transfering about 1.2 GB the transfer stopped. An iwevent on the 
Master gives this output:

greebo 2.1.7cvs20040603 # /boot/iwevent
Waiting for Wireless Events...
07:59:55.824264    eth3     Custom driver event:Disassociate request from 
00:04:E2:64:9F:37  (08)
07:59:56.084542    eth3     Custom driver event:Authenticate request from 
00:04:E2:64:9F:37  : ACCEPTED  (00)
07:59:57.879666    eth3     Custom driver event:Authenticate request from 
00:04:E2:64:9F:37  : ACCEPTED  (00)

The client in Managed Mode says:

fli4l 2.1.7cvs20040704 # /boot/iwevent
Waiting for Wireless Events...
07:59:56.594650    eth3     Custom driver event:Authenticate request to 
00:04:E2:64:9F:4F  : REJECTED  (10)
07:59:57.681721    eth3     Custom driver event:Link lost
07:59:58.389680    eth3     Custom driver event:Authenticate request to 
00:04:E2:64:9F:4F  : REJECTED  (10)
08:00:00.184748    eth3     Custom driver event:Authenticate request to 
00:04:E2:64:9F:4F  : REJECTED  (10)
08:00:13.502719    eth3     Custom driver event:Authenticate request to 
00:04:E2:64:9F:4F  : REJECTED  (10)

An iwconfig ethX on the Managed node gives that it has no AP assoc. Then I 
tried an iwpriv ethX reset on the Managed node. This gives the following 
kernel msg:

Jul 13 10:01:03 fli4l kernel: eth3: resetting device...
Jul 13 10:01:04 fli4l kernel: eth3: device soft reset timed out

And a few moments later I get the following:

Kernel BUG at isl_38xx.c:241!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c4855260>] Not tainted
EFLAGS: 00010293
eax: fffffd79 ebx: c39d6800 ecx: 00000004 edx: fffffd79
esi: 00000002 edi: c39d6960 ebp: c01f7fb8 esp: c01f7f50
ds: 0018 es: 0018 ss: 0018

After looking at the source I found this:

int
isl38xx_in_queue(isl38xx_control_block *cb, int queue)
{
        const s32 delta = (le32_to_cpu(cb->driver_curr_frag[queue]) -
                           le32_to_cpu(cb->device_curr_frag[queue]));

        /* determine the amount of fragments in the queue depending on the 
type
         * of the queue, either transmit or receive */

        BUG_ON(delta < 0);      /* driver ptr must be ahead of device ptr */

        switch (queue) {
                /* send queues */

So it clear to me that someone expected that this bug could happens but 
he/she didn't know how to handle that. The driver is from CVS 20040610. 
Maybe this helps to get the bug/problem fixed.

-- 
 Claas Hilbrecht
 http://www.jucs-kramkiste.de