> On 04/05/2012 07:31 AM, Joshua Roys wrote: >> >> On 04/05/2012 03:27 AM, Nicu Pavel wrote: >>> >>> After mode debugging with DBG_LOUD I found out that the difference when >>> the >>> driver is loaded/modprobed and ifdown/ifup to be a receive configuration >>> register (RCR) value. >>> >>> On bootup/modprobe: ### Set RCR(0xf0002a0e) ### >>> On ifdown/ifup: ### Set RCR(0xf0002ace) ### >>> >>> If I force RCR value to 0x2a0e in rtl92cu_set_hw_reg()inside HW_VAR_RCR >>> case >>> everything works ok. >>> >>> This seems to work with 3 different vendors USB sticks based on 8192cu >>> chipset >>> (Edimax, EDUP and some unknown vendor). >>> >>> I tried looking up the bit values meanings from that register but >>> couldn't find >>> a proper spec. >> >> >> Hello, >> >> I found a header file that seems to have better definitions and comments >> than >> what is currently in-tree (I think it's a copy of the Realtek sources). It >> says >> that the "8192C (RCR) Receive Configuration Register" BIT 6 and 7 are, >> respectively: RCR_CBSSID_DATA [Accept BSSID match packet (Data)] and >> RCR_CBSSID_BCN [Accept BSSID match packet (Rx beacon, probe rsp)]. >> These bits are set/cleared in _rtl92cu_set_check_bssid (it calls >> set_hw_reg >> w/HW_VAR_RCR) which is called by rtl92cu_set_network_type. The set/clear >> choice >> is made based on the rtlphy->current_io_type which is set in >> rtl8192c/phy_common.c:rtl92c_phy_scan_operation_backup which in turn is >> called >> from core.c:rtl_op_sw_scan_start/_complete. >> It would be interesting to see the output from rtl8192c/phy_common.c >> functions >> rtl92c_phy_set_io_cmd and rtl92c_phy_set_io to see if the current_io_type >> perhaps isn't being updated properly. > > > Attached is a patch that I think will help. The main thing it changes is > that routine rtl92cu_set_check_bssid() has been coded to update RCR. The > other thing that was changed is to make the RCR setting always log even with > the default debug option of 0. That will be temporary and that change will > be deleted once we get this problem fixed. > > Let me know if the patch helps. [..] Tried the patch, but didn't help: <7>rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ### <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ### ----> Driver loaded scanning gets results ok. <6>rtl8192cu: MAC auto ON okay! <6>rtl8192cu: Tx queue select: 0x05 <7>rtl8192c_common:rtl92c_phy_set_bw_mode():<0-0> FALSE driver sleep or unload <6>rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin <7>rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002ace) ### <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ### ----> ifdown/ifup no scanning results. <6>rtl8192cu: MAC auto ON okay! <6>rtl8192cu: Tx queue select: 0x05 <7>rtl8192c_common:rtl92c_phy_set_bw_mode():<0-0> FALSE driver sleep or unload <6>rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin <7>rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002ace) ### <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtlwifi:rtl_op_conf_tx():<0-0> queue number -954253944 is incorrect! <7>rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ### ----> ifdown/ifup no scanning results. Nicu -- 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
