<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/net/wireless, branch v2.6.34.3</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>iwlwifi: fix scan abort</title>
<updated>2010-08-10T17:54:12+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2010-07-29T09:37:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9c9dc3c4df0c3cd899f2871dc4f5cea0b386f5fe'/>
<id>9c9dc3c4df0c3cd899f2871dc4f5cea0b386f5fe</id>
<content type='text'>
commit d28232b461b8d54b09e59325dbac8b0913ce2049 upstream.

Fix possible double priv-&gt;mutex lock introduced by commit
a69b03e941abae00380fc6bc1877fb797a1b31e6
"iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
We can not call cancel_delayed_work_sync(&amp;priv-&gt;scan_check) with
priv-&gt;mutex locked because workqueue function iwl_bg_scan_check()
take that lock internally.

We do not need to synchronize when canceling priv-&gt;scan_check work.
We can avoid races (sending double abort command or send no
command at all) using STATUS_SCAN_ABORT bit. Moreover
current iwl_bg_scan_check() code seems to be broken, as
we should not send abort commands when currently aborting.

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d28232b461b8d54b09e59325dbac8b0913ce2049 upstream.

Fix possible double priv-&gt;mutex lock introduced by commit
a69b03e941abae00380fc6bc1877fb797a1b31e6
"iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
We can not call cancel_delayed_work_sync(&amp;priv-&gt;scan_check) with
priv-&gt;mutex locked because workqueue function iwl_bg_scan_check()
take that lock internally.

We do not need to synchronize when canceling priv-&gt;scan_check work.
We can avoid races (sending double abort command or send no
command at all) using STATUS_SCAN_ABORT bit. Moreover
current iwl_bg_scan_check() code seems to be broken, as
we should not send abort commands when currently aborting.

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix yet another buffer leak in the tx aggregation code</title>
<updated>2010-08-10T17:54:11+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2010-07-23T01:53:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2fb49ae6528c294776d8b6a90401c9567d5a670a'/>
<id>2fb49ae6528c294776d8b6a90401c9567d5a670a</id>
<content type='text'>
commit 4cee78614cfa046a26c4fbf313d5bbacb3ad8efc upstream.

When an aggregation session is being cleaned up, while the tx status
for some frames is being processed, the TID is flushed and its buffers
are sent out.

Unfortunately that left the pending un-acked frames unprocessed, thus
leaking buffers. Fix this by reordering the code so that those frames
are processed first, before the TID is flushed.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4cee78614cfa046a26c4fbf313d5bbacb3ad8efc upstream.

When an aggregation session is being cleaned up, while the tx status
for some frames is being processed, the TID is flushed and its buffers
are sent out.

Unfortunately that left the pending un-acked frames unprocessed, thus
leaking buffers. Fix this by reordering the code so that those frames
are processed first, before the TID is flushed.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix TSF after reset on AR913x</title>
<updated>2010-08-10T17:54:10+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2010-06-30T00:07:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a1972d6d42c0c1763c0b95093fae805636125b47'/>
<id>a1972d6d42c0c1763c0b95093fae805636125b47</id>
<content type='text'>
commit f860d526eb2939a1c37128900b5af2b6f3ff7f20 upstream.

When issuing a reset, the TSF value is lost in the hardware because of
the 913x specific cold reset. As with some AR9280 cards, the TSF needs
to be preserved in software here.

Additionally, there's an issue that frequently prevents a successful
TSF write directly after the chip reset. In this case, repeating the
TSF write after the initval-writes usually works.

This patch detects failed TSF writes and recovers from them, taking
into account the delay caused by the initval writes.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Reported-by: Björn Smedman &lt;bjorn.smedman@venatech.se&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f860d526eb2939a1c37128900b5af2b6f3ff7f20 upstream.

When issuing a reset, the TSF value is lost in the hardware because of
the 913x specific cold reset. As with some AR9280 cards, the TSF needs
to be preserved in software here.

Additionally, there's an issue that frequently prevents a successful
TSF write directly after the chip reset. In this case, repeating the
TSF write after the initval-writes usually works.

This patch detects failed TSF writes and recovers from them, taking
into account the delay caused by the initval writes.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Reported-by: Björn Smedman &lt;bjorn.smedman@venatech.se&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k_hw: fix an off-by-one error in the PDADC boundaries calculation</title>
<updated>2010-08-10T17:54:10+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2010-07-11T10:48:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8e0e0465a8bb89e31cc5c3b8e68b65639ba84221'/>
<id>8e0e0465a8bb89e31cc5c3b8e68b65639ba84221</id>
<content type='text'>
commit 03b4776c408d2f4bf3a5d204e223724d154716d1 upstream.

