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