rtl8192cu goes silent/dead after some time...

rtl8192cu goes silent/dead after some time...

[Jussi Kivilinna]

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

Hello,

I've been trying to get rtl8192cu work on ARM board I got recently.  
While I don't get crashes anymore and I can connect to AP, open  
connections, do short transfers, eventually rtl8192cu goes silent  
(bulk-IN urbs stop completing, no packets received). Bringing  
interface down and back up does not help, I need to rmmod/modprobe to  
wake the device.

I noticed that, when doing large transfer (with iperf), "signal avg"  
reading from iw started to behave interestingly...

Idle (0.1 sec interval):
         signal avg:     -75 dBm
         signal avg:     -68 dBm
         signal avg:     -72 dBm
         signal avg:     -73 dBm
         signal avg:     -74 dBm
         signal avg:     -75 dBm
         signal avg:     -75 dBm
         signal avg:     -75 dBm
         signal avg:     -75 dBm
         signal avg:     -74 dBm

While doing TCP transfer, rtl8192cu at RX side (0.1sec intervals):
         signal avg:     -88 dBm
         signal avg:     -13 dBm
         signal avg:     -38 dBm
         signal avg:     100 dBm
         signal avg:     -11 dBm
         signal avg:     122 dBm
         signal avg:     51 dBm
         signal avg:     77 dBm
         signal avg:     -14 dBm
         signal avg:     -18 dBm
         signal avg:     78 dBm
         signal avg:     46 dBm
         signal avg:     -65 dBm
         signal avg:     -103 dBm
         signal avg:     -90 dBm
         signal avg:     88 dBm
         signal avg:     -43 dBm
         signal avg:     -12 dBm

This keeps on until rtl8129cu goes silent.

I have attached kernel log with rtl8192cu loaded with debug=4.  
Connection stops working around timestamp 1377. (Log shows some BUGs  
which do appear with debugging on but not without.)

Apparently triggering this hang becomes much harder to trigger when  
debug=4 is enabled... probably because debug logging increasing CPU  
usage, transfer rate drops to 1Mbit/s and above symptom mostly  
disappears. Without debug=4, RX runs at ~28Mbit/s.

-Jussi


[-- Attachment #2: lsusb.txt --]
[-- Type: text/plain, Size: 3178 bytes --]

Bus 004 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0x8176 RTL8188CUS 802.11n WLAN Adapter
  bcdDevice            2.00
  iManufacturer           1 Realtek
  iProduct                2 802.11n WLAN Adapter
  iSerial                 3 00e04c000001
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           46
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)


