rtl8192cu: testing with EdiMax USB

rtl8192cu: testing with EdiMax USB

[Mark Cave-Ayland]

Hi all,

So talking to some colleagues at work, I managed to find someone else 
who uses the EdiMax USB dongle and persuaded them to lend it to me for 
the weekend in order to see whether it could be related to a hardware 
difference with my OEM dongle.

I've just tested with the EdiMax USB dongle which reports as "Bus 004 
Device 004: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n 
Wireless Adapter [Realtek RTL8188CUS]" in lsusb, which I believe is 
exactly the same hardware that Larry is using. And again I still see the 
problem with disassociation.

I spent a bit more time tinkering further with debug=0x5, forgetting 
that I had left your last diagnostic patch applied. Based upon when the 
beacon output disappears in the logs (after updating the power 
registers), it does seem likely that is a power-related problem.

The two power-related messages that stand out to me are:

1) Repeated output of "pHalData->bHwRadioOff and eRfPowerStateToSet do 
not match: pHalData->bHwRadioOff 0, eRfPowerStateToSet 0" messages

2) rtl92c_dm_txpower_tracking_callback_thermalmeter() seems to be called 
X seconds before the "AP off for X seconds" messages

Larry - I've sent you the complete debug off-list from the EdiMax, so it 
should be a like-for-like comparison with your setup. Hopefully 
comparing with your output will help you work out exactly what the 
problem is.


ATB,

Mark.

Re: rtl8192cu: testing with EdiMax USB

[Mark Cave-Ayland]

On 13/09/13 10:29, Mark Cave-Ayland wrote:

> I spent a bit more time tinkering further with debug=0x5, forgetting
> that I had left your last diagnostic patch applied. Based upon when the
> beacon output disappears in the logs (after updating the power
> registers), it does seem likely that is a power-related problem.

FWIW I just tried a quick test where I commented out the entire 
rtl92c_dm_txpower_tracking_callback_thermalmeter() function to make it a 
nop, and that didn't seem to make any difference...


ATB,

Mark.

Re: rtl8192cu: testing with EdiMax USB

[Mark Cave-Ayland]

On 13/09/13 14:01, Mark Cave-Ayland wrote:

>> I spent a bit more time tinkering further with debug=0x5, forgetting
>> that I had left your last diagnostic patch applied. Based upon when the
>> beacon output disappears in the logs (after updating the power
>> registers), it does seem likely that is a power-related problem.
>
> FWIW I just tried a quick test where I commented out the entire
> rtl92c_dm_txpower_tracking_callback_thermalmeter() function to make it a
> nop, and that didn't seem to make any difference...

Aha! The following diff to remove the call to rtl92c_dm_diginit() keeps 
me associated to the AP:

diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c 
b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
index d2d57a2..c18362d 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
@@ -1275,7 +1275,7 @@ void rtl92c_dm_init(struct ieee80211_hw *hw)
         struct rtl_priv *rtlpriv = rtl_priv(hw);

         rtlpriv->dm.dm_type = DM_TYPE_BYDRIVER;
-       rtl92c_dm_diginit(hw);
+       //rtl92c_dm_diginit(hw);
         rtl92c_dm_init_dynamic_txpower(hw);
         rtl92c_dm_init_edca_turbo(hw);
         rtl92c_dm_init_rate_adaptive_mask(hw);

However, dhclient still takes a very long time get an IP address and the 
connection seems extremely lossy, much like it was when I could get a 
connection before. Perhaps there are two different bugs here, one for 
the association and one for the data loss?


ATB,

Mark.

Re: rtl8192cu: testing with EdiMax USB

[Larry Finger]

On 09/13/2013 08:27 AM, Mark Cave-Ayland wrote:
> On 13/09/13 14:01, Mark Cave-Ayland wrote:
>
>>> I spent a bit more time tinkering further with debug=0x5, forgetting
>>> that I had left your last diagnostic patch applied. Based upon when the
>>> beacon output disappears in the logs (after updating the power
>>> registers), it does seem likely that is a power-related problem.
>>
>> FWIW I just tried a quick test where I commented out the entire
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() function to make it a
>> nop, and that didn't seem to make any difference...
>
> Aha! The following diff to remove the call to rtl92c_dm_diginit() keeps me
> associated to the AP:
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> index d2d57a2..c18362d 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> @@ -1275,7 +1275,7 @@ void rtl92c_dm_init(struct ieee80211_hw *hw)
>          struct rtl_priv *rtlpriv = rtl_priv(hw);
>
>          rtlpriv->dm.dm_type = DM_TYPE_BYDRIVER;
> -       rtl92c_dm_diginit(hw);
> +       //rtl92c_dm_diginit(hw);
>          rtl92c_dm_init_dynamic_txpower(hw);
>          rtl92c_dm_init_edca_turbo(hw);
>          rtl92c_dm_init_rate_adaptive_mask(hw);
>
> However, dhclient still takes a very long time get an IP address and the
> connection seems extremely lossy, much like it was when I could get a connection
> before. Perhaps there are two different bugs here, one for the association and
> one for the data loss?

Thanks for the info. Eliminating the call to rtl92c_dm_diginit() is a very large 
hammer to attack a small flea, but that points to a potential problem.

Larry

Re: rtl8192cu: testing with EdiMax USB

[Mark Cave-Ayland]

On 13/09/13 19:00, Larry Finger wrote:

> Thanks for the info. Eliminating the call to rtl92c_dm_diginit() is a
> very large hammer to attack a small flea, but that points to a potential
> problem.

Glad that it proves useful to you. If you need me to run test patches 
(e.g. logging calculated power values to dmesg), please send them 
through to me off-list and I'll run them and send you back the results.

Given that it could be related to power calculations, another bit of 
information that may help you recreate this is that my desk is really 
close to the AP (probably 10m or a bit less), and so the indicated 
signal strength should be close to maximum.


HTH,

Mark.