* rtl8192cu goes silent/dead after some time...
@ 2013-02-25 16:51 Jussi Kivilinna
2013-02-27 19:05 ` Larry Finger
0 siblings, 1 reply; 13+ messages in thread
From: Jussi Kivilinna @ 2013-02-25 16:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Larry Finger
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: rtl8192cu goes silent/dead after some time...
2013-02-25 16:51 rtl8192cu goes silent/dead after some time Jussi Kivilinna
@ 2013-02-27 19:05 ` Larry Finger
2013-03-10 12:29 ` Jussi Kivilinna
0 siblings, 1 reply; 13+ messages in thread
From: Larry Finger @ 2013-02-27 19:05 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, 'George0505'
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rtl8192cu goes silent/dead after some time...
2013-02-27 19:05 ` Larry Finger
@ 2013-03-10 12:29 ` Jussi Kivilinna
2013-03-11 19:17 ` rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...) Jussi Kivilinna
0 siblings, 1 reply; 13+ messages in thread
From: Jussi Kivilinna @ 2013-03-10 12:29 UTC (permalink / raw)
To: Larry Finger; +Cc: Jussi Kivilinna, linux-wireless, 'George0505'
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
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-10 12:29 ` Jussi Kivilinna
@ 2013-03-11 19:17 ` Jussi Kivilinna
2013-03-11 20:25 ` Larry Finger
0 siblings, 1 reply; 13+ messages in thread
From: Jussi Kivilinna @ 2013-03-11 19:17 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: Larry Finger, Jussi Kivilinna, linux-wireless,
'George0505'
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
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-11 19:17 ` rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...) Jussi Kivilinna
@ 2013-03-11 20:25 ` Larry Finger
2013-03-11 21:06 ` Jussi Kivilinna
0 siblings, 1 reply; 13+ messages in thread
From: Larry Finger @ 2013-03-11 20:25 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: Jussi Kivilinna, linux-wireless, 'George0505'
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-11 20:25 ` Larry Finger
@ 2013-03-11 21:06 ` Jussi Kivilinna
2013-03-11 21:10 ` Larry Finger
2013-03-11 21:31 ` Larry Finger
0 siblings, 2 replies; 13+ messages in thread
From: Jussi Kivilinna @ 2013-03-11 21:06 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, 'George0505'
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-11 21:06 ` Jussi Kivilinna
@ 2013-03-11 21:10 ` Larry Finger
2013-03-11 21:31 ` Larry Finger
1 sibling, 0 replies; 13+ messages in thread
From: Larry Finger @ 2013-03-11 21:10 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, 'George0505'
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-11 21:06 ` Jussi Kivilinna
2013-03-11 21:10 ` Larry Finger
@ 2013-03-11 21:31 ` Larry Finger
2013-03-12 9:10 ` Jussi Kivilinna
1 sibling, 1 reply; 13+ messages in thread
From: Larry Finger @ 2013-03-11 21:31 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, 'George0505'
[-- 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 *) (®_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 *) (®_rcr));
+ }
}
/*========================================================================== */
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-11 21:31 ` Larry Finger
@ 2013-03-12 9:10 ` Jussi Kivilinna
2013-03-12 16:51 ` Larry Finger
0 siblings, 1 reply; 13+ messages in thread
From: Jussi Kivilinna @ 2013-03-12 9:10 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, 'George0505'
[-- 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 *) (®_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 *) (®_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;
}
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-12 9:10 ` Jussi Kivilinna
@ 2013-03-12 16:51 ` Larry Finger
2013-03-12 19:49 ` Jussi Kivilinna
0 siblings, 1 reply; 13+ messages in thread
From: Larry Finger @ 2013-03-12 16:51 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, 'George0505'
[-- 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 *)(®_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 *)(®_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 *)(®_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 *) (®_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 *)(®_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 *)(®_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 *) (®_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;
}
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-12 16:51 ` Larry Finger
@ 2013-03-12 19:49 ` Jussi Kivilinna
0 siblings, 0 replies; 13+ messages in thread
From: Jussi Kivilinna @ 2013-03-12 19:49 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, 'George0505'
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
@ 2013-03-13 15:11 Alessandro Lannocca
2013-03-13 15:25 ` Larry Finger
0 siblings, 1 reply; 13+ messages in thread
From: Alessandro Lannocca @ 2013-03-13 15:11 UTC (permalink / raw)
To: 'Jussi Kivilinna', 'Larry Finger'
Cc: linux-wireless, 'George0505'
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
2013-03-13 15:11 Alessandro Lannocca
@ 2013-03-13 15:25 ` Larry Finger
0 siblings, 0 replies; 13+ messages in thread
From: Larry Finger @ 2013-03-13 15:25 UTC (permalink / raw)
To: Alessandro Lannocca
Cc: 'Jussi Kivilinna', linux-wireless, 'George0505'
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-03-13 15:25 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-25 16:51 rtl8192cu goes silent/dead after some time Jussi Kivilinna
2013-02-27 19:05 ` Larry Finger
2013-03-10 12:29 ` Jussi Kivilinna
2013-03-11 19:17 ` rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...) Jussi Kivilinna
2013-03-11 20:25 ` Larry Finger
2013-03-11 21:06 ` Jussi Kivilinna
2013-03-11 21:10 ` Larry Finger
2013-03-11 21:31 ` Larry Finger
2013-03-12 9:10 ` Jussi Kivilinna
2013-03-12 16:51 ` Larry Finger
2013-03-12 19:49 ` Jussi Kivilinna
-- strict thread matches above, loose matches on Subject: below --
2013-03-13 15:11 Alessandro Lannocca
2013-03-13 15:25 ` Larry Finger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).