[-- Attachment #3: log.txt.xz --]
[-- Type: application/x-xz, Size: 49856 bytes --]

Re: rtl8192cu goes silent/dead after some time...

[Larry Finger]

On 02/25/2013 10:51 AM, Jussi Kivilinna wrote:
> Hello,
>
> I've been trying to get rtl8192cu work on ARM board I got recently. While I
> don't get crashes anymore and I can connect to AP, open connections, do short
> transfers, eventually rtl8192cu goes silent (bulk-IN urbs stop completing, no
> packets received). Bringing interface down and back up does not help, I need to
> rmmod/modprobe to wake the device.
>
> I noticed that, when doing large transfer (with iperf), "signal avg" reading
> from iw started to behave interestingly...
>
> Idle (0.1 sec interval):
>          signal avg:     -75 dBm
>          signal avg:     -68 dBm
>          signal avg:     -72 dBm
>          signal avg:     -73 dBm
>          signal avg:     -74 dBm
>          signal avg:     -75 dBm
>          signal avg:     -75 dBm
>          signal avg:     -75 dBm
>          signal avg:     -75 dBm
>          signal avg:     -74 dBm
>
> While doing TCP transfer, rtl8192cu at RX side (0.1sec intervals):
>          signal avg:     -88 dBm
>          signal avg:     -13 dBm
>          signal avg:     -38 dBm
>          signal avg:     100 dBm
>          signal avg:     -11 dBm
>          signal avg:     122 dBm
>          signal avg:     51 dBm
>          signal avg:     77 dBm
>          signal avg:     -14 dBm
>          signal avg:     -18 dBm
>          signal avg:     78 dBm
>          signal avg:     46 dBm
>          signal avg:     -65 dBm
>          signal avg:     -103 dBm
>          signal avg:     -90 dBm
>          signal avg:     88 dBm
>          signal avg:     -43 dBm
>          signal avg:     -12 dBm
>
> This keeps on until rtl8129cu goes silent.
>
> I have attached kernel log with rtl8192cu loaded with debug=4. Connection stops
> working around timestamp 1377. (Log shows some BUGs which do appear with
> debugging on but not without.)
>
> Apparently triggering this hang becomes much harder to trigger when debug=4 is
> enabled... probably because debug logging increasing CPU usage, transfer rate
> drops to 1Mbit/s and above symptom mostly disappears. Without debug=4, RX runs
> at ~28Mbit/s.

Thanks for the log and the signal average data. All of the BUGs come from a 
single debug statement in the source. I will delete that trace call.

Realtek has apparently stopped development on the mac80211-based driver. The 
latest version is dated 2011.02.10. The latest driver with Realtek's softmac 
stack is 2012.06.22. As the two drivers are totally different, porting the fixes 
from one to the other are quite difficult.

My plan is to try to improve rtl8192cu; however, if that does not work, I will 
pull it in favor of the version with Realtek's stack. It will, of course, need 
to be placed in staging. The downside is that a number of distros do not install 
drivers from staging, and all the mac80211 features will be lost. That is the 
worst case outcome.

Larry

Re: rtl8192cu goes silent/dead after some time...

[Jussi Kivilinna]

Hello,

I've made some more testing, and noticed that device does not go  
completely silent...

After device stops working in managed mode, I added monitor interface  
and it receives beacons and other broadcast packets. However if I turn  
on any monitor interface for device, managed interface is silent and  
monitor interface only receives probe requests.

Before this condition appears, there is "wlan0: deauthenticated from  
xx:xx:xx:xx:xx:xx (Reason: 2)" with reconnect to AP:

[   22.910000] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[   22.940000] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[   22.980000] wlan0: authenticated
[   23.000000] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[   23.030000] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411  
status=0 aid=2)
[   23.040000] wlan0: associated
[   23.050000] cfg80211: Calling CRDA for country: FI
[   23.080000] cfg80211: Updating information on frequency 2412 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.090000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.100000] cfg80211: Updating information on frequency 2417 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.110000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.120000] cfg80211: Updating information on frequency 2422 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.130000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.140000] cfg80211: Updating information on frequency 2427 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.150000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.160000] cfg80211: Updating information on frequency 2432 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.170000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.180000] cfg80211: Updating information on frequency 2437 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.190000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.200000] cfg80211: Updating information on frequency 2442 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.210000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.220000] cfg80211: Updating information on frequency 2447 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.230000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.240000] cfg80211: Updating information on frequency 2452 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.250000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.260000] cfg80211: Updating information on frequency 2457 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.270000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.280000] cfg80211: Updating information on frequency 2462 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.290000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.300000] cfg80211: Updating information on frequency 2467 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.310000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.320000] cfg80211: Updating information on frequency 2472 MHz  
for a 20 MHz width channel with regulatory rule:
[   23.330000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A  
mBi, 2000 mBm)
[   23.340000] cfg80211: Disabling freq 2484 MHz
[   23.350000] cfg80211: Regulatory domain changed to country: FI
[   23.360000] cfg80211:   (start_freq - end_freq @ bandwidth),  
(max_antenna_gain, max_eirp)
[   23.370000] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz),  
(N/A, 2000 mBm)
[   23.380000] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz),  
(N/A, 2000 mBm)
[   23.390000] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz),  
(N/A, 2000 mBm)
[   23.400000] cfg80211:   (5490000 KHz - 5710000 KHz @ 40000 KHz),  
(N/A, 2700 mBm)

