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.