* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
[IA64] fix siglock
Quoth Tony:
"I committed the fix for this last week prior to your -rc4 announcement
reminding us to give proper "Reported-by:" credit. This one should have
had:
Reported-by: Tony Ernst <tee@sgi.com>
and also
Much-useful-investigation-and-tracing-by: Hedi Berriche <hedi@sgi.com>
Much-useful-investigation-and-tracing-by: Petr Tesarik <ptesarik@novell.com>"
A real life genuine preemption leak..
Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'kvm-updates/2.6.36' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Perform hardware_enable in CPU_STARTING callback
KVM: i8259: fix migration
KVM: fix i8259 oops when no vcpus are online
KVM: x86 emulator: fix regression with cmpxchg8b on i386 hosts
* 'at91-fixes-for-linus' of git://github.com/at91linux/linux-2.6-at91:
AT91: at91sam9261ek: remove C99 comments but keep information
AT91: at91sam9261ek board: remove warnings related to use of SPI or SD/MMC
AT91: dm9000 initialization update
AT91: SAM9G45 - add a separate clock entry for every single TC block
AT91: clock: peripheral clocks can have other parent than mck
AT91: change dma resource index
The sd/mmc data structure is not used if SPI is selected. The configuration
of PIO on the board prevent from using both interfaces at the same time
(board dependent).
Remove the warnings at compilation time adding a preprocessor condition.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Add information in dm9000 mac/phy chip initialization:
- irq resource details
- platform data details
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
The slab.h header is required to use the kmalloc() family of functions.
Due to recent kernel changes, this header must be directly included by
code that calls into the memory allocator.
Without this patch, any code which includes this header fails to build.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* master.kernel.org:/home/rmk/linux-2.6-arm: (30 commits)
ARM: Update mach-types
ARM: Partially revert "Auto calculate ZRELADDR and provide option for exceptions"
ARM: Ensure PTE modifications via dma_alloc_coherent are visible
ARM: 6359/1: ep93xx: move clock initialization earlier
Revert "[ARM] pxa: remove now unnecessary dma_needs_bounce()"
ARM: 6352/1: perf: fix event validation
ARM: 6344/1: Mark CPU_32v6K as depended on CPU_V7
ARM: 6343/1: wire up fanotify and prlimit64 syscalls on ARM
ARM: 6330/1: perf: reword comments relating to perf_event_do_pending
ARM: pxa168fb: fix section mismatch
ARM: pxa: Make id const in pwm_probe()
ARM: pxa: fix CI_HSYNC and CI_VSYNC MFP defines for pxa300
ARM: pxa: remove __init from cpufreq_driver->init()
ARM: imx: set cache line size to 64 bytes for i.MX5
mx5/clock: fix clear bit fields issue in _clk_ccgr_disable function
mxc/tzic: add base address when accessing TZIC registers
ARM: mach-shmobile: ap4evb: fix write protect for SDHI1
ARM: mach-shmobile: ap4evb: modify FSI2 ID
ARM: mach-shmobile: do not enable the PLLC2 clock on init
ARM: mach-shmobile: Clock framework comment fix
...
When ia64 converted to using ticket locks, an inline implementation
of trylock/unlock in fsys.S was missed. This was not noticed because
in most circumstances it simply resulted in using the slow path because
the siglock was apparently not available (under old spinlock rules).
Problems occur when the ticket spinlock has value 0x0 (when first
initialised, or when it wraps around). At this point the fsys.S
code acquires the lock (changing the 0x0 to 0x1. If another process
attempts to get the lock at this point, it will change the value from
0x1 to 0x2 (using new ticket lock rules). Then the fsys.S code will
free the lock using old spinlock rules by writing 0x0 to it. From
here a variety of bad things can happen.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Partially revert e69edc7, which introduced automatic zreladdr
support. The change in the way the manual definition is defined
seems to be error and conflict prone. Go back to the original way
we were handling this for the time being, while keeping the automatic
zreladdr facility.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Without this patch you will not be able to register the first block
because of the second association call on at91_add_device_tc().
Signed-off-by: Fabian Godehardt <fg@emlix.com>
[nicolas.ferre@atmel.com: change tcb1_clk to fake child clock of tcb0_clk]
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
While registering clock allow to set parent clock other
than mck. It is useful for clocks than can be seen as
child clock of a peripheral.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86, mcheck: Avoid duplicate sysfs links/files for thresholding banks
io-mapping: Fix the address space annotations
x86: Fix the address space annotations of iomap_atomic_prot_pfn()
x86, mm: Fix CONFIG_VMSPLIT_1G and 2G_OPT trampoline
x86, hwmon: Fix unsafe smp_processor_id() in thermal_throttle_add_dev
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
perf, x86: Try to handle unknown nmis with an enabled PMU
perf, x86: Fix handle_irq return values
perf, x86: Fix accidentally ack'ing a second event on intel perf counter
oprofile, x86: fix init_sysfs() function stub
lockup_detector: Sync touch_*_watchdog back to old semantics
tracing: Fix a race in function profile
oprofile, x86: fix init_sysfs error handling
perf_events: Fix time tracking for events with pid != -1 and cpu != -1
perf: Initialize callchains roots's childen hits
oprofile: fix crash when accessing freed task structs
Top of kvm_kpic_state structure should have the same memory layout as
kvm_pic_state since it is copied by memcpy.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
operand::val and operand::orig_val are 32-bit on i386, whereas cmpxchg8b
operands are 64-bit.
Fix by adding val64 and orig_val64 union members to struct operand, and
using them where needed.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Dave Hylands reports:
| We've observed a problem with dma_alloc_writecombine when the system
| is under heavy load (heavy bus traffic). We've managed to reduce the
| problem to the following snippet, which is run from a kthread in a
| continuous loop:
|
| void *virtAddr;
| dma_addr_t physAddr;
| unsigned int numBytes = 256;
|
| for (;;) {
| virtAddr = dma_alloc_writecombine(NULL,
| numBytes, &physAddr, GFP_KERNEL);
| if (virtAddr == NULL) {
| printk(KERN_ERR "Running out of memory\n");
| break;
| }
|
| /* access DMA memory allocated */
| tmp = virtAddr;
| *tmp = 0x77;
|
| /* free DMA memory */
| dma_free_writecombine(NULL,
| numBytes, virtAddr, physAddr);
|
| ...sleep here...
| }
|
| By itself, the code will run forever with no issues. However, as we
| increase our bus traffic (typically using DMA) then the *tmp = 0x77
| line will eventually cause a page fault. If we add a small delay (a
| few microseconds) before the *tmp = 0x77, then we don't see a page
| fault, even under heavy load.
A dsb() is required after modifying the PTE entries to ensure that they
will always be visible. Add this dsb().
Reported-by: Dave Hylands <dhylands@gmail.com>
Tested-by: Dave Hylands <dhylands@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 7cfe24947 ("ARM: AMBA: Add pclk support to AMBA bus
infrastructure") changed AMBA bus to handle the PCLK automatically.
However, in EP93xx clock initialization is arch_initcall which is done
later than AMBA device identification. This causes
amba_get_enable_pclk() to fail resulting device where UARTs are not
functional.
So change ep93xx_clock_init() to be postcore_initcall.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This reverts commit 4fa5518, which causes a compilation regression for
IXP4xx platforms.
Reported-by: Richard Cochran <richardcochran@gmail.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI: bus speed strings should be const
PCI hotplug: Fix build with CONFIG_ACPI unset
PCI: PCIe: Remove the port driver module exit routine
PCI: PCIe: Move PCIe PME code to the pcie directory
PCI: PCIe: Disable PCIe port services during port initialization
PCI: PCIe: Ask BIOS for control of all native services at once
ACPI/PCI: Negotiate _OSC control bits before requesting them
ACPI/PCI: Do not preserve _OSC control bits returned by a query
ACPI/PCI: Make acpi_pci_query_osc() return control bits
ACPI/PCI: Reorder checks in acpi_pci_osc_control_set()
PCI: PCIe: Introduce commad line switch for disabling port services
PCI: PCIe AER: Introduce pci_aer_available()
x86/PCI: only define pci_domain_nr if PCI and PCI_DOMAINS are set
PCI: provide stub pci_domain_nr function for !CONFIG_PCI configs
Recent changes to linker segments that hold per-cpu data broke linking
for m68knommu targets:
LD vmlinux
/usr/local/bin/m68k-uclinux-ld.real: error: no memory region specified for loadable section `.data..shared_aligned'
Add missing segments into the m68knommu linker script.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix missing consts in h8300's kernel_execve():
arch/h8300/kernel/sys_h8300.c: In function 'kernel_execve':
arch/h8300/kernel/sys_h8300.c:59: warning: initialization from incompatible pointer type
arch/h8300/kernel/sys_h8300.c:60: warning: initialization from incompatible pointer type
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix h8300's die() to take care of a number of problems:
CC arch/h8300/kernel/traps.o
In file included from arch/h8300/include/asm/bitops.h:10,
from include/linux/bitops.h:22,
from include/linux/kernel.h:17,
from include/linux/sched.h:54,
from arch/h8300/kernel/traps.c:18:
arch/h8300/include/asm/system.h:136: warning: 'struct pt_regs' declared inside parameter list
arch/h8300/include/asm/system.h:136: warning: its scope is only this definition or declaration, which is probably not what you want
arch/h8300/kernel/traps.c💯 error: conflicting types for 'die'
arch/h8300/include/asm/system.h:136: error: previous declaration of 'die' was here
make[2]: *** [arch/h8300/kernel/traps.o] Error 1
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix h8300's asm/atomic.h to store the IRQ flags in an unsigned long to deal
with warnings of the following type:
arch/h8300/include/asm/atomic.h: In function 'atomic_add_return':
arch/h8300/include/asm/atomic.h:22: warning: comparison of distinct pointer types lacks a cast
arch/h8300/include/asm/atomic.h:24: warning: comparison of distinct pointer types lacks a cast
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes the sparse warnings when the return pointer of
iomap_atomic_prot_pfn() is used as an argument of iowrite32()
and friends.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
LKML-Reference: <1283633804-11749-1-git-send-email-currojerez@riseup.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
When the PMU is enabled it is valid to have unhandled nmis, two
events could trigger 'simultaneously' raising two back-to-back
NMIs. If the first NMI handles both, the latter will be empty
and daze the CPU.
The solution to avoid an 'unknown nmi' massage in this case was
simply to stop the nmi handler chain when the PMU is enabled by
stating the nmi was handled. This has the drawback that a) we
can not detect unknown nmis anymore, and b) subsequent nmi
handlers are not called.
This patch addresses this. Now, we check this unknown NMI if it
could be a PMU back-to-back NMI. Otherwise we pass it and let
the kernel handle the unknown nmi.
This is a debug log:
cpu #6, nmi #32333, skip_nmi #32330, handled = 1, time = 1934364430
cpu #6, nmi #32334, skip_nmi #32330, handled = 1, time = 1934704616
cpu #6, nmi #32335, skip_nmi #32336, handled = 2, time = 1936032320
cpu #6, nmi #32336, skip_nmi #32336, handled = 0, time = 1936034139
cpu #6, nmi #32337, skip_nmi #32336, handled = 1, time = 1936120100
cpu #6, nmi #32338, skip_nmi #32336, handled = 1, time = 1936404607
cpu #6, nmi #32339, skip_nmi #32336, handled = 1, time = 1937983416
cpu #6, nmi #32340, skip_nmi #32341, handled = 2, time = 1938201032
cpu #6, nmi #32341, skip_nmi #32341, handled = 0, time = 1938202830
cpu #6, nmi #32342, skip_nmi #32341, handled = 1, time = 1938443743
cpu #6, nmi #32343, skip_nmi #32341, handled = 1, time = 1939956552
cpu #6, nmi #32344, skip_nmi #32341, handled = 1, time = 1940073224
cpu #6, nmi #32345, skip_nmi #32341, handled = 1, time = 1940485677
cpu #6, nmi #32346, skip_nmi #32347, handled = 2, time = 1941947772
cpu #6, nmi #32347, skip_nmi #32347, handled = 1, time = 1941949818
cpu #6, nmi #32348, skip_nmi #32347, handled = 0, time = 1941951591
Uhhuh. NMI received for unknown reason 00 on CPU 6.
Do you have a strange power saving mode enabled?
Dazed and confused, but trying to continue
Deltas:
nmi #32334 340186
nmi #32335 1327704
nmi #32336 1819 <<<< back-to-back nmi [1]
nmi #32337 85961
nmi #32338 284507
nmi #32339 1578809
nmi #32340 217616
nmi #32341 1798 <<<< back-to-back nmi [2]
nmi #32342 240913
nmi #32343 1512809
nmi #32344 116672
nmi #32345 412453
nmi #32346 1462095 <<<< 1st nmi (standard) handling 2 counters
nmi #32347 2046 <<<< 2nd nmi (back-to-back) handling one
counter nmi #32348 1773 <<<< 3rd nmi (back-to-back)
handling no counter! [3]
For back-to-back nmi detection there are the following rules:
The PMU nmi handler was handling more than one counter and no
counter was handled in the subsequent nmi (see [1] and [2]
above).
There is another case if there are two subsequent back-to-back
nmis [3]. The 2nd is detected as back-to-back because the first
handled more than one counter. If the second handles one counter
and the 3rd handles nothing, we drop the 3rd nmi because it
could be a back-to-back nmi.
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
[ renamed nmi variable to pmu_nmi to avoid clash with .nmi in entry.S ]
Signed-off-by: Don Zickus <dzickus@redhat.com>
Cc: peterz@infradead.org
Cc: gorcunov@gmail.com
Cc: fweisbec@gmail.com
Cc: ying.huang@intel.com
Cc: ming.m.lin@intel.com
Cc: eranian@google.com
LKML-Reference: <1283454469-1909-3-git-send-email-dzickus@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
During testing of a patch to stop having the perf subsytem
swallow nmis, it was uncovered that Nehalem boxes were randomly
getting unknown nmis when using the perf tool.
Moving the ack'ing of the PMI closer to when we get the status
allows the hardware to properly re-set the PMU bit signaling
another PMI was triggered during the processing of the first
PMI. This allows the new logic for dealing with the
shortcomings of multiple PMIs to handle the extra NMI by
'eat'ing it later.
Now one can wonder why are we getting a second PMI when we
disable all the PMUs in the begining of the NMI handler to
prevent such a case, for that I do not know. But I know the fix
below helps deal with this quirk.
Tested on multiple Nehalems where the problem was occuring.
With the patch, the code now loops a second time to handle the
second PMI (whereas before it was not).
Signed-off-by: Don Zickus <dzickus@redhat.com>
Cc: peterz@infradead.org
Cc: robert.richter@amd.com
Cc: gorcunov@gmail.com
Cc: fweisbec@gmail.com
Cc: ying.huang@intel.com
Cc: ming.m.lin@intel.com
Cc: eranian@google.com
LKML-Reference: <1283454469-1909-2-git-send-email-dzickus@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The validate_event function in the ARM perf events backend has the
following problems:
1.) Events that are disabled count towards the cost.
2.) Events associated with other PMUs [for example, software events or
breakpoints] do not count towards the cost, but do fail validation,
causing the group to fail.
This patch changes validate_event so that it ignores events in the
PERF_EVENT_STATE_OFF state or that are scheduled for other PMUs.
Reported-by: Pawel Moll <pawel.moll@arm.com>
Acked-by: Jamie Iles <jamie.iles@picochip.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
CPU_32v6K is selected by CPU_V7 but it only depends on CPU_V6.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The dlpar code can cause a deadlock to occur when making the RTAS
configure-connector call. This occurs because we make kmalloc calls,
which can block, while parsing the rtas_data_buf and holding the
rtas_data_buf_lock. This an cause issues if someone else attempts
to grab the rtas_data_bug_lock.
This patch alleviates this issue by copying the contents of the rtas_data_buf
to a local buffer before parsing. This allows us to only hold the
rtas_data_buf_lock around the RTAS configure-connector calls.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
fixes the warning:
.config:369:warning: symbol value '' invalid for ZRELADDR
and the prompt for ZRELADDR on make
Signed-off-by: Erik Gilling <konkers@android.com>
The use of the return value of init_sysfs() with commit
10f0412 oprofile, x86: fix init_sysfs error handling
discovered the following build error for !CONFIG_PM:
.../linux/arch/x86/oprofile/nmi_int.c: In function ‘op_nmi_init’:
.../linux/arch/x86/oprofile/nmi_int.c:784: error: expected expression before ‘do’
make[2]: *** [arch/x86/oprofile/nmi_int.o] Error 1
make[1]: *** [arch/x86/oprofile] Error 2
This patch fixes this.
Reported-by: Ingo Molnar <mingo@elte.hu>
Cc: stable@kernel.org
Signed-off-by: Robert Richter <robert.richter@amd.com>
When compiling alpha generic build get errors such as:
arch/alpha/kernel/err_marvel.c: In function ‘marvel_print_err_cyc’:
arch/alpha/kernel/err_marvel.c:119: error: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘u64’
Replaced a number of %ld format specifiers with %lld since u64
is unsigned long long.
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Signed-off-by: Matt Turner <mattst88@gmail.com>
The 2.6.36-rc kernel added three new system calls:
fanotify_init, fanotify_mark, and prlimit64. This patch
wires them up on ARM.
The only non-trivial issue here is the u64 argument to
sys_fanotify_mark(), but it is the 3rd argument and thus
passed in r2/r3 in both kernel and user space, so it causes
no problems.
Tested with a 2.6.36-rc2 EABI kernel on an ixp4xx machine.
Tested-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
