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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