After which silence strikes. So maybe that signal average bug is not  
related to this connection issue, but driver/device goes in to some  
mixed up state because of disconnect/reconnect?

-Jussi

Quoting Larry Finger <Larry.Finger@lwfinger.net>:

>
> Thanks for the log and the signal average data. All of the BUGs come  
> from a single debug statement in the source. I will delete that  
> trace call.
>
> Realtek has apparently stopped development on the mac80211-based  
> driver. The latest version is dated 2011.02.10. The latest driver  
> with Realtek's softmac stack is 2012.06.22. As the two drivers are  
> totally different, porting the fixes from one to the other are quite  
> difficult.
>
> My plan is to try to improve rtl8192cu; however, if that does not  
> work, I will pull it in favor of the version with Realtek's stack.  
> It will, of course, need to be placed in staging. The downside is  
> that a number of distros do not install drivers from staging, and  
> all the mac80211 features will be lost. That is the worst case  
> outcome.
>
> Larry
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

Quoting Jussi Kivilinna <jussi.kivilinna@iki.fi>:

> Hello,
>
> I've made some more testing, and noticed that device does not go  
> completely silent...

I can now reproduce this hang without large transfers with 'ifconfig  
wlan0 up; iw dev wlan0 scan & sleep 0.02; ifconfig wlan0 down'.

The large tranfers caused connection to fail sometimes, leading  
wpa_supplicant to issue scan that is aborted. Manually aborting scan  
causes device/driver go into this partial silence state too (with  
beacons/probe requests received).

So maybe driver does not do all the required clean-ups for aborted scans?

-Jussi

>
> After device stops working in managed mode, I added monitor  
> interface and it receives beacons and other broadcast packets.  
> However if I turn on any monitor interface for device, managed  
> interface is silent and monitor interface only receives probe  
> requests.
>
> Before this condition appears, there is "wlan0: deauthenticated from  
> xx:xx:xx:xx:xx:xx (Reason: 2)" with reconnect to AP:
>
<snip>
>
> After which silence strikes. So maybe that signal average bug is not  
> related to this connection issue, but driver/device goes in to some  
> mixed up state because of disconnect/reconnect?
>
> -Jussi
>
> Quoting Larry Finger <Larry.Finger@lwfinger.net>:
>
>>
>> Thanks for the log and the signal average data. All of the BUGs  
>> come from a single debug statement in the source. I will delete  
>> that trace call.
>>
>> Realtek has apparently stopped development on the mac80211-based  
>> driver. The latest version is dated 2011.02.10. The latest driver  
>> with Realtek's softmac stack is 2012.06.22. As the two drivers are  
>> totally different, porting the fixes from one to the other are  
>> quite difficult.
>>
>> My plan is to try to improve rtl8192cu; however, if that does not  
>> work, I will pull it in favor of the version with Realtek's stack.  
>> It will, of course, need to be placed in staging. The downside is  
>> that a number of distros do not install drivers from staging, and  
>> all the mac80211 features will be lost. That is the worst case  
>> outcome.
>>
>> Larry
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

On 03/11/2013 02:17 PM, Jussi Kivilinna wrote:
> Quoting Jussi Kivilinna <jussi.kivilinna@iki.fi>:
>
>> Hello,
>>
>> I've made some more testing, and noticed that device does not go completely
>> silent...
>
> I can now reproduce this hang without large transfers with 'ifconfig wlan0 up;
> iw dev wlan0 scan & sleep 0.02; ifconfig wlan0 down'.
>
> The large tranfers caused connection to fail sometimes, leading wpa_supplicant
> to issue scan that is aborted. Manually aborting scan causes device/driver go
> into this partial silence state too (with beacons/probe requests received).
>
> So maybe driver does not do all the required clean-ups for aborted scans?

