- Dec 29, 2009
-
-
Andrey Borzenkov authored
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>
-
- 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>
-
Gertjan van Wingerde authored
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. Cc: stable@kernel.org 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>
-
Julia Lawall authored
sizeof(iv16) and sizeof(iv32) are the sizes of pointers. Change them to the size of the copied data. Furthermore, iveiv_entry is a local structure that has just been initialized and is not visible outside this function. Thus, there would seem to be no point to copy data into it. The order of the arguments is thus changed to copy the data into the parameters, which are provided as pointers, suggesting in this case that they should be used to return values. A simplified version of the semantic patch that finds the first problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression *x; expression f; type T; @@ *f(...,(T)x,...) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Benoit Papillault authored
First, we copy/paste the padding stuff from ath9k_tx to ath_tx_cabq since it needs to same kind of padding, but for internally generated beacons. Next, software padding done on TX needs to be removed before calling ieee80211_tx_status. The code was already there in ath_tx_complete but it was wrong. Fix it by using ath9k_cmn_padpos. This later code has been tested by sending packets to a monitor interface and reading packets from the same interface. Signed-off-by:
Benoit PAPILLAULT <benoit.papillault@free.fr> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
When trigger event log dumping from debugfs, the entire event log should be dumped and the size should match the number of events being dump. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Reinette Chatre authored
Recent commits "iwlwifi: remove power-wasting calls to apm_ops.init()" and "iwlagn: power up device before initializing EEPROM" had the goal of reducing device power consumption from the time the module is loaded until the interface is brought up and the device's power saving mechanisms kick in. The idea is that once the module is loaded there is no need for the device to consume power until the interface is brought up. With the current solution the device is only powered up during EEPROM read, and then so also only if the EEPROM type is OTP. We have found that on certain platforms even non-OTP devices require power to be up during EEPROM read. On these platforms the driver never loads and the system log contains the following: iwlagn 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x080403D8 We thus now power up all devices during EEPROM read. Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
In iwlwifi, priv->alloc_rxb_page is used to keep track of the Rx pages allocated by the driver. This cleans up the page free routines by introducing __iwl_free_pages/iwl_free_pages so that the accounting is more accurate and less error prone. This also fixes two instances where the counter was not updated. Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- Dec 15, 2009
-
-
Gertjan van Wingerde authored
Add a definition of the amount of TX headroom reserved by mac80211 itself for its own purposes. Also add BUILD_BUG_ON to validate the value. This define can then be used by drivers to request additional TX headroom in the most efficient manner. Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
rt2800lib incorrectly detected whether RT2800USB was enabled because it didn't account for a modularized RT2800USB driver. 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>
-
- Dec 11, 2009
-
-
John W. Linville authored
Update "US" and "JP" for current rules, and replace "EU" rules with the world roaming domain (since it was only a pseudo-domain anyway). Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
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@cozybit.com> Signed-off-by:
Andrey Yurovsky <andrey@cozybit.com> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
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@cozybit.com> Signed-off-by:
Andrey Yurovsky <andrey@cozybit.com> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Julia Lawall authored
Memset should be given the size of the structure, not the size of the pointer. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ type T; T *x; expression E; @@ memset(x, E, sizeof( + * x)) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
As shown in Kernel Bugzilla #14761, doing a controller restart after a fatal DMA error does not accomplish anything other than consume the CPU on an affected system. Accordingly, substitute a meaningful message for the restart. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [2.6.32] Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Herton Ronaldo Krzesinski authored
Michael Buesch reports that his rtl8187 gives warnings on suspend ("queueing ieee80211 work while going to suspend" warnings), as rtl8187 can call ieee80211_queue_delayed_work after mac80211 is suspended. This change enhances rtl8187 led code so we can avoid queuing work after mac80211 is suspended: now we register a radio led and make additional checks to ensure led is off/on properly as mac80211 wants. Signed-off-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
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: stable@kernel.org Cc: jirislaby@gmail.com Cc: akpm@linux-foundation.org Cc: rjw@sisk.pl Cc: me@bobcopeland.com Cc: david.quan@atheros.com Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- Dec 10, 2009
-
-
John W. Linville authored
This part was missed in "cfg80211: implement get_wireless_stats", probably because sta_set_sinfo already existed and was only handling dBm signals. Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vivek Natarajan authored
When the current_bss is not set, 'iwconfig <iface> key off' does not clear the private flag. Hence after we connect with WEP to an AP and then try to connect with another non-WEP AP, it does not work. This issue will not be seen if supplicant is used. Signed-off-by:
Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- Dec 09, 2009
-
-
Anton Vorontsov authored
commit 46ceb60c ("gianfar: Add Multiple group Support") introduced the following build error with CONFIG_NET_POLL_CONTROLLER=y: CC ggianfar.o ggianfar.c: In function 'gfar_netpoll': ggianfar.c:2653: error: invalid storage class for function 'gfar_interrupt' ggianfar.c:2652: warning: ISO C90 forbids mixed declarations and code ggianfar.c:2681: error: invalid storage class for function 'adjust_link' ggianfar.c:2764: error: invalid storage class for function 'gfar_set_multi' ggianfar.c:2855: error: invalid storage class for function 'gfar_clear_exact_match' ggianfar.c:2877: error: invalid storage class for function 'gfar_set_hash_for_addr' ggianfar.c:2898: error: invalid storage class for function 'gfar_set_mac_for_addr' ggianfar.c:2922: error: invalid storage class for function 'gfar_error' ggianfar.c:3020: warning: ISO C90 forbids mixed declarations and code ggianfar.c:3032: error: invalid storage class for function 'gfar_init' ggianfar.c:3037: error: invalid storage class for function 'gfar_exit' ggianfar.c:3041: error: initializer element is not constant ggianfar.c:3042: error: initializer element is not constant ggianfar.c:3042: warning: ISO C90 forbids mixed declarations and code ggianfar.c:3042: error: expected declaration or statement at end of input make[1]: *** [ggianfar.o] Error 1 This patch fixes the issue. Reported-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Stanislav Brabec authored
About 50% of shutdowns of b44 Ethernet adapter ends by kernel panic with kernels compiled with stack-protector. Checking b44_magic_pattern() return values, one call of b44_magic_pattern() returns 127. It means, that set_bit(128, pmask) was called on line 1509. It means that bit 0 of 17th byte of pmask was overwritten. But pmask has only 16 bytes. Stack corruption happens. It seems that set_bit() on line 1509 always writes one bit off. The fix does not only solve the stack corruption, but also makes Wake On LAN working on my onboard B44 on Asus A7V-333X mainboard. It seems that this problem affects all kernel versions since commit 725ad800 ([PATCH] b44: add wol for old nic) on 2006-06-20. Signed-off-by:
Stanislav Brabec <sbrabec@suse.cz> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ilpo Järvinen authored
It can happen, that tcp_retransmit_skb fails due to some error. In such cases we might end up into a state where tp->retrans_out is zero but that's only because we removed the TCPCB_SACKED_RETRANS bit from a segment but couldn't retransmit it because of the error that happened. Therefore some assumptions that retrans_out checks are based do not necessarily hold, as there still can be an old retransmission but that is only visible in TCPCB_EVER_RETRANS bit. As retransmission happen in sequential order (except for some very rare corner cases), it's enough to check the head skb for that bit. Main reason for all this complexity is the fact that connection dying time now depends on the validity of the retrans_stamp, in particular, that successive retransmissions of a segment must not advance retrans_stamp under any conditions. It seems after quick thinking that this has relatively low impact as eventually TCP will go into CA_Loss and either use the existing check for !retrans_stamp case or send a retransmission successfully, setting a new base time for the dying timer (can happen only once). At worst, the dying time will be approximately the double of the intented time. In addition, tcp_packet_delayed() will return wrong result (has some cc aspects but due to rarity of these errors, it's hardly an issue). One of retrans_stamp clearing happens indirectly through first going into CA_Open state and then a later ACK lets the clearing to happen. Thus tcp_try_keep_open has to be modified too. Thanks to Damian Lukowski <damian@tvk.rwth-aachen.de> for hinting that this possibility exists (though the particular case discussed didn't after all have it happening but was just a debug patch artifact). Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Damian Lukowski authored
This patch moves retransmits_timed_out() from include/net/tcp.h to tcp_timer.c, where it is used. Reported-by:
Frederic Leroy <fredo@starox.org> Signed-off-by:
Damian Lukowski <damian@tvk.rwth-aachen.de> Acked-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Damian Lukowski authored
This patch fixes a problem in the TCP connection timeout calculation. Currently, timeout decisions are made on the basis of the current tcp_time_stamp and retrans_stamp, which is usually set at the first retransmission. However, if the retransmission fails in tcp_retransmit_skb(), retrans_stamp is not updated and remains zero. This leads to wrong decisions in retransmits_timed_out() if tcp_time_stamp is larger than the specified timeout, which is very likely. In this case, the TCP connection dies after the first attempted (and unsuccessful) retransmission. With this patch, tcp_skb_cb->when is used instead, when retrans_stamp is not available. This bug has been introduced together with retransmits_timed_out() in 2.6.32, as the number of retransmissions has been used for timeout decisions before. The corresponding commit was 6fa12c85 (Revert Backoff [v3]: Calculate TCP's connection close threshold as a time value.). Thanks to Ilpo Järvinen for code suggestions and Frederic Leroy for testing. Reported-by:
Frederic Leroy <fredo@starox.org> Signed-off-by:
Damian Lukowski <damian@tvk.rwth-aachen.de> Acked-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jie Yang authored
use common_task instead of reset_task and link_chg_task, so it fix "call cancel_work_sync from the work itself". Signed-off-by:
Jie Yang <jie.yang@atheros.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-