- Dec 27, 2009
-
-
Anton Vorontsov authored
Following oops was seen with the ucc_geth driver: Unable to handle kernel paging request for data at address 0x00000058 Faulting instruction address: 0xc024f2fc Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c024f2fc] skb_recycle_check+0x14/0x100 LR [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver] Call Trace: [df857d50] [c000b03c] __ipipe_grab_irq+0x3c/0xa4 (unreliable) [df857d60] [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver] [df857dd0] [c0258cf8] net_rx_action+0xf8/0x1b8 [df857e10] [c0032a38] __do_softirq+0xb8/0x13c [df857e60] [c00065cc] do_softirq+0xa0/0xac [...] This is because ucc_geth_tx() tries to process an empty queue when queues are logically stopped. Stopping the queues doesn't disable polling, and since nowadays ucc_geth_tx() is actually called from the polling routine, the oops above might pop up. Fix this by removing 'netif_queue_stopped() == 0' check. Reported-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Tested-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Cc: Stable <stable@vger.kernel.org> [2.6.32] Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Dec 26, 2009
-
-
Denis Kirjanov authored
Use DMA_BIT_MASK instead of plain values. Signed-off-by:
Denis Kirjanov <kirjanov@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jamal Hadi Salim authored
when using policy routing and the skb mark: there are cases where a back path validation requires us to use a different routing table for src ip validation than the one used for mapping ingress dst ip. One such a case is transparent proxying where we pretend to be the destination system and therefore the local table is used for incoming packets but possibly a main table would be used on outbound. Make the default behavior to allow the above and if users need to turn on the symmetry via sysctl src_valid_mark Signed-off-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Chan authored
When the device is reset during MTU change, ring size change, or self test, etc, the cnic status block needs to be properly initialized if cnic is registered. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
Eilon Greenstein <eilong@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Dec 24, 2009
-
-
John Fastabend authored
This updates pktgen so that it does not decrement skb->users when it receives valid NET_XMIT_xxx values. These are now valid return values from ndo_start_xmit in net-next-2.6. They also indicate the skb has been consumed. This fixes pktgen to work correctly with vlan devices. Signed-off-by:
John Fastabend <john.r.fastabend@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jarek Poplawski authored
There are BUGs "scheduling while atomic" triggered by the timer rhine_tx_timeout(). They are caused by calling napi_disable() (with msleep()). This patch fixes it by moving most of the timer content to the workqueue function (similarly to other drivers, like tg3), with spin_lock() changed to BH version. Additionally, there is spin_lock_irq() moved in rhine_close() to exclude napi_disable() etc., also tg3's way. Reported-by:
Andrey Rahmatullin <wrar@altlinux.org> Tested-by:
Andrey Rahmatullin <wrar@altlinux.org> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Don Skidmore authored
This patch adds a pci_save_state() call in ixgbe_resume() after pci_restore_state(). A similar change was made in ixgbe_io_slot_reset() that accommodates pci_restore_state() new behavior. This change makes pci_restore_state() clear the saved_state flag This is necessary due to a resent kernel change to pci_restore_state() so that it now clears the saved_state flag of the device right after the device.s standard configuration registers have been poplulated with the previously saved values. Signed-off-by:
Don Skidmore <donald.c.skidmore@intel.com> Acked-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sarveshwar Bandi authored
Changes to return correct values for transceiver and supported in ethtool get_settings function. Signed-off-by:
Sarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sarveshwar Bandi authored
NIC controller has to be set to an appropriate mode before doing a loopback test. Test will fail otherwise. Signed-off-by:
Sarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sarveshwar Bandi authored
This change ensures that loopback test command gives up after 4 seconds when the hardware is not responsive. This could happen if the ports are connected properly in loopback mode. Signed-off-by:
Sarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Williams, Mitch A authored
Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
The ethtool code for enabling Wake on Lan was not correctly checking the status register bits so as a result ports 0 and 2 were both being allowed to set WOL to enabled even though it is only supported on the first port for our adapters. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
The watermark values for the 82575 were not being set correctly. As a result the high and low watermark values were set to the same value which can lead to excess xon/xoff packets being generated. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
This change resolves an issue seen in some configurations where the link may drop to 100Mb/s even though the link itself supports 1000Mb/s. The issue was root caused to the fact that we were only trying the link once. Now instead we will try up to 5 attempts on a faulty cable before downshifting to 100Mb/s. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
We were forcing the PCS link up in error when we are in KX mode. We should only be disabling autoneg, not forcing the link up. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Hutchings authored
This hardware watchdog can misfire, so it does more harm than good. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Hutchings authored
Some cables have EEPROMs that conflict with the PHY's on-board EEPROM so it cannot load firmware. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Matthew Slattery authored
The PHY's firmware very occasionally appears to lock up very early, but with the heartbeat update still running. Rebooting the microcontroller core seems to be sufficient to recover. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Matthew Slattery authored
The PHY boots in a mode which is not necessarily optimal. This change switches it to self-configure mode (except when in loopback, which won't work in that mode if an SFP+ module is not present) by rebooting the PHY's microcontroller, and replicating the sequence of configuration writes from the boot EEPROM with the appropriate changes. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Matthew Slattery authored
If we see the PHY remaining stuck in a link-down state due to PCS being down while PMA/PMD is up, we briefly switch to PMA/PMD loopback and back, which usually unsticks it. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Neil Turton authored
We need buffer->len to remain valid to work out the correct address to be unmapped. We therefore need to clear buffer->len after the unmap operation. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Hutchings authored
The XGXS block may not get a link immediately in XGXS or XAUI loopback modes, so we still need to check it. Split falcon_xaui_link_ok() into falcon_xgxs_link_ok(), which checks only the Falcon XGXS block, and falcon_xmac_link_ok(), which checks one or both sides of the link as appropriate. Also rename falcon_check_xaui_link() to falcon_xmac_link_ok_retry(). Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Steve Hodgson authored
This prevents efx->link_advertising from being blatted during a reset. The phy_short_reach sysfs node is now destroyed later in the port shutdown process, so check for STATE_RUNNING after acquiring the rtnl_lock (just like in set_phy_flash_cfg). Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Dec 22, 2009
-
-
Benjamin Herrenschmidt authored
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>
-
Johannes Berg authored
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>
-
Johannes Berg authored
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>
-
Roel Kluin authored
`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>
-
Daniel Mack authored
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>
-
Andrew Morton authored
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>
-
Sujith authored
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>
-
Sujith authored
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>
-
Sujith authored
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>
-
Gertjan van Wingerde authored
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>
-
Reinette Chatre authored
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@intel.com> CC: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
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>
-
Reinette Chatre authored
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>
-
Reinette Chatre authored
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>
-
Johannes Berg authored
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@sipsolutions.net> Cc: stable@kernel.org Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
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@sipsolutions.net> Cc: stable@kernel.org Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>