Commit 8bf3d79b 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: stable@kernel.org
Cc: David Quan <david.quan@atheros.com>
Cc: Stephen Beahm <stephenbeahm@comcast.net>
Reported-by: Joshua Covington <joshuacov@googlemail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If multicast parameter (as returned by zd_op_prepare_multicast) has
changed, no bit in changed_flags is set. To handle this situation, we do
not return if changed_flags is 0. If we do so, we will have some issue
with IPv6 which uses multicast for link layer address resolution.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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@gmail.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If there was an error acquiring the firmware lock in
mwl8k_configure_filter(), we would end up leaking the multicast
command packet prepared by mwl8k_prepare_multicast().
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The unit of sizeof() is byte instead of bit, so fix it.
The patch can fix debug output of some dma_addr_t variables.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add missing DEBUG_FS dependency for ATH9K_DEBUGFS in ath9k's Kconfig.
Signed-off-by: Dominik D. Geyer <dominik.geyer@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This reverts commit 9bd568a5.

That commit is shown to cause allocation failures during initialization
on some machines.

http://bugzilla.kernel.org/show_bug.cgi?id=14844Signed-off-by: John W. Linville <linville@tuxdriver.com>

Allocate priv->rx_packets[IWM_RX_ID_HASH + 1] because the max array
index is IWM_RX_ID_HASH according to IWM_RX_ID_GET_HASH().

Cc: stable@kernel.org
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