Have you tested 'ifconfig wlan0 up & sleep 0.02; ifconfig wlan0 down'? Is the 
scan part absolutely necessary?

Larry

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

Quoting Larry Finger <Larry.Finger@lwfinger.net>:

> On 03/11/2013 02:17 PM, Jussi Kivilinna wrote:
>> Quoting Jussi Kivilinna <jussi.kivilinna@iki.fi>:
>>
>>> Hello,
>>>
>>> I've made some more testing, and noticed that device does not go completely
>>> silent...
>>
>> I can now reproduce this hang without large transfers with  
>> 'ifconfig wlan0 up;
>> iw dev wlan0 scan & sleep 0.02; ifconfig wlan0 down'.
>>
>> The large tranfers caused connection to fail sometimes, leading  
>> wpa_supplicant
>> to issue scan that is aborted. Manually aborting scan causes  
>> device/driver go
>> into this partial silence state too (with beacons/probe requests received).
>>
>> So maybe driver does not do all the required clean-ups for aborted scans?
>
> Have you tested 'ifconfig wlan0 up & sleep 0.02; ifconfig wlan0  
> down'? Is the scan part absolutely necessary?

Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02;  
ifconfig wlan0 down' is enough. Just doing 'ifconfig wlan0 up;  
ifconfig wlan0 down' is enough.

I also tested with monitor interface opened for tcpdump while doing  
'ifconfig up&down' on wlan0 and still triggered the issue. Then  
turning wlan0 up resulted monitor interface only receiving probe  
requests from nearby devices.

-Jussi

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

On 03/11/2013 04:06 PM, Jussi Kivilinna wrote:
>
> Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02; ifconfig
> wlan0 down' is enough. Just doing 'ifconfig wlan0 up; ifconfig wlan0 down' is
> enough.
>
> I also tested with monitor interface opened for tcpdump while doing 'ifconfig
> up&down' on wlan0 and still triggered the issue. Then turning wlan0 up resulted
> monitor interface only receiving probe requests from nearby devices.

Thanks for the test. Something is not being cleared in the 
authentication/association/keying process.

Larry

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

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

On 03/11/2013 04:06 PM, Jussi Kivilinna wrote:
>
> Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02; ifconfig
> wlan0 down' is enough. Just doing 'ifconfig wlan0 up; ifconfig wlan0 down' is
> enough.
>
> I also tested with monitor interface opened for tcpdump while doing 'ifconfig
> up&down' on wlan0 and still triggered the issue. Then turning wlan0 up resulted
> monitor interface only receiving probe requests from nearby devices.

I am in the middle of a long-term test of rtl8192ce, which keeps me from running 
tests of rtl8192cu, but I noticed something strange. Does the attached patch 
help? It is compile tested.

Larry


