summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2009-01-18x86: fix RIP printout in early_idt_handlerJiri Slaby
commit 7aed55d1085f71241284a30af0300feea48c36db upstream. Impact: fix debug/crash printout Since errorcode is popped out, RIP is on the top of the stack. Use real RIP value instead of wrong CS. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18x86, cpa: dont use large pages for kernel identity mapping with DEBUG_PAGEALLOCSuresh Siddha
commit 0b8fdcbcd287a1fbe66817491e6149841ae25705 upstream. Don't use large pages for kernel identity mapping with DEBUG_PAGEALLOC. This will remove the need to split the large page for the allocated kernel page in the interrupt context. This will simplify cpa code(as we don't do the split any more from the interrupt context). cpa code simplication in the subsequent patches. Tested-by: Tony Battersby <tonyb@cybernetics.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: arjan@linux.intel.com Cc: venkatesh.pallipadi@intel.com Cc: jeremy@goop.org Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18x86: avoid theoretical vmalloc fault loopAndi Kleen
commit f313e12308f7c5ea645f18e759d104d088b18615 upstream. Ajith Kumar noticed: I was going through the vmalloc fault handling for x86_64 and am unclear about the following lines in the vmalloc_fault() function. pgd = pgd_offset(current->mm ?: &init_mm, address); pgd_ref = pgd_offset_k(address); Here the intention is to get the pgd corresponding to the current process and sync it up with the pgd in init_mm(obtained from pgd_offset_k). However, for kernel threads current->mm is NULL and hence pgd = pgd_offset(init_mm, address) = pgd_ref which means the fault handler returns without setting the pgd entry in the MM structure in the context of which the kernel thread has faulted. This could lead to never-ending faults and busy looping of kernel threads like pdflush. So, shouldn't the pgd = pgd_offset(current->mm ?: &init_mm, address); be pgd = pgd_offset(current->active_mm ?: &init_mm, address); We can use active_mm unconditionally because it should be always set. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18powerpc: Disable Collaborative Memory Manager for kdumpBrian King
commit 2218108e182fd8a6d9106077833ed7ad05fc8e75 upstream. When running Active Memory Sharing, the Collaborative Memory Manager (CMM) may mark some pages as "loaned" with the hypervisor. Periodically, the CMM will query the hypervisor for a loan request, which is a single signed value. When kexec'ing into a kdump kernel, the CMM driver in the kdump kernel is not aware of the pages the previous kernel had marked as "loaned", so the hypervisor and the CMM driver are out of sync. This results in the CMM driver getting a negative loan request, which can then get treated as a large unsigned value and can cause kdump to hang due to the CMM driver inflating too large. Since there really is no clean way for the CMM driver in the kdump kernel to clean this up, simply disable CMM in the kdump kernel. This fixes hangs we were seeing doing kdump with AMS. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18s390 specific system call wrappersHeiko Carstens
commit 26689452f5ca201add63b1b1ff0dbcf82d6885e7 upstream. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18s390: enable system call wrappersHeiko Carstens
commit ed6bb6194350dc6ae97a65dbf2d621a3dbe6bbe9 upstream. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18powerpc: Enable syscall wrappers for 64-bitBenjamin Herrenschmidt
commit ee6a093222549ac0c72cfd296c69fa5e7d6daa34 upstream. This enables the use of syscall wrappers to do proper sign extension for 64-bit programs. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18System call wrapper infrastructureHeiko Carstens
commit 1a94bc34768e463a93cb3751819709ab0ea80a01 upstream. From: Martin Schwidefsky <schwidefsky@de.ibm.com> By selecting HAVE_SYSCALL_WRAPPERS architectures can activate system call wrappers in order to sign extend system call arguments. All architectures where the ABI defines that the caller of a function has to perform sign extension probably need this. Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18Remove __attribute__((weak)) from sys_pipe/sys_pipe2Heiko Carstens
commit 1134723e96f6e2abcf8bfd7a2d1c96fcc323ef35 upstream. Remove __attribute__((weak)) from common code sys_pipe implemantation. IA64, ALPHA, SUPERH (32bit) and SPARC (32bit) have own implemantations with the same name. Just rename them. For sys_pipe2 there is no architecture specific implementation. Cc: Richard Henderson <rth@twiddle.net> Cc: David S. Miller <davem@davemloft.net> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18Rename old_readdir to sys_old_readdirHeiko Carstens
commit e55380edf68796d75bf41391a781c68ee678587d upstream. This way it matches the generic system call name convention. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18x86, UV: remove erroneous BAU initializationCliff Wickman
commit 46814dded1b972a07b1609d81632eef3009fbb10 upstream. Impact: fix crash on x86/UV UV is the SGI "UltraViolet" machine, which is x86_64 based. BAU is the "Broadcast Assist Unit", used for TLB shootdown in UV. This patch removes the allocation and initialization of an unused table. This table is left over from a development test mode. It is unused in the present code. And it was incorrectly initialized: 8 entries allocated but 17 initialized, causing slab corruption. This patch should go into 2.6.27 and 2.6.28 as well as the current tree. Diffed against 2.6.28 (linux-next, 12/30/08) Signed-off-by: Cliff Wickman <cpw@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18x86: fix incorrect __read_mostly on _boot_cpu_pdaRavikiran G Thirumalai
commit 26799a63110dcbe81291ea53178f6b4810d07424 upstream. The pda rework (commit 3461b0af025251bbc6b3d56c821c6ac2de6f7209) to remove static boot cpu pdas introduced a performance bug. _boot_cpu_pda is the actual pda used by the boot cpu and is definitely not "__read_mostly" and ended up polluting the read mostly section with writes. This bug caused regression of about 8-10% on certain syscall intensive workloads. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Acked-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-18x86: default to SWIOTLB=y on x86_64Joerg Roedel
commit a1afd01c175324656d0e8f1c82ea94b474953c04 upstream. Impact: fixes korg bugzilla 11980 A kernel for a 64bit x86 system should always contain the swiotlb code in case it is booted on a machine without any hardware IOMMU supported by the kernel and more than 4GB of RAM. This patch changes Kconfig to always compile swiotlb into the kernel for x86_64. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-14AMD IOMMU: fix wrong loop counter in free_pagetablesJoerg Roedel
Upstream commit 3cc3d84bffbd93bdb671ac7961b12cd98fbb9266 This fixes a bug which causes the driver to go in an endless loop if initialization fails and its resources are freed. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-14AMD IOMMU: initialize phys_addr correctly in iommu_page_mapJoerg Roedel
Upstream commit bb9d4ff80bc032d7961815c2ff5eaf458ae3adff Due to this bug mappings for devices requested by the ACPI table are incorrect. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-14AMD IOMMU: allocate rlookup_table with __GFP_ZEROJoerg Roedel
Upstream commit 83fd5cc6481c6b7fa8b45f8a7e0aa7120213430b This is pointer list and if we dereference an uninitialized pointer later this results in a kernel crash at boot. Happens typically after 3-5 hours of rebooting. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-14AMD IOMMU: reset command buffer pointers manuallyJoerg Roedel
Upstream commit cf558d25e5c9f70fa0279c9b7b8b4aed7cae9bd4 Under special circumstances the IOMMU does not reset the head and tail pointer of its command ringbuffer to zero when the command base is written. This causes the IOMMU to fetch random memory and executes it as an command. Since these commands are likely illegal IOMMU stops fetching further commands including IOTLB flushes. This leads to completion wait errors at boot and in some cases to data corruption and kernel crashes. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-14powerpc: Fix corruption error in rh_alloc_fixed()Guillaume Knispel
commit af4d3643864ee5fcba0c97d77a424fa0b0346f8e upstream. There is an error in rh_alloc_fixed() of the Remote Heap code: If there is at least one free block blk won't be NULL at the end of the search loop, so -ENOMEM won't be returned and the else branch of "if (bs == s || be == e)" will be taken, corrupting the management structures. Signed-off-by: Guillaume Knispel <gknispel@proformatique.com> Acked-by: Timur Tabi <timur@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-18x86 Fix VMI crash on boot in 2.6.28-rc8Zachary Amsden
commit ae8d04e2ecbb233926860e9ce145eac19c7835dc upstream. VMI initialiation can relocate the fixmap, causing early_ioremap to malfunction if it is initialized before the relocation. To fix this, VMI activation is split into two phases; the detection, which must happen before setting up ioremap, and the activation, which must happen after parsing early boot parameters. This fixes a crash on boot when VMI is enabled under VMware. Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-18AMD IOMMU: enable device isolation per defaultJoerg Roedel
commit 3ce1f93c6d53c3f91c3846cf66b018276c8ac2e7 upstream. Impact: makes device isolation the default for AMD IOMMU Some device drivers showed double-free bugs of DMA memory while testing them with AMD IOMMU. If all devices share the same protection domain this can lead to data corruption and data loss. Prevent this by putting each device into its own protection domain per default. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13powerpc: Use cpu_thread_in_core in smp_init for of_spin_mapMilton Miller
commit 6a75a6b8e85e92cc774d42a4e113c76c30b5a539 upstream. We used to assume that even numbered threads were the primary threads, ie those that would be listed and started as a cpu from open firmware. Replace a left over is even (% 2) check with a check for it being a primary thread and update the comments. Tested with a debug print on pseries, identical code found for cell. Signed-off-by: Milton Miller <miltonm@bga.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13powerpc/virtex5: Fix Virtex5 machine check handlingGrant Likely
commit 640d17d60e83401e10e66a0ab6e9e2d6350df656 upstream. The 440x5 core in the Virtex5 uses the 440A type machine check (ie, they have MCSRR0/MCSRR1). They thus need to call the appropriate fixup function to hook the right variant of the exception. Without this, all machine checks become fatal due to loss of context when entering the exception handler. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13uml: boot broken due to buffer overrunBalbir Singh
commit 361371201b60ffd686a694c848c1d5ad6061725f upstream. mconsole_init() passed 256 bytes as length in os_create_unix_socket, while the sizeof UNIX_PATH_MAX is 108. This patch fixes that problem and avoids a big overrun bug reported on UML bootup. sockaddr_un.sun_path is UNIX_PATH_MAX long which causes the problem. Reported-by: Vikas K Managutte <vikki.km@gmail.com> Reported-by: Sarvesh Kumar Lal Das <skldas@gmail.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi> Reviewed-by: WANG Cong <wangcong@zeuux.org> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13x86: remove debug code from arch_add_memory()Gary Hade
commit fe8b868eccb9f85a0e231e35f0abac5b39bac801 upstream. Impact: remove incorrect WARN_ON(1) Gets rid of dmesg spam created during physical memory hot-add which will very likely confuse users. The change removes what appears to be debugging code which I assume was unintentionally included in: x86: arch/x86/mm/init_64.c printk fixes commit 10f22dde556d1ed41d55355d1fb8ad495f9810c8 Signed-off-by: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13x86, memory hotplug: remove wrong -1 in calling init_memory_mapping()Shaohua Li
commit 60817c9b31ef7897d60bca2f384cbc316a3fdd8b upstream. Impact: fix crash with memory hotplug Shuahua Li found: | I just did some experiments on a desktop for memory hotplug and this bug | triggered a crash in my test. | | Yinghai's suggestion also fixed the bug. We don't need to round it, just remove that extra -1 Signed-off-by: Yinghai <yinghai@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13x86: HPET: convert WARN_ON to WARN_ON_ONCEMatt Fleming
commit 1de5b0854623d30d01d72cd4ea323eb5f39d1f16 upstream. It is possible to flood the console with call traces if the WARN_ON condition is true because of the frequency with which this function is called. Signed-off-by: Matt Fleming <mjf@gentoo.org> Cc: mingo@elte.hu Cc: venkatesh.pallipadi@intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13powerpc/mpic: Don't reset affinity for secondary MPIC on bootArnd Bergmann
commit cc353c30bbdb84f4317a6c149ebb11cde2232e40 upstream. Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens on a CPU other than the initial boot CPU. It turns out that this is the result of mpic_init trying to set affinity of each interrupt vector to the current boot CPU. As far as I can tell, the same problem is likely to exist on any secondary MPIC, because they have to deliver interrupts to the first output all the time. There are two potential solutions for this: either not set up affinity at all for secondary MPICs, or assume that a single CPU output is connected to the upstream interrupt controller and hardcode affinity to that per architecture. This patch implements the second approach, defaulting to the first output. Currently, all known secondary MPICs are routed to their upstream port using the first destination, so we hardcode that. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13sparc64: Sync FPU state in VIS emulation handler.Hong H. Pham
[ Upstream commit 410d2c8187ed969238ba98008c1d57307a56cfd8 ] Copy the FPU state to the task's thread_info->fpregs for the VIS emulation functions to access. Signed-off-by: Hong H. Pham <hong.pham@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13sparc64: Fix VIS emulation bugsJoseph Myers
[ Upstream commit 726c12f57d7e3ff43693d88e13b1ff02464c75d3 ] This patch fixes some bugs in VIS emulation that cause the GCC test failure FAIL: gcc.target/sparc/pdist-3.c execution test for both 32-bit and 64-bit testing on hardware lacking these instructions. The emulation code for the pdist instruction uses RS1(insn) for both source registers rs1 and rs2, which is obviously wrong and leads to the instruction doing nothing (the observed problem), and further inspection of the code shows that RS1 uses a shift of 24 and RD a shift of 25, which clearly cannot both be right; examining SPARC documentation indicates the correct shift for RS1 is 14. This patch fixes the bug if single-stepping over the affected instruction in the debugger, but not if the testcase is run standalone. For that, Wind River has another patch I hope they will send as a followup to this patch submission. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13sparc64: Fix bug in PTRACE_SETFPREGS64 handling.Chris Torek
[ Upstream commit 5769907ade8dda7002b304c03ef9e4ee5c1e0821 ] From: Chris Torek <chris.torek@windriver.com> >The SPARC64 kernel code for PTRACE_SETFPREGS64 appears to be an exact copy >of that for PTRACE_GETFPREGS64. This means that gdbserver and native >64-bit GDB cannot set floating-point registers. It looks like a simple typo. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13sparc64: Fix PCI resource mapping on sparc64Max Dmitrichenko
[ Upstream commit 145e1c0023585e0e8f6df22316308ec61c5066b2 ] There is a problem discovered in recent versions of ATI Mach64 driver in X.org on sparc64 architecture. In short, the driver fails to mmap MMIO aperture (PCI resource #2). I've found that kernel's __pci_mmap_make_offset() returns EINVAL. It checks whether user attempts to mmap more than the resource length, which is 0x1000 bytes in our case. But PAGE_SIZE on SPARC64 is 0x2000 and this is what actually is being mmaped. So __pci_mmap_make_offset() failed for this PCI resource. Signed-off-by: Max Dmitrichenko <dmitrmax@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13sparc64: Fix __copy_{to,from}_user_inatomic defines.Hugh Dickins
[ Upstream commit b270ee8a9fc9547eb781ce9ccd379450bcf9a204 ] Alexander Beregalov reports oops in __bzero() called from copy_from_user_fixup() called from iov_iter_copy_from_user_atomic(), when running dbench on tmpfs on sparc64: its __copy_from_user_inatomic and __copy_to_user_inatomic should be avoiding, not calling, the fixups. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-13sparc64: Fix offset calculation in compute_size()David S. Miller
[ Upstream commit b270ee8a9fc9547eb781ce9ccd379450bcf9a204 ] The fault address is somewhere inside of the buffer, not before it. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05powerpc/spufs: add a missing mutex_unlockKou Ishizaki
commit 6747c2ee8abf749e63fee8cd01a9ee293e6a4247 upstream. A mutex_unlock(&gang->aff_mutex) in spufs_create_context() is missing in case spufs_context_open() fails. As a result, spu_create syscall and spu_get_idle() may block. This patch adds the mutex_unlock. Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Acked-by: Andre Detsch <adetsch@br.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05powerpc/spufs: Fix spinning in spufs_ps_fault on signalJeremy Kerr
commit 606572634c3faa5b32a8fc430266e6e9d78d2179 upstream. Currently, we can end up in an infinite loop if we get a signal while the kernel has faulted in spufs_ps_fault. Eg: alarm(1); write(fd, some_spu_psmap_register_address, 4); - the write's copy_from_user will fault on the ps mapping, and signal_pending will be non-zero. Because returning from the fault handler will never clear TIF_SIGPENDING, so we'll just keep faulting, resulting in an unkillable process using 100% of CPU. This change returns VM_FAULT_SIGBUS if there's a fatal signal pending, letting us escape the loop. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05x86: call dmi-quirks for HP Laptops after early-quirks are executedAndreas Herrmann
commit 35af28219e684a36cc8b1ff456c370ce22be157d upstream. Impact: make warning message disappear - functionality unchanged Problems with bogus IRQ0 override of those laptops should be fixed with commits x86: SB600: skip IRQ0 override if it is not routed to INT2 of IOAPIC x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC that introduce early-quirks based on chipset configuration. For further information, see http://bugzilla.kernel.org/show_bug.cgi?id=11516 Instead of removing the related dmi-quirks completely we'd like to keep them for (at least) one kernel version -- to double-check whether the early-quirks really took effect. But the dmi-quirks need to be called after early-quirks are executed. With this patch calling sequence for dmi-quriks is changed as follows: acpi_boot_table_init() (dmi-quirks) ... early_quirks() (detect bogus IRQ0 override) ... acpi_boot_init() (late dmi-quirks and setup IO APIC) Note: Plan is to remove the "late dmi-quirks" with next kernel version. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05x86: SB600: skip ACPI IRQ0 override if it is not routed to INT2 of IOAPICAndreas Herrmann
commit 26adcfbf00e0726b4469070aa2f530dcf963f484 upstream. On some more HP laptops BIOS reports an IRQ0 override but the SB600 chipset is configured such that timer interrupts go to INT0 of IOAPIC. Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the timer override. http://bugzilla.kernel.org/show_bug.cgi?id=11715 http://bugzilla.kernel.org/show_bug.cgi?id=11516 Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05x86: Hibernate: Fix breakage on x86_32 with CONFIG_NUMA setRafael J. Wysocki
backport of commit 97a70e548bd97d5a46ae9d44f24aafcc013fd701 to the 2.6.27 kernel. The NUMA code on x86_32 creates special memory mapping that allows each node's pgdat to be located in this node's memory. For this purpose it allocates a memory area at the end of each node's memory and maps this area so that it is accessible with virtual addresses belonging to low memory. As a result, if there is high memory, these NUMA-allocated areas are physically located in high memory, although they are mapped to low memory addresses. Our hibernation code does not take that into account and for this reason hibernation fails on all x86_32 systems with CONFIG_NUMA=y and with high memory present. Fix this by adding a special mapping for the NUMA-allocated memory areas to the temporary page tables created during the last phase of resume. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05xen: do not reserve 2 pages of padding between hypervisor and fixmap.Ian Campbell
commit 5dc64a3442b98eaa0e3730c35fcf00cf962a93e7 upstream. When reserving space for the hypervisor the Xen paravirt backend adds an extra two pages (this was carried forward from the 2.6.18-xen tree which had them "for safety"). Depending on various CONFIG options this can cause the boot time fixmaps to span multiple PMDs which is not supported and triggers a WARN in early_ioremap_init(). This was exposed by 2216d199b1430d1c0affb1498a9ebdbd9c0de439 which moved the dmi table parsing earlier. x86: fix CONFIG_X86_RESERVE_LOW_64K=y The bad_bios_dmi_table() quirk never triggered because we do DMI setup too late. Move it a bit earlier. There is no real reason to reserve these two extra pages and the fixmap already incorporates FIX_HOLE which serves the same purpose. None of the other callers of reserve_top_address do this. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05CPUFREQ: powernow-k8: ignore out-of-range PstateStatus valueAndreas Herrmann
commit a266d9f1253a38ec2d5655ebcd6846298b0554f4 upstream. A workaround for AMD CPU family 11h erratum 311 might cause that the P-state Status Register shows a "current P-state" which is larger than the "current P-state limit" in P-state Current Limit Register. For the wrong P-state value there is no ACPI _PSS object defined and powernow-k8/cpufreq can't determine the proper CPU frequency for that state. As a consequence this can cause a panic during boot (potentially with all recent kernel versions -- at least I have reproduced it with various 2.6.27 kernels and with the current .28 series), as an example: powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82 processors (2 \ ) powernow-k8: 0 : pstate 0 (2200 MHz) powernow-k8: 1 : pstate 1 (1100 MHz) powernow-k8: 2 : pstate 2 (600 MHz) BUG: unable to handle kernel paging request at ffff88086e7528b8 IP: [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f PGD 202063 PUD 0 Oops: 0002 [#1] SMP last sysfs file: CPU 1 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.28-rc3-dirty #16 RIP: 0010:[<ffffffff80486361>] [<ffffffff80486361>] cpufreq_stats_update+0x4a/0\ f Synaptics claims to have extended capabilities, but I'm not able to read them.<6\ 6 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88006e7528c0 RDX: 00000000ffffffff RSI: ffff88006e54af00 RDI: ffffffff808f056c RBP: 00000000fffee697 R08: 0000000000000003 R09: ffff88006e73f080 R10: 0000000000000001 R11: 00000000002191c0 R12: ffff88006fb83c10 R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88006fb50740(0000) knlGS:0000000000000000 Unable to initialize Synaptics hardware. CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffff88086e7528b8 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88006fb82000, task ffff88006fb816d0) Stack: ffff88006e74da50 0000000000000000 ffff88006e54af00 ffffffff804863c7 ffff88006e74da50 0000000000000000 00000000ffffffff 0000000000000000 ffff88006fb83c10 ffffffff8024b46c ffffffff808f0560 ffff88006fb83c10 Call Trace: [<ffffffff804863c7>] ? cpufreq_stat_notifier_trans+0x51/0x83 [<ffffffff8024b46c>] ? notifier_call_chain+0x29/0x4c [<ffffffff8024b561>] ? __srcu_notifier_call_chain+0x46/0x61 [<ffffffff8048496d>] ? cpufreq_notify_transition+0x93/0xa9 [<ffffffff8021ab8d>] ? powernowk8_target+0x1e8/0x5f3 [<ffffffff80486687>] ? cpufreq_governor_performance+0x1b/0x20 [<ffffffff80484886>] ? __cpufreq_governor+0x71/0xa8 [<ffffffff80484b21>] ? __cpufreq_set_policy+0x101/0x13e [<ffffffff80485bcd>] ? cpufreq_add_dev+0x3f0/0x4cd [<ffffffff8048577a>] ? handle_update+0x0/0x8 [<ffffffff803c2062>] ? sysdev_driver_register+0xb6/0x10d [<ffffffff8056592c>] ? powernowk8_init+0x0/0x7e [<ffffffff8048604c>] ? cpufreq_register_driver+0x8f/0x140 [<ffffffff80209056>] ? _stext+0x56/0x14f [<ffffffff802c2234>] ? proc_register+0x122/0x17d [<ffffffff802c23a0>] ? create_proc_entry+0x73/0x8a [<ffffffff8025c259>] ? register_irq_proc+0x92/0xaa [<ffffffff8025c2c8>] ? init_irq_proc+0x57/0x69 [<ffffffff807fc85f>] ? kernel_init+0x116/0x169 [<ffffffff8020cc79>] ? child_rip+0xa/0x11 [<ffffffff807fc749>] ? kernel_init+0x0/0x169 [<ffffffff8020cc6f>] ? child_rip+0x0/0x11 Code: 05 c5 83 36 00 48 c7 c2 48 5d 86 80 48 8b 04 d8 48 8b 40 08 48 8b 34 02 48\ RIP [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f RSP <ffff88006fb83b20> CR2: ffff88086e7528b8 ---[ end trace 0678bac75e67a2f7 ]--- Kernel panic - not syncing: Attempted to kill init! In short, aftereffect of the wrong P-state is that cpufreq_stats_update() uses "-1" as index for some array in cpufreq_stats_update (unsigned int cpu) { ... if (stat->time_in_state) stat->time_in_state[stat->last_index] = cputime64_add(stat->time_in_state[stat->last_index], cputime_sub(cur_time, stat->last_time)); ... } Fortunately, the wrong P-state value is returned only if the core is in P-state 0. This fix solves the problem by detecting the out-of-range P-state, ignoring it, and using "0" instead. Cc: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05x86: more general identifier for Phoenix BIOSPhilipp Kohlbecher
commit 0af40a4b1050c050e62eb1dc30b82d5ab22bf221 upstream. Impact: widen the reach of the low-memory-protect DMI quirk Phoenix BIOSes variously identify their vendor as "Phoenix Technologies, LTD" or "Phoenix Technologies LTD" (without the comma.) This patch makes the identification string in the bad_bios_dmi_table more general (following a suggestion by Ingo Molnar), so that both versions are handled. Again, the patched file compiles cleanly and the patch has been tested successfully on my machine. Signed-off-by: Philipp Kohlbecher <xt28@gmx.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05IA64: fix boot panic caused by offline CPUsDoug Chapman
commit 62ee0540f5e5a804b79cae8b3c0185a85f02436b upstream. This fixes a regression introduced by 2c6e6db41f01b6b4eb98809350827c9678996698 "Minimize per_cpu reservations." That patch incorrectly used information about what CPUs are possible that was not yet initialized by ACPI. The end result was that per_cpu structures for offline CPUs were not initialized causing a NULL pointer reference. Since we cannot do the full acpi_boot_init() call any earlier, the simplest fix is to just parse the MADT for SAPIC entries early to find the CPU info. This should also allow for some cleanup of the code added by the "Minimize per_cpu reservations". This patch just fixes the regressions, the cleanup will come in a later patch. Signed-off-by: Doug Chapman <doug.chapman@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> CC: Robin Holt <holt@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05parisc: fix kernel crash when unwinding a userspace processHelge Deller
commit 7a3f5134a8f5bd7fa38b5645eef05e8a4eb62951 upstream. Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO. A simple testcase is available here: http://gsyprf10.external.hp.com/~deller/crash.tgz The problem is introduced by the fact, that the handle_interruption() crash handler calls the show_regs() function, which in turn tries to unwind the stack by calling parisc_show_stack(). Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash. The fix is trivial: For userspace processes a) avoid to unwind the stack, and b) avoid to resolve userspace addresses to kernel symbol names. While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static. An initial patch for this was written by Kyle McMartin back in August: http://marc.info/?l=linux-parisc&m=121805168830283&w=2 Compile and run-tested with a 64bit parisc kernel. Signed-off-by: Helge Deller <deller@gmx.de> Cc: Grant Grundler <grundler@parisc-linux.org> Cc: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20m68k: Fix off-by-one in m68k_setup_user_interrupt()Geert Uytterhoeven
commit 27123cbc264de89ce6951b1b4c84c223eb0f1702 upstream. commit 69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari: Interrupt updates") added a BUG_ON() with an incorrect upper bound comparison, which causes an early crash on VME boards, where IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. Reported-by: Stephen N Chivers <schivers@csc.com.au> Tested-by: Kars de Jong <jongk@linux-m68k.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20S390: cpu topology: fix lockingHeiko Carstens
commit 74af283102b358b0da545460d0d176f473e110f6 upstream. cpu_coregroup_map used to grab a mutex on s390 since it was only called from process context. Since c7c22e4d5c1fdebfac4dba76de7d0338c2b0d832 "block: add support for IO CPU affinity" this is not true anymore. It now also gets called from softirq context. To prevent possible deadlocks change this in architecture code and use a spinlock instead of a mutex. Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20powerpc/mpic: Fix regression caused by change of default IRQ affinityKumar Gala
commit 3c10c9c45e290022ca7d2aa1ad33a0b6ed767520 upstream. The Freescale implementation of MPIC only allows a single CPU destination for non-IPI interrupts. We add a flag to the mpic_init to distinquish these variants of MPIC. We pull in the irq_choose_cpu from sparc64 to select a single CPU as the destination of the interrupt. This is to deal with the fact that the default smp affinity was changed by commit 18404756765c713a0be4eb1082920c04822ce588 ("genirq: Expose default irq affinity mask (take 3)") to be all CPUs. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20ARM: 5329/1: Feroceon: fix feroceon_l2_inv_rangeNicolas Pitre
commit 72bc2b1ad62f4d2f0a51b35829093d41f55accce upstream. Same fix as commit c7cf72dcadb: when 'start' and 'end' are less than a cacheline apart and 'start' is unaligned we are done after cleaning and invalidating the first cacheline. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13ARM: 5300/1: fixup spitz reset during bootDmitry Baryshkov
commit 69fc7eed5f56bce15b239e5110de2575a6970df4 upstream Some machines don't have the pullup/down on their reset pin, so configuring the reset generating pin as input makes them reset immediately. Fix that by making reset pin direction configurable. This fixes the boot problem on Sharp Zaurus c3000 Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13x86: don't use tsc_khz to calculate lpj if notsc is passedAlok Kataria
commit 70de9a97049e0ba79dc040868564408d5ce697f9 upstream Impact: fix udelay when "notsc" boot parameter is passed With notsc passed on commandline, tsc may not be used for udelays, make sure that we do not use tsc_khz to calculate the lpj value in such cases. Reported-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Alok N Kataria <akataria@vmware.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13ARM: xsc3: fix xsc3_l2_inv_rangeDan Williams
commit c7cf72dcadbe39c2077b32460f86c9f8167be3be upstream When 'start' and 'end' are less than a cacheline apart and 'start' is unaligned we are done after cleaning and invalidating the first cacheline. So check for (start < end) which will not walk off into invalid address ranges when (start > end). This issue was caught by drivers/dma/dmatest. 2.6.27 is susceptible. Cc: <stable@kernel.org> Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Cc: Lothar Wafmann <LW@KARO-electronics.de> Cc: Lennert Buytenhek <buytenh@marvell.com> Cc: Eric Miao <eric.miao@marvell.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-28 17:34:23 +0000