[Prism54-devel] Re: islpci_mgt_transaction and stability
vda at port.imtp.ilyichevsk.odessa.ua
Tue Aug 10 20:27:18 UTC 2004
> > Of course it is not surprising. I just verify that I see exactly
> > those values that I programmed in. I conclude running "set_rates
> > 1,2,5,11" again must not change anything.
> > However. it does change SOMETHING, because after set_rates STA
> > successfully associates with AP. It was trying to do so for ~10 minutes
> > in a row without any success before I typed "iwpriv ifp set_rates
> > 1,2,5,11".
> Well, the thing that sticks out is the profile change. (OID_PROFILES)
> Presumably the device has to react to that.
> The "iwpriv ifp set_rates 1,2,5,11" should be equivalent to "iwpriv ifp
> s_profile 0"
profile = -1;
ret = mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile);
But I just finished yet another round of testing.
This is new facts:
I do this UDP flood with both boxes otherwise almost idle. I only
switch between consoles, looking at throughput metering tool, syslog
viewer etc. I am careful _not_ to run iwconfig even once while flooding,
because that can cause mgt timeouts, and I want to exclude that factor
from testing. I am generally gentle on the system.
Now, when prism54 AP enters 'catatonic' state and STA cannot reassoc
for several minutes (I wait ~10mins at least), I try to awake it
not with set_rates, but with other means. Well. It leaves this state
if I do some 'significant' thing to the system. Like running iwconfig,
reading some oids with iwprivs, etc. Sadly, there is no 100% sure way
to do it. For each given action, sometimes it wakes up, sometimes don't.
(I wait ~20 seconds after I do e.g. iwconfig before trying something else).
Once it woke up just when I switched away from X to framebuffer console!
A heisenbug :(
Maybe this is some powersaving mode or auto tx power control?
All this stuff makes me really wish we had firmware source...
More information about the Prism54-devel