Bug 559711 - Add wireless fixes from 2.6.32.y tree
Summary: Add wireless fixes from 2.6.32.y tree
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.5
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: John W. Linville
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 456943 481575 526948
TreeView+ depends on / blocked
 
Reported: 2010-01-28 19:53 UTC by John W. Linville
Modified: 2010-03-30 07:20 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 07:20:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Fixes in 2.6.32.y tree that are applicable to rhel5.5 (51.17 KB, text/plain)
2010-01-28 19:53 UTC, John W. Linville
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0178 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.5 kernel security and bug fix update 2010-03-29 12:18:21 UTC

Description John W. Linville 2010-01-28 19:53:33 UTC
Created attachment 387413 [details]
Fixes in 2.6.32.y tree that are applicable to rhel5.5

The 2.6.32.y (i.e. "stable") tree contains a number of fixes pertinent to the (2.6.32-based) wireless support in RHEL 5.5 kernels.  These fixes should be included in the RHEL5.5 kernel ASAP.

Comment 1 RHEL Program Management 2010-01-28 20:12:00 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 3 John W. Linville 2010-02-04 16:22:12 UTC
This really needs to get into RHEL5.5 if at all possible...

Comment 6 John W. Linville 2010-02-08 16:40:29 UTC
Below is the list of commits from linux-2.6.32.y...hth! :-)

commit 58cd74bafb36b884abe67998cdef4203ae01769f
Author: Vivek Natarajan <vnatarajan>
Date:   Wed Dec 16 11:51:45 2009 -0500

    mac80211: Fix dynamic power save for scanning.
    
    Upstream commit: 7c3f4bbedc241ddcd3abe1f419c356e625231da1
    
    Not only ps_sdata but also IEEE80211_CONF_PS is to be considered
    before restoring PS in scan_ps_disable(). For instance, when ps_sdata
    is set but CONF_PS is not set just because the dynamic timer is still
    running, a sw scan leads to setting of CONF_PS in scan_ps_disable
    instead of restarting the dynamic PS timer.
    Also for the above case, a null data frame is to be sent after
    returning to operating channel which was not happening with the
    current implementation. This patch fixes this too.
    
    
    Signed-off-by: Vivek Natarajan <vnatarajan>
    Reviewed-by: Kalle Valo <kalle.valo>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 0f77b958dccf9d3b59d986ea160f84b50c646712
Author: Felix Fietkau <nbd>
Date:   Wed Dec 16 11:51:44 2009 -0500

    ath9k: fix tx status reporting
    
    This is a backport of upstream commit: e8c6342d989e241513baeba4b05a04b6b1f3bc8b
    
    This patch fixes a bug in ath9k's tx status check, which
    caused mac80211 to consider regularly transmitted unicast frames
    as un-acked.
    
    When checking the ts_status field for errors, it needs to be masked
    with ATH9K_TXERR_FILT, because this field also contains other fields
    like ATH9K_TX_ACKED.
    
    Without this patch, AP mode is pretty much unusable, as hostapd
    checks the ACK status for the frames that it injects.
    
    
    Signed-off-by: Felix Fietkau <nbd>
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit e82a3a2db53b6df3a211c7b90c793d61fcb6ddae
Author: Luis R. Rodriguez <lrodriguez>
Date:   Wed Dec 16 11:51:43 2009 -0500

    ath9k: Fix maximum tx fifo settings for single stream devices
    
    This is a backport of upstream commit: f4709fdf683e1ed37b321c258b614ebe39752bf3
    
    Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO
    buffer size of that of dual stream devices. Dual stream devices
    have a max PCU TX FIFO size of 8 KB while single stream devices
    have 4 KB. Single stream devices have an issue though and require
    hardware only to use half of the amount of its capable PCU TX FIFO
    size, 2 KB and this requires a change in software.
    
    Technically a change would not have been required (except for frame
    burst considerations of 128 bytes) if these devices would have been
    able to use the full 4 KB of the PCU TX FIFO size but our systems
    engineers recommend 2 KB to be used only. We enforce this through
    software by reducing the max frame triggger level to 2 KB.
    
    Fixing the max frame trigger level should then have a few benefits:
    
      * The PER will now be adjusted as designed for underruns when the
        max trigger level is reached. This should help alleviate the
        bus as the rate control algorithm chooses a slower rate which
        should ensure frames are transmitted properly under high system
        bus load.
    
      * The poll we use on our TX queues should now trigger and work
        as designed for single stream devices. The hardware passes
        data from each TX queue on the PCU TX FIFO queue respecting each
        queue's priority. The new trigger level ensures this seeding of
        the PCU TX FIFO queue occurs as designed which could mean avoiding
        false resets and actually reseting hw correctly when a TX queue
        is indeed stuck.
    
      * Some undocumented / unsupported behaviour could have been triggered
        when the max trigger level level was being set to 4 KB on single
        stream devices. Its not clear what this issue was to me yet.
    
    Cc: Kyungwan Nam <kyungwan.nam>
    Cc: Bennyam Malavazi <bennyam.malavazi>
    Cc: Stephen Chen <stephen.chen>
    Cc: Shan Palanisamy <shan.palanisamy>
    Cc: Paul Shaw <paul.shaw>
    Signed-off-by: Vasanthakumar Thiagarajan <vasanth>
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 022fe0eb677b07aa37a3f88eab5ed47be2faffb5
Author: Luis R. Rodriguez <lrodriguez>
Date:   Wed Dec 16 11:51:42 2009 -0500

    ath9k: fix processing of TX PS null data frames
    
    This is a backport of upstream commit: e7824a50662f7f79b1a739f705b4d906c31cf221
    
    When mac80211 was telling us to go into Powersave we listened
    and immediately turned RX off. This meant hardware would not
    see the ACKs from the AP we're associated with and hardware
    we'd end up retransmiting the null data frame in a loop
    helplessly.
    
    Fix this by keeping track of the transmitted nullfunc frames
    and only when we are sure the AP has sent back an ACK do we
    go ahead and shut RX off.
    
    
    Signed-off-by: Vasanthakumar Thiagarajan <vasanth>
    Signed-off-by: Vivek Natarajan <Vivek.Natarajan>
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 978962f22c95c70f9018a9181c73525d26f0f3bd
Author: Sujith <Sujith.Manoharan>
Date:   Wed Dec 16 11:51:41 2009 -0500

    ath9k: Fix TX hang poll routine
    
    This is a backport of upstream commit: 332c556633b8c5fb4e890b1783122f2315526590
    
    When TX is hung, the chip is reset. Ensure that
    the chip is awake by using the PS wrappers.
    
    
    Signed-off-by: Sujith <Sujith.Manoharan>
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 7fd943643cc5aef6546ca3d8914e01d4298ee769
Author: Larry Finger <Larry.Finger>
Date:   Sat Dec 5 19:25:22 2009 -0600

    rtl8187: Fix wrong rfkill switch mask for some models
    
    commit 70d57139f932b9ca21026253d02af71cf53d764a upstream.
    
    There are different bits used to convey the setting of the rfkill
    switch to the driver. The current driver only supports one of these
    possibilities. These changes were derived from the latest version
    of the vendor driver.
    
    This patch fixes the regression noted in kernel Bugzilla #14743.
    
    Signed-off-by: Larry Finger <Larry.Finger>
    Reported-and-tested-by: Antti Kaijanmäki <antti>
    Tested-by: Hin-Tak Leung <hintak.leung>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 22731c4b03371594e3bfdf032a64ee3cc6e61365
