Problem with the rtl8192cu - kernelmodule after ifdown, ifup

Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Markus Königshaus]

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@lwfinger.net>
author:         Georgia <georgia@realtek.com>
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

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Larry Finger]

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@lwfinger.net>
> author: Georgia <georgia@realtek.com>
> 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

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Nicu Pavel]

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

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Nicu Pavel]

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

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Joshua Roys]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5045 bytes --]

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Larry Finger]

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

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 3707 bytes --]

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

[-- Attachment #2: rtl8192cu_set_check_bssid --]
[-- Type: text/plain, Size: 1653 bytes --]

Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,12 +1377,27 @@ void rtl92cu_card_disable(struct ieee802
 
 void rtl92cu_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
-	/* dummy routine needed for callback from rtl_op_configure_filter() */
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
+
+	if (!check_bssid) {
+		reg_rcr &= ~(RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+			rtlpriv->cfg->ops->set_hw_reg(hw,
+					 HW_VAR_RCR, (u8 *)(&reg_rcr));
+			/* disable update TSF */
+			_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+	} else {
+		reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+		rtlpriv->cfg->ops->set_hw_reg(hw,
+				 HW_VAR_RCR, (u8 *)(&reg_rcr));
+		/* enable update TSF */
+		_rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
+	}
 }
 
 /*========================================================================== */
 
-static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
+void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
 			      enum nl80211_iftype type)
 {
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -1869,7 +1884,7 @@ void rtl92cu_set_hw_reg(struct ieee80211
 	case HW_VAR_RCR:{
 			rtl_write_dword(rtlpriv, REG_RCR, ((u32 *) (val))[0]);
 			mac->rx_conf = ((u32 *) (val))[0];
-			RT_TRACE(rtlpriv, COMP_RECV, DBG_DMESG,
+			RT_TRACE(rtlpriv, COMP_RECV, DBG_EMERG,
 				 "### Set RCR(0x%08x) ###\n", mac->rx_conf);
 			break;
 		}

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[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

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

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


[-- Attachment #2: rtl8192cu_set_check_bssid --]
[-- Type: text/plain, Size: 937 bytes --]

Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1867,8 +1867,14 @@ void rtl92cu_set_hw_reg(struct ieee80211
 			break;
 		}
 	case HW_VAR_RCR:{
-			rtl_write_dword(rtlpriv, REG_RCR, ((u32 *) (val))[0]);
 			mac->rx_conf = ((u32 *) (val))[0];
+			/* whenever the driver sets bits enabling only a
+			 * specific BSSID for beacons or data, a failure
+			 * occurs. Thus we do not allow those bits to be set */
+			if (mac->rx_conf & (RCR_CBSSID_BCN | RCR_CBSSID_DATA))
+				mac->rx_conf &= ~(RCR_CBSSID_BCN |
+						  RCR_CBSSID_DATA);
+			rtl_write_dword(rtlpriv, REG_RCR, ((u32 *) (val))[0]);
 			RT_TRACE(rtlpriv, COMP_RECV, DBG_DMESG,
 				 "### Set RCR(0x%08x) ###\n", mac->rx_conf);
 			break;

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Nicu Pavel]

Hi,

On Fri, Apr 6, 2012 at 10:54 PM, Larry Finger <Larry.Finger@lwfinger.net> 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
>

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Larry Finger]

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

Re: Problem with the rtl8192cu - kernelmodule after ifdown, ifup

[Nicu Pavel]

Hi,

On Mon, Apr 9, 2012 at 7:03 PM, Larry Finger <Larry.Finger@lwfinger.net> 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