[Prism54-devel] Re: islpci_mgt_transaction and stability

[Denis Vlasenko]

>  > 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"

Actually, -1:
        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...
--
vda