Becky Bruce [Thu, 14 May 2009 12:42:28 +0000 (12:42 +0000)]
powerpc: Add support for swiotlb on 32-bit
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most interesting bit is the
addition of addr_needs_map to dma_ops - we need this as
a dma_op because the decision of whether or not an addr
can be mapped by a device is device-specific.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Acked-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Commit 45db9240890d9343c934db1fe82d6e68ac2d28da ("powerpc/spufs: Remove
double check for non-negative dentry") removed the only user of the
out_dput label, so remove it and the code following it.
Gets rid of this warning:
arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_create':
arch/powerpc/platforms/cell/spufs/inode.c:647: warning: label 'out_dput' defined but not used
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Fix warning when printing a resource_size_t
resource_size_t is 64 bits on PowerPC 64.
Gets rid of this warning:
arch/powerpc/kernel/pci_64.c: In function 'pcibios_map_io_space':
arch/powerpc/kernel/pci_64.c:504: warning: format '%016lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/pseries: Fix warnings when printing resource_size_t
resource_size_t is 64 bits on pseries
Gets rid of these warnings:
arch/powerpc/platforms/pseries/iommu.c: In function 'pci_dma_bus_setup_pSeries':
arch/powerpc/platforms/pseries/iommu.c:391: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
arch/powerpc/platforms/pseries/iommu.c:417: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Shield code specific to 64-bit server processors
This is a random collection of added ifdef's around portions of
code that only mak sense on server processors. Using either
CONFIG_PPC_STD_MMU_64 or CONFIG_PPC_BOOK3S as seems appropriate.
This is meant to make the future merging of Book3E 64-bit support
easier.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This patch has no effect other than re-ordering PACA fields on
current server CPUs. It however is a pre-requisite for future
support of BookE 64-bit processors. Various parts of the PACA
struct are now moved under some ifdef's, either the new
CONFIG_PPC_BOOK3S or CONFIG_PPC_STD_MMU_64, whatever seems more
appropriate.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.craashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Split exception handling out of head_64.S
To prepare for future support of Book3E 64-bit PowerPC processors,
which use a completely different exception handling, we move that
code to a new exceptions-64s.S file.
This file is #included from head_64.S due to some of the absolute
address requirements which can currently only be fulfilled from
within that file.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This patch introduce a new Kconfig option, CONFIG_PPC_BOOK3S
that represents processors that are compliant with the "classic"
(aka "server") variant of the PowerPC architecture.
It replaces CONFIG_6xx on 32-bit (though the symbol is still
defined for compatibility) and encompass all currently supported
64-bit processors.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Currently, load_up_altivec and give_up_altivec are duplicated
in 32-bit and 64-bit. This creates a common implementation that
is moved away from head_32.S, head_64.S and misc_64.S and into
vector.S, using the same macros we already use for our common
implementation of load_up_fpu.
I also moved the VSX code over to vector.S though in that case
I didn't make it build on 32-bit (yet).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Set init_bootmem_done on NUMA platforms as well
For some obscure reason, we only set init_bootmem_done after initializing
bootmem when NUMA isn't enabled. We even document this next to the declaration
of that global in system.h which of course I didn't read before I had to
debug why some WIP code wasn't working properly...
This patch changes it so that we always set it after bootmem is initialized
which should have always been the case... go figure !
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/mm: Fix a AB->BA deadlock scenario with nohash MMU context lock
The MMU context_lock can be taken from switch_mm() while the
rq->lock is held. The rq->lock can also be taken from interrupts,
thus if we get interrupted in destroy_context() with the context
lock held and that interrupt tries to take the rq->lock, there's
a possible deadlock scenario with another CPU having the rq->lock
and calling switch_mm() which takes our context lock.
The fix is to always ensure interrupts are off when taking our
context lock. The switch_mm() path is already good so this fixes
the destroy_context() path.
While at it, turn the context lock into a new style spinlock.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/mm: Fix some SMP issues with MMU context handling
This patch fixes a couple of issues that can happen as a result
of steal_context() dropping the context_lock when all possible
PIDs are ineligible for stealing (hopefully an extremely hard to
hit occurence).
This case exposes the possibility of a stale context_mm[] entry
to be seen since destroy_context() doesn't clear it and the free
map isn't re-tested. It also means steal_context() will not notice
a context freed while the lock was help, thus possibly trying to
steal a context when a free one was available.
This fixes it by always returning to the caller from steal_context
when it dropped the lock with a return value that causes the
caller to re-samble the number of free contexts, along with
properly clearing the context_mm[] array for destroyed contexts.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
John Linn [Sat, 6 Jun 2009 16:43:16 +0000 (10:43 -0600)]
fbdev: Add PLB support and cleanup DCR in xilinxfb driver.
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
Previously, the dcr interface was assumed to be used in mmio mode,
and the register space of the dcr interface was precomputed and stuffed
into the device tree. This driver now makes use of the new dcr
infrastructure to represent the dcr interface. This enables the dcr
interface to be connected directly to a native dcr interface in a clean
way.
Added compatibility for ml507 dvi core.
Signed-off-by: Suneel <suneelg@xilinx.com> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Signed-off-by: John Linn <john.linn@xilinx.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Stefan Roese [Tue, 7 Apr 2009 05:31:05 +0000 (05:31 +0000)]
powerpc/4xx: Sequoia: Enable NAND support
Now that the 4xx NAND driver is available again in arch/powerpc, let's
enable it on Sequoia. This patch also disables the early debug messages
(CONFIG_PPC_EARLY_DEBUG) in the Sequoia defconfig.
Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Josh Boyer [Tue, 31 Mar 2009 12:57:53 +0000 (08:57 -0400)]
powerpc/4xx: Disable PCI_LEGACY
The single board defconfig files were missed during the cleanup
of CONFIG_PCI_LEGACY in the multi-board config files. This
disables the option for the single board configs, as it isn't
used by anything for these boards.
powerpc/pci: Fix annotation of pcibios_claim_one_bus
It was __devinit, but it is also within a CONFIG_HOTPLUG guarded section
of code, so the __devinit does nothing but cause the following warning:
WARNING: vmlinux.o(.text+0x107a8): Section mismatch in reference from the function pcibios_finish_adding_to_bus() to the function .devinit.text:pcibios_claim_one_bus()
The function pcibios_finish_adding_to_bus() references
the function __devinit pcibios_claim_one_bus().
This is often because pcibios_finish_adding_to_bus lacks a __devinit
annotation or the annotation of pcibios_claim_one_bus is wrong.
It is also only (externally) used in arch/powerpc/kernel/of_platform.c
which cannot be built as a module so don't export it.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Nathan Fontenot [Wed, 27 May 2009 04:41:21 +0000 (04:41 +0000)]
powerpc: Display processor virtualization resource allocs in lparcfg
This patch updates the output from /proc/ppc64/lparcfg to display the
processor virtualization resource allocations for a shared processor
partition.
This information is already gathered via the h_get_ppp call, we just
have to make sure that the ibm,partition-performance-parameters-level
property is >= 1 to ensure that the information is valid.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Anton Blanchard [Mon, 25 May 2009 20:25:49 +0000 (20:25 +0000)]
powerpc: Convert RTAS event scan from kernel thread to workqueue
RTAS event scan has to run across all cpus. Right now we use a kernel
thread and set_cpus_allowed but in doing so we wake up the previous cpu
unnecessarily.
Michel Dänzer [Fri, 22 May 2009 10:59:10 +0000 (10:59 +0000)]
therm_adt746x: Always clear hardware bit which inverts fan speed range.
This bit would get enabled sometimes (probably after suspend/resume), so the
fan would run at full speed below the temperature thresholds, but slow down and
eventually stop if temperatures rose above the thresholds... not exactly what
you want.
Signed-off-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Linus Torvalds [Wed, 27 May 2009 17:58:23 +0000 (10:58 -0700)]
Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Fix up dma_alloc_coherent() on platforms without cache coherency.
powerpc: Minor cleanups of kernel virt address space definitions
powerpc: Move dma-noncoherent.c from arch/powerpc/lib to arch/powerpc/mm
Revert "powerpc: Rework dma-noncoherent to use generic vmalloc layer"
powerpc: Fix up dma_alloc_coherent() on platforms without cache coherency.
The implementation we just revived has issues, such as using a
Kconfig-defined virtual address area in kernel space that nothing
actually carves out (and thus will overlap whatever is there),
or having some dependencies on being self contained in a single
PTE page which adds unnecessary constraints on the kernel virtual
address space.
This fixes it by using more classic PTE accessors and automatically
locating the area for consistent memory, carving an appropriate hole
in the kernel virtual address space, leaving only the size of that
area as a Kconfig option. It also brings some dma-mask related fixes
from the ARM implementation which was almost identical initially but
grew its own fixes.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Minor cleanups of kernel virt address space definitions
Make FIXADDR_TOP a compile time constant and cleanup a
couple of definitions relative to the layout of the kernel
address space on ppc32. We also print out that layout at
boot time for debugging purposes.
This is a pre-requisite for properly fixing non-coherent
DMA allocactions.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Mike Frysinger [Tue, 26 May 2009 09:03:52 +0000 (05:03 -0400)]
Blackfin: fix strncmp.o build error
Fix some more fallout of the string changes:
CC arch/blackfin/lib/strncmp.o
In file included from include/linux/bitmap.h:9,
from include/linux/nodemask.h:90,
from include/linux/mmzone.h:17,
from include/linux/gfp.h:5,
from include/linux/kmod.h:23,
from include/linux/module.h:14,
from arch/blackfin/lib/strncmp.c:14:
include/linux/string.h: In function ‘strstarts’:
include/linux/string.h:132: error: implicit declaration of function ‘strncmp’
make[1]: *** [arch/blackfin/lib/strncmp.o] Error 1
Signed-off-by: Mike Frysinger <vapier@gentoo.org> CC: Rusty Russell <rusty@rustcorp.com.au>
Mike Frysinger [Mon, 18 May 2009 08:33:07 +0000 (04:33 -0400)]
MAINTAINERS: drop (subscribers-only) markings on Blackfin lists
All of the Blackfin lists are transparently moderated for non-subscribers.
i.e. there are no annoying notices and people get whitelisted after first
their posting.
While it was a good idea to try to use the mm/vmalloc.c allocator instead
of our own (in fact, ours is itself a dup on an old variant of the vmalloc
one), unfortunately, the approach is terminally busted since
dma_alloc_coherent() can be called at interrupt time or in atomic contexts
and there's little chances we'll make the code in mm/vmalloc.c cope with\ that :-(
Until we can get the generic code to forbid that idiocy and fix all
drivers abusing it, we pretty much have no choice but revert to
our custom virtual space allocator.
There's also a problem with SMP safety since freeing such mapping
would require an IPI which cannot be done at interrupt time.
However, right now, I don't think we support any platform that is
both SMP and has non-coherent DMA (don't laugh, I know such things
do exist !) so we can sort that out later.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
cap_bprm_set_creds() has to be called from security_bprm_set_creds().
TOMOYO forgot to call cap_bprm_set_creds() from tomoyo_bprm_set_creds()
and suid executables were not being working.
Make sure we call cap_bprm_set_creds() with TOMOYO, to set credentials
properly inside tomoyo_bprm_set_creds().
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <jmorris@namei.org>
Linus Torvalds [Tue, 26 May 2009 22:06:12 +0000 (15:06 -0700)]
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: avoid back to back on_each_cpu in cpa_flush_array
x86, relocs: ignore R_386_NONE in kernel relocation entries
Linus Torvalds [Tue, 26 May 2009 21:48:36 +0000 (14:48 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
drm/i915: Add support for VGA load detection (pre-945).
drm/i915: Use an I2C algo to do the flip to SDVO DDC bus.
drm/i915: Determine type before initialising connector
drm/i915: Return SDVO LVDS VBT mode if no EDID modes are detected.
drm/i915: Fetch SDVO LVDS mode lines from VBT, then reserve them
i915: support 8xx desktop cursors
drm/i915: allocate large pointer arrays with vmalloc
Linus Torvalds [Tue, 26 May 2009 19:15:35 +0000 (12:15 -0700)]
Merge branch 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6
* 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6:
NFSv4: Fix the case where NFSv4 renewal fails
nfs: fix build error in nfsroot with initconst
XPRTRDMA: fix client rpcrdma FRMR registration on mlx4 devices
Linus Torvalds [Tue, 26 May 2009 19:14:46 +0000 (12:14 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: hda - Add missing check of pin vref 50 and others in Realtek codecs
ALSA: hda - Add 5stack-no-fp model for STAC927x
ALSA: hda - Add forced codec-slots for ASUS W5Fm
Linus Torvalds [Tue, 26 May 2009 19:13:33 +0000 (12:13 -0700)]
Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] powernow-k8: determine exact CPU frequency for HW Pstates
[CPUFREQ] powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data
[CPUFREQ] fix timer teardown in ondemand governor
[CPUFREQ] fix timer teardown in conservative governor
[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call
[CPUFREQ] powernow-k7 build fix when ACPI=n
[CPUFREQ] add atom family to p4-clockmod
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (21 commits)
r8169: avoid losing MSI interrupts
tcp: tcp_vegas ssthresh bugfix
mac8390: fix regression caused during net_device_ops conversion
gianfar: fix BUG under load after introduction of skb recycling
wimax/i2400m: usb: fix device reset on autosuspend while not yet idle
RxRPC: Error handling for rxrpc_alloc_connection()
ipv4: Fix oops with FIB_TRIE
pktgen: do not access flows[] beyond its length
gigaset: beyond ARRAY_SIZE of iwb->data
IPv6: set RTPROT_KERNEL to initial route
net: fix rtable leak in net/ipv4/route.c
net: fix length computation in rt_check_expire()
wireless: beyond ARRAY_SIZE of intf->crypto_stats
iwlwifi: update 5000 ucode support to version 2 of API
cfg80211: fix race between core hint and driver's custom apply
airo: fix airo_get_encode{,ext} buffer overflow like I mean it...
ath5k: fix interpolation with equal power levels
iwlwifi: do not cancel delayed work inside spin_lock_irqsave
ath5k: fix exp off-by-one when computing OFDM delta slope
wext: verify buffer size for SIOCSIWENCODEEXT
...
Trond Myklebust [Tue, 26 May 2009 18:51:00 +0000 (14:51 -0400)]
NFSv4: Fix the case where NFSv4 renewal fails
If the asynchronous lease renewal fails (usually due to a soft timeout),
then we _must_ schedule state recovery in order to ensure that we don't
lose the lease unnecessarily or, if the lease is already lost, that we
recover the locking state promptly...
But the missing const causes popwerpc to fail with latest
updates to __initconst like this:
fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
The bug is only present with kbuild-next.
Following patch has been build tested.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Vu Pham [Tue, 26 May 2009 18:51:00 +0000 (14:51 -0400)]
XPRTRDMA: fix client rpcrdma FRMR registration on mlx4 devices
mlx4/connectX FRMR requires local write enable together with remote
rdma write enable. This fixes NFS/RDMA operation over the ConnectX
Infiniband HCA in the default memreg mode.
Signed-off-by: Vu Pham <vu@mellanox.com> Signed-off-by: Tom Talpey <tmtalpey@gmail.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Ma Ling [Tue, 26 May 2009 03:31:00 +0000 (11:31 +0800)]
drm/i915: Add support for VGA load detection (pre-945).
Two approaches for VGA detections: hot plug detection for 945G onwards
and load pipe detection for Pre-945G. Load pipe detection will get one free
pipe, set border color as red and blue, then check CRT status by
swf register. This is a sync-up with the 2D driver.
Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
Solution is to determine the frequency directly from Pstate MSRs instead
of using rounded values from ACPI table.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(updated changelog)
cpufreq fix timer teardown in ondemand governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Andrew Morton <akpm@linux-foundation.org> CC: gregkh@suse.de CC: stable@kernel.org CC: cpufreq@vger.kernel.org CC: Ingo Molnar <mingo@elte.hu> CC: rjw@sisk.pl CC: Ben Slusky <sluskyb@paranoiacs.org> Signed-off-by: Dave Jones <davej@redhat.com>
[CPUFREQ] fix timer teardown in conservative governor
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(re-send with updated changelog)
cpufreq fix timer teardown in conservative governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
The following patch applies to 2.6.30-rc2. Stable kernels have a similar
issue which should also be fixed, but the code changed between 2.6.29
and 2.6.30, so this patch only applies to 2.6.30-rc.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Andrew Morton <akpm@linux-foundation.org> CC: gregkh@suse.de CC: stable@kernel.org CC: cpufreq@vger.kernel.org CC: Ingo Molnar <mingo@elte.hu> CC: rjw@sisk.pl CC: Ben Slusky <sluskyb@paranoiacs.org> Signed-off-by: Dave Jones <davej@redhat.com>
[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
The patches linked above depend on the following patch to remove
circular locking dependency :
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
(the following issue was faced when using cancel_delayed_work_sync() in the
timer teardown (which fixes a race).
* KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
> Hi
>
> my box output following warnings.
> it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
>
> A: work -> do_dbs_timer() -> cpu_policy_rwsem
> B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
>
>
Hrm, I think it must be due to my attempt to fix the timer teardown race
in ondemand governor mixed with new locking behavior in 2.6.30-rc.
The rwlock seems to be taken around the whole call to
cpufreq_governor_dbs(), when it should be only taken around accesses to
the locked data, and especially *not* around the call to
dbs_timer_exit().
Reverting my fix attempt would put the teardown race back in place
(replacing the cancel_delayed_work_sync by cancel_delayed_work).
Instead, a proper fix would imply modifying this critical section :
cpufreq.c: __cpufreq_remove_dev()
...
if (cpufreq_driver->target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
unlock_policy_rwsem_write(cpu);
To make sure the __cpufreq_governor() callback is not called with rwsem
held. This would allow execution of cancel_delayed_work_sync() without
being nested within the rwsem.
Applies on top of the 2.6.30-rc5 tree.
Required to remove circular dep in teardown of both conservative and
ondemande governors so they can use cancel_delayed_work_sync().
CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
unneeded.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Greg KH <greg@kroah.com> CC: Ingo Molnar <mingo@elte.hu> CC: "Rafael J. Wysocki" <rjw@sisk.pl> CC: Ben Slusky <sluskyb@paranoiacs.org> CC: Chris Wright <chrisw@sous-sol.org> CC: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
Jarod Wilson [Fri, 6 Mar 2009 20:24:57 +0000 (20:24 +0000)]
[CPUFREQ] add atom family to p4-clockmod
Some atom procs don't do freq scaling (such as the atom 330 on my own
littlefalls2 board). By adding the atom family here, we at least get
the benefit of passive cooling in a thermal emergency. Not sure how
to see that its actually helping any, but the driver does bind and
claim its functioning on my atom 330.
Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Dave Jones <davej@redhat.com>
David Dillow [Fri, 22 May 2009 15:29:34 +0000 (15:29 +0000)]
r8169: avoid losing MSI interrupts
The 8169 chip only generates MSI interrupts when all enabled event
sources are quiescent and one or more sources transition to active. If
not all of the active events are acknowledged, or a new event becomes
active while the existing ones are cleared in the handler, we will not
see a new interrupt.
The current interrupt handler masks off the Rx and Tx events once the
NAPI handler has been scheduled, which opens a race window in which we
can get another Rx or Tx event and never ACK'ing it, stopping all
activity until the link is reset (ifconfig down/up). Fix this by always
ACK'ing all event sources, and loop in the handler until we have all
sources quiescent.
Signed-off-by: David Dillow <dave@thedillows.org> Tested-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Tejun Heo [Tue, 26 May 2009 05:42:40 +0000 (14:42 +0900)]
x86, relocs: ignore R_386_NONE in kernel relocation entries
For relocatable 32bit kernels, boot/compressed/relocs.c processes
relocation entries in the kernel image and appends it to the kernel
image such that boot/compressed/head_32.S can relocate the kernel.
The kernel image is one statically linked object and only uses two
relocation types - R_386_PC32 and R_386_32, of the two only the latter
needs massaging during kernel relocation and thus handled by relocs.
R_386_PC32 is ignored and all other relocation types are considered
error.
When the target of a relocation resides in a discarded section,
binutils doesn't throw away the relocation record but nullifies it by
changing it to R_386_NONE, which unfortunately makes relocs fail.
The problem was triggered by yet out-of-tree x86 stack unwind patches
but given the binutils behavior, ignoring R_386_NONE is the right
thing to do.
The problem has been tracked down to binutils behavior by Jan Beulich.
[ Impact: fix build with certain binutils by ignoring R_386_NONE ]
Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Jan Beulich <JBeulich@novell.com> Cc: Ingo Molnar <mingo@elte.hu>
LKML-Reference: <4A1B8150.40702@kernel.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Finn Thain [Tue, 26 May 2009 05:43:49 +0000 (22:43 -0700)]
mac8390: fix regression caused during net_device_ops conversion
Changeset ca17584bf2ad1b1e37a5c0e4386728cc5fc9dabc ("mac8390: update
to net_device_ops") broke mac8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in mac8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c. They seem to be of no value since
COMPAT_NET_DEV_OPS is going away soon.
Tested with a Kinetics EtherPort card.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Hideo Saito [Sun, 24 May 2009 15:33:34 +0000 (15:33 +0000)]
powerpc/mm: Fix broken MMU PID stealing on !SMP
The recent rework of the MMU PID handling for non-hash CPUs has a
subtle bug in the !SMP "optimized" variant of the PID stealing
function. It clears the PID in the mm context before it calls
local_flush_tlb_mm(). However, the later will not flush anything
if the PID in the context is clear...
Signed-off-by: Hideo Saito <hsaito.ppc@gmail.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
NeilBrown [Tue, 26 May 2009 02:57:21 +0000 (12:57 +1000)]
md: don't update curr_resync_completed without also updating reshape_position.
In order for the metadata to always be consistent, we mustn't updated
curr_resync_completed without also updating reshape_position.
The reshape code updates both at the same time. However since
commit 97e4f42d62badb0f9fbc27c013e89bc1336a03bc
the common md_do_sync will sometimes update curr_resync_completed
but is not in a position to update reshape_position.
So if MD_RECOVERY_RESHAPE is set (indicating that a reshape is
happening, so reshape_position might change), don't update
curr_resync_completed in md_do_sync, leave it to the per-personality
reshape code.
NeilBrown [Mon, 25 May 2009 23:41:17 +0000 (09:41 +1000)]
md: bitmap: improve bitmap maintenance code.
The code for checking which bits in the bitmap can be cleared
has 2 problems:
1/ it repeatedly takes and drops a spinlock, where it would make
more sense to just hold on to it most of the time.
2/ it doesn't make use of some opportunities to skip large sections
of the bitmap
This patch fixes those. It will only affect CPU consumption, not
correctness.
NeilBrown [Mon, 25 May 2009 23:41:17 +0000 (09:41 +1000)]
md: improve errno return when setting array_size
Instead of always returns EINVAL if anything goes wrong
when setting the array size, add the option of
E2BIG
if the size requested is too large. This makes it easier
for user-space to be sure what went wrong.
We previously didn't update these fields when writing the metadata
because they could never change. They can now, so we better write
them.
v0.90 metadata always updated these fields.
Linus Torvalds [Mon, 25 May 2009 22:51:27 +0000 (15:51 -0700)]
Merge branch 'kvm-updates/2.6.30' of git://git.kernel.org/pub/scm/virt/kvm/kvm
* 'kvm-updates/2.6.30' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: Fix PDPTR reloading on CR4 writes
KVM: Make paravirt tlb flush also reload the PAE PDPTRs
Linus Torvalds [Mon, 25 May 2009 22:50:32 +0000 (15:50 -0700)]
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: Remove remap percpu allocator for the time being
x86: cpa_flush_array wbinvd should be done on all CPUs
x86: bugfix wbinvd() model check instead of family check
x86: introduce noxsave boot parameter
x86, setup: revert ACPI 3 E820 extended attributes support
x86: DMI match for the Sony VGN-Z540N as it needs BIOS reboot
Avi Kivity [Sun, 24 May 2009 19:19:00 +0000 (22:19 +0300)]
KVM: Fix PDPTR reloading on CR4 writes
The processor is documented to reload the PDPTRs while in PAE mode if any
of the CR4 bits PSE, PGE, or PAE change. Linux relies on this
behaviour when zapping the low mappings of PAE kernels during boot.
The code already handled changes to CR4.PAE; augment it to also notice changes
to PSE and PGE.
This triggered while booting an F11 PAE kernel; the futex initialization code
runs before any CR3 reloads and writes to a NULL pointer; the futex subsystem
ended up uninitialized, killing PI futexes and pulseaudio which uses them.
Cc: stable@kernel.org Signed-off-by: Avi Kivity <avi@redhat.com>
Avi Kivity [Sun, 24 May 2009 19:15:25 +0000 (22:15 +0300)]
KVM: Make paravirt tlb flush also reload the PAE PDPTRs
The paravirt tlb flush may be used not only to flush TLBs, but also
to reload the four page-directory-pointer-table entries, as it is used
as a replacement for reloading CR3. Change the code to do the entire
CR3 reloading dance instead of simply flushing the TLB.
Cc: stable@kernel.org Signed-off-by: Avi Kivity <avi@redhat.com>
gianfar: fix BUG under load after introduction of skb recycling
Since commit 0fd56bb5be6455d0d42241e65aed057244665e5e ("gianfar:
Add support for skb recycling"), gianfar puts skbuffs that are in
the rx ring back onto the recycle list as-is in case there was a
receive error, but this breaks the following invariant: that all
skbuffs on the recycle list have skb->data = skb->head + NET_SKB_PAD.
The RXBUF_ALIGNMENT realignment done in gfar_new_skb() will be done
twice on skbuffs recycled in this way, causing there not to be enough
room in the skb anymore to receive a full packet, eventually leading
to an skb_over_panic from gfar_clean_rx_ring() -> skb_put().
Resetting the skb->data pointer to skb->head + NET_SKB_PAD before
putting the skb back onto the recycle list restores the mentioned
invariant, and should fix this issue.
Reported-by: Michael Guntsche <mike@it-loops.com> Tested-by: Michael Guntsche <mike@it-loops.com> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Takashi Iwai [Mon, 25 May 2009 06:06:02 +0000 (08:06 +0200)]
ALSA: hda - Add missing check of pin vref 50 and others in Realtek codecs
Some Realtek codecs like ALC861 seem to support only VREF50 while the
current driver assumes it's only VREF80. Check other VREF bits to set
the correct value.
Tejun Heo [Mon, 25 May 2009 03:01:59 +0000 (12:01 +0900)]
x86: Remove remap percpu allocator for the time being
Remap percpu allocator has subtle bug when combined with page
attribute changing. Remap percpu allocator aliases PMD pages for the
first chunk and as pageattr doesn't know about the alias it ends up
updating page attributes of the original mapping thus leaving the
alises in inconsistent state which might lead to subtle data
corruption. Please read the following threads for more information:
http://thread.gmane.org/gmane.linux.kernel/835783
The following is the proposed fix which teaches pageattr about percpu
aliases.
http://thread.gmane.org/gmane.linux.kernel/837157
However, the above changes are deemed too pervasive for upstream
inclusion for 2.6.30 release, so this patch essentially disables
the remap allocator for the time being.
James Bottomley [Sun, 24 May 2009 20:03:43 +0000 (13:03 -0700)]
async: make sure independent async domains can't accidentally entangle
The problem occurs when async_synchronize_full_domain() is called when
the async_pending list is not empty. This will cause lowest_running()
to return the cookie of the first entry on the async_pending list, which
might be nothing at all to do with the domain being asked for and thus
cause the domain synchronization to wait for an unrelated domain. This
can cause a deadlock if domain synchronization is used from one domain
to wait for another.
Fix by running over the async_pending list to see if any pending items
actually belong to our domain (and return their cookies if they do).
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
PM: Do not hold dpm_list_mtx while disabling/enabling nonboot CPUs
We shouldn't hold dpm_list_mtx while executing
[disable|enable]_nonboot_cpus(), because theoretically this may lead
to a deadlock as shown by the following example (provided by Johannes
Berg):
CPU 3 CPU 2 CPU 1
suspend/hibernate
something:
rtnl_lock() device_pm_lock()
-> mutex_lock(&dpm_list_mtx)
mutex_lock(&dpm_list_mtx)
linkwatch_work
-> rtnl_lock()
disable_nonboot_cpus()
-> flush CPU 3 workqueue
Fortunately, device drivers are supposed to stop any activities that
might lead to the registration of new device objects way before
disable_nonboot_cpus() is called, so it shouldn't be necessary to
hold dpm_list_mtx over the entire late part of device suspend and
early part of device resume.
Thus, during the late suspend and the early resume of devices acquire
dpm_list_mtx only when dpm_list is going to be traversed and release
it right after that.
This patch is reported to fix the regressions tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=13245.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Miles Lane <miles.lane@gmail.com> Tested-by: Ming Lei <tom.leiming@gmail.com>