In rt2800usb_work_txdone we check flags in order:
- ENTRY_OWNER_DEVICE_DATA
- ENTRY_DATA_STATUS_PENDING
- ENTRY_DATA_IO_FAILED
Modify flags in separate order in rt2x00usb_interrupt_txdone, to avoid
processing entries in _txdone with wrong flags or skip processing
ready entries.
Reported-by: Justin Piszcz <[email protected]>
Cc: [email protected]
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Ivo van Doorn <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We receive many bug reports about system hang during suspend/resume
when ath9k driver is in use. Adrian Chadd remarked that this problem
happens on systems that have ASPM disabled.
To do not hit the bug, skip doing ->config_pci_powersave magic if PCIe
downstream port device, which ath9k device is connected to, has ASPM
disabled.
Bug was introduced by:
commit 53bc7aa08b
Author: Vivek Natarajan <[email protected]>
Date: Mon Apr 5 14:48:04 2010 +0530
ath9k: Add support for newer AR9285 chipsets.
Patch should address:
https://bugzilla.kernel.org/show_bug.cgi?id=37462https://bugzilla.kernel.org/show_bug.cgi?id=37082https://bugzilla.redhat.com/show_bug.cgi?id=697157
however I did not receive confirmation about that, except from Camilo
Mesias, whose system stops hang regularly with this patch (but still
hangs from time to time, but this is probably some other bug).
Tested-by: Camilo Mesias <[email protected]>
Cc: [email protected] # 2.6.35+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
If settings of tx power was deferred during scan or changing channel we
have to setup them during commit rxon. Fix problem on 3945 (4965 already
has this fix).
Optimize code to apply tx settings only when tx power was actually
changed.
Cc: [email protected] # 2.6.39+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
priv->bus.bus_specific pointer is used after priv structures was freed,
in iwl_pci_remove(), what make ugly rmmod crash. This bug was introduced
by current pci changes.
On the way remove fake check, if prober error code is returned from
.probe() function, .remove() will never be called be null drvdata.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Use less indentions and remove uneeded irq-save flags.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We do not reset radio anymore, hence don't need that code too.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Recover from statistics code was added during 6xxx devices development,
I don't think is needed on old devices. Also it is suspicious to cause
random, unreproducible microcode errors and hangs. So remove it.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().
To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.
Cc: [email protected] # 2.6.39+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Setting tx power can be deferred during scan or changing channel.
If after that correct tx power settings will not be sent to device,
we can observe transmission problems and timeouts. Force to send
tx power settings also after partial rxon change, to assure device
always be configured with up-to-date settings.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=36492
Cc: [email protected] # 2.6.39+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This patch fixes 802.11n stability and performance regression we have
since 2.6.35. It boost performance on my 5GHz N-only network from about
5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz.
These are test results of 5x downloading of approximately 700MB iso
image:
vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110
patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946
This was achieved with NetworkManager configured to do not perform
periodical scans, by configuring constant BSSID. With periodical scans,
after some time, performance downgrade to unpatched driver level, like
in example below:
patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683
However patch still make better here, since similar test on unpatched
driver make link disconnects with below messages after some time:
wlan1: authenticate with 00:23:69:35:d1:3f (try 1)
wlan1: authenticate with 00:23:69:35:d1:3f (try 2)
wlan1: authenticate with 00:23:69:35:d1:3f (try 3)
wlan1: authentication with 00:23:69:35:d1:3f timed out
On 2.6.35 kernel patch helps against connection hangs with messages:
iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload.
iwlagn 0000:20:00.0: On demand firmware reload
iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting
Cc: [email protected] # 2.6.35+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We use priv->mutex to avoid race conditions between iwl_chswitch_done()
and iwlagn_mac_channel_switch(), when marking channel switch in
progress. But iwl_chswitch_done() can be called in atomic context
from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon().
These bugs were introduced by:
commit 79d0732550
Author: Wey-Yi Guy <[email protected]>
Date: Thu May 6 08:54:11 2010 -0700
iwlwifi: support channel switch offload in driver
To fix remove mutex from iwl_chswitch_done() and use atomic bitops for
marking channel switch pending.
Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
2.4GHz only devices.
Cc: [email protected] # 2.6.36+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
rx_status.band is used uninitialized, what disallow to work on 5GHz .
Cc: [email protected] # 2.6.39+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We should not switch to non-IBSS channels when working in IBSS mode,
otherwise there are microcode errors, and after some time system
crashes.
This bug is only observable when software scan is used in IBSS mode,
so should be considered as regression after:
commit 0263aa4529
Author: Stanislaw Gruszka <[email protected]>
Date: Tue Mar 29 11:24:21 2011 +0200
iwl3945: disable hw scan by default
However IBSS mode check, which this patch add again, was removed by
commit b2f30e8bdd
Author: Johannes Berg <[email protected]>
Date: Thu Jan 21 07:32:20 2010 -0800
iwlwifi: remove IBSS channel sanity check
That commit claim that mac80211 will not use non-IBSS channel in IBSS
mode, what definitely is not true. Bug probably should be fixed in
mac80211, but that will require more work, so better to apply that patch
temporally, and provide proper mac80211 fix latter.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=34452
Reported-and-tested-by: Mikko Rapeli <[email protected]>
Cc: [email protected] # 2.6.38.5+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We now use priv->mutex to serialize sync command, remove old
priv->sync_cmd_mutex and add assertion that priv->mutex must be locked.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Check status bits with mutex taken, because when we wait for mutex
unlock, status can change. Patch should also make remaining sync
commands be send with priv->mutex taken. That will prevent execute
these commands when we are currently reset firmware, what could
possibly cause troubles.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We mark command as huge by using meta->flags from other (non huge) command,
but flags can be possibly overridden, when non huge command is enqueued,
what can lead to:
WARNING: at lib/dma-debug.c:696 dma_debug_device_change+0x1a3/0x1f0()
DMA-API: device driver has pending DMA allocations while released from device [count=1]
To fix introduce additional CMD_MAPPED to mark command as mapped and
serialize iwl_enqueue_hcmd() with iwl_tx_cmd_complete() using
hcmd_lock. Serialization will also fix possible race conditions,
because q->read_ptr, q->write_ptr are modified/used in parallel.
Do not change callback, I did (and fixed) that mistake in iwlagn.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
struct iwl_queue is not part of firmware interface, so __packed is not
needed. Remove it since is may affect performance.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We never set STATUS_SCANNING in softwre scanning mode, disable_hw_scan
check is unneeded. Correct debug message while at it.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Don't need to use conditional as ch->band is already assigned to
IEEE80211_BAND_5GHZ or IEEE80211_BAND_2GHZ
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Add two below iwlwifi commits to iwlegacy:
commit 554d1d027b
Author: Stanislaw Gruszka <[email protected]>
Date: Thu Dec 23 12:38:21 2010 +0100
iwlagn: enable only rfkill interrupt when device is down
commit 3dd823e6b8
Author: Don Fry <[email protected]>
Date: Sun Feb 6 09:29:45 2011 -0800
iwlagn: Re-enable RF_KILL interrupt when down
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since
commit f844a709a7
Author: Stanislaw Gruszka <[email protected]>
Date: Fri Jan 28 16:47:44 2011 +0100
iwlwifi: do not set tx power when channel is changing
we set device tx power during initialization to priv->tx_power_next,
which itself is initialized to minimum power. That changed
default behaviour of driver. Previously we initialized device to
transmit at maximum available power by default. Patch change again
to previous behaviour and cleanup tx power initialization.
Fortunately this is not critical fix, as mac80211 layer setup
tx power lately to 14dB, hence device does not operate at minimal
transmit power all the time.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Need to use broadcast sta_id for management frames, otherwise we broke
BA session in the firmware and get messages like that:
"Received BA when not expected"
or (on older kernels):
"BA scd_flow 0 does not match txq_id 10"
This fix regression introduced in 2.6.35 during station management
code rewrite by:
commit 2a87c26bbe
Author: Johannes Berg <[email protected]>
Date: Fri Apr 30 11:30:45 2010 -0700
iwlwifi: use iwl_find_station less
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Need to use broadcast sta_id for management frames, otherwise we broke
BA session in the firmware and get messages like that:
"Received BA when not expected"
or (on older kernels):
"BA scd_flow 0 does not match txq_id 10"
This fix regression introduced in 2.6.35 during station management
code rewrite by:
commit 2a87c26bbe
Author: Johannes Berg <[email protected]>
Date: Fri Apr 30 11:30:45 2010 -0700
iwlwifi: use iwl_find_station less
Patch partially resolve:
https://bugzilla.kernel.org/show_bug.cgi?id=16691
However, there are still 11n performance problems on 4965 and 5xxx
devices that need to be investigated.
Cc: [email protected] # 2.6.35+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Johannes Berg <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
My commit 3598e1774c
"iwlwifi: fix enqueue hcmd race conditions" move hcmd callback after
command queue reclaim, to avoid call it with hcmd_lock. But since
queue read index was updated, cmd data can be overwritten. Fix problem
by calling callback before taking hcmd_lock and queue reclaim.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since
commit a120e912eb
Author: Stanislaw Gruszka <[email protected]>
Date: Fri Feb 19 15:47:33 2010 -0800
iwlwifi: sanity check before counting number of tfds can be free
we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.
On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link, making bisection of other problems impossible.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since
commit a120e912eb
Author: Stanislaw Gruszka <[email protected]>
Date: Fri Feb 19 15:47:33 2010 -0800
iwlwifi: sanity check before counting number of tfds can be free
we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.
On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link.
Cc: [email protected] # 2.6.32+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
priv->tx_power_next is not initialized to max supported power,
but instead default value is used, what cause errors like
[ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
[ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).
if maximum tx power read from the eeprom is smaller than default.
In consequence card is unable to initialize properly. Fix the problem
and cleanup tx power initialization.
Reported-and-tested-by: Robin Dong <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We now use priv->mutex to serialize sync command, remove old
priv->sync_cmd_mutex and add assertion that priv->mutex must be locked.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Check status bits with mutex taken, because when we wait for mutex
unlock, status can change. Patch should also make remaining sync
commands be send with priv->mutex taken. That will prevent execute
these commands when we are currently reset firmware, what could
possibly cause troubles.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We mark command as huge by using meta->flags from other (non huge) command,
but flags can be possibly overridden, when non huge command is enqueued,
what can lead to:
WARNING: at lib/dma-debug.c:696 dma_debug_device_change+0x1a3/0x1f0()
DMA-API: device driver has pending DMA allocations while released from device [count=1]
To fix introduce additional CMD_MAPPED to mark command as mapped and
serialize iwl_enqueue_hcmd() with iwl_tx_cmd_complete() using
hcmd_lock. Serialization will also fix possible race conditions,
because q->read_ptr, q->write_ptr are modified/used in parallel.
On the way fix whitespace.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
When driver leak dma mapping, print additional information about one of
leaked entries, to to help investigate problem. Patch should be useful
for debugging drivers, which maps many different class of buffers.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Software scanning can be used for workaround some performance problems,
so do not deprecate it.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
After commit d5dbda2380 "ethtool: Add
support for vlan accleration.", drivers that have NETIF_F_HW_VLAN_TX,
and/or NETIF_F_HW_VLAN_RX feature, but do not allow enable/disable vlan
acceleration via ethtool set_flags, always return -EINVAL from that
function. Fix by returning -EINVAL only if requested features do not
match current settings and can not be changed by driver.
Change any driver that define ethtool->set_flags to use
ethtool_invalid_flags() to avoid similar problems in the future
(also on drivers that do not have the problem).
Tested with modified (to reproduce this bug) myri10ge driver.
Cc: [email protected] # 2.6.37+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Avoid theoretical race condition regarding accessing dev->features
NETIF_F_LRO flag, which is illustrated below.
CPU1 CPU2
myri10ge_clean_rx_done(): myri10ge_set_flags():
or
myri10ge_set_rx_csum():
if (dev->features & NETIF_F_LRO)
setup lro
dev->features |= NETIF_F_LRO
or
dev->features &= ~NETIF_F_LRO;
if (dev->features & NETIF_F_LRO)
flush lro
On the way reduce myri10ge_rx_done() number of arguments and calls by
moving mgp->small_bytes check into that function. That reduce code size
from:
text data bss dec hex filename
36644 248 100 36992 9080 drivers/net/myri10ge/myri10ge.o
to:
text data bss dec hex filename
36037 247 100 36384 8e20 drivers/net/myri10ge/myri10ge.o
on my i686 system, what should also make myri10ge_clean_rx_done()
being faster.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because napi
structures are already deallocated. To fix call netif_napi_del() before
kfree() at myri10ge_free_slices().
Cc: [email protected]
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
In complex subsystems like mac80211 structures can contain several
timers and work structs, so identifying a specific instance from the
call trace and object type output of debugobjects can be hard.
Allow the subsystems which support debugobjects to provide a hint
function. This function returns a pointer to a kernel address
(preferrably the objects callback function) which is printed along
with the debugobjects type.
Add hint methods for timer_list, work_struct and hrtimer.
[ tglx: Massaged changelog, made it compile ]
Signed-off-by: Stanislaw Gruszka <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Usually H/W generate statistics notify once per about 100ms, but
sometimes we can receive notify in shorter time, even 2 ms.
This can be problem for plcp health and ack health checking.
I.e. with 2 plcp errors happens randomly in 2 ms duration, we
exceed plcp delta threshold equal to 100 (2*100/2).
Also checking ack's in short time, can results not necessary false
positive and firmware reset, for example when channel is noised and
we do not receive ACKs frames or when remote device does not send
ACKs at the moment.
Patch change code to do statistic check and possible recovery only
if 99ms elapsed from last check. Forced delay should assure we have
good statistic data to estimate hardware state.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Put generic rx_handlers (except iwlagn_rx_reply_compressed_ba) to
iwl-rx.c . Make functions static and change prefix from iwlagn_ to
iwl_ . Beautify iwl_setup_rx_handlers and do some other minor coding
style changes.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
For some time is known that ASPM is causing troubles on r8169, i.e. make
device randomly stop working without any errors in dmesg.
Currently Tomi Leppikangas reports that system with r8169 device hangs
with MCE errors when ASPM is enabled:
https://bugzilla.redhat.com/show_bug.cgi?id=642861#c4
Lets disable ASPM for r8169 devices at all, to avoid problems with
r8169 PCIe devices at least for some users.
Reported-by: Tomi Leppikangas <[email protected]>
Cc: [email protected]
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
There is no need to have separate iwl-agn-rx.c file after iwlegacy
split.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Remove check_plcp_health and check_ack_health ops methods, they are
unneeded after iwlegacy driver split. Merge check health code into to
iwl-rx.c and make functions static.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Add module ack_check, and plcp_check parameters. Ack_check is disabled
by default since is proved that check ack health can cause troubles.
Plcp_check is enabled by default.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Fix possible dma mappings and skbs introduced by commit
470058e0ad "iwlwifi: avoid Tx queue
memory allocation in interface down".
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since commit commit 470058e0ad
"iwlwifi: avoid Tx queue memory allocation in interface down" we do
not unmap dma and free skbs when down device and there is pending
transfer. What in consequence may cause that system hung (waiting
for free skb's) when performing shutdown at iptables module unload.
DMA leak manifest itself following warning:
WARNING: at lib/dma-debug.c:689 dma_debug_device_change+0x15a/0x1b0()
Hardware name: HP xw8600 Workstation
pci 0000:80:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=240]
Modules linked in: iwlagn(-) aes_x86_64 aes_generic fuse cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod uinput hp_wmi sparse_keymap sg wmi microcode serio_raw tg3 arc4 ecb shpchp mac80211 cfg80211 rfkill ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif firewire_ohci firewire_core crc_itu_t mptsas mptscsih mptbase scsi_transport_sas pata_acpi ata_generic ata_piix ahci libahci floppy nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iwlagn]
Pid: 9131, comm: rmmod Tainted: G W 2.6.38-rc6-wl+ #33
Call Trace:
[<ffffffff810649ef>] ? warn_slowpath_common+0x7f/0xc0
[<ffffffff81064ae6>] ? warn_slowpath_fmt+0x46/0x50
[<ffffffff812320ab>] ? dma_debug_device_change+0xdb/0x1b0
[<ffffffff8123212a>] ? dma_debug_device_change+0x15a/0x1b0
[<ffffffff8149dc18>] ? notifier_call_chain+0x58/0xb0
[<ffffffff8108e370>] ? __blocking_notifier_call_chain+0x60/0x90
[<ffffffff8108e3b6>] ? blocking_notifier_call_chain+0x16/0x20
[<ffffffff812f570c>] ? __device_release_driver+0xbc/0xe0
[<ffffffff812f5808>] ? driver_detach+0xd8/0xe0
[<ffffffff812f45d1>] ? bus_remove_driver+0x91/0x100
[<ffffffff812f6022>] ? driver_unregister+0x62/0xa0
[<ffffffff8123d5d4>] ? pci_unregister_driver+0x44/0xa0
[<ffffffffa05632d1>] ? iwl_exit+0x15/0x1c [iwlagn]
[<ffffffff810ab492>] ? sys_delete_module+0x1a2/0x270
[<ffffffff81498da9>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8100bf42>] ? system_call_fastpath+0x16/0x1b
I still can observe above warning after apply patch, but it is very
hard to reproduce it, and have count=1. Whereas that one is easy to
reproduce using debugfs force_reset while transmitting data, and have
very big counts eg. 240, like quoted here. So count=1 WARNING seems
to be different issue that need to be resolved separately.
v1 -> v2: fix infinity loop bug I made during "for" to "while" loop transition.
v2 -> v3: remove unneeded EXPORT_SYMBOL
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Is still possible to schedule conn_mon_timer after disassociate from
ieee80211_sta_tx_notify() and ieee80211_offchannel_ps_disable().
Move disassociate check to ieee80211_sta_reset_conn_monitor() to cover
all these cases, and add unlikely since in most the time we call
ieee80211_sta_reset_conn_monitor() when associated.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Commit 4df3071ebd "ath9k_hw: optimize
interrupt mask changes", changed ath9k_hw_set_interrupts function to
enable interrupts regardless of function argument, what could possibly
be wrong. Correct that behaviour and check "ints" arguments before
enabling interrupts, also disable interrupts if ints do not have
ATH9K_INT_GLOBAL flag set.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Combo devices have TX statistics on different place, because
struct statistics_rx_bt and struct statistics_rx have different
size. User proper values on combo devices instead of random data.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Make ack health code easies to read. Compared to previous
code, we do not print debug messages when expected_ack_cnt_delta == 0
and also do check against negative deltas.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
No functional change, make recover from statistics code
easies to read.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Patch fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=654599
Many users report very low speed problem on 3945 devices,
this patch fixes problem, but only for some of them.
For unknown reason, sometimes after hw scanning, device is not able
to receive frames at high rate. Since plcp health check may request
hw scan to "reset radio", performance problem start to be observable
after update kernel to .35, where plcp check was introduced.
Bug reporter confirmed that removing plcp check fixed problem for him.
Reported-and-tested-by: SilvioTO <[email protected]>
Cc: [email protected] # 2.6.35+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
After commit 59eb21a650
"cfg80211: Extend channel to frequency mapping for 802.11j"
we use uninitialized sband->band when assign channel frequencies, what
results that 5GHz channels have erroneous (zero) center_freq value.
Patch fixes problem and simplifies code a bit.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We use priv->cfg->bt_params && priv->cfg->bt_params->bt_statistics
conditional in few places, merge it into one function.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We never set STATUS_SCANNING in softwre scanning mode, disable_hw_scan
check is unneeded. Correct debug message while at it.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We use priv->cfg->bt_params && priv->cfg->bt_params->advanced_bt_coexist
conditional in few places, merge it into one function.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
struct iwl_queue is not part of firmware interface, so __packed is not
needed. Remove it since is may affect performance.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Similar change as we already do for agn, need to avoid
"Error setting Tx power (-5)" message when loading module.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Mac80211 can request for tx power and channel change in one ->config
call. If that happens, *_send_tx_power functions will try to setup tx
power for old channel, what can be not correct because we already change
the band. I.e error "Failed to get channel info for channel 140 [0]",
can be printed frequently when operating in software scanning mode.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We do not kill any scheduled tasklets when stopping device, that may
cause usage of resources after free. Disable interrupts, kill tasklets
and then works in correct order.
Cc: [email protected]
Tested-by: Sujith <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We do not kill any scheduled tasklets when stopping device, that may
cause usage of resources after free. Moreover we enable interrupts
in tasklet function, so we could potentially end with interrupts
enabled when driver is not ready to receive them.
I think patch should fix Ben's kernel crash from:
http://marc.info/?l=linux-wireless&m=129438358921501&w=2
Cc: [email protected]
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
pcmcia_request_irq() and pcmcia_enable_device() are intended
to be called from process context (first function allocate memory
with GFP_KERNEL, second take a mutex). We can not take spin lock
and call them.
It's safe to move spin lock after pcmcia_enable_device() as we
still hold off IRQ until dev->base_addr is 0 and driver will
not proceed with interrupts when is not ready.
Patch resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=643758
Reported-and-tested-by: [email protected]
Cc: [email protected] # 2.6.34+
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Looks that we do not set correctly antennas when scanning
on 5Ghz band and when bluetooth is enabled, because
priv->cfg->scan_tx_antennas[band] is only defined for
IEEE80211_BAND_2GHZ.
To fix we check band before limiting antennas to first one.
This allow to remove hard coded cfg->scan_tx_antennas[band].
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since commit 6cd0b1cb87 "iwlagn: fix
hw-rfkill while the interface is down", we enable interrupts when
device is not ready to receive them. However hardware, when it is in
some inconsistent state, can generate other than rfkill interrupts
and crash the system. I can reproduce crash with "kernel BUG at
drivers/net/wireless/iwlwifi/iwl-agn.c:1010!" message, when forcing
firmware restarts.
To fix only enable rfkill interrupt when down device and after probe.
I checked patch on laptop with 5100 device, rfkill change is still
passed to user space when device is down.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Cc: [email protected]
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This patch replace monitor/recover timer by watchdog based on time
stamp. New code allow to discover hangs more precisely.
Timeout values are currently doubled monitoring period values of
previous timer. This have to be tuned based of firmware timing
capabilities.
Tested on 3945, 4965, 5300, 6300.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Similarly like on iwlagn, initialize reset duration on iwl3945 to prevent
too frequent firmware resets.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Commit dbbf1755b0 "iwlwifi: use
antenna information in EEPROM" caused 4965 device breakage with
"Microcode SW error detected. Restarting 0x82000000." message.
This patch reverts 4965 part of that commit.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Johannes Berg <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Subtract of jiffies is fine even if one variable overwrap.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We can simplify length calculation in iwlagn_tx_skb, that function
is enough complex, without fuzz it more than necessary.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Currently we are canceling scan when changing BSSID. Behave the same
when changing association and beacon enablement, to avoid committing
rxon during scan in iwl_set_no_assoc().
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Do not set power mode when scanning, and defer that when scan finish.
We still set power mode in force case i.e. when device is overheated.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Avoid sending commands to firmware (including commit_rxon) when scan
is pending and we are calling iwlagn_bt_traffic_change_work simultaneously.
Also comment some innocent race conditions.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Almost anywhere in the code we avoid committing rxon while performing
scan, and make rxon commit when scan complete. However in some places
in the code we do not follow that rule. This patch fix that problem in
iwlagn_configure_filter().
Since we do not commit directly in iwl3945_configure_filter, we can
also do the same for agn, so I just remove iwlcore_commit_rxon()
function and add a comment. Also change comment for iwl3945.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
According to comment in iwl_bg_scan_completed, setting tx power should
be deferred during pending scan, but we are not doing this.
This patch change code to really defer setting tx power after scan
complete. Additionally refactor iwl_set_tx_power code and call
lib->send_tx_power() directly from iwlagn_commit_rxon.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
On 5xxx and 6xxx change to send tx_power_cmd command synchronously,
to do not start other commands when setting tx power is pending.
We currently do the same for 4956 and 3945.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Add WARN_ONCE when scanning is pending. Use STATUS_SCAN_HW bit since we
can have scan canceled or completed but STATUS_SCANNING bit still set.
v1 -> v2: replace EIO to EAGAIN
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
If dma mapping fail we are dropping packages or fail to open device.
But exact reason of drop/fail stays unknow for a user, so print errors.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Since we do not change rx buffer size any longer, we can
clean up rtl8169_change_mtu and in consequence rtl8169_down.
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Stanislaw Gruszka