[-- Attachment #2: rtl8192cu_modify_check_bssid --]
[-- Type: text/plain, Size: 1109 bytes --]

Index: linux-2.6/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ linux-2.6/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,7 +1377,23 @@ 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 (rtlpriv->psc.rfpwr_state != ERFON)
+		return;
+
+	if (check_bssid) {
+		reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+		rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
+					      (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
+	} else if (!check_bssid) {
+		reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
+		_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+		rtlpriv->cfg->ops->set_hw_reg(hw,
+					      HW_VAR_RCR, (u8 *) (&reg_rcr));
+	}
 }
 
 /*========================================================================== */

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

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

Quoting Larry Finger <Larry.Finger@lwfinger.net>:

> On 03/11/2013 04:06 PM, Jussi Kivilinna wrote:
>>
>> Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02; ifconfig
>> wlan0 down' is enough. Just doing 'ifconfig wlan0 up; ifconfig  
>> wlan0 down' is
>> enough.
>>
>> I also tested with monitor interface opened for tcpdump while doing  
>> 'ifconfig
>> up&down' on wlan0 and still triggered the issue. Then turning wlan0  
>> up resulted
>> monitor interface only receiving probe requests from nearby devices.
>
> I am in the middle of a long-term test of rtl8192ce, which keeps me  
> from running tests of rtl8192cu, but I noticed something strange.  
> Does the attached patch help? It is compile tested.
>

That patch alone did not help.. however replacing  
_rtl92cu_set_check_bssid() with that new rtl92cu_set_check_bssid()  
does fix the issue (patch attached).

But I think _rtl92cu_set_check_bssid() needs to be rechecked since it  
has '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.

-Jussi


[-- Attachment #2: 01-rtl8192cu_set_network_type_with_new_set_check_bssid.patch --]
[-- Type: text/x-diff, Size: 1946 bytes --]



From: Jussi Kivilinna <jussi.kivilinna@iki.fi>


---
 drivers/net/wireless/rtlwifi/rtl8192cu/hw.c |   31 +++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
index 3c6e18c..ee87201 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,11 +1377,28 @@ void rtl92cu_card_disable(struct ieee80211_hw *hw)
 
 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 (rtlpriv->psc.rfpwr_state != ERFON)
+		return;
+
+	if (check_bssid) {
+		reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+		rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
+					      (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
+	} else if (!check_bssid) {
+		reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
+		_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+		rtlpriv->cfg->ops->set_hw_reg(hw,
+					      HW_VAR_RCR, (u8 *) (&reg_rcr));
+	}
 }
 
 /*========================================================================== */
 
+#if 0
 static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
 			      enum nl80211_iftype type)
 {
@@ -1439,12 +1456,22 @@ static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
 		}
 	}
 }
+#endif
 
 int rtl92cu_set_network_type(struct ieee80211_hw *hw, enum nl80211_iftype type)
 {
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
 	if (_rtl92cu_set_media_status(hw, type))
 		return -EOPNOTSUPP;
-	_rtl92cu_set_check_bssid(hw, type);
+
+	if (rtlpriv->mac80211.link_state == MAC80211_LINKED) {
+		if (type != NL80211_IFTYPE_AP)
+			rtl92cu_set_check_bssid(hw, true);
+	} else {
+		rtl92cu_set_check_bssid(hw, false);
+	}
+
 	return 0;
 }
 

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

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

On 03/12/2013 04:10 AM, Jussi Kivilinna wrote:
>
> That patch alone did not help.. however replacing _rtl92cu_set_check_bssid()
> with that new rtl92cu_set_check_bssid() does fix the issue (patch attached).
>
> But I think _rtl92cu_set_check_bssid() needs to be rechecked since it has
> '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.

I doubt that that IS_NORMAL_CHIP business affects us - the test chips are not 
supposed to be in the wild, but I modified your patch to include that test.

With that patch I am getting watchdog_wq callbacks that force a reconnection 
every 6 seconds, but that is due to other changes in my code. The result is a 
34% loss of pings, but the connection stays up.

Larry



