Dear all,
I have no idea who is responsible or how to continue, but the rtl driver
is in such a dire state and it seems nobody cares. I have no reported
several times about it, without the slightest reactions. How can it be
that after so many years we still not be able to do wireless.
Ok, here are some facts to make people happy:
kernel 3.7.0
rtl8192se
AP infos:distance: 3m
NEC Aterm WR8600N ATERM-B45459
firmware 1.0.11
Network card is built in into a Lenovo Thinkpad Edge
# lspci -nnv -s 03:00.0
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB
Wireless LAN Controller [10ec:8172] (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:e020]
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f0500000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"norbujp"
Mode:Managed Frequency:2.442 GHz Access Point: 00:3A:9D:B4:54:5A
Bit Rate=150 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-35 dBm
Effects:
- either does not associate at all with the AP
- or the kernel believes it is associated and packages ping to the router
get stuck for up to 50+ seconds!!!
- the kernel believes everything is fine but actually nothing gets out
(Destination unreachable)
- wild ping time up-down:
64 bytes from 192.168.0.1: icmp_req=73 ttl=255 time=3.05 ms
64 bytes from 192.168.0.1: icmp_req=74 ttl=255 time=6.42 ms
64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=1.21 ms
64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=6808 ms
64 bytes from 192.168.0.1: icmp_req=77 ttl=255 time=5800 ms
64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=4792 ms
64 bytes from 192.168.0.1: icmp_req=79 ttl=255 time=3784 ms
64 bytes from 192.168.0.1: icmp_req=80 ttl=255 time=2776 ms
64 bytes from 192.168.0.1: icmp_req=81 ttl=255 time=1768 ms
64 bytes from 192.168.0.1: icmp_req=82 ttl=255 time=760 ms
64 bytes from 192.168.0.1: icmp_req=83 ttl=255 time=2.19 ms
64 bytes from 192.168.0.1: icmp_req=84 ttl=255 time=1.67 ms
64 bytes from 192.168.0.1: icmp_req=85 ttl=255 time=4.99 ms
64 bytes from 192.168.0.1: icmp_req=86 ttl=255 time=1.40 ms
64 bytes from 192.168.0.1: icmp_req=87 ttl=255 time=583 ms
64 bytes from 192.168.0.1: icmp_req=88 ttl=255 time=4.96 ms
64 bytes from 192.168.0.1: icmp_req=89 ttl=255 time=1.26 ms
Then, when one tries to reset the driver by echoing 1 onto /sys/debug/.../reset
it hoses the driver even more, going into DMAR fault:
Dec 22 23:37:35 tofuschnitzel kernel: [ 3383.668663] dmar: DRHD: handling fault status reg 2
Dec 22 23:37:35 tofuschnitzel kernel: [ 3383.668674] dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr fff35000
Dec 22 23:37:35 tofuschnitzel kernel: [ 3383.668674] DMAR:[fault reason 06] PTE Read access is not set
Dec 22 23:37:36 tofuschnitzel kernel: [ 3384.666158] rtlwifi:rtl_pci_tx():<300-1> No more TX desc@1, ring->idx = 9, idx = 9, skb_queue_len = 0x0
Dec 22 23:37:37 tofuschnitzel kernel: [ 3385.680919] rtlwifi:rtl_pci_tx():<600-1> No more TX desc@1, ring->idx = 9, idx = 9, skb_queue_len = 0x0
Dec 22 23:37:38 tofuschnitzel kernel: [ 3386.677098] rtlwifi:rtl_pci_tx():<300-1> No more TX desc@1, ring->idx = 9, idx = 9, skb_queue_len = 0x0
Dec 22 23:37:39 tofuschnitzel kernel: [ 3387.674602] rtlwifi:rtl_pci_tx():<300-1> No more TX desc@1, ring->idx = 9, idx = 9, skb_queue_len = 0x0
Dec 22 23:37:40 tofuschnitzel kernel: [ 3388.689394] rtlwifi:rtl_pci_tx():<600-1> No more TX desc@1, ring->idx = 9, idx = 9, skb_queue_len = 0x0
Dec 22 23:37:41 tofuschnitzel kernel: [ 3389.685531] rtlwifi:rtl_pci_tx():<300-1> No more TX desc@1, ring->idx = 9, idx = 9, skb_queue_len = 0x0
Then it often hangs in endless loops where it does not associate:
Dec 22 23:43:11 tofuschnitzel kernel: [ 3718.925859] wlan0: authentication with 00:3a:9d:b4:54:5a timed out
Dec 22 23:43:11 tofuschnitzel kernel: [ 3718.925954] rtlwifi:rtl_op_bss_info_changed():<0-0> 00:00:00:00:00:00
Dec 22 23:43:11 tofuschnitzel NetworkManager[7546]: <info> (wlan0): supplicant interface state: authenticating -> disconnected
Dec 22 23:43:11 tofuschnitzel kernel: [ 3719.025581] rtl8192se:rtl92s_phy_set_rf_power_state():<0-0> IPS Set eRf nic disable
Dec 22 23:43:11 tofuschnitzel NetworkManager[7546]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.089498] rtl8192se:rtl92s_phy_set_rf_power_state():<0-1> IPS Set eRf nic enable
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.112723] rtl8192se:_rtl92se_macconfig_after_fwdownload():<0-1> EFUSE CONFIG OK
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.112726] rtl8192se:_rtl92se_macconfig_after_fwdownload():<0-1> OK
^LDec 22 23:43:12 tofuschnitzel wpa_supplicant[4641]: wlan0: SME: Trying to authenticate with 00:3a:9d:b4:54:5a (SSID='norbujp' freq=2447 MHz)
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.996208] wlan0: authenticate with 00:3a:9d:b4:54:5a
Dec 22 23:43:12 tofuschnitzel NetworkManager[7546]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015206] rtlwifi:rtl_op_bss_info_changed():<0-0> 00:3a:9d:b4:54:5a
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015285] wlan0: send auth to 00:3a:9d:b4:54:5a (try 1/3)
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015301] rtlwifi:rtl_pci_tx():<200-1> MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.218612] wlan0: send auth to 00:3a:9d:b4:54:5a (try 2/3)
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.218630] rtlwifi:rtl_pci_tx():<200-1> MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.422100] wlan0: send auth to 00:3a:9d:b4:54:5a (try 3/3)
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.422120] rtlwifi:rtl_pci_tx():<200-1> MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.625545] wlan0: authentication with 00:3a:9d:b4:54:5a timed out
==================
It seems that often when something happens it is related to WPA Group rekeying or somethin, because
immediately afterwards it starts hanging.
Dec 22 23:55:50 tofuschnitzel wpa_supplicant[4650]: wlan0: WPA: Group rekeying completed with 00:3a:9d:b4:54:5a [GTK=CCMP]
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278193] rtlwifi:rtl_op_set_key():<0-0> Disabling hardware based encryption for keyidx: 1, mac: ff:ff:ff
:ff:ff:ff
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278200] rtlwifi:rtl_op_set_key():<0-0> alg:CCMP
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278203] rtlwifi:rtl_op_set_key():<
0-0> disable key delete one entry
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278206] rtlwifi:rtl_cam_delete_one_entry():<0-0> key_idx:1
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278209] rtlwifi:rtl_cam_delete_one_entry():<0-0> rtl_cam_delete_one_entry(): WRITE A4: 0
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278212] rtlwifi:rtl_cam_delete_one_entry():<0-0> rtl_cam_delete_one_entry(): WRITE A0: 80010008
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278275] rtlwifi:rtl_op_set_key():<0-0> Using hardware based encryption for keyidx: 1, mac: ff:ff:ff:ff:ff:ff
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278278] rtlwifi:rtl_op_set_key():<0-0> alg:CCMP
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278281] rtlwifi:rtl_op_set_key():<0-0> set enable_hw_sec, key_type:4(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5)
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278284] rtlwifi:rtl_op_set_key():<0-0> set group key
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278288] rtl8192se:rtl92se_set_key():<0-0> add one entry
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278290] rtl8192se:rtl92se_set_key():<0-0> set group key
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278891] rtlwifi:rtl_cam_add_one_entry():<0-0> <===
Dec 22 23:55:52 tofuschnitzel kernel: [ 489.272265] wlan0: deauthenticated from 00:3a:9d:b4:54:5a (Reason: 2)
========================
Another strange message I got was this beautiful one:
Dec 22 23:45:55 tofuschnitzel kernel: [ 3882.413599] rtl8192se:rtl92s_phy_set_rf_power_state():<0-1> awake, sleeped:3591952 ms state_inap:0
***sleeped:3591952 ms***
This is *VERY* close to exactely 1 hours 60*60 = 360000 ms .... whatever that might be....
================
I don't know what other information I can provide.
I don't know if there is anyone who feels responsible.
I am willing to test and provide more data.
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
CRANLEIGH (n.)
A mood of irrational irritation with everyone and everything.
--- Douglas Adams, The Meaning of Liff
On 12/22/2012 11:49 PM, Mike Galbraith wrote:
> On Sun, 2012-12-23 at 00:09 +0900, Norbert Preining wrote:
>
>> Network card is built in into a Lenovo Thinkpad Edge
>
> Toshiba Satellite.
>> # lspci -nnv -s 03:00.0
>> 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB
>> Wireless LAN Controller [10ec:8172] (rev 10)
>> Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:e020]
>
> [10ec:8181] here.
>
>> Effects:
>> - either does not associate at all with the AP
>> - or the kernel believes it is associated and packages ping to the router
>> get stuck for up to 50+ seconds!!!
>> - the kernel believes everything is fine but actually nothing gets out
>> (Destination unreachable)
>> - wild ping time up-down:
>> 64 bytes from 192.168.0.1: icmp_req=73 ttl=255 time=3.05 ms
>> 64 bytes from 192.168.0.1: icmp_req=74 ttl=255 time=6.42 ms
>> 64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=1.21 ms
>> 64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=6808 ms
>> 64 bytes from 192.168.0.1: icmp_req=77 ttl=255 time=5800 ms
>> 64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=4792 ms
>
> ...
>
> Looks a lot like my driver experience with older kernels, I had to use
> the external driver in the rare event that I needed wireless to work.
> The in tree driver works peachy these days (needed it recently, was
> pleasantly surprised when it _just worked_, not even a hiccup), so
> somebody cared, gave at least the 10ec:8181 bits some serious love.
Note, the RTL8188CE uses rtl8192ce, while the RTL8191SE uses rtl8192se. They
share the underlying plumbing in driver rtlwifi, but the rest is completely
different.
The reason that rtl8192ce now works with your device is that the so-called B-Cut
chip was not supported until recently. The fix required 2 patches. The first was
simple enough to be backported to stable; however the second was too invasive
for that. Accordingly the second part had to wait for kernel 3.7.
Larry
On Sun, 2012-12-23 at 00:09 +0900, Norbert Preining wrote:
> Network card is built in into a Lenovo Thinkpad Edge
Toshiba Satellite.
> # lspci -nnv -s 03:00.0
> 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB
> Wireless LAN Controller [10ec:8172] (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:e020]
[10ec:8181] here.
> Effects:
> - either does not associate at all with the AP
> - or the kernel believes it is associated and packages ping to the router
> get stuck for up to 50+ seconds!!!
> - the kernel believes everything is fine but actually nothing gets out
> (Destination unreachable)
> - wild ping time up-down:
> 64 bytes from 192.168.0.1: icmp_req=73 ttl=255 time=3.05 ms
> 64 bytes from 192.168.0.1: icmp_req=74 ttl=255 time=6.42 ms
> 64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=1.21 ms
> 64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=6808 ms
> 64 bytes from 192.168.0.1: icmp_req=77 ttl=255 time=5800 ms
> 64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=4792 ms
...
Looks a lot like my driver experience with older kernels, I had to use
the external driver in the rare event that I needed wireless to work.
The in tree driver works peachy these days (needed it recently, was
pleasantly surprised when it _just worked_, not even a hiccup), so
somebody cared, gave at least the 10ec:8181 bits some serious love.
-Mike
On 12/22/2012 09:09 AM, Norbert Preining wrote:
> Dear all,
>
> I have no idea who is responsible or how to continue, but the rtl driver
> is in such a dire state and it seems nobody cares. I have no reported
> several times about it, without the slightest reactions. How can it be
> that after so many years we still not be able to do wireless.
>
> Ok, here are some facts to make people happy:
> kernel 3.7.0
> rtl8192se
> AP infos:distance: 3m
> NEC Aterm WR8600N ATERM-B45459
> firmware 1.0.11
It is not that no one cares; however, your attitude does nothing to induce me to
work on this problem. The facts are not needed "to make people happy", they are
necessary to try to reproduce the problem. If I cannot make it happen here, then
I cannot fix it. Also, remember that I am a volunteer. I get nothing from
Realtek but starting code of varying quality and some sample chips. At least my
versions do not crash your computer.
Your subject for the E-mails certainly defeats any attempt to search. There is
no driver named "rtl".
As I told you in a previous mailing, my system shows none of the symptoms that
you see. I have tested all 3 varieties of chips that use driver rtl8192se and I
never get the long ping times that you reported earlier.
I have never tested forcing a reset on the chip the way you did. I am not
surprised that bad things happen.
From some of the material that you report, it appears that you have an 802.11n
connection using WPA1 encryption. (More of those pesky details!) That particular
configuration is one that I have not been using as my 802.11n router is shared
with my spouse, and I cannot change it that easily, but I will give it a try.
Larry
On 12/23/2012 07:21 AM, Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 06:49:55AM +0100, Mike Galbraith wrote:
>> Looks a lot like my driver experience with older kernels, I had to use
>> the external driver in the rare event that I needed wireless to work.
>> The in tree driver works peachy these days (needed it recently, was
>> pleasantly surprised when it _just worked_, not even a hiccup), so
>> somebody cared, gave at least the 10ec:8181 bits some serious love.
>
> Good for you.
>
> I have a [10ec:8176] in my laptop and while I don't have the issues
> Norbert is reporting, I can't say the thing just worked.
>
> I had to use the wireless recently in a bunch of networks and what it
> would do, is associate properly, connection gets established and traffic
> is fine for a minute or so. Then, after a minute traffic would cease and
> I'd need to re-associate. And it worked sporadically, sometimes fine,
> sometimes with constant connection interruptions. And this observation
> was the case with almost all wireless networks I'd use.
>
> FWIW, the wifi adapter is:
>
> 01:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
> Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:8195]
> Flags: fast devsel, IRQ 17
> I/O ports at 3000 [size=256]
> Memory at f0200000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 01-91-81-fe-ff-4c-e0-00
>
> using rtl8192ce.
Again a different driver! What do you mean "in a bunch of networks"? How am I
supposed to duplicate the conditions with descriptions like this?
Larry
On Sun, Dec 23, 2012 at 01:13:20PM -0600, Larry Finger wrote:
> Again a different driver! What do you mean "in a bunch of networks"?
> How am I supposed to duplicate the conditions with descriptions like
> this?
A "bunch of networks" means, everytime I was at a coffee shop or
similar, I'd try to use their network. And it was a different shop each
time :-).
Sorry if you've misunderstood me, I'm not asking you to duplicate the
conditions. This was just a general observation as a reply to what
Mike said. It was meant as a FYI, nothing more. If I have a simple
reproduction scenario, I'll let you know.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 12/22/2012 04:55 PM, Norbert Preining wrote:
> Hi Larry,, hi all
>
> On Sa, 22 Dez 2012, Larry Finger wrote:
>> It is not that no one cares; however, your attitude does nothing to
>> induce me to work on this problem. The facts are not needed "to make
>
> Aehm, ... after my initial report you asked me several more questions,
> which I answered within a few hours. After that no as in 0 response,
> although I pinged back a few times.
>
> So am I supposed to deduce from 0 reactions that anyone is interested?
>
>> people happy", they are necessary to try to reproduce the problem. If I
>> cannot make it happen here, then I cannot fix it. Also, remember that I
>
> Disagree. I am involved in tracking down a nasty regression in the intel
> drm driver, which the intel people can *not* reproduce, but several
> other people, and after long trials and patches and converse it is
> starting to look much better.
>
>> am a volunteer. I get nothing from Realtek but starting code of varying
>> quality and some sample chips. At least my versions do not crash your
>
> Ok, that is a problem I understand. If this is the case, that it is
> a single volunteer caring for the code, then I see a real problem.
> (And I also will try to stay away from rtl wlan cards on my next laptop)
>
>> I have never tested forcing a reset on the chip the way you did. I am not
>> surprised that bad things happen.
>
> But the DMAR item I also reported points to a real problem I guess.
Yes, I would agree.
>> From some of the material that you report, it appears that you have an
>> 802.11n connection using WPA1 encryption. (More of those pesky details!)
>
> WPA PSK, yes. I don't know the difference between WPA2 and WPA, though.
WPA2 is AES and WPA(1) is TKIP.
My device is the same as yours. The command 'lspci -nn' shows:
0e:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB
Wireless LAN Controller [10ec:8172] (rev 10)
The B variety is a 1x2 configuration.
My signal strength is essentially the same as yours.
wlan0 IEEE 802.11bgn ESSID:"lwfdjf-n"
Mode:Managed Frequency:2.422 GHz Access Point: C0:3F:0E:BE:2B:44
Bit Rate=18 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=-35 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:1943 Missed beacon:0
A throughput test with netperf shows the following for 3 second samples:
TCP_MAERTS Test: 23.73 20.80 20.87 20.62 20.50 20.62 20.19 20.67 20.70 20.75
RX Results: max 23.73, min 20.19. Mean 20.95(0.95)
TCP_STREAM Test: 20.82 26.36 25.77 25.89 26.36 26.31 26.19 26.50 26.16 25.93
TX Results: max 26.50, min 20.82. Mean 25.63(1.62)
My router does not let me change the TKIP interval, which I think means 3600
seconds. Running a ping for ~4000 seconds results in
--- 192.168.1.1 ping statistics ---
4004 packets transmitted, 4002 received, 0% packet loss, time 4007793ms
rtt min/avg/max/mdev = 0.782/1.605/77.929/4.310 ms
Only 2 packets lost in 4000 is pretty good, and my longest return time of 77 ms
is certainly not like you get.
My router is a Netgear WNDR3300 running firmware version V1.0.45_1.0.45NA.
These results are representative of what I have always gotten. I have no idea
why your system is so different.
One thing to try is loading the module with option "ips=0".
Larry
On Sun, 2012-12-23 at 13:10 -0600, Larry Finger wrote:
> Note, the RTL8188CE uses rtl8192ce, while the RTL8191SE uses rtl8192se. They
> share the underlying plumbing in driver rtlwifi, but the rest is completely
> different.
Driver here is rtl8192se.
08:00.0 0280: 10ec:8172 (rev 10)
Subsystem: 10ec:8181
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 4000 [size=256]
Memory at c0900000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
Point was, driver state may still be dire for some hardware, but here,
the same driver for very similar looking hardware went from useless to
works fine.
My desktop box has this thing in it, which also used to be completely
useless with the in kernel driver, but now works (it's still useless,
router sits on top of that box;). Both devices now seem to work just
fine, whereas both used to be a PITA if I wanted to use them.
Bus 001 Device 004: ID 13d3:3247 IMC Networks 802.11 n/g/b Wireless LAN Adapter
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x13d3 IMC Networks
idProduct 0x3247 802.11 n/g/b Wireless LAN Adapter
bcdDevice 8.01
iManufacturer 1 Ralink
iProduct 2 802.11 n WLAN
iSerial 3 1.0
Hi Larry,, hi all
On Sa, 22 Dez 2012, Larry Finger wrote:
> It is not that no one cares; however, your attitude does nothing to
> induce me to work on this problem. The facts are not needed "to make
Aehm, ... after my initial report you asked me several more questions,
which I answered within a few hours. After that no as in 0 response,
although I pinged back a few times.
So am I supposed to deduce from 0 reactions that anyone is interested?
> people happy", they are necessary to try to reproduce the problem. If I
> cannot make it happen here, then I cannot fix it. Also, remember that I
Disagree. I am involved in tracking down a nasty regression in the intel
drm driver, which the intel people can *not* reproduce, but several
other people, and after long trials and patches and converse it is
starting to look much better.
> am a volunteer. I get nothing from Realtek but starting code of varying
> quality and some sample chips. At least my versions do not crash your
Ok, that is a problem I understand. If this is the case, that it is
a single volunteer caring for the code, then I see a real problem.
(And I also will try to stay away from rtl wlan cards on my next laptop)
> I have never tested forcing a reset on the chip the way you did. I am not
> surprised that bad things happen.
But the DMAR item I also reported points to a real problem I guess.
> From some of the material that you report, it appears that you have an
> 802.11n connection using WPA1 encryption. (More of those pesky details!)
WPA PSK, yes. I don't know the difference between WPA2 and WPA, though.
Best wishes, and merry christmas
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
`This must be Thursday,' said Arthur to himself, sinking
low over his beer, `I never could get the hang of
Thursdays.'
--- Arthur, on what was to be his last Thursday on Earth.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
On Sun, Dec 23, 2012 at 06:49:55AM +0100, Mike Galbraith wrote:
> Looks a lot like my driver experience with older kernels, I had to use
> the external driver in the rare event that I needed wireless to work.
> The in tree driver works peachy these days (needed it recently, was
> pleasantly surprised when it _just worked_, not even a hiccup), so
> somebody cared, gave at least the 10ec:8181 bits some serious love.
Good for you.
I have a [10ec:8176] in my laptop and while I don't have the issues
Norbert is reporting, I can't say the thing just worked.
I had to use the wireless recently in a bunch of networks and what it
would do, is associate properly, connection gets established and traffic
is fine for a minute or so. Then, after a minute traffic would cease and
I'd need to re-associate. And it worked sporadically, sometimes fine,
sometimes with constant connection interruptions. And this observation
was the case with almost all wireless networks I'd use.
FWIW, the wifi adapter is:
01:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:8195]
Flags: fast devsel, IRQ 17
I/O ports at 3000 [size=256]
Memory at f0200000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-91-81-fe-ff-4c-e0-00
using rtl8192ce.
Hmm.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Hi Larry, hi all,
it is some time that I didn't post, but here I want to come back to
this item.
On Sa, 22 Dez 2012, Larry Finger wrote:
>> But the DMAR item I also reported points to a real problem I guess.
>
> Yes, I would agree.
That seems to be gone with current kernels 3.8.0-rc3
I have had the hanging issue today again, but this time it showed
a very interesting rythm, that might help to understand.
Pinging my router I normally have about ~1ms response time.
When it hanged (and this is now several thousand seconds long test)
the hang times are *always very close:
4sec
3sec
2sec
1sec
is one block. This block might repeat a few times, or only once, but it
is always in this rythm:
64 bytes from 192.168.0.1: icmp_req=407 ttl=255 time=1.23 ms
64 bytes from 192.168.0.1: icmp_req=408 ttl=255 time=1.89 ms
64 bytes from 192.168.0.1: icmp_req=409 ttl=255 time=3925 ms
64 bytes from 192.168.0.1: icmp_req=410 ttl=255 time=2918 ms
64 bytes from 192.168.0.1: icmp_req=411 ttl=255 time=1910 ms
64 bytes from 192.168.0.1: icmp_req=412 ttl=255 time=903 ms
64 bytes from 192.168.0.1: icmp_req=413 ttl=255 time=1.15 ms
...
64 bytes from 192.168.0.1: icmp_req=418 ttl=255 time=1.16 ms
64 bytes from 192.168.0.1: icmp_req=419 ttl=255 time=4040 ms
64 bytes from 192.168.0.1: icmp_req=420 ttl=255 time=3033 ms
64 bytes from 192.168.0.1: icmp_req=421 ttl=255 time=2025 ms
64 bytes from 192.168.0.1: icmp_req=422 ttl=255 time=1018 ms
64 bytes from 192.168.0.1: icmp_req=423 ttl=255 time=4087 ms
64 bytes from 192.168.0.1: icmp_req=424 ttl=255 time=3081 ms
64 bytes from 192.168.0.1: icmp_req=425 ttl=255 time=2073 ms
64 bytes from 192.168.0.1: icmp_req=426 ttl=255 time=1065 ms
64 bytes from 192.168.0.1: icmp_req=427 ttl=255 time=4124 ms
64 bytes from 192.168.0.1: icmp_req=428 ttl=255 time=3121 ms
64 bytes from 192.168.0.1: icmp_req=429 ttl=255 time=2114 ms
64 bytes from 192.168.0.1: icmp_req=430 ttl=255 time=1109 ms
64 bytes from 192.168.0.1: icmp_req=431 ttl=255 time=4169 ms
64 bytes from 192.168.0.1: icmp_req=432 ttl=255 time=3163 ms
64 bytes from 192.168.0.1: icmp_req=433 ttl=255 time=2155 ms
64 bytes from 192.168.0.1: icmp_req=434 ttl=255 time=1147 ms
....
64 bytes from 192.168.0.1: icmp_req=521 ttl=255 time=1.30 ms
64 bytes from 192.168.0.1: icmp_req=522 ttl=255 time=1.25 ms
64 bytes from 192.168.0.1: icmp_req=523 ttl=255 time=4300 ms
64 bytes from 192.168.0.1: icmp_req=524 ttl=255 time=3293 ms
64 bytes from 192.168.0.1: icmp_req=525 ttl=255 time=2295 ms
64 bytes from 192.168.0.1: icmp_req=526 ttl=255 time=1287 ms
64 bytes from 192.168.0.1: icmp_req=527 ttl=255 time=4357 ms
64 bytes from 192.168.0.1: icmp_req=528 ttl=255 time=3351 ms
64 bytes from 192.168.0.1: icmp_req=529 ttl=255 time=2344 ms
64 bytes from 192.168.0.1: icmp_req=530 ttl=255 time=1336 ms
64 bytes from 192.168.0.1: icmp_req=531 ttl=255 time=4408 ms
64 bytes from 192.168.0.1: icmp_req=532 ttl=255 time=3403 ms
64 bytes from 192.168.0.1: icmp_req=533 ttl=255 time=2395 ms
64 bytes from 192.168.0.1: icmp_req=534 ttl=255 time=1387 ms
64 bytes from 192.168.0.1: icmp_req=535 ttl=255 time=4453 ms
64 bytes from 192.168.0.1: icmp_req=536 ttl=255 time=3449 ms
64 bytes from 192.168.0.1: icmp_req=537 ttl=255 time=2441 ms
64 bytes from 192.168.0.1: icmp_req=538 ttl=255 time=1433 ms
64 bytes from 192.168.0.1: icmp_req=539 ttl=255 time=4499 ms
...
In addition, the responses for these blocks come *together*,
not after 4sec the first, then after 3 sec the next. No.
It is wait 10 sec, bammmm, all 4, wait 10secs, bam all 4.
Does that ring *any* bell*
Norbert
------------------------------------------------------------------------
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------