| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 93f4d91d879acfcb0ba9c2725e3133fcff2dfd1e upstream.
Fix formatting on r8169 printk
Brandon Philips noted that I had a spacing issue in my printk for the
last r8169 patch that made it quite ugly. Fix that up and add the PFX
macro to it as well so it looks like the other r8169 printks
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit dac876193cd79ced36d0462749ea47c05844fb49 upstream.
Tx ring buffers after tx_ring->next_to_use are volatile and could
change, possibly causing a crash. Stop cleaning when we hit
tx_ring->next_to_use.
Signed-off-by: Terry Loftin <terry.loftin@hp.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Matthew Burgess <matthew@linuxfromscratch.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit bbcbb9ef9735c67da303d30bd6beb9e699f0f508 upstream.
There is a problem if an "internal short scan" is in progress when a
mac80211 requested scan arrives. If this new scan request arrives within
the "next_scan_jiffies" period then driver will immediately return success
and complete the scan. The problem here is that the scan has not been
fully initialized at this time (is_internal_short_scan is still set to true
because of the currently running scan), which results in the scan
completion never to be sent to mac80211. At this time also, evan though the
internal short scan is still running the state (is_internal_short_scan)
will be set to false, so when the internal scan does complete then mac80211
will receive a scan completion.
Fix this by checking right away if a scan is in progress when a scan
request arrives from mac80211.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit dff010ac8e57e43669518a14c0e945dfeb80c2a7 upstream.
Reset and clear all the tx queues when finished downloading runtime
uCode and ready to go into operation mode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 9e3bd9190800e8209b4a3e1d724c35f0738dcad2 upstream.
This makes the b43 driver just automatically fall back to PIO mode when
DMA doesn't work.
The driver already told the user to do it, so rather than have the user
reload the module with a new flag, just make the driver do it
automatically. We keep the message as an indication that something is
wrong, but now just automatically fall back to the hopefully working PIO
case.
(Some post-2.6.33 merge fixups by Larry Finger <Larry.Finger@lwfinger.net>
and yours truly... -- JWL)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit b02914af4d7020828ce921a572589dd793517c09 upstream.
If userencounter the "Fatal DMA Problem" with a BCM43XX device, and
still wish to use b43 as the driver, their only option is to rebuild
the kernel with CONFIG_B43_FORCE_PIO. This patch removes this option and
allows PIO mode to be selected with a load-time parameter for the module.
Note that the configuration variable CONFIG_B43_PIO is also removed.
Once the DMA problem with the BCM4312 devices is solved, this patch will
likely be reverted.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: John Daiker <daikerjohn@gmail.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit ece6444c2fe80dab679beb5f0d58b091f1933b00 upstream.
For 4965, need to check it is valid qos frame before free, only valid
QoS frame has the tid used to free the packets.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 1144601118507f8b3b676a9a392584d216d3f2cc upstream.
With the enable_radio being uninitialized, ath_radio_enable() might be
called twice, which can leave some hardware in an undefined state.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 2d20c72c021d96f8b9230396c8e3782f204214ec upstream.
An int urb is constructed but we fill it in with a bulk pipe type.
Commit f661c6f8c67bd55e93348f160d590ff9edf08904 implemented a pipe type
check when CONFIG_USB_DEBUG is enabled. The check failed for all the ar9170
usb transfers and the driver could not configure the wifi dongle.
This went unnoticed until now because most people don't have
CONFIG_USB_DEBUG enabled.
Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 8e1a53c615e8efe0fac670f2973da64758748a8a upstream.
IWL_RATE_COUNT is 13 and IWL_RATE_COUNT_LEGACY is 12.
IWL_RATE_COUNT_LEGACY is the right one here because iwl3945_rates
doesn't support 60M and also that's how "rates" is defined in
iwlcore_init_geos() from drivers/net/wireless/iwlwifi/iwl-core.c.
rates = kzalloc((sizeof(struct ieee80211_rate) * IWL_RATE_COUNT_LEGACY),
GFP_KERNEL);
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit be6b38bcb175613f239e0b302607db346472c6b6 upstream.
Forget one hunk in 4965 during "iwlwifi: error checking for number of tfds
in queue" patch.
Reported-by: Shanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit f6c8f1523a2de3b84340e45913cbcee8bee74570 upstream.
Commit "cfg80211: convert bools into flags" mistakenly modified iwlwifi's
regulatory settings instead of just converting it. Fix this.
This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2172
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 96869a39399269a776a94812e9fff3d38b47d838 upstream
The TKIP key update callback is called from the RX path, where the driver
mutex is already locked. This results in a circular locking bug.
Avoid this by removing the lock.
Johannes noted that there is a separate bug: The callback still breaks on SDIO
hardware, because SDIO hardware access needs to sleep, but we are not allowed
to sleep in the callback due to mac80211's RCU locking.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: kecsa@kutfo.hit.bme.hu
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ Upstream commit c0cd884af045338476b8e69a61fceb3f34ff22f1 ]
Official patch to fix the r8169 frame length check error.
Based on this initial thread:
http://marc.info/?l=linux-netdev&m=126202972828626&w=1
This is the official patch to fix the frame length problems in the r8169
driver. As noted in the previous thread, while this patch incurs a performance
hit on the driver, its possible to improve performance dynamically by updating
the mtu and rx_copybreak values at runtime to return performance to what it was
for those NICS which are unaffected by the ideosyncracy (if there are any).
Summary:
A while back Eric submitted a patch for r8169 in which the proper
allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too
much data. This was done in commit fdd7b4c3302c93f6833e338903ea77245eb510b4. A
long time prior to that however, Francois posted
126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the MaxSize
setting due to the fact that the hardware behaved in odd ways when overlong
frames were received on NIC's supported by this driver. This was mentioned in a
security conference recently:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html
It seems that if we can't enable frame size filtering, then, as Eric correctly
noticed, we can find ourselves DMA-ing too much data to a buffer, causing
corruption. As a result is seems that we are forced to allocate a frame which
is ready to handle a maximally sized receive.
This obviously has performance issues with it, so to mitigate that issue, this
patch does two things:
1) Raises the copybreak value to the frame allocation size, which should force
appropriately sized packets to get allocated on rx, rather than a full new 16k
buffer.
2) This patch only disables frame filtering initially (i.e., during the NIC
open), changing the MTU results in ring buffer allocation of a size in relation
to the new mtu (along with a warning indicating that this is dangerous).
Because of item (2), individuals who can't cope with the performance hit (or can
otherwise filter frames to prevent the bug), or who have hardware they are sure
is unaffected by this issue, can manually lower the copybreak and reset the mtu
such that performance is restored easily.
Signed-off-by: Neil Horman <nhorman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ Upstream commit 211a0d941b1924e667483f822a55e2cc694cd212 ]
When the PCI pool changes were added to fix resume failures:
commit 98468efddb101f8a29af974101c17ba513b07be1
e100: Use pci pool to work around GFP_ATOMIC order 5 memory allocation failu
and
commit 70abc8cb90e679d8519721e2761d8366a18212a6
e100: Fix broken cbs accounting due to missing memset.
This introduced a problem that can happen if the TX ring size
is increased. We need to size the PCI pool using cbs->max
instead of the default cbs->count value.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ Upstream commit 8d6184e4881b423522136aeb3ec1cbd9c35e8813 ]
When the register_netdevice() call fails, the newly allocated device is
not freed.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ Upstream commit c3259c8a7060d480e8eb2166da0a99d6879146b4 ]
This patch fixes UDP socket refcnt bugs in the pppol2tp driver.
A bug can cause a kernel stack trace when a tunnel socket is closed.
A way to reproduce the issue is to prepare the UDP socket for L2TP (by
opening a tunnel pppol2tp socket) and then close it before any L2TP
sessions are added to it. The sequence is
Create UDP socket
Create tunnel pppol2tp socket to prepare UDP socket for L2TP
pppol2tp_connect: session_id=0, peer_session_id=0
L2TP SCCRP control frame received (tunnel_id==0)
pppol2tp_recv_core: sock_hold()
pppol2tp_recv_core: sock_put
L2TP ZLB control frame received (tunnel_id=nnn)
pppol2tp_recv_core: sock_hold()
pppol2tp_recv_core: sock_put
Close tunnel management socket
pppol2tp_release: session_id=0, peer_session_id=0
Close UDP socket
udp_lib_close: BUG
The addition of sock_hold() in pppol2tp_connect() solves the problem.
For data frames, two sock_put() calls were added to plug a refcnt leak
per received data frame. The ref that is grabbed at the top of
pppol2tp_recv_core() must always be released, but this wasn't done for
accepted data frames or data frames discarded because of bad UDP
checksums. This leak meant that any UDP socket that had passed L2TP
data traffic (i.e. L2TP data frames, not just L2TP control frames)
using pppol2tp would not be released by the kernel.
WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120()
Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8
Call Trace:
[<c119e9b7>] ? udp_lib_unhash+0x117/0x120
[<c101b871>] ? warn_slowpath_common+0x71/0xd0
[<c119e9b7>] ? udp_lib_unhash+0x117/0x120
[<c101b8e3>] ? warn_slowpath_null+0x13/0x20
[<c119e9b7>] ? udp_lib_unhash+0x117/0x120
[<c11598a7>] ? sk_common_release+0x17/0x90
[<c11a5e33>] ? inet_release+0x33/0x60
[<c11577b0>] ? sock_release+0x10/0x60
[<c115780f>] ? sock_close+0xf/0x30
[<c106e542>] ? __fput+0x52/0x150
[<c106b68e>] ? filp_close+0x3e/0x70
[<c101d2e2>] ? put_files_struct+0x62/0xb0
[<c101eaf7>] ? do_exit+0x5e7/0x650
[<c1081623>] ? mntput_no_expire+0x13/0x70
[<c106b68e>] ? filp_close+0x3e/0x70
[<c101eb8a>] ? do_group_exit+0x2a/0x70
[<c101ebe1>] ? sys_exit_group+0x11/0x20
[<c10029b0>] ? sysenter_do_call+0x12/0x26
Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ Upstream commit 3feec9095d12e311b7d4eb7fe7e5dfa75d4a72a5 ]
When transmitting L2TP frames, we derive the outgoing interface's UDP
checksum hardware assist capabilities from the tunnel dst dev. This
can sometimes be NULL, especially when routing protocols are used and
routing changes occur. This patch just checks for NULL dst or dev
pointers when checking for netdev hardware assist features.
BUG: unable to handle kernel NULL pointer dereference at 0000000c
IP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp]
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/class/net/lo/operstate
Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Not tainted (2.6.32.8 #1)
EIP: 0060:[<f89d074c>] EFLAGS: 00010297 CPU: 3
EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp]
EAX: 00000000 EBX: f64d1680 ECX: 000005b9 EDX: 00000000
ESI: f6b91850 EDI: f64d16ac EBP: f6a0c4c0 ESP: f70a9cac
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=f70a8000 task=f70a31c0 task.ti=f70a8000)
Stack:
000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800
<0> 000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680
<0> f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f
Call Trace:
[<f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic]
[<f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic]
[<f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic]
[<c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2
[<c11d0947>] ? sch_direct_xmit+0x48/0x10e
[<c11c19a0>] ? dev_queue_xmit+0x263/0x3a6
[<c11e2a9f>] ? ip_finish_output+0x1f7/0x221
[<c11df682>] ? ip_forward_finish+0x2e/0x30
[<c11de645>] ? ip_rcv_finish+0x295/0x2a9
[<c11c0b19>] ? netif_receive_skb+0x3e9/0x404
[<f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e]
[<f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e]
[<c1047eff>] ? sched_clock_local+0x15/0x11b
[<c11c1095>] ? net_rx_action+0x96/0x195
[<c1035750>] ? __do_softirq+0xaa/0x151
[<c1035828>] ? do_softirq+0x31/0x3c
[<c10358fe>] ? irq_exit+0x26/0x58
[<c1004b21>] ? do_IRQ+0x78/0x89
[<c1003729>] ? common_interrupt+0x29/0x30
[<c101ac28>] ? native_safe_halt+0x2/0x3
[<c1008c54>] ? default_idle+0x55/0x75
[<c1009045>] ? c1e_idle+0xd2/0xd5
[<c100233c>] ? cpu_idle+0x46/0x62
Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08
EIP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac
CR2: 000000000000000c
Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
| |
commit 05df49865be08b30e7ba91b9d3d94d7d52dd3033 upstream.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 1a20034a73a40b8056731f9db0c535cec2961eb7 upstream.
beacons configuration SHOULD be done only if the STA is associated.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 3f7c5c10e9dc6bf90179eb9f7c06151d508fb324 upstream.
The TIM timer interrupt is enabled even before the ACK of nullqos
is received which is unnecessary.
Also clean up the CONF_PS part of config callback properly for
better readability.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 4fdec031b9169b3c17938b9c4168f099f457169c upstream.
When I initially stumbled upon sequence number problems with PAE frames
in ath9k, I submitted a patch to remove all special cases for PAE
frames and let them go through the normal transmit path.
Out of concern about crypto incompatibility issues, this change was
merged instead:
commit 6c8afef551fef87a3bf24f8a74c69a7f2f72fc82
Author: Sujith <Sujith.Manoharan@atheros.com>
Date: Tue Feb 9 10:07:00 2010 +0530
ath9k: Fix sequence numbers for PAE frames
After a lot of testing, I'm able to reliably trigger a driver crash on
rekeying with current versions with this change in place.
It seems that the driver does not support sending out regular MPDUs with
the same TID while an A-MPDU session is active.
This leads to duplicate entries in the TID Tx buffer, which hits the
following BUG_ON in ath_tx_addto_baw():
index = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno);
cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
BUG_ON(tid->tx_buf[cindex] != NULL);
I believe until we actually have a reproducible case of an
incompatibility with another AP using no PAE special cases, we should
simply get rid of this mess.
This patch completely fixes my crash issues in STA mode and makes it
stay connected without throughput drops or connectivity issues even
when the AP is configured to a very short group rekey interval.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit c8406ea8fa1adde8dc5400127281d497bbcdb84a upstream.
Commit a239a8b47cc0e5e6d7416a89f340beac06d5edaa introduced a
noisy message, that fills up the log very fast.
The error seems not to be fatal (the connection is stable and
performance is ok), so make it IWL_DEBUG_TX rather than IWL_ERR.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit bf5e5360fd1df1ae429ebbd81838d7d0879797d1 upstream.
Temporary stop the RX IRQ, and disable (sync) tasklet or napi.
And restore it after finished the vlgrp pointer assignment.
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 17da69b8bfbe441a33a873ad5dd7d3d85800bf2b upstream.
Fix memory leak while receiving 8021q tagged packet which is not
registered by user.
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 3f60ebc9d6291863652d564bacc430629271e6a9 upstream.
In case debugfs does not init for some reason (or is disabled
on older kernels) driver does not allocate stats.fw_stats
structure, but tries to clear it later and trips on a NULL
pointer:
Unable to handle kernel NULL pointer dereference at virtual address
00000000
PC is at __memzero+0x24/0x80
Backtrace:
[<bf0ddb88>] (wl1251_debugfs_reset+0x0/0x30 [wl1251])
[<bf0d6a2c>] (wl1251_op_stop+0x0/0x12c [wl1251])
[<bf0bc228>] (ieee80211_stop_device+0x0/0x74 [mac80211])
[<bf0b0d10>] (ieee80211_stop+0x0/0x4ac [mac80211])
[<c02deeac>] (dev_close+0x0/0xb4)
[<c02deac0>] (dev_change_flags+0x0/0x184)
[<c031f478>] (devinet_ioctl+0x0/0x704)
[<c0320720>] (inet_ioctl+0x0/0x100)
Add a NULL pointer check to fix this.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit e9dcd1613f0ac0b3573b7d813a2c5672cd8302eb upstream.
Looks like commit a6e4bc530403 didn't include updates to drivers so the
Blackfin CAN driver fails to build now.
Signed-off-by: Barry Song <barry.song@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit f36d04abe684f9e2b07c6ebe9f77ae20eb5c1e84 upstream.
Change pci_alloc_consistent() to dma_alloc_coherent() so we can use
GFP_KERNEL flag.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backport of of upstream commit:
5ffaf8a361b4c9025963959a744f21d8173c7669
Some single chip family devices are sold in the market with
802.11n bonded out, these have no hardware capability for
02.11n but ath9k can still support them. These are called
AR2427.
Reported-by: Rolf Leggewie <bugzilla.kernel.org@rolf.leggewie.biz>
Tested-by: Bernhard Reiter <ockham@raz.or.at>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit a9f042cbe5284f34ccff15f3084477e11b39b17b upstream.
Since txq->axq_lock may be hold in softirq context, it must be
acquired with spin_lock_bh() instead of spin_lock() if softieq is
enabled.
The patch fixes the lockdep warning below when unloading ath9k modules.
=================================
[ INFO: inconsistent lock state ]
2.6.33-wl #12
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
rmmod/3642 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&txq->axq_lock)->rlock){+.?...}, at: [<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k]
{IN-SOFTIRQ-W} state was registered at:
[<ffffffff8107577d>] __lock_acquire+0x2f6/0xd35
[<ffffffff81076289>] lock_acquire+0xcd/0xf1
[<ffffffff813a7486>] _raw_spin_lock_bh+0x3b/0x6e
[<ffffffffa0356b49>] spin_lock_bh+0xe/0x10 [ath9k]
[<ffffffffa0358ec7>] ath_tx_tasklet+0xcd/0x391 [ath9k]
[<ffffffffa0354f5f>] ath9k_tasklet+0x70/0xc8 [ath9k]
[<ffffffff8104e601>] tasklet_action+0x8c/0xf4
[<ffffffff8104f459>] __do_softirq+0xf8/0x1cd
[<ffffffff8100ab1c>] call_softirq+0x1c/0x30
[<ffffffff8100c2cf>] do_softirq+0x4b/0xa3
[<ffffffff8104f045>] irq_exit+0x4a/0x8c
[<ffffffff813acccc>] do_IRQ+0xac/0xc3
[<ffffffff813a7d53>] ret_from_intr+0x0/0x16
[<ffffffff81302d52>] cpuidle_idle_call+0x9e/0xf8
[<ffffffff81008be7>] cpu_idle+0x62/0x9d
[<ffffffff81391c1a>] rest_init+0x7e/0x80
[<ffffffff818bbd38>] start_kernel+0x3e8/0x3f3
[<ffffffff818bb2bc>] x86_64_start_reservations+0xa7/0xab
[<ffffffff818bb3b8>] x86_64_start_kernel+0xf8/0x107
irq event stamp: 42037
hardirqs last enabled at (42037): [<ffffffff813a7b21>] _raw_spin_unlock_irqrestore+0x47/0x56
hardirqs last disabled at (42036): [<ffffffff813a72f4>] _raw_spin_lock_irqsave+0x2b/0x88
softirqs last enabled at (42000): [<ffffffffa0353ea6>] spin_unlock_bh+0xe/0x10 [ath9k]
softirqs last disabled at (41998): [<ffffffff813a7463>] _raw_spin_lock_bh+0x18/0x6e
other info that might help us debug this:
4 locks held by rmmod/3642:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8132c10d>] rtnl_lock+0x17/0x19
#1: (&wdev->mtx){+.+.+.}, at: [<ffffffffa01e53f2>] cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
#2: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0260834>] ieee80211_mgd_deauth+0x3f/0x17e [mac80211]
#3: (&local->sta_mtx){+.+.+.}, at: [<ffffffffa025a381>] sta_info_destroy_addr+0x2b/0x5e [mac80211]
stack backtrace:
Pid: 3642, comm: rmmod Not tainted 2.6.33-wl #12
Call Trace:
[<ffffffff81074469>] valid_state+0x178/0x18b
[<ffffffff81014f94>] ? save_stack_trace+0x2f/0x4c
[<ffffffff81074e08>] ? check_usage_backwards+0x0/0x88
[<ffffffff8107458f>] mark_lock+0x113/0x230
[<ffffffff810757f1>] __lock_acquire+0x36a/0xd35
[<ffffffff8101018d>] ? native_sched_clock+0x2d/0x5f
[<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
[<ffffffff81076289>] lock_acquire+0xcd/0xf1
[<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
[<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff813a7193>] _raw_spin_lock+0x36/0x69
[<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
[<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k]
[<ffffffff810749ed>] ? trace_hardirqs_on+0xd/0xf
[<ffffffffa0353950>] ath9k_sta_remove+0x22/0x26 [ath9k]
[<ffffffffa025a08f>] __sta_info_destroy+0x1ad/0x38c [mac80211]
[<ffffffffa025a394>] sta_info_destroy_addr+0x3e/0x5e [mac80211]
[<ffffffffa02605d6>] ieee80211_set_disassoc+0x175/0x180 [mac80211]
[<ffffffffa026084d>] ieee80211_mgd_deauth+0x58/0x17e [mac80211]
[<ffffffff813a60c1>] ? __mutex_lock_common+0x37f/0x3a4
[<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
[<ffffffffa026786e>] ieee80211_deauth+0x1e/0x20 [mac80211]
[<ffffffffa01f47f9>] __cfg80211_mlme_deauth+0x130/0x13f [cfg80211]
[<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
[<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf
[<ffffffffa01f7eee>] __cfg80211_disconnect+0x111/0x189 [cfg80211]
[<ffffffffa01e5433>] cfg80211_netdev_notifier_call+0x2ce/0x46d [cfg80211]
[<ffffffff813aa9ea>] notifier_call_chain+0x37/0x63
[<ffffffff81068c98>] raw_notifier_call_chain+0x14/0x16
[<ffffffff81322e97>] call_netdevice_notifiers+0x1b/0x1d
[<ffffffff8132386d>] dev_close+0x6a/0xa6
[<ffffffff8132395f>] rollback_registered_many+0xb6/0x2f4
[<ffffffff81323bb8>] unregister_netdevice_many+0x1b/0x66
[<ffffffffa026494f>] ieee80211_remove_interfaces+0xc5/0xd0 [mac80211]
[<ffffffffa02580a2>] ieee80211_unregister_hw+0x47/0xe8 [mac80211]
[<ffffffffa035290e>] ath9k_deinit_device+0x7a/0x9b [ath9k]
[<ffffffffa035bc26>] ath_pci_remove+0x38/0x76 [ath9k]
[<ffffffff8120940a>] pci_device_remove+0x2d/0x51
[<ffffffff8129d797>] __device_release_driver+0x7b/0xd1
[<ffffffff8129d885>] driver_detach+0x98/0xbe
[<ffffffff8129ca7a>] bus_remove_driver+0x94/0xb7
[<ffffffff8129ddd6>] driver_unregister+0x6c/0x74
[<ffffffff812096d2>] pci_unregister_driver+0x46/0xad
[<ffffffffa035bae1>] ath_pci_exit+0x15/0x17 [ath9k]
[<ffffffffa035e1a2>] ath9k_exit+0xe/0x2f [ath9k]
[<ffffffff8108050a>] sys_delete_module+0x1c7/0x236
[<ffffffff813a7df5>] ? retint_swapgs+0x13/0x1b
[<ffffffff810749b5>] ? trace_hardirqs_on_caller+0x119/0x144
[<ffffffff8109b9f6>] ? audit_syscall_entry+0x11e/0x14a
[<ffffffff81009bb2>] system_call_fastpath+0x16/0x1b
wlan1: deauthenticating from 00:23:cd:e1:f9:b2 by local choice (reason=3)
PM: Removing info for No Bus:wlan1
cfg80211: Calling CRDA to update world regulatory domain
PM: Removing info for No Bus:rfkill2
PM: Removing info for No Bus:phy1
ath9k 0000:16:00.0: PCI INT A disabled
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit a951ae2176b982574ffa197455db6c89359fd5eb upstream.
The beacon sent gating doesn't seem to work with any combination
of flags. Thus, buffered frames tend to stay buffered forever,
using up tx descriptors.
Instead, use the DBA gating and hold transmission of the buffered
frames until 80% of the beacon interval has elapsed using the ready
time. This fixes the following error in AP mode:
ath5k phy0: no further txbuf available, dropping packet
Add a comment to acknowledge that this isn't the best solution.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 5d6ce628f986d1a3c523cbb0a5a52095c48cc332 upstream.
When using the external sleep clock in AP mode, the
TSF increments too quickly, causing beacon interval
to be much lower than it is supposed to be, resulting
in lots of beacon-not-ready interrupts.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=14802.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 86415d43efd4f7093979cfa8a80232114266f1a4 upstream.
I/Q calibration was completely broken, resulting in a high number of CRC errors
on received packets. before i could see around 10% to 20% CRC errors, with this
patch they are between 0% and 3%.
1.) the removal of the mask in commit "ath5k: Fix I/Q calibration
(f1cf2dbd0f798b71b1590e7aca6647f2caef1649)" resulted in no mask beeing used
when writing the I/Q values into the register. additional errors in the
calculation of the values (see 2.) resulted too high numbers, exceeding the
masks, so wrong values like 0xfffffffe were written. to be safe we should
always use the bitmask when writing parts of a register.
2.) using a (s32) cast for q_coff is a wrong conversion to signed, since we
convert to a signed value later by substracting 128. this resulted in too low
numbers for Q many times, which were limited to -16 by the boundary check later
on.
3.) checked everything against the HAL sources and took over comments and minor
optimizations from there.
4.) we can't use ENABLE_BITS when we want to write a number (the number can
contain zeros). also always write the correction values first and set ENABLE
bit last, like the HAL does.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit fe234f0e5cbb880792d2d1ac0743cf8c07e9dde3 upstream.
Commit 09943a1819a240ff4a72f924d0038818fcdd0a90
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Fri Aug 28 14:01:57 2009 +0000
tg3: Convert ISR parameter to tnapi
forgot to update tg3_poll_controller(), leading to intermittent crashes with
netpoll.
Fix this.
Signed-off-by: Louis Rilling <louis.rilling@kerlabs.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 4fa004373133ece3d9b1c0a7e243b0e53760b165 upstream.
Handling HT configuration changes involved setting the channel
with the new HT parameters and then issuing a rate_update()
notification to the driver.
This behavior changed after the off-channel changes. Now, the channel
is not updated with the new HT params in enable_ht() - instead, it
is now done when the scan work terminates. This results in the driver
depending on stale information, defaulting to non-HT mode always.
Fix this by passing the new channel type to the driver.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 0866b03c7d7dee8a34ffa527ecda426c0f405518 upstream.
If b43 or b43legacy are deauthenticated or disconnected, there is a
possibility that a reconnection is tried with the queues stopped in
mac80211. To prevent this, start the queues before setting
STAT_INITIALIZED.
In b43, a similar change has been in place (twice) in the
wireless_core_init() routine. Remove the duplicate and add similar
code to b43legacy.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 2ac2927a953a01c83df255118922cce1523d1a18 upstream.
The hardware needs to know what type of frames are being
sent in order to fill in various fields, for example the
timestamp in probe responses (before this patch, it was
always 0). Set it correctly when initializing the TX
descriptor.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 7bfbae10dc10a5c94a780d117a57e875d77e8e5a upstream.
While ath9k does not support RIFS yet, the ability to receive RIFS
frames is currently enabled for most chipsets in the initvals.
This is causing baseband related issues on AR9160 and AR9130 based
chipsets, which can lock up under certain conditions.
This patch fixes these issues by overriding the initvals, effectively
disabling RIFS for all affected chipsets.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 5c0ba62fd4b2dce08055a89600f1d834f9f0fe9e upstream.
When selecting the tx fallback rate, rc.c used a separate variable
'nrix' for storing the next rate index, however it did not use that as
reference for further rate index lowering. Because of that, it ended up
reusing the same rate for multiple multi-rate retry stages, thus
decreasing delivery probability under changing link conditions.
This patch removes the separate (unnecessary) variable and fixes
fallback the way it was intended to work.
This should result in increased throughput and better link stability.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit d8728ee919282c7b01b65cd479ec1e2a9c5d3ba8 upstream.
In AP mode, ath_beacon_config_ap only restarts the timer if a TSF
restart is requested. Apparently this was added, because this function
unconditionally sets the flag for TSF reset.
The problem with this is, that ath9k_hw_reset() clobbers the timer
registers (specified in the initvals), thus effectively disabling the
SWBA interrupt whenever a card reset without TSF reset is issued
(happens in a few places in the code).
This patch fixes ath_beacon_config_ap to only issue the TSF reset flag
when necessary, but reinitialize the timer unconditionally. Tests show,
that this is enough to keep the SWBA interrupt going after a call to
ath_reset()
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
The newer single chip hardware family of chipsets have not been
experiencing issues with power saving set by default with recent
fixes merged (even into stable). The remaining issues are only
reported with AR5416 and since enabling PS by default can increase
power savings considerably best to take advantage of that feature
as this has been tested properly.
For more details on this issue see the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=14267
We leave AR5416 with PS disabled by default, that seems to require
some more work.
Cc: Peter Stuge <peter@stuge.se>
Cc: Justin P. Mattock <justinmattock@gmail.com>
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
| |
commit 288c8ce8047695fd8872dd5db3ef21a9679c402f upstream.
This patch adds error-paths to handle pci_dma_mapping errors.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 5b9a919a97ac8bdda8020c9b366491b5b91b196e upstream.
Yet another USB ID.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 733da37dab72de6b3f8b0c56b5cdea322f18a684 upstream.
If split tkip key is used, ath_delete_key should delete
rx key and rx mic key. This patch fixes the leak of hw
keycache in the case.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit f09c256375c7cf1e112b8ef6306cdd313490d7c0 upstream.
Patch prevents call set_wep_key() with zero key length. That fix long
standing regression since commit c0380693520b1a1e4f756799a0edc379378b462a
"airo: clean up WEP key operations". Additionally print call trace when
someone will try to use improper parameters, and remove key.len = 0
assignment, because it is in not possible code path.
Reported-by: Chris Siebenmann <cks-rhbugzilla@cs.toronto.edu>
Bisected-by: Chris Siebenmann <cks-rhbugzilla@cs.toronto.edu>
Tested-by: Chris Siebenmann <cks@cs.toronto.edu>
Cc: Dan Williams <dcbw@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|\
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Check the frame control for ieee80211_is_data_qos() is true before
counting the number of tfds can be free, the tfds_in_queue only
increment when ieee80211_is_data_qos() is true before transmit; so it
should only decrement if the type match.
Remove ieee80211_is_data_qos check for frame_ctrl in tx_resp to avoid
invalid information pass from uCode.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When receive reply_tx and ready to decrement the count for number of
tfds in queue, do error checking to prevent error condition and
tfds_in_queue become negative number.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The HT extension channel settings require priv->staging_rxon.channel to be
accurate. However, iwl_set_rxon_ht was being called before iwl_set_rxon_channel
and thus HT40 could be broken unless another call to iwl_mac_config came in.
This problem was recently introduced by "iwlwifi: Fix to set correct ht
configuration"
The particular setting in which I noticed this was monitor mode:
iwconfig wlan0 mode monitor
ifconfig wlan0 up
./iw wlan0 set channel 64 HT40-
#./iw wlan0 set channel 64 HT40-
tcpdump -i wlan0 -y IEEE802_11_RADIO
would only catch HT40 packets if I issued the IW command twice.
From visual inspection, iwl_set_rxon_channel does not depend on
iwl_set_rxon_ht, so simply swapping them should be safe and fixes this problem.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The netif_wake_queue() is called correctly (i.e. only on !txfull
condition) from txdone routine. So Unconditional call to the
netif_wake_queue() here is wrong. This might cause calling of
start_xmit routine on txfull state and trigger BUG_ON.
This bug does not happen when NAPI disabled. After txdone there
must be at least one free tx slot. But with NAPI, this is not
true anymore and the BUG_ON can hits on heavy load.
In this driver NAPI was enabled on 2.6.33-rc1 so this is
regression from 2.6.32 kernel.
Reported-by: Ralf Roesch <ralf.roesch@rw-gmbh.de>
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
|