`loop' reaches INIT_LOOP + 1 after the loop. so if ACX_INTR_INIT_COMPLETE
occurs in the last iteration the write occurs but also the error out as if a
timeout occurred. This is probably very unlikely to ever occur.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

My previous change added in:

 commit 815833e7
    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.

Cc: stable@kernel.org
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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.

Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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.

Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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.

Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If there's an invalid channel or SSID, the code leaks
the scan request. Always free the scan request, unless
it was successfully given to the driver.
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This is just a clean up and doesn't make a functional difference.  It keeps the
lint checkers happy.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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@nahmias.net>
Cc: stable@kernel.org
Cc: 562016-quiet@bugs.debian.org
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This removes the remaining users of the rx status
'qual' field and the field itself.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This is a rt2870 based device.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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@bobcopeland.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When fixed bssid is requested when joining an ibss network, incoming
beacons that match the configured bssid cause mac80211 to create new
sta entries, even before the ibss interface is in joined state.
When that happens, it fails to bring up the interface entirely, because
it checks for existing sta entries before joining.
This patch fixes this bug by refusing to create sta info entries before
the interface is fully operational.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

There is no reason to signal a carrier off when doing a 802.11 scan.

Cc: Holger Schurig <holgerschurig@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

orinoco_set_key is called from two places both with interrupts disabled
(under orinoco_lock). Use GFP_ATOMIC instead of GFP_KERNEL. Fixes following
warning:

[   77.254109] WARNING: at /home/bor/src/linux-git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x9a/0xa0()
[   77.254109] Hardware name: PORTEGE 4000
[   77.254109] Modules linked in: af_packet irnet ppp_generic slhc ircomm_tty ircomm binfmt_misc dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath dm_mod loop nvram toshiba cryptomgr aead pcompress crypto_blkcipher michael_mic crypto_hash crypto_algapi orinoco_cs orinoco cfg80211 smsc_ircc2 pcmcia irda toshiba_acpi yenta_socket video i2c_ali1535 backlight rsrc_nonstatic ali_agp pcmcia_core psmouse output crc_ccitt i2c_core alim1535_wdt rfkill sg evdev ohci_hcd agpgart usbcore pata_ali libata reiserfs [last unloaded: scsi_wait_scan]
[   77.254109] Pid: 2296, comm: wpa_supplicant Not tainted 2.6.32-1avb #1
[   77.254109] Call Trace:
[   77.254109]  [<c011f0ad>] warn_slowpath_common+0x6d/0xa0
[   77.254109]  [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0
[   77.254109]  [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0
[   77.254109]  [<c011f0f5>] warn_slowpath_null+0x15/0x20
[   77.254109]  [<c014206a>] lockdep_trace_alloc+0x9a/0xa0
[   77.254109]  [<c018d296>] __kmalloc+0x36/0x130
[   77.254109]  [<dffcb6a8>] ? orinoco_set_key+0x48/0x1c0 [orinoco]
[   77.254109]  [<dffcb6a8>] orinoco_set_key+0x48/0x1c0 [orinoco]
[   77.254109]  [<dffcb9fc>] orinoco_ioctl_set_encodeext+0x1dc/0x2d0 [orinoco]
[   77.254109]  [<c035b117>] ioctl_standard_call+0x207/0x3b0
[   77.254109]  [<dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco]
[   77.254109]  [<c0307f1f>] ? rtnl_lock+0xf/0x20
[   77.254109]  [<c0307f1f>] ? rtnl_lock+0xf/0x20
[   77.254109]  [<c02fb115>] ? __dev_get_by_name+0x85/0xb0
[   77.254109]  [<c035b616>] wext_handle_ioctl+0x176/0x200
[   77.254109]  [<dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco]
[   77.254109]  [<c030020f>] dev_ioctl+0x6af/0x730
[   77.254109]  [<c02eec65>] ? move_addr_to_kernel+0x55/0x60
[   77.254109]  [<c02eed59>] ? sys_sendto+0xe9/0x130
[   77.254109]  [<c02ed77e>] sock_ioctl+0x7e/0x250
[   77.254109]  [<c02ed700>] ? sock_ioctl+0x0/0x250
[   77.254109]  [<c019cf4c>] vfs_ioctl+0x1c/0x70
[   77.254109]  [<c019d1fa>] do_vfs_ioctl+0x6a/0x590
[   77.254109]  [<c0178e50>] ? might_fault+0x90/0xa0
[   77.254109]  [<c0178e0a>] ? might_fault+0x4a/0xa0
[   77.254109]  [<c02ef90e>] ? sys_socketcall+0x17e/0x280
[   77.254109]  [<c019d759>] sys_ioctl+0x39/0x60
[   77.254109]  [<c0102e3b>] sysenter_do_call+0x12/0x32
[   77.254109] ---[ end trace 95ef563548d21efd ]---
Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The option to support the old style PSK interface in the PS3
GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

My
  commit 77fdaa12
  Author: Johannes Berg <johannes@sipsolutions.net>
  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@sipsolutions.net>
Cc: stable@kernel.org [2.6.31+]
Signed-off-by: John W. Linville <linville@tuxdriver.com>

I noticed yesterday, because Jeff had noticed
a speed regression, cf. bug
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138
that the SM PS settings for peers were wrong.
Instead of overwriting the SM PS settings with
the local bits, we need to keep the remote bits.

The bug was part of the original HT code from
over two years ago, but unfortunately nobody
noticed that it makes no sense -- we shouldn't
be overwriting the peer's setting with our own
but rather keep it intact when masking the peer
capabilities with our own.

While fixing that, I noticed that the masking of
capabilities is completely useless for most of
the bits, so also fix those other bits.

Finally, I also noticed that PSMP_SUPPORT no
longer exists in the final 802.11n version, so
also remove that.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

`queue' was unsigned so the test did not work.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Reviewed-by: Pavel Roskin <proski@gnu.org>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The libertas driver copies the SSID buffer back to the wireless core and
appends a trailing NULL character for termination. This is

a) unnecessary because the buffer is allocated with kzalloc and is hence
   already NULLed when this function is called, and

b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
   much which causes memory corruptions.

Fix this by removing the extra write.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Maithili Hinge <maithili@marvell.com>
Cc: Kiran Divekar <dkiran@marvell.com>
Cc: Michael Hirsch <m.hirsch@raumfeld.com>
Cc: netdev@vger.kernel.org
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@lists.infradead.org
Cc: stable@kernel.org
Acked-by: Holger Schurig <holgerschurig@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/net/wireless/iwlwifi/iwl-tx.c: In function `iwl_hw_txq_ctx_free':
drivers/net/wireless/iwlwifi/iwl-tx.c:410: warning: suggest explicit braces to avoid ambiguous `else'

Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The MIB counters are disabled when doing a chip reset.
Since ANI depends on the MIB registers for its operation, relying
on the contents of said registers during HW reset results in sub-optimal
performance.

Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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.

Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The internal, driver-specific maintenance of sequence
numbers is applicable only for HT frames.

Also, remove comments that are not relevant anymore.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Fix typo. The index should be multiplied by the entry size, not 'and'-ed.

Found via code-inspection.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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=2135Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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@gmail.com>
Tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Recent powersaving work resulted in power management ops being called
during EEPROM initialization. The lock used by these functions is not
initialized at this time. Ensure lock is initialized before it is used.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>