aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2009-08-28parisc: fix warning in traps.cGrant Grundler
On Tue, Aug 18, 2009 at 01:45:17PM -0400, John David Anglin wrote: > CC arch/parisc/kernel/traps.o > arch/parisc/kernel/traps.c: In function 'handle_interruption': > arch/parisc/kernel/traps.c:535:18: warning: operation on 'regs->iasq[0]' > may be undefined Yes - Line 535 should use both [0] and [1]. Reported-by: John David Anglin <dave@hiauly1.hia.nrc.ca> Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-28Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
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: Fix vSMP boot crash x86, xen: Initialize cx to suppress warning x86, xen: Suppress WP test on Xen
2009-08-26Merge branch 'merge' of ↵Linus Torvalds
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/ps3: Update ps3_defconfig powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
2009-08-27powerpc/ps3: Update ps3_defconfigGeoff Levand
Update ps3_defconfig. o Refresh for 2.6.31. o Remove MTD support. o Add more HID drivers. Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-08-27powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registrationGeert Uytterhoeven
On non-PS3, we get: | kernel BUG at drivers/rtc/rtc-ps3.c:36! because the rtc-ps3 platform device is registered unconditionally in a kernel with builtin support for PS3. Reported-by: Sachin Sant <sachinp@in.ibm.com> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Acked-by: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-08-26m68k,m68knommu: Wire up rt_tgsigqueueinfo and perf_counter_openGeert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer <gerg@uclinux.org>
2009-08-26m68k: Fix redefinition of pgprot_noncachedAlexey Dobriyan
arch/m68k/include/asm/pgtable_mm.h:148:1: warning: "pgprot_noncached" redefined In file included from arch/m68k/include/asm/pgtable_mm.h:138, from arch/m68k/include/asm/pgtable.h:4, from include/linux/mm.h:40, from include/linux/pagemap.h:7, from include/linux/blkdev.h:12, from arch/m68k/emu/nfblock.c:17: include/asm-generic/pgtable.h:133:1: warning: this is the location of the previous definition pgprot_noncached() should be defined _before_ including asm-generic/pgtable.h Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2009-08-26arch/m68k/include/asm/motorola_pgalloc.h: fix kunmap argAndrew Morton
arch/m68k/include/asm/motorola_pgalloc.h: In function 'pte_alloc_one': arch/m68k/include/asm/motorola_pgalloc.h:44: warning: passing argument 1 of 'kunmap' from incompatible pointer type Also, remove unneeded test for kmap() failure. Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2009-08-26m68k: cnt reaches -1, not 0Roel Kluin
With the postfix decrement cnt reaches -1 rather than 0. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2009-08-26x86: Fix vSMP boot crashYinghai Lu
2.6.31-rc7 does not boot on vSMP systems: [ 8.501108] CPU31: Thermal monitoring enabled (TM1) [ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8 [ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping 04 [ 8.710324] Brought up 32 CPUs [ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS). [ 8.721489] ERROR: parent span is not a superset of domain->span [ 8.727686] ERROR: domain->groups does not contain CPU0 [ 8.733091] ERROR: groups don't span domain->span [ 8.737975] ERROR: domain->cpu_power not set [ 8.742416] Ravikiran Thirumalai bisected it to: | commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c | x86: don't call read_apic_id if !cpu_has_apic The problem is that on vSMP systems the CPUID derived initial-APICIDs are overlapping - so we need to fall back on hard_smp_processor_id() which reads the local APIC. Both come from the hardware (influenced by firmware though) so it's a tough call which one to trust. Doing the quirk expresses the vSMP property properly and also does not affect other systems, so we go for this solution instead of a revert. Reported-and-Tested-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Shai Fultheim <shai@scalex86.org> Cc: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <4A944D3C.5030100@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sparc64: Validate linear D-TLB misses. sparc64: Update defconfig. sparc32: Update defconfig. sparc32: Kill trap table freeing code. sparc: sys32.S incorrect compat-layer splice() system call sparc: Use page_fault_out_of_memory() for VM_FAULT_OOM. sparc64: Sign extend length arg to truncate syscalls when compat. sparc: Fix cleanup crash in bbc_envctrl_cleanup()
2009-08-25x86, xen: Initialize cx to suppress warningH. Peter Anvin
Initialize cx before calling xen_cpuid(), in order to suppress the "may be used uninitialized in this function" warning. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
2009-08-25x86, xen: Suppress WP test on XenJeremy Fitzhardinge
Xen always runs on CPUs which properly support WP enforcement in privileged mode, so there's no need to test for it. This also works around a crash reported by Arnd Hannemann, though I think its just a band-aid for that case. Reported-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-08-25sparc64: Validate linear D-TLB misses.David S. Miller
When page alloc debugging is not enabled, we essentially accept any virtual address for linear kernel TLB misses. But with kgdb, kernel address probing, and other facilities we can try to access arbitrary crap. So, make sure the address we miss on will translate to physical memory that actually exists. In order to make this work we have to embed the valid address bitmap into the kernel image. And in order to make that less expensive we make an adjustment, in that the max physical memory address is decreased to "1 << 41", even on the chips that support a 42-bit physical address space. We can do this because bit 41 indicates "I/O space" and thus covers non-memory ranges. The result of this is that: 1) kpte_linear_bitmap shrinks from 2K to 1K in size 2) we need 64K more for the valid address bitmap We can't let the valid address bitmap be dynamically allocated once we start using it to validate TLB misses, otherwise we have crazy issues to deal with wrt. recursive TLB misses and such. If we're in a TLB miss it could be the deepest trap level that's legal inside of the cpu. So if we TLB miss referencing the bitmap, the cpu will be out of trap levels and enter RED state. To guard against out-of-range accesses to the bitmap, we have to check to make sure no bits in the physical address above bit 40 are set. We could export and use last_valid_pfn for this check, but that's just an unnecessary extra memory reference. On the plus side of all this, since we load all of these translations into the special 4MB mapping TSB, and we check the TSB first for TLB misses, there should be absolutely no real cost for these new checks in the TLB miss path. Reported-by: heyongli@gmail.com Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-25Merge branch 'timers-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: clockevent: Prevent dead lock on clockevents_lock timers: Drop write permission on /proc/timer_list
2009-08-25Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
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: Fix build with older binutils and consolidate linker script x86: Fix an incorrect argument of reserve_bootmem() x86: add vmlinux.lds to targets in arch/x86/boot/compressed/Makefile xen: rearrange things to fix stackprotector x86: make sure load_percpu_segment has no stackprotector i386: Fix section mismatches for init code with !HOTPLUG_CPU x86, pat: Allow ISA memory range uncacheable mapping requests
2009-08-25x86: Fix build with older binutils and consolidate linker scriptJan Beulich
binutils prior to 2.17 can't deal with the currently possible situation of a new segment following the per-CPU segment, but that new segment being empty - objcopy misplaces the .bss (and perhaps also the .brk) sections outside of any segment. However, the current ordering of sections really just appears to be the effect of cumulative unrelated changes; re-ordering things allows to easily guarantee that the segment following the per-CPU one is non-empty, and at once eliminates the need for the bogus data.init2 segment. Once touching this code, also use the various data section helper macros from include/asm-generic/vmlinux.lds.h. -v2: fix !SMP builds. Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: <sam@ravnborg.org> LKML-Reference: <4A94085D02000078000119A5@vpn.id2.novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-24Merge branch 'fixes' of git://git.marvell.com/orionLinus Torvalds
* 'fixes' of git://git.marvell.com/orion: [ARM] Orion NAND: Make asm volatile avoid GCC pushing ldrd out of the loop [ARM] Kirkwood: enable eSATA on QNAP TS-219P [ARM] Kirkwood: __init requires linux/init.h
2009-08-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6Linus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6: favr32: improve touchscreen response avr32/lib: fix unaligned memcpy where len < 4 avr32/lib: fix unaligned memcpy()
2009-08-24x86: Fix an incorrect argument of reserve_bootmem()Amerigo Wang
This line looks suspicious, because if this is true, then the 'flags' parameter of function reserve_bootmem_generic() will be unused when !CONFIG_NUMA. I don't think this is what we want. Signed-off-by: WANG Cong <amwang@redhat.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: akpm@linux-foundation.org LKML-Reference: <20090821083709.5098.52505.sendpatchset@localhost.localdomain> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-24[ARM] Kirkwood: enable eSATA on QNAP TS-219PJohn Holland
Initialize PCI/PCIe on the QNAP TS-119, TS-219 and TS-219P hardware allowing the use of the discrete eSATA controller connected to the PCIe bus in the TS-219P. Signed-off-by: John Holland <john.holland@cellent-fs.de> Tested-by: Thomas Reitmayr <treitmayr@devbase.at> Signed-off-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-08-24[ARM] Kirkwood: __init requires linux/init.hMartin Michlmayr
Include linux/init.h for __init to fix this error: CC [M] drivers/net/wireless/wl12xx/boot.o In file included from arch/arm/mach-kirkwood/include/mach/gpio.h:13, from arch/arm/include/asm/gpio.h:5, from include/linux/gpio.h:7, from drivers/net/wireless/wl12xx/boot.c:24: arch/arm/plat-orion/include/plat/gpio.h:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘orion_gpio_init’ make[6]: *** [drivers/net/wireless/wl12xx/boot.o] Error 1 make[5]: *** [drivers/net/wireless/wl12xx] Error 2 Signed-off-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-08-23[S390] set preferred console based on conmodeHendrik Brueckner
setup_arch() unconditionally sets the preferred console to ttyS. This breaks the use of 3270 devices as the console. Provide a new function to set the default preferred console for s390. The preferred console depends on the conmode parameter that is used to switch between 3270 and 3215 terminal/console mode. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-08-21x86: don't call '->send_IPI_mask()' with an empty maskLinus Torvalds
As noted in 83d349f35e1ae72268c5104dbf9ab2ae635425d4 ("x86: don't send an IPI to the empty set of CPU's"), some APIC's will be very unhappy with an empty destination mask. That commit added a WARN_ON() for that case, and avoided the resulting problem, but didn't fix the underlying reason for why those empty mask cases happened. This fixes that, by checking the result of 'cpumask_andnot()' of the current CPU actually has any other CPU's left in the set of CPU's to be sent a TLB flush, and not calling down to the IPI code if the mask is empty. The reason this started happening at all is that we started passing just the CPU mask pointers around in commit 4595f9620 ("x86: change flush_tlb_others to take a const struct cpumask"), and when we did that, the cpumask was no longer thread-local. Before that commit, flush_tlb_mm() used to create it's own copy of 'mm->cpu_vm_mask' and pass that copy down to the low-level flush routines after having tested that it was not empty. But after changing it to just pass down the CPU mask pointer, the lower level TLB flush routines would now get a pointer to that 'mm->cpu_vm_mask', and that could still change - and become empty - after the test due to other CPU's having flushed their own TLB's. See http://bugzilla.kernel.org/show_bug.cgi?id=13933 for details. Tested-by: Thomas Björnell <thomas.bjornell@gmail.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-21x86: don't send an IPI to the empty set of CPU'sLinus Torvalds
The default_send_IPI_mask_logical() function uses the "flat" APIC mode to send an IPI to a set of CPU's at once, but if that set happens to be empty, some older local APIC's will apparently be rather unhappy. So just warn if a caller gives us an empty mask, and ignore it. This fixes a regression in 2.6.30.x, due to commit 4595f9620 ("x86: change flush_tlb_others to take a const struct cpumask"), documented here: http://bugzilla.kernel.org/show_bug.cgi?id=13933 which causes a silent lock-up. It only seems to happen on PPro, P2, P3 and Athlon XP cores. Most developers sadly (or not so sadly, if you're a developer..) have more modern CPU's. Also, on x86-64 we don't use the flat APIC mode, so it would never trigger there even if the APIC didn't like sending an empty IPI mask. Reported-by: Pavel Vilim <wylda@volny.cz> Reported-and-tested-by: Thomas Björnell <thomas.bjornell@gmail.com> Reported-and-tested-by: Martin Rogge <marogge@onlinehome.de> Cc: Mike Travis <travis@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-20x86: add vmlinux.lds to targets in arch/x86/boot/compressed/MakefileJan Beulich
The absence of vmlinux.lds here keeps .vmlinux.lds.cmd from being included, which in turn leads to it and all its dependents always getting rebuilt independent of whether they are already up-to-date. Signed-off-by: Jan Beulich <jbeulich@novell.com> LKML-Reference: <4A8D84670200007800010D31@vpn.id2.novell.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-08-20Merge branch 'bugfix' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen into x86/urgent
2009-08-19xen: rearrange things to fix stackprotectorJeremy Fitzhardinge
Make sure the stack-protector segment registers are properly set up before calling any functions which may have stack-protection compiled into them. [ Impact: prevent Xen early-boot crash when stack-protector is enabled ] Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
2009-08-19x86: make sure load_percpu_segment has no stackprotectorJeremy Fitzhardinge
load_percpu_segment() is used to set up the per-cpu segment registers, which are also used for -fstack-protector. Make sure that the load_percpu_segment() function doesn't have stackprotector enabled. [ Impact: allow percpu setup before calling stack-protected functions ] Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
2009-08-19Merge branch 'next' of git://git.monstr.eu/linux-2.6-microblazeLinus Torvalds
* 'next' of git://git.monstr.eu/linux-2.6-microblaze: microblaze: Update Microblaze defconfigs microblaze: Use klimit instead of _end for memory init microblaze: Enable ppoll syscall microblaze: Sane handling of missing timer/intc in device tree microblaze: use the generic ack_bad_irq implementation
2009-08-19clockevent: Prevent dead lock on clockevents_lockSuresh Siddha
Currently clockevents_notify() is called with interrupts enabled at some places and interrupts disabled at some other places. This results in a deadlock in this scenario. cpu A holds clockevents_lock in clockevents_notify() with irqs enabled cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled cpu C doing set_mtrr() which will try to rendezvous of all the cpus. This will result in C and A come to the rendezvous point and waiting for B. B is stuck forever waiting for the spinlock and thus not reaching the rendezvous point. Fix the clockevents code so that clockevents_lock is taken with interrupts disabled and thus avoid the above deadlock. Also call lapic_timer_propagate_broadcast() on the destination cpu so that we avoid calling smp_call_function() in the clockevents notifier chain. This issue left us wondering if we need to change the MTRR rendezvous logic to use stop machine logic (instead of smp_call_function) or add a check in spinlock debug code to see if there are other spinlocks which gets taken under both interrupts enabled/disabled conditions. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com> Cc: "Brown Len" <len.brown@intel.com> LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2009-08-18sparc64: Update defconfig.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-18sparc32: Update defconfig.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-18sparc32: Kill trap table freeing code.David S. Miller
Normally, srmmu uses different trap table register values to allow determination of the cpu we're on. All of the trap tables have identical content, they just sit at different offsets from the first trap table, and the offset shifted down and masked out determines the cpu we are on. The code tries to free them up when they aren't actually used (don't have all 4 cpus, we're on sun4d, etc.) but that causes problems. For one thing it triggers false positives in the DMA debugging code. And fixing that up while preserving this relative offset thing isn't trivial. So just kill the freeing code, it costs us at most 3 pages, big deal... Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-18sparc: sys32.S incorrect compat-layer splice() system callMathieu Desnoyers
I think arch/sparc/kernel/sys32.S has an incorrect splice definition: SIGN2(sys32_splice, sys_splice, %o0, %o1) The splice() prototype looks like : long splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags); So I think we should have : SIGN2(sys32_splice, sys_splice, %o0, %o2) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-18Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: percpu: use the right flag for get_vm_area() percpu, sparc64: fix sparse possible cpu map handling init: set nr_cpu_ids before setup_per_cpu_areas()
2009-08-18Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
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, mce: Don't initialize MCEs on unknown CPUs x86, mce: don't log boot MCEs on Pentium M (model == 13) CPUs x86: Annotate section mismatch warnings in kernel/apic/x2apic_uv_x.c x86, mce: therm_throt: Don't log redundant normality x86: Fix UV BAU destination subnode id
2009-08-18Merge branch 'sh/for-2.6.31' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 * 'sh/for-2.6.31' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: sh: sh7724 ddr self-refresh changes sh: use in-soc KEYSC on se7724 sh: CMT suspend/resume sh: skip disabled LCDC channels
2009-08-18i386: Fix section mismatches for init code with !HOTPLUG_CPUJan Beulich
Commit 0e83815be719d3391bf5ea24b7fe696c07dbd417 changed the section the initial_code variable gets allocated in, in an attempt to address a section conflict warning. This, however created a new section conflict when building without HOTPLUG_CPU. The apparently only (reasonable) way to address this is to always use __REFDATA. Once at it, also fix a second section mismatch when not using HOTPLUG_CPU. Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: Robert Richter <robert.richter@amd.com> LKML-Reference: <4A8AE7CD020000780001054B@vpn.id2.novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-18microblaze: Update Microblaze defconfigsMichal Simek
Signed-off-by: Michal Simek <monstr@monstr.eu>
2009-08-18microblaze: Use klimit instead of _end for memory initMichal Simek
For noMMU system when you use larger rootfs image there is problem with using _end label because we increase klimit but in memory initialization we use still _end which is wrong. Larger mtd rootfs was rewritten by init_bootmem_node. MMU kernel use static initialization where klimit is setup to _end. There is no any other hanling with klimit. Signed-off-by: Michal Simek <monstr@monstr.eu>
2009-08-18microblaze: Enable ppoll syscallMichal Simek
Signed-off-by: Michal Simek <monstr@monstr.eu>
2009-08-18microblaze: Sane handling of missing timer/intc in device treeJohn Williams
This code path doesn't test any returned pointers for NULL, leading to a bad kernel page fault if there's no timer/intc found. Slightly better is to BUG(), but even better still would be a printk beforehand. Signed-off-by: John Williams <john.williams@petalogix.com> Signed-off-by: Michal Simek <monstr@monstr.eu>
2009-08-18microblaze: use the generic ack_bad_irq implementationChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Michal Simek <monstr@monstr.eu>
2009-08-17x86, pat: Allow ISA memory range uncacheable mapping requestsSuresh Siddha
Max Vozeler reported: > Bug 13877 - bogl-term broken with CONFIG_X86_PAT=y, works with =n > > strace of bogl-term: > 814 mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) > = -1 EAGAIN (Resource temporarily unavailable) > 814 write(2, "bogl: mmaping /dev/fb0: Resource temporarily unavailable\n", > 57) = 57 PAT code maps the ISA memory range as WB in the PAT attribute, so that fixed range MTRR registers define the actual memory type (UC/WC/WT etc). But the upper level is_new_memtype_allowed() API checks are failing, as the request here is for UC and the return tracked type is WB (Tracked type is WB as MTRR type for this legacy range potentially will be different for each 4k page). Fix is_new_memtype_allowed() by always succeeding the ISA address range checks, as the null PAT (WB) and def MTRR fixed range register settings satisfy the memory type needs of the applications that map the ISA address range. Reported-and-Tested-by: Max Vozeler <xam@debian.org> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-08-17Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: MIPS: Fix HPAGE_SIZE redefinition
2009-08-17Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds
* master.kernel.org:/home/rmk/linux-2.6-arm: (37 commits) ARM: 5673/1: U300 fix initsection compile warning ARM: Fix broken highmem support mx31moboard: invert sdhc ro signal sense ARM: S3C24XX: Fix clkout mpx error ARM: S3C64XX: serial: Fix a typo in Kconfig IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changes OMAP3: RX51: Updated rx51_defconfig OMAP2/3: mmc-twl4030: Free up MMC regulators while cleaning up OMAP3: RX51: Define TWL4030 USB transceiver in board file OMAP3: Overo: Fix smsc911x platform device resource value OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after increasing vmalloc size OMAP2/3: DMA errata correction OMAP: Fix testing of cpu defines for mach-omap1 OMAP3: Overo: add missing pen-down GPIO definition OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask OMAP3: PM: Fix wrong sequence in suspend. OMAP: PM: CPUfreq: obey min/max settings of policy OMAP2/3/4: UART: allow in-order port traversal OMAP2/3/4: UART: Allow per-UART disabling wakeup for serial ports OMAP3: Fixed crash bug with serial + suspend ...
2009-08-17MIPS: Fix HPAGE_SIZE redefinitionAtsushi Nemoto
This patch fixes warnings like this: CC fs/proc/meminfo.o In file included from /work/linux/include/linux/mmzone.h:20, from /work/linux/include/linux/gfp.h:4, from /work/linux/include/linux/mm.h:8, from /work/linux/fs/proc/meminfo.c:5: /work/linux/arch/mips/include/asm/page.h:36:1: warning: "HPAGE_SIZE" redefined In file included from /work/linux/fs/proc/meminfo.c:2: /work/linux/include/linux/hugetlb.h:107:1: warning: this is the location of the previous definition Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Acked-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-08-17x86, mce: Don't initialize MCEs on unknown CPUsIngo Molnar
An older test-box started hanging at the following point during bootup: [ 0.022996] Mount-cache hash table entries: 512 [ 0.024996] Initializing cgroup subsys debug [ 0.025996] Initializing cgroup subsys cpuacct [ 0.026995] Initializing cgroup subsys devices [ 0.027995] Initializing cgroup subsys freezer [ 0.028995] mce: CPU supports 5 MCE banks I've bisected it down to commit 4efc0670 ("x86, mce: use 64bit machine check code on 32bit"), which utilizes the MCE code on 32-bit systems too. The problem is caused by this detail in my config: # CONFIG_CPU_SUP_INTEL is not set This disables the quirks in mce_cpu_quirks() but still enables MCE support - which then hangs due to the missing quirk workaround needed on this CPU: if (c->x86 == 6 && c->x86_model < 0x1A && banks > 0) mce_banks[0].init = 0; The safe solution is to not initialize MCEs if we dont know on what CPU we are running (or if that CPU's support code got disabled in the config). Also be a bit more defensive on 32-bit systems: dont do a boot-time dump of pending MCEs not just on the specific system that we found a problem with (Pentium-M), but earlier ones as well. Now this problem is probably not common and disabling CPU support is rare - but still being more defensive in something we turned on for a wide range of CPUs is prudent. Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> LKML-Reference: Message-ID: <4A88E3E4.40506@jp.fujitsu.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-17x86, mce: don't log boot MCEs on Pentium M (model == 13) CPUsBartlomiej Zolnierkiewicz
On my legacy Pentium M laptop (Acer Extensa 2900) I get bogus MCE on a cold boot with CONFIG_X86_NEW_MCE enabled, i.e. (after decoding it with mcelog): MCE 0 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 BANK 1 MCG status: MCi status: Error overflow Uncorrected error Error enabled Processor context corrupt MCA: Data CACHE Level-1 UNKNOWN Error STATUS f200000000000195 MCGSTATUS 0 [ The other STATUS values observed: f2000000000001b5 (... UNKNOWN error) and f200000000000115 (... READ Error). To verify that this is not a CONFIG_X86_NEW_MCE bug I also modified the CONFIG_X86_OLD_MCE code (which doesn't log any MCEs) to dump content of STATUS MSR before it is cleared during initialization. ] Since the bogus MCE results in a kernel taint (which in turn disables lockdep support) don't log boot MCEs on Pentium M (model == 13) CPUs by default ("mce=bootlog" boot parameter can be be used to get the old behavior). Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Reviewed-by: Andi Kleen <andi@firstfloor.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>