[-- Attachment #2: 01-rtl8192cu_set_network_type_with_new_set_check_bssid.patch --]
[-- Type: text/x-patch, Size: 3848 bytes --]



From: Jussi Kivilinna <jussi.kivilinna@iki.fi>


---
 drivers/net/wireless/rtlwifi/rtl8192cu/hw.c |   31 +++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

Index: wireless-testing-rebased/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
===================================================================
--- wireless-testing-rebased.orig/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ wireless-testing-rebased/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,74 +1377,57 @@ 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() */
-}
-
-/*========================================================================== */
-
-static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
-			      enum nl80211_iftype type)
-{
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
-	u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
 	struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
-	struct rtl_phy *rtlphy = &(rtlpriv->phy);
-	u8 filterout_non_associated_bssid = false;
+	u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
 
-	switch (type) {
-	case NL80211_IFTYPE_ADHOC:
-	case NL80211_IFTYPE_STATION:
-		filterout_non_associated_bssid = true;
-		break;
-	case NL80211_IFTYPE_UNSPECIFIED:
-	case NL80211_IFTYPE_AP:
-	default:
-		break;
-	}
-	if (filterout_non_associated_bssid) {
+	if (rtlpriv->psc.rfpwr_state != ERFON)
+		return;
+
+	if (check_bssid) {
+		u8 tmp;
 		if (IS_NORMAL_CHIP(rtlhal->version)) {
-			switch (rtlphy->current_io_type) {
-			case IO_CMD_RESUME_DM_BY_SCAN:
-				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));
-				break;
-			case IO_CMD_PAUSE_DM_BY_SCAN:
-				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);
-				break;
-			}
+			reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+			tmp = BIT(4);
 		} else {
-			reg_rcr |= (RCR_CBSSID);
-			rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
-						      (u8 *)(&reg_rcr));
-			_rtl92cu_set_bcn_ctrl_reg(hw, 0, (BIT(4)|BIT(5)));
+			reg_rcr |= RCR_CBSSID;
+			tmp = BIT(4) | BIT(5);
 		}
-	} else if (filterout_non_associated_bssid == false) {
+		rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
+					      (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, 0, tmp);
+	} else {
+		u8 tmp;
 		if (IS_NORMAL_CHIP(rtlhal->version)) {
-			reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
-			rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
-						      (u8 *)(&reg_rcr));
-			_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+			reg_rcr &= ~(RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+			tmp = BIT(4);
 		} else {
-			reg_rcr &= (~RCR_CBSSID);
-			rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
-						      (u8 *)(&reg_rcr));
-			_rtl92cu_set_bcn_ctrl_reg(hw, (BIT(4)|BIT(5)), 0);
+			reg_rcr &= ~RCR_CBSSID;
+			tmp = BIT(4) | BIT(5);
 		}
+		reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
+		rtlpriv->cfg->ops->set_hw_reg(hw,
+					      HW_VAR_RCR, (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, tmp, 0);
 	}
 }
 
+/*========================================================================== */
+
 int rtl92cu_set_network_type(struct ieee80211_hw *hw, enum nl80211_iftype type)
 {
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
 	if (_rtl92cu_set_media_status(hw, type))
 		return -EOPNOTSUPP;
-	_rtl92cu_set_check_bssid(hw, type);
+
+	if (rtlpriv->mac80211.link_state == MAC80211_LINKED) {
+		if (type != NL80211_IFTYPE_AP)
+			rtl92cu_set_check_bssid(hw, true);
+	} else {
+		rtl92cu_set_check_bssid(hw, false);
+	}
+
 	return 0;
 }
 

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

On 12.03.2013 18:51, Larry Finger wrote:
> On 03/12/2013 04:10 AM, Jussi Kivilinna wrote:
>>
>> That patch alone did not help.. however replacing
>> _rtl92cu_set_check_bssid()
>> with that new rtl92cu_set_check_bssid() does fix the issue (patch
>> attached).
>>
>> But I think _rtl92cu_set_check_bssid() needs to be rechecked since it has
>> '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.
> 
> I doubt that that IS_NORMAL_CHIP business affects us - the test chips
> are not supposed to be in the wild, but I modified your patch to include
> that test.
> 

Modified patch works here.

> With that patch I am getting watchdog_wq callbacks that force a
> reconnection every 6 seconds, but that is due to other changes in my
> code. The result is a 34% loss of pings, but the connection stays up.
> 

No problems here.. <1% loss and can do large transfers, rtl8192cu being
able to reconnect is connection is dropped.

-Jussi

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