Author: Johannes Berg <johannes>
Date:   Sat Oct 31 07:44:08 2009 +0100

    mac80211: fix scan abort sanity checks
    
    commit 6d3560d4fc9c5b9fe1a07a63926ea70512c69c32 upstream.
    
    Since sometimes mac80211 queues up a scan request
    to only act on it later, it must be allowed to
    (internally) cancel a not-yet-running scan, e.g.
    when the interface is taken down. This condition
    was missing since we always checked only the
    local->scanning variable which isn't yet set in
    that situation.
    
    Reported-by: Luis R. Rodriguez <mcgrof>
    Signed-off-by: Johannes Berg <johannes>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit c04c99abc6754fa92d428915ac4215994fe95609
Author: Javier Cardona <javier>
Date:   Wed Dec 9 18:43:01 2009 -0800

    mac80211: Revert 'Use correct sign for mesh active path refresh'
    
    commit 7b324d28a94dac5a451e8cba66e8d324601e5b9a upstream.
    
    The patch ("mac80211: Use correct sign for mesh active path
    refresh.") was actually a bug.  Reverted it and improved the
    explanation of how mesh path refresh works.
    
    Signed-off-by: Javier Cardona <javier>
    Signed-off-by: Andrey Yurovsky <andrey>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit dde24b6c58b10e27c296f2d343e9512ec0dce874
Author: Javier Cardona <javier>
Date:   Wed Dec 9 18:43:00 2009 -0800

    mac80211: Fixed bug in mesh portal paths
    
    commit 5d618cb81aeea19879975cd1f9a1e707694dfd7c upstream.
    
    Paths to mesh portals were being timed out immediately after each use in
    intermediate forwarding nodes.  mppath->exp_time is set to the expiration time
    so assigning it to jiffies was marking the path as expired.
    
    Signed-off-by: Javier Cardona <javier>
    Signed-off-by: Andrey Yurovsky <andrey>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit fb0f7048cfa072125c98dc11884a96d1e03c0f9a
Author: Vasanthakumar Thiagarajan <vasanth>
Date:   Fri Dec 4 17:41:34 2009 +0530

    mac80211: Fix bug in computing crc over dynamic IEs in beacon
    
    commit 1814077fd12a9cdf478c10076e9c42094e9d9250 upstream.
    
    On a 32-bit machine, BIT() macro does not give the required
    bit value if the bit is mroe than 31. In ieee802_11_parse_elems_crc(),
    BIT() is suppossed to get the bit value more than 31 (42 (id of ERP_INFO_IE),
    37 (CHANNEL_SWITCH_IE), (42), 32 (POWER_CONSTRAINT_IE), 45 (HT_CAP_IE),
    61 (HT_INFO_IE)). As we do not get the required bit value for the above
    IEs, crc over these IEs are never calculated, so any dynamic change in these
    IEs after the association is not really handled on 32-bit platforms.
    This patch fixes this issue.
    
    Signed-off-by: Vasanthakumar Thiagarajan <vasanth>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5
Author: Luis R. Rodriguez <lrodriguez>
Date:   Wed Nov 25 17:23:26 2009 -0500

    ath5k: enable EEPROM checksum check
    
    commit 512414b0bed0d376ac4d5ec1dd6f0b1a3551febc upstream.
    
    Without this we have no gaurantee of the integrity of the
    EEPROM and are likely to encounter a lot of bogus bug reports
    due to actual issues on the EEPROM. With the EEPROM checksum
    check in place we can easily rule those issues out.
    
    If you run patch during a revert *you* have a card with a busted
    EEPROM and only older kernel will support that concoction. This
    patch is a trade off between not accepitng bogus EEPROMs and
    avoiding bogus bug reports allowing developers to focus instead
    on real concrete issues.
    
    If stable keeps bogus bug reports because of a possibly busted EEPROM
    feel free to apply this there too.
    
    Tested on an AR5414
    
    Cc: jirislaby
    Cc: akpm
    Cc: rjw
    Cc: me
    Cc: david.quan
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit f0da7d9ab2ab222669e51f0404dc9b4e2fef9944
Author: Bob Copeland <me>
Date:   Mon Nov 16 08:30:29 2009 -0500

    ath5k: allow setting txpower to 0
    
    commit 2eb2fa67e5462a36e98172fb92c78bc405b3035f upstream.
    
    As a holdover from earlier code when we used to set
    the power limit to '0' after a reset to configure the
    default transmit power, ath5k interprets txpower=0 as
    12.5 dBm.  Fix that by just passing 0 through.
    
    This fixes http://bugzilla.kernel.org/show_bug.cgi?id=14567
    
    Reported-by: Daniel Folkers <daniel.folkers>
    Tested-by: Daniel Folkers <daniel.folkers>
    Signed-off-by: Bob Copeland <me>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 3815270b3107d31c8b7bd69461f0bb3c350ee25c
Author: Gertjan van Wingerde <gwingerde>
Date:   Mon Dec 14 20:33:55 2009 +0100

    rt2x00: Disable powersaving for rt61pci and rt2800pci.
    
    commit 93b6bd26b74efe46b4579592560f9f1cb7b61994 upstream.
    
    We've had many reports of rt61pci failures with powersaving enabled.
    Therefore, as a stop-gap measure, disable powersaving of the rt61pci
    until we have found a proper solution.
    Also disable powersaving on rt2800pci as it most probably will show
    the same problem.
    
    Signed-off-by: Gertjan van Wingerde <gwingerde>
    Acked-by: Ivo van Doorn <IvDoorn>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 1cfe005024b5c820f9b37c9045ec87ee75a8cfb6
Author: Luis R. Rodriguez <lrodriguez>
Date:   Thu Dec 24 15:26:09 2009 -0500

    mac80211: fix race with suspend and dynamic_ps_disable_work
    
    commit b98c06b6debfe84c90200143bb1102f312f50a33 upstream.
    
    When mac80211 suspends it calls a driver's suspend callback
    as a last step and after that the driver assumes no calls will
    be made to it until we resume and its start callback is kicked.
    If such calls are made, however, suspend can end up throwing
    hardware in an unexpected state and making the device unusable
    upon resume.
    
    Fix this by preventing mac80211 to schedule dynamic_ps_disable_work
    by checking for when mac80211 starts to suspend and starts
    quiescing. Frames should be allowed to go through though as
    that is part of the quiescing steps and we do not flush the
    mac80211 workqueue since it was already done towards the
    beginning of suspend cycle.
    
    The other mac80211 issue will be hanled in the next patch.
    
    For further details see refer to the thread:
    
    http://marc.info/?t=126144866100001&r=1&w=2
    
    Cc: stable
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 14b4d749ab35158853bca4868b42c0a8cb947206
Author: Reinette Chatre <reinette.chatre>
Date:   Mon Dec 14 14:12:13 2009 -0800

    iwlwifi: fix 40MHz operation setting on cards that do not allow it
    
    commit 6c3069b1e7e983e176a5f826e2edffefdd404a08 upstream.
    
    Some devices have 40MHz operation disabled entirely. Ensure that driver do
    not enable 40MHz operation if a channel does not allow this.
    
    This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2135
    
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit c4ae8aea88809050e8ae76a8c3e252ba3fe6e2cc
Author: Johannes Berg <johannes>
Date:   Mon Dec 14 14:12:09 2009 -0800

    iwlwifi: fix more eeprom endian bugs
    
    commit b7bb1756cb6a610cdbac8cfdad9e79bb5670b63b upstream.
    
    I've also for a long time had a problem with the
    temperature calculation code, which I had fixed
    by byte-swapping the values, and now it turns out
    that was the correct fix after all.
    
    Also, any use of iwl_eeprom_query_addr() that is
    for more than a u8 must be cast to little endian,
    and some structs as well.
    
    Fix all this. Again, no real impact on platforms
    that already are little endian.
    
    Signed-off-by: Johannes Berg <johannes>
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit df5d119f46660631b9d50b91b1b888cdb512bdb2
Author: Johannes Berg <johannes>
Date:   Mon Dec 14 14:12:08 2009 -0800

    iwlwifi: fix EEPROM/OTP reading endian annotations and a bug
    
    commit af6b8ee38833b39f70946f767740565ceb126961 upstream.
    
    The construct "le16_to_cpu((__force __le16)(r >> 16))" has
    always bothered me when looking through the iwlwifi code,
    it shouldn't be necessary to __force anything, and before
    this code, "r" was obtained with an ioread32, which swaps
    each of the two u16 values in it properly when swapping the
    entire u32 value. I've had arguments about this code with
    people before, but always conceded they were right because
    removing it only made things not work at all on big endian
    platforms.
    
    However, analysing a failure of the OTP reading code, I now
    finally figured out what is going on, and why my intuition
    about that code being wrong was right all along.
    
    It turns out that the 'priv->eeprom' u8 array really wants
    to have the data in it in little endian. So the force code
    above and all really converts *to* little endian, not from
    it. Cf., for instance, the function iwl_eeprom_query16() --
    it reads two u8 values and combines them into a u16, in a
    little-endian way. And considering it more, it makes sense
    to have the eeprom array as on the device, after all not
    all values really are 16-bit values, the MAC address for
    instance is not.
    
    Now, what this really means is that all the annotations are
    completely wrong. The eeprom reading code should fill the
    priv->eeprom array as a __le16 array, with __le16 values.
    
    This also means that iwl_read_otp_word() should really have
    a __le16 pointer as the data argument, since it should be
    filling that in a format suitable for priv->eeprom.
    
    Propagating these changes throughout, iwl_find_otp_image()
    is found to be, now obviously visible, defective -- it uses
    the data returned by iwl_read_otp_word() directly as if it
    was CPU endianness. Fixing that, which is this hunk of the
    patch:
    
    -               next_link_addr = link_value * sizeof(u16);
    +               next_link_addr = le16_to_cpu(link_value) * sizeof(u16);
    
    is the only real change of this patch. Everything else is
    just fixing the sparse annotations.
    
    Also, the bug only shows up on big endian platforms with a
    1000 series card. 5000 and previous series do not use OTP,
    and 6000 series has shadow RAM support which means we don't
    ever use the defective code on any cards but 1000.
    
    Signed-off-by: Johannes Berg <johannes>
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 0c0cdaff83704490511b462c7ba76d3ff2d0eedb
Author: Zhu Yi <yi.zhu>
Date:   Mon Dec 14 14:12:12 2009 -0800

    iwl3945: fix panic in iwl3945 driver
    
    commit dc57a303faab8562b92e85df0d79c4a05d7e2a61 upstream.
    
    3945 updated write_ptr without regard to read_ptr on the Tx path.
    This messes up our TFD on high load and result in the following:
    
    <1>[ 7290.414172] IP: [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <4>[ 7290.414205] PGD 0
    <1>[ 7290.414214] Thread overran stack, or stack corrupted
    <0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP
    <0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
    <4>[ 7290.414265] CPU 0
    <4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress
    <6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P           2.6.32-rc8-wl #213 Aspire 5720
    <6>[ 7290.414507] RIP: 0010:[<ffffffffa0dd53a1>]  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <6>[ 7290.414541] RSP: 0018:ffff880002203d60  EFLAGS: 00010246
    <6>[ 7290.414557] RAX: 000000000000004f RBX: ffff880064c11600 RCX: 0000000000000013
    <6>[ 7290.414576] RDX: ffffffffa0ddcf20 RSI: ffff8800512b7008 RDI: 0000000000000038
    <6>[ 7290.414596] RBP: ffff880002203dd0 R08: 0000000000000000 R09: 0000000000000100
    <6>[ 7290.414616] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000a0
    <6>[ 7290.414635] R13: 0000000000000002 R14: 0000000000000013 R15: 0000000000020201
    <6>[ 7290.414655] FS:  0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000
    <6>[ 7290.414677] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    <6>[ 7290.414693] CR2: 0000000000000041 CR3: 0000000001001000 CR4: 00000000000006f0
    <6>[ 7290.414712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    <6>[ 7290.414732] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    <4>[ 7290.414752] Process swapper (pid: 0, threadinfo ffffffff81524000, task ffffffff81528b60)
    <0>[ 7290.414772] Stack:
    <4>[ 7290.414780]  ffff880002203da0 0000000000000046 0000000000000000 0000000000000046
    <4>[ 7290.414804] <0> 0000000000000282 0000000000000282 0000000000000282 ffff880064c12010
    <4>[ 7290.414830] <0> ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000
    <0>[ 7290.414858] Call Trace:
    <0>[ 7290.414867]  <IRQ>
    <4>[ 7290.414884]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
    <4>[ 7290.414910]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
    <4>[ 7290.414931]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
    <4>[ 7290.414950]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
    <4>[ 7290.414968]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
    <4>[ 7290.414986]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
    <4>[ 7290.415003]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
    <4>[ 7290.415020]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
    <4>[ 7290.415038]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
    <0>[ 7290.415052]  <EOI>
    <4>[ 7290.415067]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415087]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
    <4>[ 7290.415107]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415130]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
    <4>[ 7290.415149]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
    <4>[ 7290.415168]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
    <4>[ 7290.415187]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
    <4>[ 7290.415206]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
    <4>[ 7290.415227]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
    <0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49
    <1>[ 7290.415382] RIP  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <4>[ 7290.415410]  RSP <ffff880002203d60>
    <0>[ 7290.415421] CR2: 0000000000000041
    <4>[ 7290.415436] ---[ end trace ec46807277caa515 ]---
    <0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt
    <4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P      D    2.6.32-rc8-wl #213
    <4>[ 7290.415486] Call Trace:
    <4>[ 7290.415495]  <IRQ>  [<ffffffff8138c040>] panic+0x7d/0x13a
    <4>[ 7290.415519]  [<ffffffff8101071a>] oops_end+0xda/0xe0
    <4>[ 7290.415538]  [<ffffffff8102e1ea>] no_context+0xea/0x250
    <4>[ 7290.415557]  [<ffffffff81038991>] ? select_task_rq_fair+0x511/0x780
    <4>[ 7290.415578]  [<ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0
    <4>[ 7290.415597]  [<ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80
    <4>[ 7290.415616]  [<ffffffff81039201>] ? enqueue_task_fair+0x111/0x150
    <4>[ 7290.415636]  [<ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10
    <4>[ 7290.415656]  [<ffffffff8102e8fa>] do_page_fault+0x26a/0x320
    <4>[ 7290.415674]  [<ffffffff813905df>] page_fault+0x1f/0x30
    <4>[ 7290.415697]  [<ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <4>[ 7290.415723]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
    <4>[ 7290.415746]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
    <4>[ 7290.415764]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
    <4>[ 7290.415783]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
    <4>[ 7290.415801]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
    <4>[ 7290.415818]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
    <4>[ 7290.415835]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
    <4>[ 7290.415852]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
    <4>[ 7290.415869]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
    <4>[ 7290.415883]  <EOI>  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415911]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
    <4>[ 7290.415931]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415952]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
    <4>[ 7290.415971]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
    <4>[ 7290.415989]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
    <4>[ 7290.416007]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
    <4>[ 7290.416026]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
    <4>[ 7290.416047]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
    
    Reported-by: Maxim Levitsky <maximlevitsky>
    Tested-by: Maxim Levitsky <maximlevitsky>
    Signed-off-by: Zhu Yi <yi.zhu>
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 66c9e44e5740fe9024e3ed02fd66ad6e0e57408f
Author: Reinette Chatre <reinette.chatre>
Date:   Mon Dec 14 14:12:10 2009 -0800

    iwl3945: disable power save
    
    commit bc45a67079c916a9bd0a95b0b879cc0f259bac6e upstream.
    
    we see from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2125
    that power saving does not work well on 3945. Since then power saving has
    also been connected with association problems where an AP deathenticates a
    3945 after it is unable to transmit data to it - this happens when 3945
    enters power savings mode.
    
    Disable power save support until issues are resolved.
    
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 87d512cacd0aff44719736ef6d583cafd5c0e1be
Author: Vasanthakumar Thiagarajan <vasanth>
Date:   Fri Nov 13 14:32:40 2009 +0530

    ath9k_hw: Fix AR_GPIO_INPUT_EN_VAL_BT_PRIORITY_BB and its shift value in 0x4054
    
    commit c37919bfe0a5c1bee9a31701a31e05a2f8840936 upstream.
    
    The bit value of AR_GPIO_INPUT_EN_VAL_BT_PRIORITY_BB is wrong, it should
    be 0x400 and the number of bits to be right shifted is 10. Having this
    wrong value in 0x4054 sometimes affects bt quality on btcoex environment.
    
    Signed-off-by: Vasanthakumar Thiagarajan <vasanth>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit a6d8cc616a9058b2e08776f971febf5c84534551
Author: Vasanthakumar Thiagarajan <vasanth>
Date:   Fri Nov 13 14:32:39 2009 +0530

    ath9k_hw: Fix possible OOB array indexing in gen_timer_index[] on 64-bit
    
    commit c90017dd43f0cdb42134b9229761e8be02bcd524 upstream.
    
    debruijn32 (0x077CB531) is used to index gen_timer_index[]
    which is an array of 32 u32. Having debruijn32 as unsigned
    long on a 64-bit platform  will result in indexing more than 32
    in gen_timer_index[] and there by causing a crash. Make it
    unsigned to fix this issue.
    
    Signed-off-by: Vasanthakumar Thiagarajan <vasanth>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 12ba7097e0996b27d768504ae4b337ae3e892221
Author: Sujith <Sujith.Manoharan>
Date:   Wed Dec 23 20:03:27 2009 -0500

    ath9k: fix suspend by waking device prior to stop
    
    commit 3867cf6a8c699846e928e8f5a9f31013708df192 upstream.
    
    Ensure the device is awake prior to trying to tell hardware
    to stop it. Impact of not doing this is we can likely leave
    the device in an undefined state likely causing issues with
    suspend and resume. This patch ensures harware is where it
    should be prior to suspend.
    
    Signed-off-by: Sujith <Sujith.Manoharan>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit c965e1efdb88a1c42afb119b276d649cddb70387
Author: Luis R. Rodriguez <lrodriguez>
Date:   Wed Dec 23 20:03:29 2009 -0500

    ath9k: wake hardware during AMPDU TX actions
    
    commit 8b685ba9de803f210936400612a32a2003f47cd3 upstream.
    
    AMDPDU actions poke hardware for TX operation, as such
    we want to turn hardware on for these actions. AMDPU RX operations
    do not require hardware on as nothing is done in hardware for
    those actions. Without this we cannot guarantee hardware has
    been programmed correctly for each AMPDU TX action.
    
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 463a7f9b2752b659f93272c0067dcbc10bd73674
Author: Felix Fietkau <nbd>
Date:   Thu Dec 24 14:04:32 2009 +0100

    ath9k: fix missed error codes in the tx status check
    
    commit 5b479a076de091590423a9e6dfc2584126b28761 upstream.
    
    My previous change added in:
    
     commit 815833e7ecf0b9a017315cae6aef4d7cd9517681
        ath9k: fix tx status reporting
    
    was not checking all possible tx error conditions. This could possibly
    lead to throughput issues due to slow rate control adaption or missed
    retransmissions of failed A-MPDU frames.
    
    This patch adds a mask for all possible error conditions and uses it
    in the xmit ok check.
    
    Reported-by: Björn Smedman <bjorn.smedman>
    Signed-off-by: Felix Fietkau <nbd>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit bef82b626e39357fd28b8303e9f88ea5c5d1b51f
Author: Sujith <Sujith.Manoharan>
Date:   Mon Dec 14 14:57:08 2009 +0530

    ath9k: Fix TX queue draining
    
    commit e8009e9850d59000d518296af372888911a129bd upstream.
    
    When TX DMA termination has failed, the HW has to be reset
    completely. Doing a fast channel change in this case is insufficient.
    Also, change the debug level of a couple of messages to FATAL.
    
    Signed-off-by: Sujith <Sujith.Manoharan>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 0ebbdd734f2509bae17f4340fc4fd07c530dbc59
Author: Luis R. Rodriguez <lrodriguez>
Date:   Wed Dec 23 20:03:28 2009 -0500

    ath9k: wake hardware for interface IBSS/AP/Mesh removal
    
    commit 5f70a88f631c3480107853cae12925185eb4c598 upstream.
    
    When we remove a IBSS/AP/Mesh interface we stop DMA
    but to do this we should ensure hardware is on. Awaken
    the device prior to these calls. This should ensure
    DMA is stopped upon suspend and plain device removal.
    
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit d5086b90c5986d33308b1ee99546a86ff1571d07
Author: Bob Copeland <me>
Date:   Mon Dec 21 22:26:48 2009 -0500

    ath5k: fix SWI calibration interrupt storm
    
    commit 242ab7ad689accafd5e87ffd22b85cf1bf7fbbef upstream.
    
    The calibration period is now invoked by triggering a software
    interrupt from within the ISR by ath5k_hw_calibration_poll()
    instead of via a timer.
    
    However, the calibration interval isn't initialized before
    interrupts are enabled, so we can have a situation where an
    interrupt occurs before the interval is assigned, so the
    interval is actually negative.  As a result, the ISR will
    arm a software interrupt to schedule the tasklet, and then
    rearm it when the SWI is processed, and so on, leading to a
    softlockup at modprobe time.
    
    Move the initialization order around so the calibration interval
    is set before interrupts are active.  Another possible fix
    is to schedule the tasklet directly from the poll routine,
    but I think there are additional plans for the SWI.
    
    Signed-off-by: Bob Copeland <me>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 477702056912abc2120a18e8494fb2204ccdd958
Author: Johannes Berg <johannes>
Date:   Wed Dec 23 13:12:05 2009 +0100

    cfg80211: fix race between deauth and assoc response
    
    commit 3bdb2d48c5f58c781a4099c99044384a23620884 upstream.
    
    Joseph Nahmias reported, in http://bugs.debian.org/562016,
    that he was getting the following warning (with some log
    around the issue):
    
      ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
      ath0: direct probe responded
      ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
      ath0: authenticated
      ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
      ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
      ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
      ath0: RX AssocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
      ath0: associated
      ------------[ cut here ]------------
      WARNING: at net/wireless/mlme.c:97 cfg80211_send_rx_assoc+0x14d/0x152 [cfg80211]()
      Hardware name: 7658CTO
      ...
      Pid: 761, comm: phy0 Not tainted 2.6.32-trunk-686 #1
      Call Trace:
       [<c1030a5d>] ? warn_slowpath_common+0x5e/0x8a
       [<c1030a93>] ? warn_slowpath_null+0xa/0xc
       [<f86cafc7>] ? cfg80211_send_rx_assoc+0x14d/0x152
      ...
      ath0: link becomes ready
      ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
      ath0: no IPv6 routers present
      ath0: link is not ready
      ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
      ath0: direct probe responded
      ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
      ath0: authenticated
      ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
      ath0: RX ReassocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
      ath0: associated
    
    It is not clear to me how the first "direct probe" here
    happens, but this seems to be a race condition, if the
    user requests to deauth after requesting assoc, but before
    the assoc response is received. In that case, it may
    happen that mac80211 tries to report the assoc success to
    cfg80211, but gets blocked on the wdev lock that is held
    because the user is requesting the deauth.
    
    The result is that we run into a warning. This is mostly
    harmless, but maybe cause an unexpected event to be sent
    to userspace; we'd send an assoc success event although
    userspace was no longer expecting that.
    
    To fix this, remove the warning and check whether the
    race happened and in that case abort processing.
    
    Reported-by: Joseph Nahmias <joe>
    Cc: 562016-quiet.org
    Signed-off-by: Johannes Berg <johannes>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 9f7028e71d940aadcdea9f777286b066971ba5da
Author: Sujith <Sujith.Manoharan>
Date:   Mon Nov 2 12:33:23 2009 +0530

    mac80211: Fix IBSS merge
    
    commit 450aae3d7b60a970f266349a837dfb30a539198b upstream.
    
    Currently, in IBSS mode, a single creator would go into
    a loop trying to merge/scan. This happens because the IBSS timer is
    rearmed on finishing a scan and the subsequent
    timer invocation requests another scan immediately.
    
    This patch fixes this issue by checking if we have just completed
    a scan run trying to merge with other IBSS networks.
    
    Signed-off-by: Sujith <Sujith.Manoharan>
    Signed-off-by: John W. Linville <linville>
    Cc: Luis Rodriguez <lrodriguez>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 0b41c5a957e4fb2be4a8ef960e4e50c8791999f3
Author: Johannes Berg <johannes>
Date:   Thu Dec 17 16:16:53 2009 +0100

    mac80211: fix WMM AP settings application
    
    commit 0183826b58a2712ffe608bc3302447be3e6a3ab8 upstream.
    
    My
      commit 77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8
      Author: Johannes Berg <johannes>
      Date:   Tue Jul 7 03:45:17 2009 +0200
    
          mac80211: rework MLME for multiple authentications
    
    inadvertedly broke WMM because it removed, along with
    a bunch of other now useless initialisations, the line
    initialising sdata->u.mgd.wmm_last_param_set to -1
    which would make it adopt any WMM parameter set. If,
    as is usually the case, the AP uses WMM parameter set
    sequence number zero, we'd never update it until the
    AP changes the sequence number.
    
    Add the missing initialisation back to get the WMM
    settings from the AP applied locally.
    
    Signed-off-by: Johannes Berg <johannes>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 330b9373f9b62fcad200f470be7f64c99322d7ef
Author: Luis R. Rodriguez <lrodriguez>
Date:   Thu Dec 24 15:38:22 2009 -0500

    mac80211: fix propagation of failed hardware reconfigurations
    
    commit 24feda0084722189468a65e20019cdd8ef99702b upstream.
    
    mac80211 does not propagate failed hardware reconfiguration
    requests. For suspend and resume this is important due to all
    the possible issues that can come out of the suspend <-> resume
    cycle. Not propagating the error means cfg80211 will assume
    the resume for the device went through fine and mac80211 will
    continue on trying to poke at the hardware, enable timers,
    queue work, and so on for a device which is completley
    unfunctional.
    
    The least we can do is to propagate device start issues and
    warn when this occurs upon resume. A side effect of this patch
    is we also now propagate the start errors upon harware
    reconfigurations (non-suspend), but this should also be desirable
    anyway, there is not point in continuing to reconfigure a
    device if mac80211 was unable to start the device.
    
    For further details refer to the thread:
    
    http://marc.info/?t=126151038700001&r=1&w=2
    
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 9b13cca3a8623088d95d9897d29370b4e0b9c213
Author: Felix Fietkau <nbd>
Date:   Thu Jan 7 20:23:53 2010 +0100

    mac80211: add missing sanity checks for action frames
    
    commit d79074488083ec0d7ecd15352192dc1631f25643 upstream.
    
    Various missing sanity checks caused rejected action frames to be
    interpreted as channel switch announcements, which can cause a client
    mode interface to switch away from its operating channel, thereby losing
    connectivity. This patch ensures that only spectrum management action
    frames are processed by the CSA handling function and prevents rejected
    action frames from getting processed by the MLME code.
    
    Signed-off-by: Felix Fietkau <nbd>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 0ea5505e18a1cb8eebf3384f825840897894ceda
Author: Dan Carpenter <error27>
Date:   Sun Jan 3 11:19:35 2010 +0200

    iwl: off by one bug
    
    commit 8a9ac160e844c7ce8074f6aa531feefb4acdee7c upstream.
    
    tid is used as an array offset.
    	agg = &priv->stations[sta_id].tid[tid].agg;
    	iwl4965_tx_status_reply_tx(priv, agg, tx_resp, txq_id, index);
    
    It should be limitted to MAX_TID_COUNT - 1;
            struct iwl_tid_data tid[MAX_TID_COUNT];
    
    regards,
    dan carpenter
    
    Signed-off-by: Dan Carpenter <error27>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 724ad42667b42b363bbef867d1c31850b599fecc
Author: Luis R. Rodriguez <lrodriguez>
Date:   Mon Jan 4 11:37:39 2010 -0500

    cfg80211: fix syntax error on user regulatory hints
    
    commit e12822e1d3fface0d9e1095c5177e10141bd6bd6 upstream.
    
    This fixes a syntax error when setting up the user regulatory
    hint. This change yields the same exact binary object though
    so it ends up just being a syntax typo fix, fortunately.
    
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit e6efac7b7c4ce45d40f5e07d3105e07704e95673
Author: Luis R. Rodriguez <lrodriguez>
Date:   Mon Jan 4 10:40:39 2010 -0500

    ath5k: Fix eeprom checksum check for custom sized eeproms
    
    commit 359207c687cc8f4f9845c8dadd0d6dabad44e584 upstream.
    
    Commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 enabled EEPROM
    checksum checks to avoid bogus bug reports but failed to address
    updating the code to consider devices with custom EEPROM sizes.
    Devices with custom sized EEPROMs have the upper limit size stuffed
    in the EEPROM. Use this as the upper limit instead of the static
    default size. In case of a checksum error also provide back the
    max size and whether or not this was the default size or a custom
    one. If the EEPROM is busted we add a failsafe check to ensure
    we don't loop forever or try to read bogus areas of hardware.
    
    This closes bug 14874
    
    http://bugzilla.kernel.org/show_bug.cgi?id=14874
    
    Cc: David Quan <david.quan>
    Cc: Stephen Beahm <stephenbeahm>
    Reported-by: Joshua Covington <joshuacov>
    Signed-off-by: Luis R. Rodriguez <lrodriguez>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit fc95845f174a07d4200a30681067d22c9e34723c
Author: Zhu Yi <yi.zhu>
Date:   Fri Jan 8 10:04:30 2010 -0800

    iwlwifi: fix iwl_queue_used bug when read_ptr == write_ptr
    
    commit c8106d7625a58ee4387cb2efe3e82320ad44b467 upstream.
    
    When txq read_ptr equals to write_ptr, iwl_queue_used should
    always return false. Because there is no used TFD in this case.
    
    This is a complementary fix to the fix already included in commit "iwl3945:
    fix panic in iwl3945 driver". Both fixes are needed to address the panic
    below.
    
    This problem was discussed on linux-wireless in
    http://thread.gmane.org/gmane.linux.kernel.wireless.general/43568
    
    <1>[ 7290.414172] IP: [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <4>[ 7290.414205] PGD 0
    <1>[ 7290.414214] Thread overran stack, or stack corrupted
    <0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP
    <0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
    <4>[ 7290.414265] CPU 0
    <4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress
    <6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P           2.6.32-rc8-wl #213 Aspire 5720
    <6>[ 7290.414507] RIP: 0010:[<ffffffffa0dd53a1>]  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <6>[ 7290.414541] RSP: 0018:ffff880002203d60  EFLAGS: 00010246
    <6>[ 7290.414557] RAX: 000000000000004f RBX: ffff880064c11600 RCX: 0000000000000013
    <6>[ 7290.414576] RDX: ffffffffa0ddcf20 RSI: ffff8800512b7008 RDI: 0000000000000038
    <6>[ 7290.414596] RBP: ffff880002203dd0 R08: 0000000000000000 R09: 0000000000000100
    <6>[ 7290.414616] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000a0
    <6>[ 7290.414635] R13: 0000000000000002 R14: 0000000000000013 R15: 0000000000020201
    <6>[ 7290.414655] FS:  0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000
    <6>[ 7290.414677] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    <6>[ 7290.414693] CR2: 0000000000000041 CR3: 0000000001001000 CR4: 00000000000006f0
    <6>[ 7290.414712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    <6>[ 7290.414732] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    <4>[ 7290.414752] Process swapper (pid: 0, threadinfo ffffffff81524000, task ffffffff81528b60)
    <0>[ 7290.414772] Stack:
    <4>[ 7290.414780]  ffff880002203da0 0000000000000046 0000000000000000 0000000000000046
    <4>[ 7290.414804] <0> 0000000000000282 0000000000000282 0000000000000282 ffff880064c12010
    <4>[ 7290.414830] <0> ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000
    <0>[ 7290.414858] Call Trace:
    <0>[ 7290.414867]  <IRQ>
    <4>[ 7290.414884]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
    <4>[ 7290.414910]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
    <4>[ 7290.414931]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
    <4>[ 7290.414950]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
    <4>[ 7290.414968]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
    <4>[ 7290.414986]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
    <4>[ 7290.415003]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
    <4>[ 7290.415020]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
    <4>[ 7290.415038]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
    <0>[ 7290.415052]  <EOI>
    <4>[ 7290.415067]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415087]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
    <4>[ 7290.415107]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415130]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
    <4>[ 7290.415149]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
    <4>[ 7290.415168]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
    <4>[ 7290.415187]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
    <4>[ 7290.415206]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
    <4>[ 7290.415227]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
    <0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49
    <1>[ 7290.415382] RIP  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <4>[ 7290.415410]  RSP <ffff880002203d60>
    <0>[ 7290.415421] CR2: 0000000000000041
    <4>[ 7290.415436] ---[ end trace ec46807277caa515 ]---
    <0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt
    <4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P      D    2.6.32-rc8-wl #213
    <4>[ 7290.415486] Call Trace:
    <4>[ 7290.415495]  <IRQ>  [<ffffffff8138c040>] panic+0x7d/0x13a
    <4>[ 7290.415519]  [<ffffffff8101071a>] oops_end+0xda/0xe0
    <4>[ 7290.415538]  [<ffffffff8102e1ea>] no_context+0xea/0x250
    <4>[ 7290.415557]  [<ffffffff81038991>] ? select_task_rq_fair+0x511/0x780
    <4>[ 7290.415578]  [<ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0
    <4>[ 7290.415597]  [<ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80
    <4>[ 7290.415616]  [<ffffffff81039201>] ? enqueue_task_fair+0x111/0x150
    <4>[ 7290.415636]  [<ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10
    <4>[ 7290.415656]  [<ffffffff8102e8fa>] do_page_fault+0x26a/0x320
    <4>[ 7290.415674]  [<ffffffff813905df>] page_fault+0x1f/0x30
    <4>[ 7290.415697]  [<ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
    <4>[ 7290.415723]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
    <4>[ 7290.415746]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
    <4>[ 7290.415764]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
    <4>[ 7290.415783]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
    <4>[ 7290.415801]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
    <4>[ 7290.415818]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
    <4>[ 7290.415835]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
    <4>[ 7290.415852]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
    <4>[ 7290.415869]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
    <4>[ 7290.415883]  <EOI>  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415911]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
    <4>[ 7290.415931]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
    <4>[ 7290.415952]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
    <4>[ 7290.415971]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
    <4>[ 7290.415989]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
    <4>[ 7290.416007]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
    <4>[ 7290.416026]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
    <4>[ 7290.416047]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
    
    Reported-by: Maxim Levitsky <maximlevitsky>
    Tested-by: Maxim Levitsky <maximlevitsky>
    Signed-off-by: Zhu Yi <yi.zhu>
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 01e991b8eb2cc28f41ed3f96ec33ae3dd6b860a3
Author: Wey-Yi Guy <wey-yi.w.guy>
Date:   Tue Jan 26 12:00:43 2010 -0800

    iwlwifi: Fix throughput stall issue in HT mode for 5000
    
    commit 1152dcc28c66a74b5b3f1a3ede0aa6729bfd48e4 upstream
    
    Similar to 6000 and 1000 series, RTS/CTS is the recommended protection
    mechanism for 5000 series in HT mode based on the HW design.
    
    Using RTS/CTS will better protect the inner exchange from interference,
    especially in highly-congested environment, it also prevent uCode encounter
    TX FIFO underrun and other HT mode related performance issues.
    
    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy>
    Signed-off-by: Reinette Chatre <reinette.chatre>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit eb6002526b1c5cb3e7f9e42004ba395f5d57beaf
Author: Abhijeet Kolekar <abhijeet.kolekar>
Date:   Wed Jan 13 13:23:14 2010 -0800

    cfg80211: fix channel setting for wext
    
    commit 5f6120335c701ba07d5151206071f4d6ccaa684f upstream.
    
    Patch fixes the bug at
    http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2139
    
    Currently we cannot set the channel using wext extension
    if we have already associated and disconnected. As
    cfg80211_mgd_wext_siwfreq will not switch the channel if ssid is set.
    This fixes it by clearing the ssid.
    Following is the sequence which it tries to fix.
    modprobe iwlagn
    iwconfig wlan0 essid ""
    ifconfig wlan0 down
    iwconfig wlan0 chan X
    
    wext is marked as deprecate.If we use nl80211 we can easily play with
    setting the channel.
    
    Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar>
    Acked-by: Samuel Ortiz <sameo.com>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

commit 304cd19e41f6c77c3d307869f15a8bfe2a7408cd
Author: Benoit Papillault <benoit.papillault>
Date:   Fri Jan 15 12:21:37 2010 +0100

    mac80211: check that ieee80211_set_power_mgmt only handles STA interfaces.
    
    commit e5de30c9bf4a39db9f54c4a373470ce65881ade0 upstream.
    
    ieee80211_set_power_mgmt is meant for STA interfaces only. Moreover,
    since sdata->u.mgd.mtx is only initialized for STA interfaces, using
    this code for any other type of interface (like creating a monitor
    interface) will result in a oops.
    
    Signed-off-by: Benoit Papillault <benoit.papillault>
    Signed-off-by: John W. Linville <linville>
    Signed-off-by: Greg Kroah-Hartman <gregkh>

Comment 24 errata-xmlrpc 2010-03-30 07:20:44 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0178.html


Note You need to log in before you can comment on or make changes to this bug.