PDADC values were only generated for values surrounding the target
index, however not for the target index itself, leading to a minor
error in the generated curve.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 03b4776c408d2f4bf3a5d204e223724d154716d1 upstream.

PDADC values were only generated for values surrounding the target
index, however not for the target index itself, leading to a minor
error in the generated curve.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix a potential buffer leak in the STA teardown path</title>
<updated>2010-08-10T17:54:10+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2010-07-07T17:42:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dd6f960af291ac95a788afa13a4b919f0b8151b9'/>
<id>dd6f960af291ac95a788afa13a4b919f0b8151b9</id>
<content type='text'>
commit 2b40994cabd2f545d5c11d3a65dcee6f6f9155f8 upstream.

It looks like it might be possible for a TID to be paused, while still
holding some queued buffers, however ath_tx_node_cleanup currently only
iterates over active TIDs.
Fix this by always checking every allocated TID for the STA that is being
cleaned up.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2b40994cabd2f545d5c11d3a65dcee6f6f9155f8 upstream.

It looks like it might be possible for a TID to be paused, while still
holding some queued buffers, however ath_tx_node_cleanup currently only
iterates over active TIDs.
Fix this by always checking every allocated TID for the STA that is being
cleaned up.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: enable serialize_regmode for non-PCIE AR9160</title>
<updated>2010-08-10T17:54:09+00:00</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2010-07-28T14:06:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b8122172766f1aa2d1c3d2db951a66b91f2ec8c5'/>
<id>b8122172766f1aa2d1c3d2db951a66b91f2ec8c5</id>
<content type='text'>
commit 4c85ab11ca56da1aa59b58c80cc6a356515cc645 upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=16476

Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Acked-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4c85ab11ca56da1aa59b58c80cc6a356515cc645 upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=16476

Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Acked-by: Luis R. Rodriguez &lt;lrodriguez@atheros.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath5k: initialize ah-&gt;ah_current_channel</title>
<updated>2010-08-02T17:30:23+00:00</updated>
<author>
<name>Bob Copeland</name>
<email>me@bobcopeland.com</email>
</author>
<published>2010-06-18T17:15:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3bc3620722100d2c49a64fca8d33dc0615caf499'/>
<id>3bc3620722100d2c49a64fca8d33dc0615caf499</id>
<content type='text'>
commit b6855772f4a22c4fbdd4fcaceff5c8a527035123 upstream.

ath5k assumes ah_current_channel is always a valid pointer in
several places, but a newly created interface may not have a
channel.  To avoid null pointer dereferences, set it up to point
to the first available channel until later reconfigured.

This fixes the following oops:
$ rmmod ath5k
$ insmod ath5k
$ iw phy0 set distance 11000

BUG: unable to handle kernel NULL pointer dereference at 00000006
IP: [&lt;d0a1ff24&gt;] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90
scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci
8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc

Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
EIP: 0060:[&lt;d0a1ff24&gt;] EFLAGS: 00010296 CPU: 0
EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
Stack:
  d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
&lt;0&gt; cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
&lt;0&gt; 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
Call Trace:
  [&lt;d0a27f0c&gt;] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
  [&lt;d09bfdc7&gt;] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
  [&lt;d08e0d28&gt;] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
  [&lt;c10f5db9&gt;] ? nla_parse+0x59/0xc0
  [&lt;c11ca8d9&gt;] ? genl_rcv_msg+0x169/0x1a0
  [&lt;c11ca770&gt;] ? genl_rcv_msg+0x0/0x1a0
  [&lt;c11c7e68&gt;] ? netlink_rcv_skb+0x38/0x90
  [&lt;c11c9649&gt;] ? genl_rcv+0x19/0x30
  [&lt;c11c7c03&gt;] ? netlink_unicast+0x1b3/0x220
  [&lt;c11c893e&gt;] ? netlink_sendmsg+0x26e/0x290
  [&lt;c11a409e&gt;] ? sock_sendmsg+0xbe/0xf0
  [&lt;c1032780&gt;] ? autoremove_wake_function+0x0/0x50
  [&lt;c104d846&gt;] ? __alloc_pages_nodemask+0x106/0x530
  [&lt;c1074933&gt;] ? do_lookup+0x53/0x1b0
  [&lt;c10766f9&gt;] ? __link_path_walk+0x9b9/0x9e0
  [&lt;c11acab0&gt;] ? verify_iovec+0x50/0x90
  [&lt;c11a42b1&gt;] ? sys_sendmsg+0x1e1/0x270
  [&lt;c1048e50&gt;] ? find_get_page+0x10/0x50
  [&lt;c104a96f&gt;] ? filemap_fault+0x5f/0x370
  [&lt;c1059159&gt;] ? __do_fault+0x319/0x370
  [&lt;c11a55b4&gt;] ? sys_socketcall+0x244/0x290
  [&lt;c101962c&gt;] ? do_page_fault+0x1ec/0x270
  [&lt;c1019440&gt;] ? do_page_fault+0x0/0x270
  [&lt;c1002ae5&gt;] ? syscall_call+0x7/0xb
Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24
0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 &lt;0f&gt; b7
43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
EIP: [&lt;d0a1ff24&gt;] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP
0068:cfa09bf4
CR2: 0000000000000006
---[ end trace 54f73d6b10ceb87b ]---

