Hello,
I am using a USB WLAN - Stick with Realtek 8192 kernel driver. After
plugging it works fine, connecting to a WPA - network works. After
ifdown wlan0, ifup wlan0 the stick no longer works , it stucks on
scanning. Only a modprobe -r rtl8192cu; modprobe rtl8192cu fixes the
problem. The problem only appear if more than one wireless - network is
in range.The problem appear only in connection with the rtl8192cu
driver, other USB - sticks (with different Chipset) and other PCIE -
boards operate properly.
In order to reproduce the behavior repeat the sequenceifdown wlan0, ifup
wlan0 a few times.
wpa_cli status->
Selected interface 'wlan0'
wpa_state=SCANNING
< no change after 10 minutes>
dmesg ->
rtl8192cu: MAC auto ON okay!
rtl8192cu: Tx queue select: 0x05
rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
wlan0: authenticate with 00:08:54:9a:b2:5f (try 1)
wlan0: authenticated
wlan0: associate with 00:08:54:9a:b2:5f (try 1)
wlan0: RX AssocResp from 00:08:54:9a:b2:5f (capab=0x411 status=0 aid=1)
wlan0: associated
< ifdown wlan0 >
wlan0: disassociated from 00:08:54:9a:b2:5f (Reason: 14)
wlan0: deauthenticating from 00:08:54:9a:b2:5f by local choice (reason=3)
cfg80211: Calling CRDA for country: US
rtl8192cu: MAC auto ON okay!
rtl8192cu: Tx queue select: 0x05
rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
< ifup wlan0 >
rtl8192cu: MAC auto ON okay!
rtl8192cu: Tx queue select: 0x05
rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
cat /sys/class/net/wlan0/carrier -> 0
cat /sys/class/net/wlan0/operstate -> down
Kernelversion: 3.1.8
modinfo rtl8192cu->
filename: kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
description: Realtek 8192C/8188C 802.11n USB wireless
author: Larry Finger <[email protected]>
author: Georgia <[email protected]>
license: GPL
vermagic: 3.1.8-WuT preempt mod_unload ARMv5
firmware: rtlwifi/rtl8192cufw.bin
depends: rtlwifi,rtl8192c-common
lsusb ->
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 0bda:8176
lsmod ->
Module Size Used by Not tainted
rtl8192cu 89196 0
rtl8192c_common 53560 1 rtl8192cu
rtlwifi 88269 1 rtl8192cu
orion_wdt 3043 1
iwlist wlan0 scan ->
wlan0 No scan results
After modprobe -r rtl8192cu; modprobe rtl8192cu
cat /sys/class/net/wlan0/carrier ->1
cat /sys/class/net/wlan0/operstate ->up
< First scan only finds Cell 01 >
iwlist wlan0 scan->
wlan0 Scan completed :
Cell 01 - Address: 00:08:54:9A:B2:5F
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=70/70 Signal level=-36 dBm
Encryption key:on
ESSID:"AP-KK"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=000000044859a0d7
Extra: Last beacon: 20ms ago
(Unknown Wireless Token 0x8C05)
< Retry >
iwlist wlan0 scan
wlan0 Scan completed :
Cell 01 - Address: 00:08:54:9A:B2:5F
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=69/70 Signal level=-41 dBm
Encryption key:on
ESSID:"AP-KK"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=000000044880b0d7
Extra: Last beacon: 20ms ago
(Unknown Wireless Token 0x8C05)
Cell 02 - Address: C8:3A:35:18:1B:D8
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=69/70 Signal level=-41 dBm
Encryption key:on
ESSID:"Logilink"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 9 Mb/s
18 Mb/s; 36 Mb/s; 54 Mb/s
Bit Rates:6 Mb/s; 12 Mb/s; 24 Mb/s; 48 Mb/s
Mode:Master
Extra:tsf=00000000dd4b9158
Extra: Last beacon: 300ms ago
(Unknown Wireless Token 0x8C05)
Regards, Markus
-- Unsere Aussagen koennen Irrtuemer und Missverstaendnisse enthalten.
Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie Entscheidungen
auf Grundlage dieser Aussagen treffen.
Wiesemann & Theis GmbH, Porschestr. 12, D-42279 Wuppertal
Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis
Registergericht: Amtsgericht Wuppertal, HRB 6377
Tel. +49-202/2680-0, Fax +49-202/2680-265, http://www.wut.de
On 01/12/2012 08:11 AM, Markus K?nigshaus wrote:
> Hello,
>
> I am using a USB WLAN - Stick with Realtek 8192 kernel driver. After plugging it
> works fine, connecting to a WPA - network works. After ifdown wlan0, ifup wlan0
> the stick no longer works , it stucks on scanning. Only a modprobe -r rtl8192cu;
> modprobe rtl8192cu fixes the problem. The problem only appear if more than one
> wireless - network is in range.The problem appear only in connection with the
> rtl8192cu driver, other USB - sticks (with different Chipset) and other PCIE -
> boards operate properly.
> In order to reproduce the behavior repeat the sequenceifdown wlan0, ifup wlan0 a
> few times.
>
> wpa_cli status->
> Selected interface 'wlan0'
> wpa_state=SCANNING
> < no change after 10 minutes>
>
> dmesg ->
> rtl8192cu: MAC auto ON okay!
> rtl8192cu: Tx queue select: 0x05
> rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
> wlan0: authenticate with 00:08:54:9a:b2:5f (try 1)
> wlan0: authenticated
> wlan0: associate with 00:08:54:9a:b2:5f (try 1)
> wlan0: RX AssocResp from 00:08:54:9a:b2:5f (capab=0x411 status=0 aid=1)
> wlan0: associated
> < ifdown wlan0 >
> wlan0: disassociated from 00:08:54:9a:b2:5f (Reason: 14)
> wlan0: deauthenticating from 00:08:54:9a:b2:5f by local choice (reason=3)
> cfg80211: Calling CRDA for country: US
> rtl8192cu: MAC auto ON okay!
> rtl8192cu: Tx queue select: 0x05
> rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
> < ifup wlan0 >
> rtl8192cu: MAC auto ON okay!
> rtl8192cu: Tx queue select: 0x05
> rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
>
>
> cat /sys/class/net/wlan0/carrier -> 0
> cat /sys/class/net/wlan0/operstate -> down
>
> Kernelversion: 3.1.8
>
> modinfo rtl8192cu->
> filename: kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
> description: Realtek 8192C/8188C 802.11n USB wireless
> author: Larry Finger <[email protected]>
> author: Georgia <[email protected]>
> license: GPL
> vermagic: 3.1.8-WuT preempt mod_unload ARMv5
> firmware: rtlwifi/rtl8192cufw.bin
> depends: rtlwifi,rtl8192c-common
>
> lsusb ->
> Bus 001 Device 001: ID 1d6b:0002
> Bus 001 Device 003: ID 0bda:8176
I will try to duplicate your results; however,there are two things I would like
you to try. First is to get a copy of the bleeding-edge compat-wireless code,
build and install the package, and test to see if it still fails. If it does, I
want you to load the driver with a 'debug=4' option. In other words, use
modprobe -v rtl8192cu debug=4
Then, after a failure occurs, send me the output of a dmesg command.
Larry
On 04/09/2012 03:40 AM, Nicu Pavel wrote:
> It works if I change:
> rtl_write_dword(rtlpriv, REG_RCR, ((u32 *) (val))[0]);
> to:
> rtl_write_dword(rtlpriv, REG_RCR, mac->rx_conf);
That was a pretty stupid mistake! Thanks for working it out.
When I send the patch upstream, may I use your name and E-mail address in a
"Tested-by:" line?
Larry
Hi,
On Mon, Apr 9, 2012 at 7:03 PM, Larry Finger <[email protected]> wrote:
> On 04/09/2012 03:40 AM, Nicu Pavel wrote:
>
>> It works if I change:
>> rtl_write_dword(rtlpriv, REG_RCR, ((u32 *) (val))[0]);
>> to:
>> rtl_write_dword(rtlpriv, REG_RCR, mac->rx_conf);
>
>
> That was a pretty stupid mistake! Thanks for working it out.
>
> When I send the patch upstream, may I use your name and E-mail address in a
> "Tested-by:" line?
Yes.
Thanks,
Nicu
>
> Larry
Hi,
> On 01/12/2012 08:11 AM, Markus Königshaus wrote:
> > Hello,
> >
> > I am using a USB WLAN - Stick with Realtek 8192 kernel driver. After
plugging it
> > works fine, connecting to a WPA - network works. After ifdown wlan0, ifup
wlan0
> > the stick no longer works , it stucks on scanning. Only a modprobe -r
rtl8192cu;
> > modprobe rtl8192cu fixes the problem. The problem only appear if more than
one
> > wireless - network is in range.The problem appear only in connection with
the
> > rtl8192cu driver, other USB - sticks (with different Chipset) and other PCIE
-
> > boards operate properly.
> > In order to reproduce the behavior repeat the sequenceifdown wlan0, ifup
wlan0 a
> > few times.
> >
> > wpa_cli status->
> > Selected interface 'wlan0'
> > wpa_state=SCANNING
> > < no change after 10 minutes>
> >
> > dmesg ->
> > rtl8192cu: MAC auto ON okay!
> > rtl8192cu: Tx queue select: 0x05
> > rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
> > wlan0: authenticate with 00:08:54:9a:b2:5f (try 1)
> > wlan0: authenticated
> > wlan0: associate with 00:08:54:9a:b2:5f (try 1)
> > wlan0: RX AssocResp from 00:08:54:9a:b2:5f (capab=0x411 status=0 aid=1)
> > wlan0: associated
> > < ifdown wlan0 >
> > wlan0: disassociated from 00:08:54:9a:b2:5f (Reason: 14)
> > wlan0: deauthenticating from 00:08:54:9a:b2:5f by local choice (reason=3)
> > cfg80211: Calling CRDA for country: US
> > rtl8192cu: MAC auto ON okay!
> > rtl8192cu: Tx queue select: 0x05
> > rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
> > < ifup wlan0 >
> > rtl8192cu: MAC auto ON okay!
> > rtl8192cu: Tx queue select: 0x05
> > rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin
> >
> >
> > cat /sys/class/net/wlan0/carrier -> 0
> > cat /sys/class/net/wlan0/operstate -> down
> >
> > Kernelversion: 3.1.8
> >
> > modinfo rtl8192cu->
> > filename: kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
> > description: Realtek 8192C/8188C 802.11n USB wireless
> > author: Larry Finger <Larry.Finger@...>
> > author: Georgia <georgia@...>
> > license: GPL
> > vermagic: 3.1.8-WuT preempt mod_unload ARMv5
> > firmware: rtlwifi/rtl8192cufw.bin
> > depends: rtlwifi,rtl8192c-common
> >
> > lsusb ->
> > Bus 001 Device 001: ID 1d6b:0002
> > Bus 001 Device 003: ID 0bda:8176
>
> I will try to duplicate your results; however,there are two things I would
like
> you to try. First is to get a copy of the bleeding-edge compat-wireless code,
> build and install the package, and test to see if it still fails. If it does,
I
> want you to load the driver with a 'debug=4' option. In other words, use
>
> modprobe -v rtl8192cu debug=4
>
> Then, after a failure occurs, send me the output of a dmesg command.
I'm having the same behavior, on a 3.1 kernel tested with 2 USB Realtek 8192cu
sticks.
However I'm unable to test with the latest compat-wireless because it's crashing
when I load the rtl8192cu module.
Compat-wireless backport release: compat-wireless-2012-03-14-2-g7bfa0a3
Backport based on linux-next.git next-20120316
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>rtl8192cu: Chip version 0x10
<6>rtl8192cu: MAC address: 80:1f:02:1b:d7:b1
<6>rtl8192cu: Board Type 0
<6>rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
<4>------------[ cut here ]------------
<4>WARNING: at /indevel/minibox-android/android-kernel/minibox-kernel-
modules/compat-wireless-2012-03-18/net/wireless/core.c:577
wiphy_register+0x19c/0x494 )
<4>Modules linked in: rtl8192cu(+) rtl8192c_common rtlwifi mac80211 cfg80211
compat
<4>Backtrace:
<4>[<c00128ec>] (dump_backtrace+0x0/0x110) from [<c0012e34>]
(dump_stack+0x18/0x1c)
<4> r6:bf04dbe8 r5:bf0699ac r4:00000241
<4>[<c0012e1c>] (dump_stack+0x0/0x1c) from [<c0021334>]
(warn_slowpath_common+0x58/0x70)
<4>[<c00212dc>] (warn_slowpath_common+0x0/0x70) from [<c0021370>]
(warn_slowpath_null+0x24/0x2c)
<4> r8:00000000 r7:00000820 r6:00000040 r5:bf06b840 r4:c27fc0e0
<4>[<c002134c>] (warn_slowpath_null+0x0/0x2c) from [<bf04dbe8>]
(wiphy_register+0x19c/0x494 [cfg80211])
<4>[<bf04da4c>] (wiphy_register+0x0/0x494 [cfg80211]) from [<bf07f628>]
(ieee80211_register_hw+0x43c/0x688 [mac80211])
<4>[<bf07f1ec>] (ieee80211_register_hw+0x0/0x688 [mac80211]) from [<bf0cb3c0>]
(rtl_fw_cb+0x8c/0xd0 [rtlwifi])
<4>[<bf0cb334>] (rtl_fw_cb+0x0/0xd0 [rtlwifi]) from [<c01b79d4>]
(request_firmware_work_func+0x5c/0x7c)
<4> r7:c01b7978 r6:c27b8be0 r5:00000000 r4:c27b8be0
<4>[<c01b7978>] (request_firmware_work_func+0x0/0x7c) from [<c003a174>]
(kthread+0x88/0x90)
<4> r5:cec43d30 r4:c27f9fcc
<4>[<c003a0ec>] (kthread+0x0/0x90) from [<c00248a0>] (do_exit+0x0/0x634)
<4> r7:00000013 r6:c00248a0 r5:c003a0ec r4:cec43d30
<4>---[ end trace 5941e5b8e919d8dc ]---
<6>rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
<6>usbcore: registered new interface driver rtl8192cu
Thanks,
Nicu
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
On 04/06/2012 03:48 AM, Nicu Pavel wrote:
> ----> 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.
Please try the attached patch. After looking at the backtraces for the calls
that set the BSSID filters, I could see no reason for the driver to fail, yet it
did. Once I kept those bits clear you did in the beginning, then it works. The
amount of extra overhead will be minimal as the bits were only set for a short time.
If this patch works for you, then I will send it upstream for mainline and
stable. The best place to keep the bits clear would be in the calling routine,
not in rtl92cu_set_hw_reg(); however, that patch will be much more intrusive and
would not be accepted for 3.4.
Larry
Hi,
> > I am using a USB WLAN - Stick with Realtek 8192 kernel driver. After
plugging it
> > works fine, connecting to a WPA - network works. After ifdown wlan0, ifup
wlan0
> > the stick no longer works , it stucks on scanning. Only a modprobe -r
rtl8192cu;
> > modprobe rtl8192cu fixes the problem. The problem only appear if more than
one
> > wireless - network is in range.The problem appear only in connection with
the
> > rtl8192cu driver, other USB - sticks (with different Chipset) and other PCIE
-
> > boards operate properly.
> > In order to reproduce the behavior repeat the sequenceifdown wlan0, ifup
wlan0 a
> > few times.
[..]
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.
Thanks,
Nicu Pavel
> 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
Hi,
On Fri, Apr 6, 2012 at 10:54 PM, Larry Finger <[email protected]> wrote:
> On 04/06/2012 03:48 AM, Nicu Pavel wrote:
>>
>> ----> ?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.
>
>
> Please try the attached patch. After looking at the backtraces for the calls
> that set the BSSID filters, I could see no reason for the driver to fail,
> yet it did. Once I kept those bits clear you did in the beginning, then it
> works. The amount of extra overhead will be minimal as the bits were only
> set for a short time.
>
> If this patch works for you, then I will send it upstream for mainline and
> stable. The best place to keep the bits clear would be in the calling
> routine, not in rtl92cu_set_hw_reg(); however, that patch will be much more
> intrusive and would not be accepted for 3.4.
It works if I change:
rtl_write_dword(rtlpriv, REG_RCR, ((u32 *) (val))[0]);
to:
rtl_write_dword(rtlpriv, REG_RCR, mac->rx_conf);
Thanks,
Nicu
>
> Larry
>
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.
Hope to help,
Josh
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.
I have a low-priority patch that will add the definitions of the bits in the
Receive Control Register. Bits 6 & 7 should be set when the interface is
associated with an AP. That will let the hardware filter out any traffic not
coming from the AP and reduce the driver's work load. When the interface is not
associated, those bits should be clear. Forcing them off will work at the
expense of extra overhead.
When NetworkManager controls the interface, I think these bits are set correctly
- it is when manual ifup/ifdown is used that the wrong settings result. I will
need to switch my system into manual mode to see if I can find the place where
it goes wrong.
Larry
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.
I did some stack dumps to see what code is changing the RCR. I captured the
following instances:
Type 1, which I think is OK.
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
rtl92cu_set_check_bssid+0x9b/0xc0 [rtl8192cu]
rtl_op_configure_filter+0xd0/0x400 [rtlwifi]
ieee80211_configure_filter+0x15b/0x5c0 [mac80211]
Type 2: This one sets the filter, but it is at the end of scanning and should be OK.
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002ace) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
rtl92cu_set_check_bssid+0x56/0xc0 [rtl8192cu]
rtl_op_configure_filter+0x2d3/0x400 [rtlwifi]
ieee80211_configure_filter+0x15b/0x5c0 [mac80211]
__ieee80211_scan_completed+0x168/0x660 [mac80211]
Type 3: This one clears the filter, and is also at the end of scanning. I don't
understand it yet. It seems that the filter should still be set.
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
_rtl92cu_set_check_bssid+0xce/0x190 [rtl8192cu]
rtl92cu_set_network_type+0x2f/0x40 [rtl8192cu]
rtl_op_sw_scan_complete+0x89/0xd0 [rtlwifi]
Type 4: This one occurred when the module was removed. It sets the filter, but
that seems to be wrong. It probably does not matter as reloading the driver will
clear those bits,
rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002ace) ###
Call Trace:
rtl92cu_set_hw_reg+0x60e/0x11d0 [rtl8192cu]
_rtl92cu_set_check_bssid+0x118/0x190 [rtl8192cu]
rtl92cu_set_network_type+0x2f/0x40 [rtl8192cu]
rtl_op_bss_info_changed+0x487/0xaa0 [rtlwifi]
Larry