rtl8192cu: testing with EdiMax USB
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.
Quoted 4 lines · Mark Cave-Ayland
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.
Quoted 8 lines · Mark Cave-Ayland
Quoted 4 lines
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:
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c +1 -1
@@ -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.
Quoted 29 lines · Mark Cave-Ayland
Quoted 8 lines · Mark Cave-Ayland
Quoted 4 lines
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:drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c +1
-1@@ -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);
Quoted 4 lines
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
Quoted 3 lines · Larry Finger
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.