Reported-by: Steve Brown &lt;sbrown@cortland.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b6855772f4a22c4fbdd4fcaceff5c8a527035123 upstream.

ath5k assumes ah_current_channel is always a valid pointer in
several places, but a newly created interface may not have a
channel.  To avoid null pointer dereferences, set it up to point
to the first available channel until later reconfigured.

This fixes the following oops:
$ rmmod ath5k
$ insmod ath5k
$ iw phy0 set distance 11000

BUG: unable to handle kernel NULL pointer dereference at 00000006
IP: [&lt;d0a1ff24&gt;] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90
scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci
8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc

Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
EIP: 0060:[&lt;d0a1ff24&gt;] EFLAGS: 00010296 CPU: 0
EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
Stack:
  d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
&lt;0&gt; cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
&lt;0&gt; 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
Call Trace:
  [&lt;d0a27f0c&gt;] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
  [&lt;d09bfdc7&gt;] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
  [&lt;d08e0d28&gt;] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
  [&lt;c10f5db9&gt;] ? nla_parse+0x59/0xc0
  [&lt;c11ca8d9&gt;] ? genl_rcv_msg+0x169/0x1a0
  [&lt;c11ca770&gt;] ? genl_rcv_msg+0x0/0x1a0
  [&lt;c11c7e68&gt;] ? netlink_rcv_skb+0x38/0x90
  [&lt;c11c9649&gt;] ? genl_rcv+0x19/0x30
  [&lt;c11c7c03&gt;] ? netlink_unicast+0x1b3/0x220
  [&lt;c11c893e&gt;] ? netlink_sendmsg+0x26e/0x290
  [&lt;c11a409e&gt;] ? sock_sendmsg+0xbe/0xf0
  [&lt;c1032780&gt;] ? autoremove_wake_function+0x0/0x50
  [&lt;c104d846&gt;] ? __alloc_pages_nodemask+0x106/0x530
  [&lt;c1074933&gt;] ? do_lookup+0x53/0x1b0
  [&lt;c10766f9&gt;] ? __link_path_walk+0x9b9/0x9e0
  [&lt;c11acab0&gt;] ? verify_iovec+0x50/0x90
  [&lt;c11a42b1&gt;] ? sys_sendmsg+0x1e1/0x270
  [&lt;c1048e50&gt;] ? find_get_page+0x10/0x50
  [&lt;c104a96f&gt;] ? filemap_fault+0x5f/0x370
  [&lt;c1059159&gt;] ? __do_fault+0x319/0x370
  [&lt;c11a55b4&gt;] ? sys_socketcall+0x244/0x290
  [&lt;c101962c&gt;] ? do_page_fault+0x1ec/0x270
  [&lt;c1019440&gt;] ? do_page_fault+0x0/0x270
  [&lt;c1002ae5&gt;] ? syscall_call+0x7/0xb
Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24
0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 &lt;0f&gt; b7
43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
EIP: [&lt;d0a1ff24&gt;] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP
0068:cfa09bf4
CR2: 0000000000000006
---[ end trace 54f73d6b10ceb87b ]---

Reported-by: Steve Brown &lt;sbrown@cortland.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwl3945: enable stuck queue detection on 3945</title>
<updated>2010-08-02T17:30:19+00:00</updated>
<author>
<name>Reinette Chatre</name>
<email>reinette.chatre@intel.com</email>
</author>
<published>2010-05-20T17:54:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4c4504ea2dccb7901189f6a48c3d3c0ed20d3475'/>
<id>4c4504ea2dccb7901189f6a48c3d3c0ed20d3475</id>
<content type='text'>
commit a6866ac93e6cb68091326e80b4fa4619a5957644 upstream.

We learn from
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
https://bugzilla.redhat.com/show_bug.cgi?id=589777
that 3945 can also suffer from a stuck command queue. Enable stuck queue
detection for iwl3945 to enable recovery in this case.

Signed-off-by: Reinette Chatre &lt;reinette.chatre@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a6866ac93e6cb68091326e80b4fa4619a5957644 upstream.

