Bug 43187
| Summary: | Asyncronous firmware loading introduced in 3.3.1 fails on realtek rtl8192cfw.bin (RTL8188CE wifi adapter) | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Lucas Treffenstädt (lucas) |
| Component: | network-wireless | Assignee: | Larry Finger (Larry.Finger) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | florian, frostyplanet, Larry.Finger, linville |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.3.1-3.3.4 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
kernel config
Trial patch for incorrect initialization Trial patch for incorrect initialization - #2 |
||
|
Description
Lucas Treffenstädt
2012-05-01 12:51:30 UTC
The problem is not with the firmware itself. If it could not find the firmware, then ieee80211_register_hw() would not have been called. The failure is in wiphy_register(). Could you please try 3.3.4, or the latest "bleeding-edge" compat-wireless code? There have been a lot of changes in the mac80211 code that could cause the problem. In the meantime, I will try the 3.3.1 code here. This problem persists with kernel 3.3.4 It does not fail for me with 3.3.1! Are those patches you are using posted anywhere? You can find the latest bfs patch right here: http://ck.kolivas.org/patches/bfs/3.3.0/3.3-sched-bfs-420.patch the gentoo patchset can be found here: http://dev.gentoo.org/~mpagano/genpatches/ Created attachment 73143 [details]
kernel config
This is my kernel configuration, in case it provides necessary information.
Please try 3.3.1 without the bfs patch. That change in the scheduler is pretty invasive, and may either be exposing or causing a bug. I'll try adding it to my 3.3.1 source as well. The gentoo patches should be harmless. I confirmed that the problem persists with 3.3.4, gentoo patchset only. I will now try 3.3.4 vanilla Is there some additional information output just above where you started the dmesg output listing? The output seems to come from one of the following:
if (WARN_ON(wiphy->addresses && !wiphy->n_addresses))
return -EINVAL;
if (WARN_ON(wiphy->addresses &&
!is_zero_ether_addr(wiphy->perm_addr) &&
memcmp(wiphy->perm_addr, wiphy->addresses[0].addr,
ETH_ALEN)))
return -EINVAL;
It would be nice to know which one is generating the warning.
For me, 3.3.1 with the bfs patch works. If you 'modprobe -rv rtl8192ce' followed by 'modprobe -v rtl8192ce' help? In other words, is it a problem only when booting, or does it also happen after user space is happpily running? 1. More extensive dmesg: [ 11.518036] Using firmware rtlwifi/rtl8192cfw.bin [ 11.518078] ------------[ cut here ]------------ [ 11.518087] WARNING: at net/wireless/core.c:566 wiphy_register+0x56/0x3dc() [ 11.518090] Hardware name: 0221A16 [ 11.518092] Modules linked in: rtl8192ce(+) snd_hda_intel(+) snd_hda_codec rtl8192c_common snd_hwdep rtlwifi snd_pcm snd_page_alloc [ 11.518105] Pid: 1116, comm: firmware/rtlwif Not tainted 3.3.4-gentoo #3 [ 11.518107] Call Trace: [ 11.518116] [<ffffffff8102ae26>] warn_slowpath_common+0x7e/0x96 [ 11.518121] [<ffffffff8102ae53>] warn_slowpath_null+0x15/0x17 [ 11.518125] [<ffffffff81457486>] wiphy_register+0x56/0x3dc [ 11.518130] [<ffffffff810cbb56>] ? __kmalloc+0xbf/0xcf [ 11.518134] [<ffffffff814704f5>] ieee80211_register_hw+0x37a/0x5a2 [ 11.518143] [<ffffffffa002012c>] rtl_fw_cb+0x145/0x1c0 [rtlwifi] [ 11.518148] [<ffffffff812d23bc>] ? _request_firmware_prepare+0x9b/0x9b [ 11.518151] [<ffffffff812d2474>] request_firmware_work_func+0xb8/0xd3 [ 11.518156] [<ffffffff81045433>] kthread+0x86/0x8e [ 11.518161] [<ffffffff814c0d74>] kernel_thread_helper+0x4/0x10 [ 11.518165] [<ffffffff810453ad>] ? kthread_freezable_should_stop+0x3e/0x3e [ 11.518169] [<ffffffff814c0d70>] ? gs_change+0xb/0xb [ 11.518172] ---[ end trace d3baf572359b220b ]--- [ 11.518176] rtlwifi:rtl_fw_cb():<0-0> Can't register mac80211 hw 2. 3.3.4 vanilla works just fine, so this is definitely due to the gentoo patchset That explains why I did not see the problem. That warning indicates that no band has been set. In most systems, that is set by CRDA. Are you running that? Perhaps the Gentoo patchset is messing that up. In any case, this is not a Linux kernel bug, and needs to be filed with Gentoo. I will close this one. I am still having this issue with vanilla-source 3.3.4 :( and even no luck using compat-wireless. Here is dmesg when loading the module : ---------- Compat-wireless backport release: compat-wireless-v3.4-rc3-1 Backport based on linux-stable.git v3.4-rc3 cfg80211: Calling CRDA to update world regulatory domain rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin ------------[ cut here ]------------ WARNING: at /home/ning/Downloads/compat-wireless-3.4-rc3-1/net/wireless/core.c:580 wiphy_register+0x577/0x620 [cfg80211]() Hardware name: 42862EC Modules linked in: rtl8192ce(O+) rtl8192c_common(O) rtlwifi(O) mac80211(O) cfg80211(O) compat(O) iptable_filter ipt_MASQUERADE iptable_nat nf_nat iptable_raw [last unloaded: compat] Pid: 3005, comm: firmware/rtlwif Tainted: G W O 3.3.4 #6 Call Trace: [<ffffffff81061a6b>] ? warn_slowpath_common+0x7b/0xc0 [<ffffffffa00c25b7>] ? wiphy_register+0x577/0x620 [cfg80211] [<ffffffff81086251>] ? ttwu_do_wakeup+0x11/0x90 [<ffffffff8108897b>] ? try_to_wake_up+0xcb/0x280 [<ffffffffa00f94d1>] ? ieee80211_register_hw+0x2e1/0x6d0 [mac80211] [<ffffffff812fae20>] ? _request_firmware+0x2f0/0x2f0 [<ffffffffa014a905>] ? rtl_fw_cb+0x65/0x100 [rtlwifi] [<ffffffff812faec6>] ? request_firmware_work_func+0xa6/0xe0 [<ffffffff812fae20>] ? _request_firmware+0x2f0/0x2f0 [<ffffffff8107d67e>] ? kthread+0x9e/0xb0 [<ffffffff8150cbd4>] ? kernel_thread_helper+0x4/0x10 [<ffffffff8107d5e0>] ? kthread_freezable_should_stop+0x60/0x60 [<ffffffff8150cbd0>] ? gs_change+0xb/0xb ---[ end trace 0954e0242588b287 ]--- If any information is needed, please let me know My source does not show a warning at line 580 of net/wireless/core.c. Please open that file and tell me what that line says. compat-wireless-3.4-rc3-1/net/wireless/core.c:580 is the line "WARN_ON(1)"
---------
if (!have_band) {
WARN_ON(1);
return -EINVAL;
}
--------------
Your system is not setting up the wireless band correctly. At this point, the system does not know whether you are using 2.4 of 5 GHz. For rtl8192ce, only 2.4 GHz makes any sense, I have heard of another user that has this kind of problem, but no one knows how it happens. What distro are you using? The problem is somewhere in the user-space code. I will try to duplicate the result, but it certainly does not happen with my openSUSE system running NetworkManager under KDE. I'm using gentoo on thinkpad x220i-42862EC, linux-firmware-20120219 from http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git , wpa_supplicant-0.7.3-r, gnome 3 and networkmanager-0.9.4.0-r2。 I can use my wireless with kernel driver <=3.2.16. Any other user-space program to remind me? I failed to compile compat-wireless dirver < 3.3 against 3.3.4 kernel source. when using driver compiled from source package rtl_92ce_92se_92de_linux_mac80211_0005.1230.2011 provided by realtek on kernel 3.3.4, currently is working for me. dmesg after I modprobe rtl8192ce . It did show band-width other than 2.4 GHz ... ===================== cfg80211: Calling CRDA to update world regulatory domain ieee80211 phy0: Selected rate control algorithm 'rtl_rc' rtlwifi: wireless switch is on cfg80211: World regulatory domain updated: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: Calling CRDA for country: EC cfg80211: Regulatory domain changed to country: EC cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 20000 KHz), (300 mBi, 1700 mBm) cfg80211: (5250000 KHz - 5330000 KHz @ 20000 KHz), (300 mBi, 2300 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 20000 KHz), (300 mBi, 3000 mBm) ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: authenticate with 00:26:f2:ee:1f:0f (try 1) wlan0: authenticated wlan0: associate with 00:26:f2:ee:1f:0f (try 1) wlan0: RX AssocResp from 00:26:f2:ee:1f:0f (capab=0x411 status=0 aid=1) wlan0: associated wlan0: moving STA 00:26:f2:ee:1f:0f to state 1 wlan0: moving STA 00:26:f2:ee:1f:0f to state 2 ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: US cfg80211: Regulatory domain changed to country: US cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) wlan0: moving STA 00:26:f2:ee:1f:0f to state 3 wlan0: no IPv6 routers present ============= Compat-wireless is designed to backport newer versions of the code to older kernels. When you try to compile a version older that the kernel you are using, it is expected that things will not compile - they are not expected to work. The bands that are shown are those allowed by the regulations, they are not from the driver. A patch showing a possible race condition that might explain your problem was posted yesterday. I will attach it next for you to try. Created attachment 73166 [details]
Trial patch for incorrect initialization
Do NOT use that patch. It works under very limited circumstances; however, it may prevent your system from booting. I'll submit a new version ASAP. I patched it to compat-wireless-3.4-rc3-1, kernel crashed when loading wifi driver, and I also failed to patched it against kernel 3.3.4 source. That is why I told you not to use it. The patch is defective. Created attachment 73167 [details]
Trial patch for incorrect initialization - #2
Please try this one. The current thinking is that there is a racy condition that shows up when the driver is loaded with the firmware cached that causes the initialization to be done in the wrong order.
This one does not fail on bootup. I have no idea if it fixes the other problem as I still have not duplicated it.
(In reply to comment #23) Works for me with 3.4.0-rc4 vanilla, Gentoo. The same as previous patch, by the way. --- [ 12.612197] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin [ 12.748298] rtlwifi: wireless switch is on --- (In reply to comment #23) > Created an attachment (id=73167) [details] > Trial patch for incorrect initialization - #2 > > Please try this one. The current thinking is that there is a racy condition > that shows up when the driver is loaded with the firmware cached that causes > the initialization to be done in the wrong order. > > This one does not fail on bootup. I have no idea if it fixes the other > problem > as I still have not duplicated it. this patch works for compat-wireless-3.4-rc3-1 , much thanks ! The patch is being pushed for kernel 3.4, and will be backported to 3.3. Thanks for testing. A patch referencing this bug report has been merged in Linux v3.4: commit 574e02abaf816b582685805f0c1150ca9f1f18ee Author: Larry Finger <Larry.Finger@lwfinger.net> Date: Fri May 4 08:27:43 2012 -0500 rtlwifi: fix for race condition when firmware is cached A patch referencing this bug report has been merged in Linux v3.4: commit 8011652957995914272f398071b70140639185ce Merge: 568b445 26a5d3c Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed May 16 13:14:52 2012 -0700 A patch referencing this bug report has been merged in Linux v3.4: commit d0cad88d071d59169ac25e5c1e3bee0719a4fccf Merge: 3ab77bf 6037463 Author: David S. Miller <davem@davemloft.net> Date: Wed May 16 01:03:54 2012 -0400 |