summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
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>
2008-11-13x86: fix macro with bad_bios_dmi_tableYinghai Lu
commit a8b71a2810386a5ac8f43d2095fe3355f0d8db37 upstream. DMI tables need a blank NULL tail. fixes the crash on Ingo's test box. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13x86: fix CONFIG_X86_RESERVE_LOW_64K=yYinghai Lu
commit 2216d199b1430d1c0affb1498a9ebdbd9c0de439 upstream The bad_bios_dmi_table() quirk never triggered because we do DMI setup too late. Move it a bit earlier. Also change the CONFIG_X86_RESERVE_LOW_64K quirk to operate on the e820 table directly instead of messing with early reservations - this handles overlaps (which do occur in this low range of RAM) more gracefully. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13x86: add X86_RESERVE_LOW_64KIngo Molnar
commit fc38151947477596aa27df6c4306ad6008dc6711 upstream. This bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=11237 Documents a wide range of systems where the BIOS utilizes the first 64K of physical memory during suspend/resume and other hardware events. Currently we reserve this memory on all AMI and Phoenix BIOS systems. Life is too short to hunt subtle memory corruption problems like this, so we try to be robust by default. Still, allow this to be overriden: allow users who want that first 64K of memory to be available to the kernel disable the quirk, via CONFIG_X86_RESERVE_LOW_64K=n. Also, allow the early reservation to overlap with other early reservations. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13x86: reserve low 64K on AMI and Phoenix BIOS boxenIngo Molnar
commit 1e22436eba84edfec9c25e5a25d09062c4f91ca9 upstream there's multiple reports about suspend/resume related low memory corruption in this bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=11237 the common pattern is that the corruption is caused by the BIOS, and that it affects some portion of the first 64K of physical RAM. So add a DMI quirk This will waste 64K RAM on 'good' systems too, but without knowing the exact nature of this BIOS memory corruption this is the safest approach. This might as well solve a wide range of suspend/resume breakages under Linux. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13x86: add DMI quirk for AMI BIOS which corrupts address 0xc000 during resumeIngo Molnar
commit 5649b7c30316a51792808422ac03ee825d26aa5e upstream Alan Jenkins and Andy Wettstein reported a suspend/resume memory corruption bug and extensively documented it here: http://bugzilla.kernel.org/show_bug.cgi?id=11237 The bug is that the BIOS overwrites 1K of memory at 0xc000 physical, without registering it in e820 as reserved or giving the kernel any idea about this. Detect AMI BIOSen and reserve that 1K. We paint this bug around with a very broad brush (reserving that 1K on all AMI BIOS systems), as the bug was extremely hard to find and needed several weeks and lots of debugging and patching. The bug was found via the CONFIG_X86_CHECK_BIOS_CORRUPTION=y debug feature, if similar bugs are suspected then this feature can be enabled on other systems as well to scan low memory for corrupted memory. Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Reported-by: Andy Wettstein <ajw1980@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06x86: register a platform RTC device if PNP doesn't describe itBjorn Helgaas
commit 758a7f7bb86b520aadc484f23da85e547b3bf3d8 upstream x86: register a platform RTC device if PNP doesn't describe it Most if not all x86 platforms have an RTC device, but sometimes the RTC is not exposed as a PNP0b00/PNP0b01/PNP0b02 device in PNPBIOS or ACPI: http://bugzilla.kernel.org/show_bug.cgi?id=11580 https://bugzilla.redhat.com/show_bug.cgi?id=451188 It's best if we can discover the RTC via PNP because then we know which flavor of device it is, where it lives, and which IRQ it uses. But if we can't, we should register a platform device using the compiled-in RTC_PORT/RTC_IRQ resource assumptions. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Reported-by: Rik Theys <rik.theys@esat.kuleuven.be> Reported-by: shr_msn@yahoo.com.tw Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06x86: avoid dereferencing beyond stack + THREAD_SIZEDavid Rientjes
commit e1e23bb0513520035ec934fa3483507cb6648b7c upstream x86: avoid dereferencing beyond stack + THREAD_SIZE It's possible for get_wchan() to dereference past task->stack + THREAD_SIZE while iterating through instruction pointers if fp equals the upper boundary, causing a kernel panic. Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06powerpc: Don't use a 16G page if beyond mem= limitsJon Tollefson
commit 4792adbac9eb41cea77a45ab76258ea10d411173 upstream If mem= is used on the boot command line to limit memory then the memory block where a 16G page resides may not be available. Thanks to Michael Ellerman for finding the problem. Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06powerpc/numa: Make memory reserve code more robustJon Tollefson
commit e81703724a966120ace6504c993bda9e084cbf3e upstream. Adjust amount to reserve based on previous nodes for reserves spanning multiple nodes. Check if the node active range is empty before attempting to pass the reserve to bootmem. In practice the range shouldn't be empty, but to be sure we check. Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06powerpc: Reserve in bootmem lmb reserved regions that cross NUMA nodesJon Tollefson
commit 8f64e1f2d1e09267ac926e15090fd505c1c0cbcb upstream If there are multiple reserved memory blocks via lmb_reserve() that are contiguous addresses and on different NUMA nodes we are losing track of which address ranges to reserve in bootmem on which node. I discovered this when I recently got to try 16GB huge pages on a system with more then 2 nodes. When scanning the device tree in early boot we call lmb_reserve() with the addresses of the 16G pages that we find so that the memory doesn't get used for something else. For example the addresses for the pages could be 4000000000, 4400000000, 4800000000, 4C00000000, etc - 8 pages, one on each of eight nodes. In the lmb after all the pages have been reserved it will look something like the following: lmb_dump_all: memory.cnt = 0x2 memory.size = 0x3e80000000 memory.region[0x0].base = 0x0 .size = 0x1e80000000 memory.region[0x1].base = 0x4000000000 .size = 0x2000000000 reserved.cnt = 0x5 reserved.size = 0x3e80000000 reserved.region[0x0].base = 0x0 .size = 0x7b5000 reserved.region[0x1].base = 0x2a00000 .size = 0x78c000 reserved.region[0x2].base = 0x328c000 .size = 0x43000 reserved.region[0x3].base = 0xf4e8000 .size = 0xb18000 reserved.region[0x4].base = 0x4000000000 .size = 0x2000000000 The reserved.region[0x4] contains the 16G pages. In arch/powerpc/mm/num.c: do_init_bootmem() we loop through each of the node numbers looking for the reserved regions that belong to the particular node. It is not able to identify region 0x4 as being a part of each of the 8 nodes. It is assuming that a reserved region is only on a single node. This patch takes out the reserved region loop from inside the loop that goes over each node. It looks up the active region containing the start of the reserved region. If it extends past that active region then it adjusts the size and gets the next active region containing it. Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06powerpc: fix i2c on PPC linkstation / kurobox machinesGuennadi Liakhovetski
commit 22e181ba7f09197dd6f35a48013cb86289644eb6 upstream. The i2c bus defn is broken on linkstation / kurobox machines since at least 2.6.27. Fix it. Also remove CONFIG_SERIAL_OF_PLATFORM, which, if enabled, breaks the serial console after the "console handover: boot [udbg0] -> real [ttyS1]" message. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06sparc64: Fix race in arch/sparc64/kernel/trampoline.SAndrea Shepard
[ Upstream commit e0037df3852b4b60edbe01f70f4968e4a9fdb272 ] Make arch/sparc64/kernel/trampoline.S in 2.6.27.1 lock prom_entry_lock when calling the PROM. This prevents a race condition that I observed causing a hang on startup on a 12-CPU E4500. I am not subscribed to this list, so please CC me on replies. Signed-off-by: Andrea Shepard <andrea@persephoneslair.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06x86: fix /dev/mem mmap breakage when PAT is disabledRavikiran G Thirumalai
commit 9e41bff2708e420e61e6b89a54c15232857069b1 upstream Impact: allow /dev/mem mmaps on non-PAT CPUs/platforms Fix mmap to /dev/mem when CONFIG_X86_PAT is off and CONFIG_STRICT_DEVMEM is off mmap to /dev/mem on kernel memory has been failing since the introduction of PAT (CONFIG_STRICT_DEVMEM=n case). Seems like the check to avoid cache aliasing with PAT is kicking in even when PAT is disabled. The bug seems to have crept in 2.6.26. This patch makes sure that the mmap to regular kernel memory succeeds if CONFIG_STRICT_DEVMEM=n and PAT is disabled, and the checks to avoid cache aliasing still happens if PAT is enabled. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Tested-by: Tim Sirianni <tim@scalemp.com> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06S390: Fix sysdev class file creation.Heiko Carstens
commit da5aae7036692fa8d03da1b705c76fd750ed9e38 upstream Use sysdev_class_create_file() to create create sysdev class attributes instead of sysfs_create_file(). Using sysfs_create_file() wasn't a very good idea since the show and store functions have a different amount of parameters for sysfs files and sysdev class files. In particular the pointer to the buffer is the last argument and therefore accesses to random memory regions happened. Still worked surprisingly well until we got a kernel panic. 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-10-25amd_iommu: fix nasty bug that caused ILLEGAL_DEVICE_TABLE_ENTRY errorsAndreas Herrmann
commit f609891f428e1c20e270e7c350daf8c93cc459d7 upstream We are on 64-bit so better use u64 instead of u32 to deal with addresses: static void __init iommu_set_device_table(struct amd_iommu *iommu) { u64 entry; ... entry = virt_to_phys(amd_iommu_dev_table); ... (I am wondering why gcc 4.2.x did not warn about the assignment between u32 and unsigned long.) Cc: iommu@lists.linux-foundation.org Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-25x86 ACPI: fix breakage of resume on 64-bit UP systems with SMP kernelRafael J. Wysocki
commit 3038edabf48f01421c621cb77a712b446d3a5d67 upstream x86 ACPI: Fix breakage of resume on 64-bit UP systems with SMP kernel We are now using per CPU GDT tables in head_64.S and the original early_gdt_descr.address is invalidated after boot by setup_per_cpu_areas(). This breaks resume from suspend to RAM on x86_64 UP systems using SMP kernels, because this part of head_64.S is also executed during the resume and the invalid GDT address causes the system to crash. It doesn't break on 'true' SMP systems, because early_gdt_descr.address is modified every time native_cpu_up() runs. However, during resume it should point to the GDT of the boot CPU rather than to another CPU's GDT. For this reason, during suspend to RAM always make early_gdt_descr.address point to the boot CPU's GDT. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11568, which is a regression from 2.6.26. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Ingo Molnar <mingo@elte.hu> Reported-and-tested-by: Andy Wettstein <ajw1980@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-18x86: improve UP kernel when CPU-hotplug and SMP is enabledThomas Gleixner
commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream num_possible_cpus() can be > 1 when disabled CPUs have been accounted. Disabled CPUs are not in the cpu_present_map, so we can use num_present_cpus() as a safe indicator to switch to UP alternatives. Reported-by: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-18x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPICAndreas Herrmann
commit 33fb0e4eb53f16af312f9698f974e2e64af39c12 upstream On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override but the SB450 chipset is configured such that timer interrupts goe to INT0 of IOAPIC. Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the timer override. [ This more generic PCI ID based quirk should alleviate the need for dmi_ignore_irq0_timer_override DMI quirks. ] Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Acked-by: "Maciej W. Rozycki" <macro@linux-mips.org> Tested-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-30 18:09:05 +0000