Bug 729618

Hi Stefan, did you report this problem to Larry Finger?

Not yet since I'm not really sure what's going on. Could it be that userspace is acting up? If you think I should contact Larry I will do so.

Yes. Maybe this is known problem. Otherwise some debugging will be needed - perhaps Larry would like to dig into it.

(In reply to comment #1)
> Hi Stefan, did you report this problem to Larry Finger?

Oh, he's CC'ed :-/

I am not a Fedora user. What is kernel 2.6.40-4 in terms of what I know?

I have not seen this problem before.

Is this a pre-built kernel, or do you build your own? If the latter, go to drivers/net/wireless/rtlwifi/debug.c and find the line that says

        rtlpriv->dbg.global_debuglevel = DBG_EMERG;

Change the DBG_EMERG to DBG_DMESG, run the driver, and attach the dmesg output to this bug report. That should tell us why the firmware is being reloaded. My TODO list includes an item to make this quantity be a module parameter, but I have not yet done that.

If you use a pre-built kernel, please get the latest compat-wireless sources, make the above change, and build a new version. You will need the kernel headers installed. Someone else will need to advise you on the necessary packages.

(In reply to comment #5)
> I am not a Fedora user. What is kernel 2.6.40-4 in terms of what I know?

That's a 3.0 kernel. :)

> 
> I have not seen this problem before.
> 
> Is this a pre-built kernel, or do you build your own? If the latter, go to
> drivers/net/wireless/rtlwifi/debug.c and find the line that says

It's the latest shipping kernel, but I can compile a 3.0 vanilla with the change below.

> 
>         rtlpriv->dbg.global_debuglevel = DBG_EMERG;
> 
> Change the DBG_EMERG to DBG_DMESG, run the driver, and attach the dmesg output
> to this bug report. That should tell us why the firmware is being reloaded. My
> TODO list includes an item to make this quantity be a module parameter, but I
> have not yet done that.
> 
> If you use a pre-built kernel, please get the latest compat-wireless sources,
> make the above change, and build a new version. You will need the kernel
> headers installed. Someone else will need to advise you on the necessary
> packages.

Not an issue, I know my way around. I'll report back, thanks Larry.

Created attachment 518076 [details]
dmesg.txt

Probably a power management issue? But PM seems to be turned off
iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr=2347 B   Fragment thr:off
          Encryption key:off
          Power Management:off

Created attachment 518098 [details]
Test patch for firmware reload issue

Check if this patch helps. For a number of reasons, I'm afraid of side effects from this, but at least see if it helps your case. You can remove the extra debug output now. It did it's job.

Larry

I'm pretty sure your patch suppressed the dmesg output, but I'm also seeing a short network disconnect (packet loss) whenever the firmware is reloaded. So the problem has to be somewhere else.
Btw, I'm on 3.1-rc1 now, same issue.

No, the patch did more than suppress the dmesg output. It completely skipped the firmware reload. Yes, the problem is somewhere else, but not in this routine.

What tests do you do to detect this packet loss?

I will be posting a patch to let us dynamically change the debug level. Perhaps that will let us find the problem.

Created attachment 518154 [details]
Patch to implement global debugging

After this patch is installed, unload rtl8192ce and reload as follows:

modprobe -v rtlwifi debug=4
modprobe -v rtl8192ce

You will get additional debug info in the logs.

Created attachment 518231 [details]
dmesg-debug.txt

Here's your log.
I tracked the issue by running ping <AP> in a terminal and that shows dropped packages. Also I first discovered the issue because my connection to the AP drops occasionally and everytime that happens the firmware reload message is printed.

The patch should have gotten rid of the firmware reload messages.

Your dmesg output shows the following error:

[   48.767659] rtl8192c_common:_rtl92c_fill_h2c_command():<100-1> Wating too long for FW read clear HMEBox(0)!
[   48.767659] rtl8192c_common:_rtl92c_fill_h2c_command():<100-1> Write H2C register BOX[0] fail!!!!! Fw do not read.

This may be a failure in the device or incorrect firmware. Please compare the md5sum of the firmware file to mine:

748944fbffd3b08b5b1929bb6c7fc537  /lib/firmware/rtlwifi/rtl8192cfw.bin

I will alert my contact at Realtek and have him review this thread and look at your dmesg output.

Looks identical
md5sum /lib/firmware/rtlwifi/rtl8192cfw.bin 
748944fbffd3b08b5b1929bb6c7fc537  /lib/firmware/rtlwifi/rtl8192cfw.bin

OK, we can rule out faulty firmware.

While we are waiting for the Realtek engineers to look at the material, please try turning off power save.

sudo modprobe -rv rtl8192ce
sudo modprobe -v rtl8192ce ips=0

I'm currently reworking the module options, but you don't need the patch to test.

Dear all:

1. about "Loading firmware file rtlwifi/rtl8192cfw.bin" issue.
   It just happened when wifi not connected to AP, right ?
   If yes, I think it's a normal message when you open inactiveps like follwing code:

   static struct rtl_mod_params rtl92ce_mod_params = {
	.sw_crypto = false,
	.inactiveps = true,
	.swctrl_lps = false,
	.fwctrl_lps = true,
   };

   because Drier will disable hardware when there's no link or other works like scan. but when you or network ask driver to scan, driver will reenable hardware, this will cause firmware loading again.


2. about the "Wating too long for FW read clear HMEBox(0)!" issue, can you test our released driver in the attachment, because I can not reproduce this issue on my platform.

Thank you!
chaoming_li

Created attachment 518968 [details]
latest rtl819x linux driver

latest rtl8188ce driver

Created attachment 518970 [details]
Patch needed to compile Realtek driver on latest kernels

(In reply to comment #16)
> Dear all:
> 
> 1. about "Loading firmware file rtlwifi/rtl8192cfw.bin" issue.
>    It just happened when wifi not connected to AP, right ?

No it also happens if wifi is connected, followed by a network manager disconnect and reconnect.

> 2. about the "Wating too long for FW read clear HMEBox(0)!" issue, can you test
> our released driver in the attachment, because I can not reproduce this issue
> on my platform.

I will do so. Thanks!

Created attachment 518997 [details]
dmesg-newdriver.txt

From a quick run of about half an hour I did not see any ping packets being dropped or any messages about firmware reloading. However I still get a lot of disconnects, reconnects by Network Manager. See dmesg.

(In reply to comment #19)
> (In reply to comment #16)
> > Dear all:
> > 
> > 1. about "Loading firmware file rtlwifi/rtl8192cfw.bin" issue.
> >    It just happened when wifi not connected to AP, right ?
> No it also happens if wifi is connected, followed by a network manager
> disconnect and reconnect.

  Yes， it just when disconnect and before connect again.

> > 2. about the "Wating too long for FW read clear HMEBox(0)!" issue, can you test
> > our released driver in the attachment, because I can not reproduce this issue
> > on my platform.
> I will do so. Thanks!

(In reply to comment #20)
> Created attachment 518997 [details]
> dmesg-newdriver.txt
> From a quick run of about half an hour I did not see any ping packets being
> dropped or any messages about firmware reloading. However I still get a lot of
> disconnects, reconnects by Network Manager. See dmesg.

From dmesg I found that， there's something wrong with your AP, it always 
not send a beacon within 2s, our driver will think AP is power off and disconnect it. So can you reboot AP and try again.

Thank you!
chaoming_li

(In reply to comment #22)
> From dmesg I found that， there's something wrong with your AP, it always 
> not send a beacon within 2s, our driver will think AP is power off and
> disconnect it. So can you reboot AP and try again.

Beacon Interval is set to 100ms on my AP and actually non of my other systems using iwlagn, ipw2200 and r8712u complain or disconnect from the AP. I even put my notebook next to the AP and it still disconnects, so it's also not range issue.
Thanks for looking into it!

Actually there are a few packets dropped, but I guess that comes with the disconnect.
777 packets transmitted, 771 received, 0% packet loss, time 777322ms
rtt min/avg/max/mdev = 1.136/6.078/522.238/28.489 ms

It seems that the updated driver helped.

Even though the beacon interval is 100ms, the RTL8188CE is not seeing the beacons for 2s. Either the AP is not sending them, or the RTL8188CE is not seeing them. Rebooting the AP should help sort out which is happening.

I am reviewing the changes between the current version of rtl8192ce in the kernel and the driver that Chaoming posted here. I will prepare a patch to incorporate the important parts for testing.

Thanks Larry,
I rebooted the AP twice and still see the disconnects (on this device only).

Dear Stefan Assmann:

   Can you set rtlpriv->dbg.global_debuglevel = DBG_DMESG; in rtl_dbgp_flag_init, and give me dmesg after disconnect.
   And can you tell me your AP's model and configration.

Thank you!
chaoming_li

Created attachment 519255 [details]
dmesg-new.txt

Hi Chaoming_li,
here's the dmesg output with debug enabled.
My AP is a D-Link DIR-825 running dd-wrt.

Dear Stefan Assmann:

Can you try to close fwctrl_lps by set fwctrl_lps = false like follwing, and test again.

   static struct rtl_mod_params rtl92ce_mod_params = {
      .sw_crypto = false,
      .inactiveps = true,
      .swctrl_lps = false,
      .fwctrl_lps = false,
   };


Thank you!
lizhaoming

Created attachment 519579 [details]
dmesg-nolps.txt

Still the same. Here's the dmesg output with debug enabled.

(In reply to comment #30)
> Created attachment 519579 [details]
> dmesg-nolps.txt
> Still the same. Here's the dmesg output with debug enabled.

Can you help to mark ieee80211_connection_loss(rtlpriv->mac80211.vif);
in base.c like this:

    //ieee80211_connection_loss(rtlpriv->mac80211.vif);

and try again.

Thank you!
chaoming_li

chaoming_li,

commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); didn't make a difference either. Do you want the log?

(In reply to comment #32)
> chaoming_li,
> commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); didn't make a
> difference either. Do you want the log?

Yes, Please give me the log after commenting out ieee80211_connection_loss.

Thank you!

Created attachment 519833 [details]
dmesg-conloss.txt

Connected to a different AP this time.

chaoming_li,
do you have any news on this?

(In reply to comment #33)
> (In reply to comment #32)
> > chaoming_li,
> > commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); didn't make a
> > difference either. Do you want the log?
> Yes, Please give me the log after commenting out ieee80211_connection_loss.
> Thank you!

Dear Sir:

I want you to commenting out ieee80211_connection_loss(rtlpriv->mac80211.vif); and give me the log, but in your log the ieee80211_connection_loss was not commented out, can you give me the log again.

Thank you!

weird I'm pretty sure I commented out ieee80211_connection_loss in the attachment in comment #34. Anyway I'll go prepare a new log just in case.

Created attachment 528189 [details]
dmesg-connection-loss-commented-out.txt

chaoming_li,
here's dmesg with commented out ieee80211_connection_loss(rtlpriv->mac80211.vif);

Hope this helps. Thanks!

(In reply to comment #38)
> Created attachment 528189 [details]
> dmesg-connection-loss-commented-out.txt
> chaoming_li,
> here's dmesg with commented out
> ieee80211_connection_loss(rtlpriv->mac80211.vif);
> Hope this helps. Thanks!

Dear Sir:

   I found that your AP will stop issue beacon, So after we test it we will reconnect it, because we think if AP stop beacon, maybe it's power off.
   But it's a normal condition for your AP to stop issue beacon sometimes, So I suggest you to commented out ieee80211_connection_loss, our update your AP' s firmware.

Thank you!
chaoming_li

To clarify, I think Chaoming meant to say "or update your AP's firmware". For whatever reason, when your AP stops sending beacons, the station (rtl8192ce) thinks it disappeared - it has no other choice. This is a bug in the AP firmware that we cannot work around in a general case. It would break too many other setups.

Ok, I'll try to update the firmware. Is there a way to capture beacon frames with for example tcpdump?

(In reply to comment #40)
> To clarify, I think Chaoming meant to say "or update your AP's firmware". For
> whatever reason, when your AP stops sending beacons, the station (rtl8192ce)
> thinks it disappeared - it has no other choice. This is a bug in the AP
> firmware that we cannot work around in a general case. It would break too many
> other setups.

Yes it's "or update your AP's firmware". 
Thank you!

That of course could be an AP issue, but according to comment 23 other stations works with this AP.

Stefan, you can configure some other wireless interface in monitor mode, set channel to the same as used by your AP, and use wireshark to check if beacons are send from AP. In case they are send, you might try to configure rtl8192ce device to operate permanently in promiscuous mode (i.e ifconfig wlan0 promisc). If that would help with problem, it will indicate rtl8192ce issue, probably with filtering.

Stanislaw that sounds like a good idea, but I'm having trouble to capture beacon frames with my Intel PRO/Wireless 2200BG. I'm not seeing any packets at all.
What I tried was booting in runlevel 1 and then
iwconfig eth1 channel 8
ifconfig eth1 promisc
ifconfig eth1 up
tcpdump -v -i eth1

Any idea why I'm not seeing any traffic (beacons)? The device entered promiscuous mode.

ipw2200 is not mac80211 driver, it crate separate interface for monitoring mode called rtap0 .

I do not think tcpdump will show any wireless traffic, it's probably only usable for upper layers. For sure you can use tshark on console to sniff what happen on the air.

ok John told me to use 
ifconfig eth1 down ; iwconfig eth1 mode monitor ; ifconfig eth1 up
with my card.
That works great. Thanks John :)

Stanislaw, I'm now able to capture beacons and tcpdump works as well, so I'll report back as soon as I have done some testing.

Ok here are the results:
I've captured beacons with ipw2200 for over an hour and couldn't spot any period where the AP failed to send beacons. During that time there was a disassociate and reconnect on the rtl8192. Here's a short excerpt of the traffic captured.

16:54:51.369027 0us tsft 1.0 Mb/s 2447 MHz 11b -60dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.471459 0us tsft 1.0 Mb/s 2447 MHz 11b -60dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.527950 0us tsft 1.0 Mb/s 2447 MHz 11b -21dB signal 0dB noise antenna 1 Action (ec:55:f9:c8:df:41 (oui Unknown)): BA DELBA
16:54:51.528789 0us tsft 1.0 Mb/s 2447 MHz 11b -21dB signal 0dB noise antenna 1 Action (ec:55:f9:c8:df:41 (oui Unknown)): BA DELBA
16:54:51.529382 0us tsft 1.0 Mb/s 2447 MHz 11b -21dB signal 0dB noise antenna 1 Action (ec:55:f9:c8:df:41 (oui Unknown)): BA DELBA
16:54:51.546865 0us tsft 1.0 Mb/s 2447 MHz 11b -22dB signal 0dB noise antenna 1 DeAuthentication (ec:55:f9:c8:df:41 (oui Unknown)): Disassociated due to inactivity
16:54:51.547448 0us tsft 1.0 Mb/s 2447 MHz 11b -23dB signal 0dB noise antenna 1 DeAuthentication (ec:55:f9:c8:df:41 (oui Unknown)): Disassociated due to inactivity
16:54:51.573829 0us tsft 1.0 Mb/s 2447 MHz 11b -61dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.676263 0us tsft 1.0 Mb/s 2447 MHz 11b -61dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]
16:54:51.778659 0us tsft 1.0 Mb/s 2447 MHz 11b -61dB signal 0dB noise antenna 1 Beacon (TitanNet) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 8, PRIVACY[|802.11]

I checked my dump before that issue and couldn't spot any irregularities in the beacons. Anyway I'll attach part my dump if anybody wants to take a closer look.

Created attachment 528562 [details]
beacons.txt

oh and please note that I only captured packets from the APs MAC address.

So AP send beacons periodically, looks for some reason we stop to receive them via rtl8192ce device.

Did you try put rtl8192ce interface in permanent promiscuous mode to see if that workaround helps with problem?

I've now set
ifconfig wlan0 promisc
but the disconnect happened again.

Is that what you suggested?

Yes, so reason not receiving beacons must be different.

We have bug in mac80211, that make we do not correctly return to operating channel after doing some off-channel work i.e. scanning. I can image that bug can cause we stop receive beacons. I had build kernel, which include possible fixes for that issue, Stefan you might give it a try:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3443284

Stanislaw,
great find! I'm on f16 beta now, is this problem present there as well? If so could you attach the patch or brew a kernel for f16.
Thanks!

Patches are here (they are not applied upstream currently):
http://marc.info/?l=linux-wireless&m=131914572421076&w=2
http://marc.info/?l=linux-wireless&m=131914572421077&w=2

I'm seeing this on f15 on an:

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
        Subsystem: AzureWave Device 1139
        Flags: bus master, fast devsel, latency 0, IRQ 18
        I/O ports at d000 [size=256]
        Memory at fea00000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: rtl8192ce
        Kernel modules: rtl8192ce

I have a Netgear WNDR3700v2 at work running OpenWRT (802.11n) and a Linksys WRT54GLv2 at home running DD-WRT (802.11g) and both exhibit this problem.  Both are pretty mainstream devices, so I'm guessing they don't have beacon problems.  Other clients with different hardware (also running f15) don't see these errors.

I'll post back here after trying Stanislaw's kernel patches.

For those of us that do not use Fedora, please state the kernel version used in F15.

Currently fedora 15 use 3.0.x kernel, usually it is synced with latest release done by GregKH. We rename it to 2.6.40.x to do not break some applications relayed on kernel version. Newest kernel is 2.6.40.8-2.fc15 based on 3.0.8 .

Latest F-16 kernel 3.1.1-1 include patches from comment 56 ...

Nice! I'll update and test. Thanks Stanislaw! :-)

So far no firmware reloads when wireless is disabled.

That should not surprise you. The firmware reloads happen when the wireless connection is dropped and the driver needs to reset before continuing.

No connection => no dropped connection.

The new kernel doesn't keep reloading the firmware, but it still drops the connection constantly.

(In reply to comment #63)
> That should not surprise you. The firmware reloads happen when the wireless
> connection is dropped and the driver needs to reset before continuing.
> 
> No connection => no dropped connection.

Larry, see the initial comment. I was seeing firmware reloads even though the network was not connected.

Dan, I'm also still seeing connection drops.

Here is another kernel to test, it include full revert of off-channel rework happened between .38 and 3.0. It's for F-15, but it should be installeble for F-16 via "rpm -ivh --force"
http://koji.fedoraproject.org/koji/taskinfo?taskID=3534603
Please test.

Testing it now as I also have the same problem with the firmware reloading and dropping the connection.

There was deadlock identified on previous kernel related with rtlwifi power save code, this one should have this problem fixed:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3536998

Any feedback about above test kernel? Note you can install it on fedora 16 using either "rpm -ivh --oldpackag" or "rpm -ivh --force".

I ran the kernel from comment #66 a whole day now and experienced 4 deauths all with "Reason 6". Not exactly sure what Reason 6 means but I moved around with the machine a bit so maybe I got out of range?

If you think the kernel from comment #68 is worth another shot let me know and I'll switch. From the 1 day experience I'd say that kernel works better but since it's only been such a short period since I ran it that might not be true.

There is not difference between #66 and #68 as long as #66 do not hung.

Reason 6 is WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA, but this do not tell much as well, generally looks like problem with autentification/encryption. You might try swenc=1 module parameter. However I do not thing this is related to bug originally reported here.

I forgot about important question, is there difference between fedora 16 kernel 3.1.x and kernel from comment #66 ?

The deauth is always followed by a firmware reload. I'll try again with the
kernel from #68 with swenc=1.

To answer your question, I'm not sure yet, my impression is that it works more reliably but please give me a bit more time for testing. :)

Hm... everyone experiencing this bug is using DD-WRT or OpenWRT (comment 28, comment 57. I'm running OpenWRT on a D-Link DIR 825). And while traveling for Thanksgiving, I've been in two houses with Apple Airports and have had no problem with the connection...

(oops, wrote the above comment without having seen the past few days discussion.)

I realized that my revert of off-channel rework missed one hunk. Here is kernel with missed hunk applied:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3545961
Except that, it include everything that kernel from comment 68, and it's for F-16. Maybe missed hung fixes these remaining connection drops with Reason 6.

ok I'll update to the latest kernel today.

Created attachment 537847 [details]
mac80211_offchannel_rework_revert_v2.patch

For non-fedora users: off-channel rework revert patch applied in kernel from comment 76. This kernel also include patch from bug 755154 .

No more disconnects with Reason 6 with the new kernel. Now I frequently get the following (happened 3-4 times already).

[ 1673.662748] cfg80211: Calling CRDA to update world regulatory domain
[ 1673.675925] cfg80211: World regulatory domain updated:
[ 1673.675940] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1673.675952] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1673.675962] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1673.675972] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1673.675982] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1673.675991] cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1673.676103] cfg80211: Calling CRDA for country: DE
[ 1673.688743] cfg80211: Regulatory domain changed to country: DE
[ 1673.688751] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1673.688759] cfg80211:     (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1673.688765] cfg80211:     (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1673.688771] cfg80211:     (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1673.688777] cfg80211:     (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
[ 1673.761048] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[ 1675.044087] wlan0: authenticate with 00:18:e7:da:f1:24 (try 1)
[ 1675.046691] wlan0: authenticated
[ 1675.047280] wlan0: associate with 00:18:e7:da:f1:24 (try 1)
[ 1675.051367] wlan0: RX ReassocResp from 00:18:e7:da:f1:24 (capab=0x431 status=0 aid=2)
[ 1675.051377] wlan0: associated

Is there some way to turn off all power save features? I tried setting fwlps=0 but it looks like this setting gets ignored. I'm still getting disconnects after a period of inactivity, but no firmware reloads, so I'm not sure whether I'm seeing this bug or a different one. Dmesg is here:
http://jim.rees.org/rtl-powersave-2-dmesg.txt

Your dmesg output does not show any disconnects that I could find. Run without any "debug=" option.

The module parameters are as follows:

parm:           swenc:Set to 1 for software crypto (default 0)
 (bool)
parm:           ips:Set to 0 to not use link power save (default 1)
 (bool)
parm:           swlps:Set to 1 to use SW control power save (default 0)
 (bool)
parm:           fwlps:Set to 1 to use FW control power save (default 1)
 (bool)
parm:           debug:Set debug level (0-5) (default 0) (int)


Load the driver with 'ips=0' to disable power saving.

F-16 kernel kernel-3.1.5-1.fc16 include patch that revert mac80211 off-channel switches, I consider this as fix for "constant firmware reload problem".
http://koji.fedoraproject.org/koji/buildinfo?buildID=278322

I do not want to mess this bug report with too many comments, so if you have any other problem with rtlwifi driver just open a new bug report for that specific problem.

Created attachment 546859 [details]
dmesg 2.6.41.5-1.fc15.x86_64

I'm still seeing this on f15 with the same kernel version - anything special about the f16 version?

[   53.059133] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[  866.503814] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[10586.504574] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[12146.505770] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[13226.503827] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[13346.504784] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[19706.499035] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[20426.501822] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[20546.504744] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
...

I cannot answer the question about Fedora kernels; however, I can provide some additional information.

The earliest version of the driver had code so that the firmware is only reloaded when not actually present. Thus, the firmware is NOT being reloaded, no matter what the log says.

A new patch (commit 8ff08b4) makes the message be logged only when the firmware is actually loaded. This patch is present in the wireless-testing tree, but not in the mainline kernel. It is possible that John Linville has applied this patch to Fedora kernels. It will appear in mainline in kernel 3.3 - it is not a serious enough bug to be pushed into 3.2 or any stable kernel.

What I think you are seeing is a temporary disconnection because the driver fails to transmit a nullfunc packet and return success to the upper levels. I have not been able to find a flaw in the code. As this condition happens infrequently, it is difficult to determine if the packet has been transmitted or not.

Hello
It looks as though I am having the same issue with Fedora 16 and am unable to connect to my AP.

Not sure if this bit helps:
When I did an initial install of F16 from the DVD, my wireless connection seemed all OK. I applied all updates and all was still OK. I then tried an install via kickstart and only managed to connect to my AP the odd time for a few seconds. I've since gone back to a new install from the DVD and applied a kernel update via a wired connected. All is fine via Windoze 7 (sorry to mention that bit).

Should you require more info, please let me know.

Some system errors/stats:

:> dmesg | tail -2
[ 2204.007965] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[ 2264.007474] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin

Currently on kernel:
:> uname -srm
Linux 3.1.6-1.fc16.x86_64 x86_64

I am using a Lenovo E525 laptop with this card:
:> lspci -vvv
05:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
	Subsystem: Realtek Semiconductor Co., Ltd. Device 8195
	Physical Slot: 0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at 2000 [size=256]
	Region 2: Memory at f0900000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
	Capabilities: [160 v1] Device Serial Number 01-91-81-fe-ff-4c-e0-00
	Kernel driver in use: rtl8192ce
	Kernel modules: rtl8192ce

I do not understand what you did. I'm not a Fedora user and the jargon is foreign to me.

As I read this, the first installation was OK. After an update, it was still OK. Then you did a reinstall and updated again, then it doesn't work. Is that an accurate description of what you did?

Hello and thank you for your response.
Yes, this that is an accurate description of what I did. Although, just for clarity, between the second reinstall and update, it didn't work either.

I downloaded the F16 live CD last night. My rtl8192ce device worked with WPA2-AES encryption with the live system. I then installed on my disk. Again, the wireless worked. I then used it to update (282 packages). It still worked.

Sorry, but I am unable to duplicate your results with F16.

The only other thing I can add, is that I am using a WEP key. Thanks.

I just booted into my patched F16 and was able to connect to an AP running WEP, and one running WPA-TKIP, as well as WPA2.

On your WEP, are you using a hex key, or passphrase? My test was with the 28-digit hex key.

(In reply to comment #86)
> I do not understand what you did. I'm not a Fedora user and the jargon is
> foreign to me.

Larry - kickstart is a scripted install (vs. using the step-by-step installer).

W Agtail - can you post your kickstart file?  There may be a different set of packages selected.

I know it's not particularly useful, but I'm seeing this bug as well on ArchLinux, running kernel 3.1.6-1. Other than a few unrelated patches, it's a stock vanilla kernel -- http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux

My observations of spontaneous disconnects are identical to Stefan's, but more frequent.  On this router, I can consistently repro within a few minutes of starting a connection.  I can disconnect and reconnect using network manager, but the connection dies soon thereafter again.

The router is a Netgear with a WPA2 TKIP-PSK network.  The bug seems to be network-specific though, since my home router (not the netgear) has never shown this automatic disconnecting behavior.  Perhaps the bug lies in a particular network encryption scheme?  Oddly enough, I'm completely unable to observe the spontaneous disconnects in another part of the flat, so the behavior may be tied to reception quality as well.  I feel closer to the access point where the disconnects are happening, though reception may be quantitatively poorer there instead.

I'm unable to test many of the other suggestions at the moment since I'm a guest on this network while traveling, but have seen this occur one other time as well.  The next time I'm near a network where I can reproduce, I'd love to help.

Thanks for all the work guys!

lspci -vv:
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
	Subsystem: Realtek Semiconductor Co., Ltd. Device 8195

lspci -vvn:
03:00.0 0280: 10ec:8176 (rev 01)
	Subsystem: 10ec:8195

dmesg:
[ 6505.714108] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
[ 6505.979776] wlan0: authenticate with c4:3d:c7:xx:xx:xx (try 1)
[ 6505.981363] wlan0: authenticated
[ 6505.983223] wlan0: associate with c4:3d:c7:xx:xx:xx (try 1)
[ 6506.986924] wlan0: RX ReassocResp from c4:3d:c7:xx:xx:xx (capab=0x411 status=0 aid=5)
[ 6506.986929] wlan0: associated

lsmod | grep rtl:
rtl8192ce			72695	0
rtl8192c_common	56668	1	rtl8192ce
rtlwifi			91668	1	rtl8192ce
mac80211		222059	3	rtl8192ce,rtl8192c_common,rtlwifi
cfg80211			165796	2	rtlwifi,mac80211
usbcore			144432	4	uvcvideo,rtlwifi,ehci_hcd

Hi Bill

Over the last few days I've been running several kickstart installs from the F16 DVD. Sometimes my wireless works, sometimes it does not. I am using a 26 char hex WEP key.

I am attaching the following files:
ks.cfg        # kickstart file.
ifcfg-space   # installed via kickstart (post).
keys-space    # installed via kickstart (post).
iwconfig.txt  # iwconfig wlan0 output.

At the moment, wireless is working OK, although 'iwconfig wlan0' shows 'Encryption key:off'. On previous versions of Fedora, 'Encryption key' shows the actual WEP key. Although it currently shows off, I can ping my AP and surf the web OK.

Happy New Year to all.

Created attachment 550164 [details]
kickstart file

Created attachment 550165 [details]
/etc/sysconfig/network-scripts

Created attachment 550166 [details]
/etc/sysconfig/network-scripts

Created attachment 550167 [details]
output from 'iwconfig wlan0'

Created attachment 550168 [details]
kickstart file ks.cfg

Hi
I have now applied all Fedora 16 updates via a wired cable.
I can confirm my wifi connection is still unstable. I just recently ran this:
dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true

dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump"

After starting with no wireless connection, I made many attempts connecting via wireless. For this test I simply selected my AP (space) from the WiFI icon on Gnome Classic Desktop. After a good while, the connection was made. Ping testing to my AP ranges from 1-2ms (the odd time), but mainly 'Destination Host Unreachable' or anything around 10000 - 28000 ms.

Please find attached files:
messages
wpa_supplicant.log

Hope these findings are a bit more useful.

Created attachment 550183 [details]
messages

Created attachment 550184 [details]
wpa_supplicant.log

Hello
I am now running with kernel 3.2.6-3.fc16.x86_64.
My wireless network connection periodically 'stalls'.
After 100 icmp_reqs (ping test) to my router,the following was observed:
1) ~1.50ms time is generally displayed.
2) 6% packet loss.
3) slowest times range from 326ms to 4000ms.
Kind regards

This thread has strayed quite a ways from the original topic.

The kind of packet losses that you report are frequently the result of interference. Have you tried switching the router to a different channel?

When I do a 100 ping set to one of the hosts on my network, I get the following:

100 packets transmitted, 100 received, 0% packet loss, time 99151ms
rtt min/avg/max/mdev = 1.624/8.196/138.168/25.214 ms

This performance is satisfactory.

Hi all
Well this is going to sound odd. I have been kickstarting F16 from a DVD with a kickstart file on a USB memory stick. While the memory stick is mounted, my WiFi connection either struggles to connect, drops, ping rate is poor or ping times out. While the USB memory stick is disconnected, my WiFi connection is excellent. Another USB memory stick, which is the same, also produces WiFi problems. Two other different USB memory sticks do not cause any WiFi problems. My issue must be down to some strange USB memory sticks.

So this is different issue, open separate bug report for it.

Stefan, is problem you reported here in comment 0 fixed?

If so we will close that bug, mixing different issues in one bug report is not good.

Yes, I no longer see the firmware reload messages. The connection is still not stable, but that is a different issue.

Ok, so let's close this bug report. For other issues please open a separate bugzillas.