Bug 559711
| Summary: | Add wireless fixes from 2.6.32.y tree | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | John W. Linville <linville> | ||||
| Component: | kernel | Assignee: | John W. Linville <linville> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 5.5 | CC: | cmeadors, hjia, jane.lv, jvillalo, kernel-maint, kernel-mgr, luyu, peterm, rpacheco, syeghiay | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-03-30 07:20:44 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 456943, 481575, 526948 | ||||||
| Attachments: |
|
||||||
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. This really needs to get into RHEL5.5 if at all possible... 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>
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 |
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.