[Prism54-devel] [Bug 87] prism54 lost link with high traffic

[bugzilla-daemon at mcgrof.com]

http://localhost/cgi-bin/bugzilla/show_bug.cgi?id=87





------- Additional Comments From babel42 at t-online.de  2004-07-13 08:32 -------
After a suggestion from Max <spamhole at gmx.at> in the thread "WG511 loses
connection to AP and dies" I disabled WEP to test my setup again. 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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.