On 03/13/2013 10:11 AM, Alessandro Lannocca wrote:
> Hi, some months ago I reported some bugs about this chipset; now I tried latest stable compat-drivers (3.9-rc2-2-su) with the modified patch by Jussi Kivilinna, and I'm happy to report that it works  with my alfa AWUS036NHR on ubuntu 12.10 with kernel 3.5; The card now sustains multiple connection/disconnection cicles, and doesn't go mute, even after changing mac address.
>
> Some problems still remains:
>
> -led is always solid, no blinking whatsoever.
> -in monitor mode, every client appears as not associated, even when it really is.
> -power/signal strength readings (in networkmanager) seem to be fuzzy, almost inverse; nearest APs have lowest signal representation, while farest ones get strongest signal (this could very well be a networkmanager bug/misrepresentation); signal appears normal when the card is connected (only the reading relative to the connected AP)
>
> I know you're probably understaffed and have a lot of work to do, however if you're willing to have a look at this secondary problems (Mr. Finger perhaps), I'm willing to recompile, test and report back to help squash these bugs.
>
> I'm attaching a debug=5 log to show my tests.
>
> As of now, this chipset/card is usable (signal reading is annoying btw)

Thanks for the report. That patch will be pushed upstream in a few minutes and 
will be backported to stable withing a few weeks. I am happy to hear that the 
patch works with your Alfa AWUS036NHR. In my limited testing with that device, 
it failed to connect. I feared that the RTL8192RU differed from the RTL8192CU.

I know that improper operation of the LEDs and screwy signal levels are 
annoying, and I will get to them when I can. At the moment, however, I have more 
important problems to solve.

Thanks,

Larry

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Alessandro Lannocca]

Hi, some months ago I reported some bugs about this chipset; now I tried latest stable compat-drivers (3.9-rc2-2-su) with the modified patch by Jussi Kivilinna, and I'm happy to report that it works  with my alfa AWUS036NHR on ubuntu 12.10 with kernel 3.5; The card now sustains multiple connection/disconnection cicles, and doesn't go mute, even after changing mac address.

Some problems still remains: 

-led is always solid, no blinking whatsoever.
-in monitor mode, every client appears as not associated, even when it really is.
-power/signal strength readings (in networkmanager) seem to be fuzzy, almost inverse; nearest APs have lowest signal representation, while farest ones get strongest signal (this could very well be a networkmanager bug/misrepresentation); signal appears normal when the card is connected (only the reading relative to the connected AP)

I know you're probably understaffed and have a lot of work to do, however if you're willing to have a look at this secondary problems (Mr. Finger perhaps), I'm willing to recompile, test and report back to help squash these bugs.

I'm attaching a debug=5 log to show my tests.

As of now, this chipset/card is usable (signal reading is annoying btw)

Thank you all for your work.

Alessandro Lannocca

-----Messaggio originale-----
Da: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] Per conto di Jussi Kivilinna
Inviato: martedì 12 marzo 2013 20.49
A: Larry Finger
Cc: linux-wireless@vger.kernel.org; 'George0505'
Oggetto: Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

On 12.03.2013 18:51, Larry Finger wrote:
> On 03/12/2013 04:10 AM, Jussi Kivilinna wrote:
>>
>> That patch alone did not help.. however replacing
>> _rtl92cu_set_check_bssid()
>> with that new rtl92cu_set_check_bssid() does fix the issue (patch 
>> attached).
>>
>> But I think _rtl92cu_set_check_bssid() needs to be rechecked since it 
>> has '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.
> 
> I doubt that that IS_NORMAL_CHIP business affects us - the test chips 
> are not supposed to be in the wild, but I modified your patch to 
> include that test.
> 

Modified patch works here.

> With that patch I am getting watchdog_wq callbacks that force a 
> reconnection every 6 seconds, but that is due to other changes in my 
> code. The result is a 34% loss of pings, but the connection stays up.
> 

No problems here.. <1% loss and can do large transfers, rtl8192cu being able to reconnect is connection is dropped.

-Jussi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html