commit e609e2ea2c upstream.
Completing aggregate frames can lead to new buffers being pushed into
the tid queues due to software retransmission.
When the tx queues are being drained, all pending aggregates must be
completed before the tid queues get drained, otherwise buffers might be
leaked.
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 4fc4fbd1d9 upstream.
The index variable to access the rate flags should be obtained from the
inner loop counter which corresponds to the rate table structure.This
fixes the invalid rate selection i.e when the supported basic rate is
invalid on a particular band and also the following warning message.
Thanks to Raj for finding this out.
Call Trace:
[<ffffffff8104ee4a>] warn_slowpath_common+0x7a/0xb0
[<ffffffff8104ee95>] warn_slowpath_null+0x15/0x20
[<ffffffffa0583c45>] ath_get_rate+0x595/0x5b0 [ath9k]
[<ffffffff811a0636>] ? cpumask_next_and+0x36/0x50
[<ffffffffa0405186>] rate_control_get_rate+0x86/0x160 [mac80211]
[<ffffffffa040dfac>] invoke_tx_handlers+0x81c/0x12d0 [mac80211]
[<ffffffffa040eae9>] ieee80211_tx+0x89/0x2b0 [mac80211]
[<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0
[<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]
[<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0
[<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]
[<ffffffffa03f8896>] ieee80211_scan_work+0x146/0x600 [mac80211]
[<ffffffff8133a375>] ? schedule+0x2f5/0x8e0
[<ffffffffa03f8750>] ? ieee80211_scan_work+0x0/0x600 [mac80211]
[<ffffffff81064fcf>] process_one_work+0x10f/0x380
[<ffffffff81066bc2>] worker_thread+0x162/0x340
[<ffffffff81066a60>] ? worker_thread+0x0/0x340
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit d654567dec upstream.
Netgear WNDA3200 device uses ar7010 firmware but it is failed to set
correct firmware offset on firmware download which causes device initialization
failure.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 0dfa6dbb73 upstream.
This updates the initvals for the AR9003 2.2 chipsets. The initvals
are the initial register values we use for our registers upon hardware
reset. This synchs up the initvals to match what our latest recommendation
from our systems engineering team.
The description of changes in this update:
Improves ability to support very strong Rx conditions.
Enhances DFS support for AP-mode.
Improves performance of Tx carrier leak calibration.
Adds support for Japan channel 14 Tx filtering requirements.
Improves Tx power accuracy.
Impact:
Update required to address degraded throughput at very short range.
Update required for AP-mode DFS certification.
Update required to comply to IEEE Tx carrier leak specification.
May not meet expected +/- 2 dB Tx power accuracy without update.
The most important fix here would be the TX carrier leakage required
to comply with IEEE 802.11 specifications. The group of changes have
been tested all together in one release.
References:
Osprey 2.2 header file ver #33
Checksums:
$ ./initvals -f ar9003-2p2
0x000000004a488fc7 ar9300_2p2_radio_postamble
0x0000000046cb1300 ar9300Modes_lowest_ob_db_tx_gain_table_2p2
0x00000000e912711f ar9300Modes_fast_clock_2p2
0x0000000037ac0ee8 ar9300_2p2_radio_core
0x00000000047a7700 ar9300Common_rx_gain_table_merlin_2p2
0x0000000003f783bb ar9300_2p2_mac_postamble
0x00000000301fc841 ar9300_2p2_soc_postamble
0x000000005ec8075f ar9200_merlin_2p2_radio_core
0x0000000083372ffa ar9300_2p2_baseband_postamble
0x00000000c4f59974 ar9300_2p2_baseband_core
0x00000000e20d2e72 ar9300Modes_high_power_tx_gain_table_2p2
0x000000007fd55c70 ar9300Modes_high_ob_db_tx_gain_table_2p2
0x0000000029495000 ar9300Common_rx_gain_table_2p2
0x0000000042cb1300 ar9300Modes_low_ob_db_tx_gain_table_2p2
0x00000000c4739cd6 ar9300_2p2_mac_core
0x000000003521a300 ar9300Common_wo_xlna_rx_gain_table_2p2
0x00000000a15ccf1b ar9300_2p2_soc_preamble
0x0000000029734396 ar9300PciePhy_pll_on_clkreq_disable_L1_2p2
0x000000002d834396 ar9300PciePhy_clkreq_enable_L1_2p2
0x0000000029834396 ar9300PciePhy_clkreq_disable_L1_2p2
$ ./initvals -f ar9003-2p2 | sha1sum
0ceddb5cf66737610fb51f04cf3e9ff71870c7b4 -
Cc: Yixiang Li <yixiang.li@atheros.com>
Cc: Don Breslin <don.breslin@atheros.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 2d3fca1807 upstream.
We are not handling all divide by zero cases in paprd.
Add additional checks for divide by zero cases in papard.
This patch has fixes intended for kernel 2.6.36.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit fac6b6a065 upstream.
Since aggregation is usually triggered by tx completion, a hardware
reset (because of beacon stuck, tx hang or baseband hang) can
significantly delay the transmission of the next AMPDU (until the next
tx completion event).
Fix this by rescheduling aggregation after such a 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 56363ddeee upstream.
According to the hardware documentation, the MIC failure bit is only
valid if the frame was decrypted using a valid TKIP key and is not a
fragment.
In some setups I've seen hardware-reported MIC failures on an AP that
was configured for CCMP only, so it's clear that additional checks are
necessary.
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 52b8ac9249 upstream.
When we return to the home channel we were never reseting our beacon
timers, this was casued by the fact that the scanning flag was still
on even after we returned to our home channel. There are also other
reasons why we would get a reset and if we are not off channel
we always need to resynch our beacon timers, because a reset will
clear them.
This bug is a regression introduced on 2.6.36. The order of the
changes are as follows:
5ee08656 - Sat Jul 31 - ath9k: prevent calibration during off-channel activity
a0daa0e7 - Tue Jul 27 - Revert "mac80211: fix sw scan bracketing"
543708be - Fri Jun 18 - mac80211: fix sw scan bracketing
mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
--contains 5ee0865615
v2.6.36-rc1~43^2~34^2~22
mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
--contains a0daa0e759
v2.6.36-rc1~571^2~64^2~13
mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
--contains 543708be32
v2.6.36-rc1~571^2~107^2~187
So 5ee08656 would have worked if a0daa0e7 was not committed but
it was so this means 5ee08656 was broken since it assumed that
when we were in the channel change routine the scan flag would
be lifted. As it turns out the scan flag will be set when we
are already on the home channel.
For more details refer to:
http://code.google.com/p/chromium-os/issues/detail?id=5715
These issues will need to be considered for our solution on
reshifting the scan complete callback location on mac80211 on
current development kernel work.
This patch has stable fixes which apply down to [2.6.36+]
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.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 008443def3 upstream.
The patch titled "ath9k: Add new file init.c" shuffled some code
around but in dong so for some reason also removed the revision
check for disablign power save. Add this revision check again
so we can get power save re-enabled again by default on cards
newer than AR5416 and AR5418.
$ git describe --contains 556242049c
v2.6.34-rc1~233^2~49^2~343
This patch has fixes for stable kernels [2.6.34+].
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.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 3ae74c33c4 upstream.
If AR_KeyMiss is set in the rx descriptor and AR_RxFrameOK is unset,
the hardware could not locate a valid key during a decryption attempt.
In this case, the frame must not be reported as decrypted, otherwise
mac80211 sees only random garbage.
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 3fac6dfdcd upstream.
The patch:
commit 293dc5dfdb
Author: Gabor Juhos <juhosg@openwrt.org>
Date: Fri Jun 19 12:17:48 2009 +0200
ath9k: remove ath_rx_ps_back_to_sleep helper
This helper only clears the SC_OP_WAIT_FOR_{BEACON,CAB} flags.
Remove it and clear these flags directly in the approptiate
places instead.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
introduced a regression which forgot to lift the beacon flag
after we received all broadcast and multicast data. This meant
we never went to sleep consuming about ~650mW on idle. This pretty
much broke power save completely.
This patch has fixes for stable kernels [2.6.32+].
Cc: Paul Stewart <pstew@google.com>
Cc: Sameer Nanda <snanda@google.com>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.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 231c3a1f06 upstream.
A new aggregation session start can be issued by mac80211, even when the
cleanup of the previous session has not completed yet. Since the data structure
for the session is not recreated, this could corrupt the block ack window
and lock up the aggregation session. Fix this by delaying the new session
until the old one has been cleaned up.
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 8ab2cd09fe upstream.
ath9k has a race on putting the chip into network sleep and
having registers read from hardware. The race occurs because
although ath9k_ps_restore() locks its own callers it makes use
of some variables which get altered in the driver at different
code paths. The variables are the ps_enabled and ps_flags.
This is easily reprodicible in large network environments when
roaming with the wpa_supplicant simple bgscan. You'd get some
0xdeadbeef read out on certain registers such as:
ath: timeout (100000 us) on reg 0x806c: 0xdeadbeef & 0x01f00000 != 0x00000000
ath: RX failed to go idle in 10 ms RXSM=0xdeadbeef
ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef & 0x00000003 != 0x00000000
ath: Chip reset failed
The fix is to protect the ath9k_config(hw, IEEE80211_CONF_CHANGE_PS)
calls with a spin_lock_irqsave() which will disable contendors for
these variables from interrupt context, timers, re-entry from mac80211
on the same callback, and most importantly from ath9k_ps_restore()
which is the only call which will put the device into network sleep.
There are quite a few threads and bug reports on these a few of them are:
https://bugs.launchpad.net/ubuntu/karmic/+source/linux/+bug/407040http://code.google.com/p/chromium-os/issues/detail?id=5709http://code.google.com/p/chromium-os/issues/detail?id=5943
Stable fixes apply to [2.6.32+]
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.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 90fa539ca3 upstream.
The tid aggregation cleanup is a bit fragile, as it discards failed
subframes in some places, and retransmits them in others. This could
block the cleanup of an existing aggregation session, if a retransmission
for a tid is issued, yet the tid is never scheduled again because of
the cleanup state.
Fix this by getting rid of as many subframes as possible, as early
as possible, and immediately transmitting pending subframes as regular
HT frames instead of waiting for the cleanup to complete.
Drop all pending subframes while keeping track of the Block ACK window
during aggregate tx completion to prevent sending out stale subframes,
which could confuse the receiver side.
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 9094537c3a upstream.
Paprd needs to be done only on active chains(not for all the chains
that hw can support). The paprd training frames which are sent
for inactive chains would be hanging on the hw queue without
getting transmitted and would make the connection so unstable.
This issue happens only with the hw which supports paprd cal(ar9003).
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit ebd022873a upstream.
This patch fixes the following problems with the rate control feedback
generated by ath9k for A-MPDU frames:
1. Rate control feedback is carried on the first frame of an aggregate
that is either ACKed, or has execeeded the software retry count and is
considered failed. However, ath9k would incorrectly assume the aggregate
had the length 1 if one of these conditions did not apply to the first
frame of the aggregate, but instead a later frame. This fix therefor
copies the bf_nframes field of the buffer in the same manner as the rates
field of the tx status.
2. Sometimes the ampdu_len and ampdu_ack_len fields of the tx status was
left uninitialized eventhough the IEEE80211_TX_STAT_AMPDU flag was set.
This is now avoid by setting flag and fields in the same place.
3. Even if a frame has been selected for aggregation by mac80211 and
marked with the IEEE80211_TX_CTL_AMPDU flag it can sometimes happen that
ath9k transmits the frame without aggregation. In these cases the
ampdu_ack_len field could be incorrectly computed because the nbad
parameter to ath_tx_rc_status was incorrect.
Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se>
Acked-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 f209f52982 upstream.
Since the regulatory code touches the channel array, it needs to be
copied for each device instance. That way the original channel array
can also be made const.
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 a8909cfb18 upstream.
This patch attempts to ensure that ath9k's built-in rate control algorithm
does not rely on the value of the ampdu_len and ampdu_ack_len tx status
fields unless the IEEE80211_TX_STAT_AMPDU flag is set.
This patch has not been tested.
Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se>
Acked-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 354da65323 upstream.
macro tile heights are aligned to num channels, not num banks.
Noticed by Dave Airlie.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit e226930835 upstream.
This code has been broken forever, but in several different and
creative ways.
So far as I can work out, the R6040 MAC filter has 4 exact-match
entries, the first of which the driver uses for its assigned unicast
address, plus a 64-entry hash-based filter for multicast addresses
(maybe unicast as well?).
The original version of this code would write the first 4 multicast
addresses as exact-match entries from offset 1 (bug #1: there is no
entry 4 so this could write to some PHY registers). It would fill the
remainder of the exact-match entries with the broadcast address (bug #2:
this would overwrite the last used entry). If more than 4 multicast
addresses were configured, it would set up the hash table, write some
random crap to the MAC control register (bug #3) and finally walk off
the end of the list when filling the exact-match entries (bug #4).
All of this seems to be pointless, since it sets the promiscuous bit
when the interface is made promiscuous or if >4 multicast addresses
are enabled, and never clears it (bug #5, masking bug #2).
The recent(ish) changes to the multicast list fixed bug #4, but
completely removed the limit on iteration over the exact-match entries
(bug #6).
Bug #4 was reported as
<https://bugzilla.kernel.org/show_bug.cgi?id=15355> and more recently
as <http://bugs.debian.org/600155>. Florian Fainelli attempted to fix
these in commit 3bcf8229a8, but that
actually dealt with bugs #1-3, bug #4 having been fixed in mainline at
that point.
That commit fixes the most important current bug #6.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 37f9fc452d upstream.
While parsing the GetValuebyClass command frame, we could potentially write
passed the skb->data pointer.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9284bcf4e3 upstream.
Ensure that we pass down properly validated iov segments before
calling into the mapping or copy functions.
Reported-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 01ea50638b upstream.
When a new disk is being discovered, add_disk() first ties the bdev to gendisk
(via register_disk()->blkdev_get()) and only after that calls
bdi_register_bdev(). Because register_disk() also creates disk's kobject, it
can happen that userspace manages to open and modify the device's data (or
inode) before its BDI is properly initialized leading to a warning in
__mark_inode_dirty().
Fix the problem by registering BDI early enough.
This patch addresses https://bugzilla.kernel.org/show_bug.cgi?id=16312
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 892b6f90db upstream.
Physical block size was declared unsigned int to accomodate the maximum
size reported by READ CAPACITY(16). Make sure we use the right type in
the related functions.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 09358972bf upstream.
Under some workloads, some channel messages have been observed being
delayed on the sending side past the point where the receiving side has
been able to tear down its partition structures.
This condition is already detected in xpc_handle_activate_IRQ_uv(), but
that information is not given to xpc_handle_activate_mq_msg_uv(). As a
result, xpc_handle_activate_mq_msg_uv() assumes the structures still exist
and references them, causing a NULL-pointer deref.
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It can't be merged into Linus' tree because this file has already been
changed in incompatible ways.
Fixup the missing second parameter to addruart macro to allow them to build,
according to to commit 0e17226f7c.
Enabling DEBUG in head.S would cause:
rch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:1037: Error: too many positional arguments
arch/arm/boot/compressed/head.S:1055: Error: too many positional arguments
Signed-off-by: Mac Lin <mkl0301@gmail.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 834b2964b7 upstream.
DBG_MAX_REG_NUM incorrectly had the number of indices in the GDB regs
array rather than the number of registers, leading to an oops when the
"rd" command is used in KDB.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 15714f7b58 upstream.
Commit 4a5a5c73 attempted to pass decent error messages back to userspace for
netfilter errors. In xt_SECMARK.c however the patch screwed up and returned
on 0 (aka no error) early and didn't finish setting up secmark. This results
in a kernel BUG if you use SECMARK.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 986fe6c7f5 upstream.
Deleting a SCSI device on a blocked fc_remote_port (before
fast_io_fail_tmo fires) results in a hanging thread:
STACK:
0 schedule+1108 [0x5cac48]
1 schedule_timeout+528 [0x5cb7fc]
2 wait_for_common+266 [0x5ca6be]
3 blk_execute_rq+160 [0x354054]
4 scsi_execute+324 [0x3b7ef4]
5 scsi_execute_req+162 [0x3b80ca]
6 sd_sync_cache+138 [0x3cf662]
7 sd_shutdown+138 [0x3cf91a]
8 sd_remove+112 [0x3cfe4c]
9 __device_release_driver+124 [0x3a08b8]
10 device_release_driver+60 [0x3a0a5c]
11 bus_remove_device+266 [0x39fa76]
12 device_del+340 [0x39d818]
13 __scsi_remove_device+204 [0x3bcc48]
14 scsi_remove_device+66 [0x3bcc8e]
15 sysfs_schedule_callback_work+50 [0x260d66]
16 worker_thread+622 [0x162326]
17 kthread+160 [0x1680b0]
18 kernel_thread_starter+6 [0x10aaea]
During the delete, the SCSI device is in moved to SDEV_CANCEL. When
the FC transport class later calls scsi_target_unblock, this has no
effect, since scsi_internal_device_unblock ignores SCSI devics in this
state.
It looks like all these are regressions caused by:
5c10e63c94
[SCSI] limit state transitions in scsi_internal_device_unblock
Fix by rejecting offline and cancel in the state transition.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
[jejb: Original patch by Christof Schmitt, modified by Mike Christie]
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 546ae796bf upstream.
Removing SCSI devices through
echo 1 > /sys/bus/scsi/devices/ ... /delete
while the FC transport class removes the SCSI target can lead to an
oops:
Unable to handle kernel pointer dereference at virtual kernel address 00000000b6815000
Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: sunrpc qeth_l3 binfmt_misc dm_multipath scsi_dh dm_mod ipv6 qeth ccwgroup [last unloaded: scsi_wait_scan]
CPU: 1 Not tainted 2.6.35.5-45.x.20100924-s390xdefault #1
Process fc_wq_0 (pid: 861, task: 00000000b7331240, ksp: 00000000b735bac0)
Krnl PSW : 0704200180000000 00000000003ff6e4 (__scsi_remove_device+0x24/0xd0)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000000 00000000b6815000 00000000bc24a8c0
00000000003ff7c8 000000000056dbb8 0000000000000002 0000000000835d80
ffffffff00000000 0000000000001000 00000000b6815000 00000000bc24a7f0
00000000b68151a0 00000000b6815000 00000000b735bc20 00000000b735bbf8
Krnl Code: 00000000003ff6d6: a7840001 brc 8,3ff6d8
00000000003ff6da: a7fbffd8 aghi %r15,-40
00000000003ff6de: e3e0f0980024 stg %r14,152(%r15)
>00000000003ff6e4: e31021200004 lg %r1,288(%r2)
00000000003ff6ea: a71f0000 cghi %r1,0
00000000003ff6ee: a7a40011 brc 10,3ff710
00000000003ff6f2: a7390003 lghi %r3,3
00000000003ff6f6: c0e5ffffc8b1 brasl %r14,3f8858
Call Trace:
([<0000000000001000>] 0x1000)
[<00000000003ff7d2>] scsi_remove_device+0x42/0x54
[<00000000003ff8ba>] __scsi_remove_target+0xca/0xfc
[<00000000003ff99a>] __remove_child+0x3a/0x48
[<00000000003e3246>] device_for_each_child+0x72/0xbc
[<00000000003ff93a>] scsi_remove_target+0x4e/0x74
[<0000000000406586>] fc_rport_final_delete+0xb2/0x23c
[<000000000015d080>] worker_thread+0x200/0x344
[<000000000016330c>] kthread+0xa0/0xa8
[<0000000000106c1a>] kernel_thread_starter+0x6/0xc
[<0000000000106c14>] kernel_thread_starter+0x0/0xc
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<00000000003ff7cc>] scsi_remove_device+0x3c/0x54
The function __scsi_remove_target iterates through the SCSI devices on
the host, but it drops the host_lock before calling
scsi_remove_device. When the SCSI device is deleted from another
thread, the pointer to the SCSI device in scsi_remove_device can
become invalid. Fix this by getting a reference to the SCSI device
before dropping the host_lock to keep the SCSI device alive for the
call to scsi_remove_device.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f63ae56e4e upstream.
gdth_ioctl_alloc() takes the size variable as an int.
copy_from_user() takes the size variable as an unsigned long.
gen.data_len and gen.sense_len are unsigned longs.
On x86_64 longs are 64 bit and ints are 32 bit.
We could pass in a very large number and the allocation would truncate
the size to 32 bits and allocate a small buffer. Then when we do the
copy_from_user(), it would result in a memory corruption.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit df30e50596 upstream.
sense_buffer is both a direct member of struct pmcraid_cmd as well as
an indirect one via an anonymous union and struct. Fix this clash by
eliminating the direct member in favour of the anonymous struct/union
one. The name duplication apparently isn't noticed by gcc versions
earlier than 4.4
Reported-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Anil Ravindranath <anil_ravindranath@pmc-sierra.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f0ad30d3d2 upstream.
Some cards (like mvsas) have issue troubles if non-NCQ commands are
mixed with NCQ ones. Fix this by using the libata default NCQ check
routine which waits until all NCQ commands are complete before issuing
a non-NCQ one. The impact to cards (like aic94xx) which don't need
this logic should be minimal
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 1a03ae0f55 upstream.
Following a site power outage which re-enabled all the ports on my FC
switches, my system subsequently booted with far too many luns! I had
let it run hoping it would make multi-user. It didn't. :( It hung solid
after exhausting the last sd device, sdzzz, and attempting to create sdaaaa
and beyond. I was unable to get a dump.
Discovered using a 2.6.32.13 based system.
correct this by detecting when the last index is utilized and failing
the sd probe of the device. Patch applies to scsi-misc-2.6.
Signed-off-by: Michael Reed <mdr@sgi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 23f45c3a76 upstream.
The GPS rfkill crappy code. The ops_data argument wasn't
set, and was totally misused. The fix have been tested
on an Asus R2H.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 56626a72a4 upstream.
A few devices (such as the RCA VR5220 voice recorder) are so
non-compliant with the USB spec that they have invalid maxpacket sizes
for endpoint 0. Nevertheless, as long as we can safely use them, we
may as well do so.
This patch (as1432) softens our acceptance criterion by allowing
high-speed devices to have ep0-maxpacket sizes other than 64. A
warning is printed in the system log when this happens, and the
existing error message is clarified.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: James <bjlockie@lockie.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 97cd8dc4ca upstream.
The bulk-read callback had two bugs:
a) The bulk-in packet's leading two zeros were returned (and the two last
bytes truncated)
b) The wrong URB was transmitted for the second (and later) read requests,
causing further reads to return the entire packet (including leading
zeros)
Signed-off-by: Alon Ziv <alon-git@nolaviz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit cfb8da8f69 upstream.
Fix regression introduced by commit
214916f2ec (USB: visor: reimplement using
generic framework) which broke initialisation of UX50/TH55 devices that
used re-mapped bulk-out endpoint addresses.
Reported-by: Robert Gadsdon <rgadsdon@bayarea.net>
Tested-by: Robert Gadsdon <rgadsdon@bayarea.net>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 80f0cf3947 upstream.
This patch (as1430) fixes a bug in usbcore. When a device
configuration change occurs or a device is removed, the endpoints for
the old config should be completely disabled. However it turns out
they aren't; this is because usb_unbind_interface() calls
usb_enable_interface() or usb_set_interface() to put interfaces back
in altsetting 0, which re-enables the interfaces' endpoints.
As a result, when a device goes through a config change or is
unconfigured, the ep_in[] and ep_out[] arrays may be left holding old
pointers to usb_host_endpoint structures. If the device is
deauthorized these structures get freed, and the stale pointers cause
errors when the the device is eventually unplugged.
The solution is to disable the endpoints after unbinding the
interfaces instead of before. This isn't as large a change as it
sounds, since usb_unbind_interface() disables all the interface's
endpoints anyway before calling the driver's disconnect routine,
unless the driver claims to support "soft" unbind.
This fixes Bugzilla #19192. Thanks to "Tom" Lei Ming for diagnosing
the underlying cause of the problem.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Carsten Sommer <carsten_sommer@ymail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
