Bug#853073: Wrong firmware loaded as a result of commit 339162b
On 01/29/2017 07:13 PM, Jurij Smakov wrote: [Contacting authors of the problematic commit with proposed patch] Hello, I was investigating the regression in performance of wifi on my laptop (using rtl8192ce driver) and I believe that it is a result of recent commit 339162b: https://github.com/torvalds/linux/commit/cf4747d7535a936105f0abe8d8109d3fe339162b I believe that during the refactoring the default name of the firmware file was erroneously changed to rtlwifi/rtl8192cfwU.bin (was rtlwifi/rtl8192cfw.bin before this change) and, as a result, some logic used to determine the correct name of the firmware file for different sub-versions of the card was removed mistakenly as well. This causes wrong firmware to be loaded on my machine (rtl8192cfwU.bin instead of rtl8192cfw.bin), resulting in much more unstable link. Please consider applying the following patch to fix this situation: http://www.wooyd.org/tmp/rtl8192ce_firmware.patch I built a kernel with this patch applied, and the expected firmware was loaded as a result, fixing my problem: [ 13.202250] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin [ 13.253980] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' [ 13.254434] rtlwifi: rtlwifi: wireless switch is on [ 13.460663] rtl8192ce :03:00.0: firmware: direct-loading firmware rtlwifi/rtl8192cfw.bin Jurij, Good catch. That explains why I have been unable to duplicate the problems that some users have reported. As it happens, my test chip uses rtlwifi/rtl8192cfwU_B.bin and was not affected by the bug. I will be sending the fix to mainline with you as the author. Thanks, Larry
Bug#651622: linux-2.6: Sitecom WLA-2000 v1.001 WLAN stick not supported
On 12/11/2011 04:16 AM, Roland Gruber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Larry, Am 11.12.2011 00:22, schrieb Larry Finger: The driver for the RTL8188SU is r8712u. Try modprobe -rv r8712u echo 0df6 005d /sys/bus/usb/drivers/r8712u/new_id wow, this works. Thank you very much for your fast help. :) This mail is sent via the WLAN stick. ;-) OK, your chip is an RTL8191SU. If that works, I can add that device ID to the driver. This would be cool. Patch sent to staging tree via GregKH with notation to add to stable. Eventually, this change will part of an updated kernel - in your case, 3.1.6. How long that takes will depend on how long it takes Debian to pick up these changes. Thanks for testing, Larry -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee49c57.9040...@lwfinger.net
Bug#651622: linux-2.6: Sitecom WLA-2000 v1.001 WLAN stick not supported
On 12/10/2011 04:37 PM, Roland Gruber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have some problem to get a Sitecom USB WLAN stick to run. Ben tried to help me but we did not get it to work. So he pointed me to you. :) It is the Sitecom WLA-2000 v1.001. Vendor 0df6 Product 005d Chipset Realtek RTL8191S Dec 10 18:45:10 roland kernel: [18513.016012] usb 2-3: new high speed USB device number 9 using ehci_hcd Dec 10 18:45:10 roland kernel: [18513.151122] usb 2-3: New USB device found, idVendor=0df6, idProduct=005d Dec 10 18:45:10 roland kernel: [18513.151126] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 10 18:45:10 roland kernel: [18513.151129] usb 2-3: Product: RTL8191S WLAN Adapter Dec 10 18:45:10 roland kernel: [18513.151130] usb 2-3: Manufacturer: Manufacturer Realtek Dec 10 18:45:10 roland kernel: [18513.151132] usb 2-3: SerialNumber: 00e04c01 We tried to use the kernel module rtl8192cu by adding the IDs with echo 0df6 005d /sys/bus/usb/drivers/rtl8192cu/new_id. But this led to a kernel oops. Is there any way to setup the rtl8192cu kernel module so that it accepts the WLAN stick? We also tried the module r8192u_usb but it complains about firmware loading problems when connecting the stick. If rtl8192cu generates an oops when you use the new_id, then it is the wrong driver for your device. The driver for the RTL8188SU is r8712u. Try modprobe -rv r8712u echo 0df6 005d /sys/bus/usb/drivers/r8712u/new_id If that works, I can add that device ID to the driver. Larry -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee3e9a1.8000...@lwfinger.net
Bug#651622: linux-2.6: Sitecom WLA-2000 v1.001 WLAN stick not supported
On 12/10/2011 05:51 PM, Ben Hutchings wrote: On Sat, 2011-12-10 at 17:22 -0600, Larry Finger wrote: If rtl8192cu generates an oops when you use the new_id, then it is the wrong driver for your device. Isn't this really just because using new_id results in driver_info = NULL? I'm not sure, but I think new_id worked in the past for this driver. Let's see if r8712u works. On Sunday night, I'll send the USB ID to the Realtek people in Taiwan. From experience, I know I won't get a response on the weekend. Larry -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee3fac6.9090...@lwfinger.net
Bug#645055: realtek 8188CE ad-hoc mode not supported
On 10/12/2011 06:24 PM, Ben Hutchings wrote: I looked a little further and saw that nl80211 does support changing interface type (mode). But this driver (rtl8192ce) only supports creating new interfaces, not changing their type. Should mac80211 drivers generally support changing interface type (change_interface operation)? I don't think that implementation of the WEXT interface is necessary. As to using iw, the following sequence worked: iw dev wlan14 interface add wlan15 type adhoc iw dev set rename5 type managed iw dev set rename5 type adhoc Why it was called rename5 when I asked for wlan15 is not understood, but the iw interface changes the mode for an existing interface when using rtl8192ce. BTW, I added a new iface because I did not want to interrupt my internat connection. Larry -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e964896.5050...@lwfinger.net
Bug#588196: b43: does not join multicast groups
On 07/13/2010 12:14 AM, Simon Richter wrote: Hi, On Sun, Jul 11, 2010 at 05:57:50PM -0500, Larry Finger wrote: When you get the FATAL DMA error, the controller is reset; however, that is just a simple work around that does not work on all systems. To get your system to work, you need to load b43 with the following options: pio=1 qos=0 nohwcrypy=1 That appears to work, at least I have v6 addresses now. Unlike before, you now have communication. Larry -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c3bfb87.5030...@lwfinger.net
Re: b43 locks the machine when resuming after suspend to disk
Johannes Berg wrote:
I think you need the appended patch, but it only applies to linux-next.
A different version has been merged into what will become 2.6.26. I'll
see what we can do about stable.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ef3a62d272f033989e83eb1f26505f93f93e3e69;hp=6d1a3fb567a728d31474636e167c324702a0c38b
Anybody have a stable tree around to see if that applies? I think it
should.
It didn't, but this version will. It has been compile tested only.
Larry
===
Index: linux-2.6/net/mac80211/tx.c
===
--- linux-2.6.orig/net/mac80211/tx.c
+++ linux-2.6/net/mac80211/tx.c
@@ -1090,7 +1090,7 @@ static int ieee80211_tx(struct net_devic
ieee80211_tx_handler *handler;
struct ieee80211_txrx_data tx;
ieee80211_txrx_result res = TXRX_DROP, res_prepare;
- int ret, i;
+ int ret, i, retries = 0;
WARN_ON(__ieee80211_queue_pending(local, control-queue));
@@ -1181,6 +1181,13 @@ retry:
if (!__ieee80211_queue_stopped(local, control-queue)) {
clear_bit(IEEE80211_LINK_STATE_PENDING,
local-state[control-queue]);
+ retries++;
+ /*
+* Driver bug, it's rejecting packets but
+* not stopping queues.
+*/
+ if (WARN_ON_ONCE(retries 5))
+ goto drop;
goto retry;
}
memcpy(store-control, control,
Index: linux-2.6/net/mac80211/tx.c
===
--- linux-2.6.orig/net/mac80211/tx.c
+++ linux-2.6/net/mac80211/tx.c
@@ -1090,7 +1090,7 @@ static int ieee80211_tx(struct net_devic
ieee80211_tx_handler *handler;
struct ieee80211_txrx_data tx;
ieee80211_txrx_result res = TXRX_DROP, res_prepare;
- int ret, i;
+ int ret, i, retries = 0;
WARN_ON(__ieee80211_queue_pending(local, control-queue));
@@ -1181,6 +1181,13 @@ retry:
if (!__ieee80211_queue_stopped(local, control-queue)) {
clear_bit(IEEE80211_LINK_STATE_PENDING,
local-state[control-queue]);
+ retries++;
+ /*
+* Driver bug, it's rejecting packets but
+* not stopping queues.
+*/
+ if (WARN_ON_ONCE(retries 5))
+ goto drop;
goto retry;
}
memcpy(store-control, control,
Re: b43 locks the machine when resuming after suspend to disk
Johannes Berg wrote: On Thu, 2008-07-03 at 01:08 +0200, Rafael J. Wysocki wrote: On Thursday, 3 of July 2008, Johannes Berg wrote: Rafael, you misled me :) This is a completely different thing. Ah, sorry then. I was too quick with my response. No trouble, it reminded me that I wanted to ask stable to pick up that patch anyway although I don't think we ever ran into the issue there. This seems very odd though, Giacomo, are you sure it also happens if you unload the module? I'm confused. Should the mac80211: detect driver tx bugs patch be sent to stable? Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