We learn from
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
https://bugzilla.redhat.com/show_bug.cgi?id=589777
that 3945 can also suffer from a stuck command queue. Enable stuck queue
detection for iwl3945 to enable recovery in this case.

Signed-off-by: Reinette Chatre &lt;reinette.chatre@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: Recover TX flow stall due to stuck queue</title>
<updated>2010-08-02T17:30:19+00:00</updated>
<author>
<name>Wey-Yi Guy</name>
<email>wey-yi.w.guy@intel.com</email>
</author>
<published>2010-03-02T01:23:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ac751d718ee83f055c9ef48413d11afdea6859a6'/>
<id>ac751d718ee83f055c9ef48413d11afdea6859a6</id>
<content type='text'>
commit b74e31a9bc1013e69b85b139072485dc153453dd upstream.

Monitors the internal TX queues periodically.  When a queue is stuck
for some unknown conditions causing the throughput to drop and the
transfer is stop, the driver will force firmware reload and bring the
system back to normal operational state.

The iwlwifi devices behave differently in this regard so this feature is
made part of the ops infrastructure so we can have more control on how to
monitor and recover from tx queue stall case per device.

Signed-off-by: Trieu 'Andrew' Nguyen &lt;trieux.t.nguyen@intel.com&gt;
Signed-off-by: Wey-Yi Guy &lt;wey-yi.w.guy@intel.com&gt;
Signed-off-by: Reinette Chatre &lt;reinette.chatre@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b74e31a9bc1013e69b85b139072485dc153453dd upstream.

Monitors the internal TX queues periodically.  When a queue is stuck
for some unknown conditions causing the throughput to drop and the
transfer is stop, the driver will force firmware reload and bring the
system back to normal operational state.

The iwlwifi devices behave differently in this regard so this feature is
made part of the ops infrastructure so we can have more control on how to
monitor and recover from tx queue stall case per device.

Signed-off-by: Trieu 'Andrew' Nguyen &lt;trieux.t.nguyen@intel.com&gt;
Signed-off-by: Wey-Yi Guy &lt;wey-yi.w.guy@intel.com&gt;
Signed-off-by: Reinette Chatre &lt;reinette.chatre@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlagn: verify flow id in compressed BA packet</title>
<updated>2010-08-02T17:30:18+00:00</updated>
<author>
<name>Shanyu Zhao</name>
<email>shanyu.zhao@intel.com</email>
</author>
<published>2010-06-02T00:13:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8483d9b94a15bae1dd9bcd03ef84726ec6a03536'/>
<id>8483d9b94a15bae1dd9bcd03ef84726ec6a03536</id>
<content type='text'>
commit b561e8274f75831ee87e4ea378cbb1f9f050a51a upstream.

The flow id (scd_flow) in a compressed BA packet should match the txq_id
of the queue from which the aggregated packets were sent. However, in
some hardware like the 1000 series, sometimes the flow id is 0 for the
txq_id (10 to 19). This can cause the annoying message:
[ 2213.306191] iwlagn 0000:01:00.0: Received BA when not expected
[ 2213.310178] iwlagn 0000:01:00.0: Read index for DMA queue txq id (0),
index 5, is out of range [0-256] 7 7.

And even worse, if agg-&gt;wait_for_ba is true when the bad BA is arriving,
this can cause system hang due to NULL pointer dereference because the
code is operating in a wrong tx queue!

Signed-off-by: Shanyu Zhao &lt;shanyu.zhao@intel.com&gt;
Signed-off-by: Pradeep Kulkarni &lt;pradeepx.kulkarni@intel.com&gt;
Signed-off-by: Reinette Chatre &lt;reinette.chatre@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b561e8274f75831ee87e4ea378cbb1f9f050a51a upstream.

The flow id (scd_flow) in a compressed BA packet should match the txq_id
of the queue from which the aggregated packets were sent. However, in
some hardware like the 1000 series, sometimes the flow id is 0 for the
txq_id (10 to 19). This can cause the annoying message:
[ 2213.306191] iwlagn 0000:01:00.0: Received BA when not expected
[ 2213.310178] iwlagn 0000:01:00.0: Read index for DMA queue txq id (0),
index 5, is out of range [0-256] 7 7.

And even worse, if agg-&gt;wait_for_ba is true when the bad BA is arriving,
this can cause system hang due to NULL pointer dereference because the
code is operating in a wrong tx queue!

Signed-off-by: Shanyu Zhao &lt;shanyu.zhao@intel.com&gt;
Signed-off-by: Pradeep Kulkarni &lt;pradeepx.kulkarni@intel.com&gt;
Signed-off-by: Reinette Chatre &lt;reinette.chatre@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
