- 18 Dec, 2009 40 commits
-
-
Vivek Natarajan authored
Upstream commit: 7c3f4bbe 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@atheros.com> Reviewed-by:
Kalle Valo <kalle.valo@nokia.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Felix Fietkau authored
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@openwrt.org> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
This is a backport of upstream commit: f4709fdf 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@atheros.com> Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com> Cc: Stephen Chen <stephen.chen@atheros.com> Cc: Shan Palanisamy <shan.palanisamy@atheros.com> Cc: Paul Shaw <paul.shaw@atheros.com> Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
This is a backport of upstream commit: e7824a50 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:
Vivek Natarajan <Vivek.Natarajan@atheros.com> Signed-off-by:
-
Sujith authored
This is a backport of upstream commit: 332c5566 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@atheros.com> Signed-off-by:
-
Johannes Berg authored
commit 811cb50b upstream. For some reason the export of the event print format to userspace uses '#fmt' which breaks if the format string is anything but a plain string, for example if it is built with macros then the macro names are exported instead of their contents. Use "\"%s\"", fmt instead of "%s", #fmt to export the string and not the way it is built. For example, in net/mac80211/driver-trace.h for the trace event drv_start there is: TP_printk( LOCAL_PR_FMT, LOCAL_PR_ARG ) Which use to produce: print fmt: LOCAL_PR_FMT, REC->wiphy_name Now produces: print fmt: "%s", REC->wiphy_name Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> LKML-Reference: <20091113224009.GB23942@elte.hu> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Larry Finger authored
commit 316a4d96 upstream. For PPC architecture with PHY Revision < 3, a read of the register B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43legacy_status() returns a value of 2 (B43legacy_STAT_STARTED); however, one finds that the driver is unable to associate after resuming from hibernation unless this routine returns 1. To satisfy both conditions, the routine is rewritten to return TRUE whenever b43legacy_status() returns a value < 2. This patch fixes the second problem listed in the postings for Red Hat Bugzilla #538523. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 7f5620a5 ] "ARCH" can be just about anything, so we shouldn't end up with UTS_MACHINE of "sparc" in a 64-bit kernel build just because someone set the personality using 'sparc32' or similar. CONFIG_SPARC64 drives the compilation and therefore provides the definitive value, not "ARCH". This mirrors commit 8c6531f7 (x86: correctly set UTS_MACHINE for "make ARCH=x86") Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 166e553a ] Commit 4f70f7a9 (sparc64: Implement IRQ stacks.) has two bugs. First, the softirq range check forgets to subtract STACK_BIAS before comparing with %sp. Next, on failure the wrong label is jumped to, resulting in a bogus stack being loaded. Reported-by:
Igor Kovalenko <igor.v.kovalenko@gmail.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 4230fa3b ] When we are trying to see if a range property entry applies to a given address, we are overly strict about the type. We should only allow I/O ranges for I/O addresses, and only allow CONFIG space ranges for CONFIG space address. However for MEM ranges, they come in 32-bit and 64-bit flavors. And a lack of an exact match is OK if the range is 32-bit and the address is 64-bit. We can assign a 64-bit address properly into a 32-bit parent range just fine. So allow it. Reported-by:
Patrick Finnegan <pat@computer-refuge.org> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 08a036d5 ] IRQF_SHARED and IRQF_DISABLED don't mix. Signed-off-by:
-
Stanislav Brabec authored
[ Upstream commit: e0188829 ] 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:
-
Patrick McHardy authored
[ Upstream commit b2722b1c ] When a large packet gets reassembled by ip_defrag(), the head skb accounts for all the fragments in skb->truesize. If this packet is refragmented again, skb->truesize is not re-adjusted to reflect only the head size since its not owned by a socket. If the head fragment then gets recycled and reused for another received fragment, it might exceed the defragmentation limits due to its large truesize value. skb_recycle_check() explicitly checks for linear skbs, so any recycled skb should reflect its true size in skb->truesize. Change ip_fragment() to also adjust the truesize value of skbs not owned by a socket. Reported-and-tested-by:
Ben Menchaca <ben@bigfootnetworks.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Damian Lukowski authored
[ Upstream commit 07f29bc5 ] 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:
-
Bartlomiej Zolnierkiewicz authored
[ Upstream commit ee31527a ] Fix checking of the currently programmed UDMA mode. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Milan Broz authored
commit 542da317 upstream. The "wipe key" message is used to wipe the volume key from memory temporarily, for example when suspending to RAM. But the initialisation vector in ESSIV mode is calculated from the hashed volume key, so the wipe message should wipe this IV key too and reinitialise it when the volume key is reinstated. This patch adds an IV wipe method called from a wipe message callback. ESSIV is then reinitialised using the init function added by the last patch. Signed-off-by:
Milan Broz <mbroz@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Milan Broz authored
commit b95bf2d3 upstream. This patch separates the construction of IV from its initialisation. (For ESSIV it is a hash calculation based on volume key.) Constructor code now preallocates hash tfm and salt array and saves it in a private IV structure. The next patch requires this to reinitialise the wiped IV without reallocating memory when resuming a suspended device. Signed-off-by:
-
Mikulas Patocka authored
commit 8e87b9b8 upstream. Under some special conditions the snapshot hash_size is calculated as zero. This patch instead sets a minimum value of 64, the same as for the pending exception table. rounddown_pow_of_two(0) is an undefined operation (it expands to shift by -1). init_exception_table with an argument of 0 would fail with -ENOMEM. The way to trigger the problem is to create a snapshot with a chunk size that is larger than the origin device. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 6076905b upstream. Fix a reported deadlock if there are still unprocessed multipath events on a device that is being removed. _hash_lock is held during dev_remove while trying to send the outstanding events. Sending the events requests the _hash_lock again in dm_copy_name_and_uuid. This patch introduces a separate lock around regions that modify the link to the hash table (dm_set_mdptr) or the name or uuid so that dm_copy_name_and_uuid no longer needs _hash_lock. Additionally, dm_copy_name_and_uuid can only be called if md exists so we can drop the dm_get() and dm_put() which can lead to a BUG() while md is being freed. The deadlock: #0 [ffff8106298dfb48] schedule at ffffffff80063035 #1 [ffff8106298dfc20] __down_read at ffffffff8006475d #2 [ffff8106298dfc60] dm_copy_name_and_uuid at ffffffff8824f740 #3 [ffff8106298dfc90] dm_send_uevents at ffffffff88252685 #4 [ffff8106298dfcd0] event_callback at ffffffff8824c678 #5 [ffff8106298dfd00] dm_table_event at ffffffff8824dd01 #6 [ffff8106298dfd10] __hash_remove at ffffffff882507ad #7 [ffff8106298dfd30] dev_remove at ffffffff88250865 #8 [ffff8106298dfd60] ctl_ioctl at ffffffff88250d80 #9 [ffff8106298dfee0] do_ioctl at ffffffff800418c4 #10 [ffff8106298dff00] vfs_ioctl at ffffffff8002fab9 #11 [ffff8106298dff40] sys_ioctl at ffffffff8004bdaf #12 [ffff8106298dff80] tracesys at ffffffff8005d28d (via system_call) Reported-by:
guy keren <choo@actcom.co.il> Signed-off-by:
-
Milan Broz authored
commit 5861f1be upstream. Use kzfree for salt deallocation because it is derived from the volume key. Use a common error path in ESSIV constructor. Required by a later patch which fixes the way key material is wiped from memory. Signed-off-by:
-
Milan Broz authored
commit 60473592 upstream. Define private structures for IV so it's easy to add further attributes in a following patch which fixes the way key material is wiped from memory. Also move ESSIV destructor and remove unnecessary 'status' operation. There are no functional changes in this patch. Signed-off-by:
-
Mikulas Patocka authored
commit 94e76572 upstream. Take snapshot lock only for STATUSTYPE_INFO, not STATUSTYPE_TABLE. Commit 4c6fff44 (dm-snapshot-lock-snapshot-while-supplying-status.patch) introduced this use of the lock, but userspace applications using libdevmapper have been found to request STATUSTYPE_TABLE while the device is suspended and the lock is already held, leading to deadlock. Since the lock is not necessary in this case, don't try to take it. Signed-off-by:
-
Julia Lawall authored
commit 613978f8 upstream. Error handling code following a kmalloc should free the allocated data. Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Ian Campbell authored
commit bc2c0303 upstream. Currently if the balloon driver is unable to increase the guest's reservation it assumes the failure was due to reaching its full allocation, gives up on the ballooning operation and records the limit it reached as the "hard limit". The driver will not try again until the target is set again (even to the same value). However it is possible that ballooning has in fact failed due to memory pressure in the host and therefore it is desirable to keep attempting to reach the target in case memory becomes available. The most likely scenario is that some guests are ballooning down while others are ballooning up and therefore there is temporary memory pressure while things stabilise. You would not expect a well behaved toolstack to ask a domain to balloon to more than its allocation nor would you expect it to deliberately over-commit memory by setting balloon targets which exceed the total host memory. This patch drops the concept of a hard limit and causes the balloon driver to retry increasing the reservation on a timer in the same manner as when decreasing the reservation. Also if we partially succeed in increasing the reservation (i.e. receive less pages than we asked for) then we may as well keep those pages rather than returning them to Xen. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
-
Gianluca Guida authored
commit 3d65c948 upstream. Change totalram_pages when a single page is added/removed to the ballooned list. This avoid totalram_pages to be set erroneously to max_pfn at boot. Signed-off-by:
Gianluca Guida <gianluca.guida@citrix.com> Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Ian Campbell authored
commit b4606f21 upstream. I have observed cases where the implicit stop_machine_destroy() done by stop_machine() hangs while destroying the workqueues, specifically in kthread_stop(). This seems to be because timer ticks are not restarted until after stop_machine() returns. Fortunately stop_machine provides a facility to pre-create/post-destroy the workqueues so use this to ensure that workqueues are only destroyed after everything is really up and running again. I only actually observed this failure with 2.6.30. It seems that newer kernels are somehow more robust against doing kthread_stop() without timer interrupts (I tried some backports of some likely looking candidates but did not track down the commit which added this robustness). However this change seems like a reasonable belt&braces thing to do. Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 6aaf5d63 upstream. If Xen wants to return to a 32b usermode with sysret it must use the right form. When using VCGF_in_syscall to trigger this, it looks at the code segment and does a 32b sysret if it is FLAT_USER_CS32. However, this is different from __USER32_CS, so it fails to return properly if we use the normal Linux segment. So avoid the whole mess by dropping VCGF_in_syscall and simply use plain iret to return to usermode. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Ian Campbell authored
commit fed5ea87 upstream. On resume irq_info[*].evtchn is reset to 0 since event channel mappings are not preserved over suspend/resume. The other contents of irq_info is preserved to allow rebind_evtchn_irq() to function. However when a device resumes it will try to unbind from the previous IRQ (e.g. blkfront goes blkfront_resume() -> blkif_free() -> unbind_from_irqhandler() -> unbind_from_irq()). This will fail due to the check for VALID_EVTCHN in unbind_from_irq() and the IRQ is leaked. The device will then continue to resume and allocate a new IRQ, eventually leading to find_unbound_irq() panic()ing. Fix this by changing unbind_from_irq() to handle teardown of interrupts which have type!=IRQT_UNBOUND but are not currently bound to a specific event channel. Signed-off-by:
-
Ian Campbell authored
commit 65f63384 upstream. The existing error handling has a few issues: - If freeze_processes() fails it exits with shutting_down = SHUTDOWN_SUSPEND. - If dpm_suspend_noirq() fails it exits without resuming xenbus. - If stop_machine() fails it exits without resuming xenbus or calling dpm_resume_end(). - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not nested in the obvious way. Fix by ensuring each failure case goto's the correct label. Treat a failure of stop_machine() as a cancelled suspend in order to follow the correct resume path. Signed-off-by:
-
Ian Campbell authored
commit f6eafe36 upstream. tick_resume() is never called on secondary processors. Presumably this is because they are offlined for suspend on native and so this is normally taken care of in the CPU onlining path. Under Xen we keep all CPUs online over a suspend. This patch papers over the issue for me but I will investigate a more generic, less hacky, way of doing to the same. tick_suspend is also only called on the boot CPU which I presume should be fixed too. Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 499d19b8 upstream. printk timestamping uses sched_clock, which in turn relies on runstate info under Xen. So make sure we set it up before any printks can be called. Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 922cc38a upstream. dpm_resume_noirq() takes a mutex, so it can't be called from a no-interrupt context. Don't call it from within the stop-machine function, but just afterwards, since we're resuming anyway, regardless of what happened. Signed-off-by:
-
Ian Campbell authored
commit 02889672 upstream. The commit "xen: re-register runstate area earlier on resume" caused us to never try and setup the runstate area for secondary CPUs. Ensure that we do this... Signed-off-by:
-
Ian Campbell authored
commit f350c792 upstream. Otherwise the timer is disabled by dpm_suspend_noirq() which in turn prevents correct operation of stop_machine on multi-processor systems and breaks suspend. Signed-off-by:
-
Ian Campbell authored
commit fa24ba62 upstream. pvops kernels >= 2.6.30 can currently only be saved and restored once. The second attempt to save results in: ERROR Internal error: Frame# in pfn-to-mfn frame list is not in pseudophys ERROR Internal error: entry 0: p2m_frame_list[0] is 0xf2c2c2c2, max 0x120000 ERROR Internal error: Failed to map/save the p2m frame list I finally narrowed it down to: commit cdaead6b Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Fri Feb 27 15:34:59 2009 -0800 xen: split construction of p2m mfn tables from registration Build the p2m_mfn_list_list early with the rest of the p2m table, but register it later when the real shared_info structure is in place. Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 3905bb2a upstream. Even if have_vcpu_info_placement is not set, we still need to set up the runstate area on each resumed vcpu. Signed-off-by:
-
Ian Campbell authored
commit be012920 upstream. This is necessary to ensure the runstate area is available to xen_sched_clock before any calls to printk which will require it in order to provide a timestamp. I chose to pull the xen_setup_runstate_info out of xen_time_init into the caller in order to maintain parity with calling xen_setup_runstate_info separately from calling xen_time_resume. Signed-off-by:
-
Jeremy Fitzhardinge authored
commit db05fed0 upstream. They don't need to be global, and may cause linker clashes. Signed-off-by:
-
Zhao Yakui authored
commit 652af9d7 upstream. Add the missing clonemask for display port on Ironlake. Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Chris Wilson authored
commit 5618ca6a upstream. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
