[Prism54-devel] [Bug 88] Wireless interface timeout waiting for mgmt response 1000, triggering device

[bugzilla-daemon at mcgrof.com]

http://prism54.org/cgi-bin/bugzilla/show_bug.cgi?id=88





------- Additional Comments From yem at y3m.net  2004-08-18 09:38 -------
I'm also getting lockups with high traffic. In this example, I brought the
interface up, and immediately tried to rsync/ssh a file across the LAN. Within
one second, the transfer had stopped and the following appeared in syslog:
                                                                                
Aug 18 20:59:56 tuna eth1: timeout waiting for mgmt response 1000, triggering device
Aug 18 20:59:56 tuna eth1: timeout waiting for mgmt response
Aug 18 20:59:57 tuna eth1: timeout waiting for mgmt response 1000, triggering device
Aug 18 20:59:57 tuna eth1: timeout waiting for mgmt response
Aug 18 20:59:58 tuna eth1: timeout waiting for mgmt response 1000, triggering device
Aug 18 20:59:58 tuna eth1: timeout waiting for mgmt response
Aug 18 21:00:00 tuna eth1: timeout waiting for mgmt response 1000, triggering device
Aug 18 21:00:00 tuna eth1: timeout waiting for mgmt response
Aug 18 21:00:00 tuna eth1: mgmt tx queue is still full
Aug 18 21:00:00 tuna eth1: mgmt tx queue is still full
Aug 18 21:00:00 tuna eth1: mgmt tx queue is still full
Aug 18 21:00:00 tuna eth1: mgmt tx queue is still full
.. and so on.
                                                                                
This is with kernel 2.6.8.1 (happened with 2.6.7 as well). Gentoo linux.
Hardware is a 3Com 3CRWE154G72 in a HP laptop (PIII-1Ghz/512Mb). Connected
to a 3Com 802.11g AP using 128 bit WEP. Using latest firmware from this site
(1.0.4.3.arm).
                                                                                
Problem appears to be CPU related. I can usually maintain a transfer of
< 80 kilobytes per second or less. Sometimes if the CPU load spikes for
some reason, the connection will die even then. If very little data was
being transferred, then the connection will /usually/ recover in these
circumstances. Whereas with a large transfer like a full rate rsync, it
dies immediately and does not recover.

I seem to recall transferring a large file (~650mb) over 802.11b with no
trouble on the AP at work - sustained 400-700kilobytes/sec. But I'll have
to try that again to confirm as it was a while ago.
                                                                                
Update.. downgraded to 0.3.0 as recommended in this ticket. Tried a big
transfer. It went at ~700kb/s for about 2 seconds before dying as above.
Reset the interface and tried again. Now it is transferring steadily with
no sign of lockup - unfortunately, its only doing ~350kb/s according to
gkrellm. Reset the connection, and tried the same transfer with scp. Died
almost immediately. Reset and tried again, this time it held a sustained
800kb/s for about 30 seconds, until the CPU spiked and it stalled out.
                                                                                
Is the code in 2.6.8.1 virtually the same as CVS as of yesterday?



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