aboutsummaryrefslogtreecommitdiffstats
path: root/arch/i386
Commit message (Collapse)AuthorAge
* Longhaul: add auto enabled "revid_errata" optionRafal Bilski2007-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VIA C3 Ezra-T has RevisionID equal to 1, but it needs RevisionKey to be 0 or CPU will ignore new frequency and will continue to work at old frequency. New "revid_errata" option will force RevisionKey to be set to 0, whatever RevisionID is. Additionaly "Longhaul" will not silently ignore unsuccessful transition. It will try to check if "revid_errata" or "disable_acpi_c3" options need to be enabled for this processor/system. Same for Longhaul ver. 2 support. It will be disabled if none of above options will work. Best case scenario (with patch apllied and v2 enabled): longhaul: VIA C3 'Ezra' [C5C] CPU detected. Longhaul v2 supported. longhaul: Using northbridge support. longhaul: VRM 8.5 longhaul: Max VID=1.350 Min VID=1.050, 13 possible voltage scales longhaul: f: 300000 kHz, index: 0, vid: 1050 mV [...] longhaul: Voltage scaling enabled. Worst case scenario: longhaul: VIA C3 'Ezra-T' [C5M] CPU detected. Powersaver supported. longhaul: Using northbridge support. longhaul: Using ACPI support. longhaul: VRM 8.5 longhaul: Claims to support voltage scaling but min & max are both 1.250. Voltage scaling disabled longhaul: Failed to set requested frequency! longhaul: Enabling "Ignore Revision ID" option. longhaul: Failed to set requested frequency! longhaul: Disabling ACPI C3 support. longhaul: Disabling "Ignore Revision ID" option. longhaul: Failed to set requested frequency! longhaul: Enabling "Ignore Revision ID" option. [akpm@linux-foundation.org: coding-style cleanups] Signed-off-by: Rafal Bilski <rafalbilski@interia.pl> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [x86 setup] Correct the SMAP check for INT 0x15, AX=0xe820H. Peter Anvin2007-09-28
| | | | | | | | | | | | The e820 probe code was checking %edx, not %eax, for the SMAP signature on return. This worked on *almost* all systems, since %edx still contained SMAP from the call on entry, but on a handful of systems it failed -- plus, we would have missed real mismatches. The error output is "=d" to make sure gcc knows %edx is clobbered here. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* Merge branch 'for-linus' of ↵Linus Torvalds2007-09-26
|\ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup: [x86 setup] Handle case of improperly terminated E820 chain
| * [x86 setup] Handle case of improperly terminated E820 chainH. Peter Anvin2007-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least one system (a Geode system with a Digital Logic BIOS) has been found which suddenly stops reporting the SMAP signature when reading the E820 memory chain. We can't know what, exactly, broke in the BIOS, so if we detect this situation, declare the E820 data unusable and fall back to E801. Also, revert to original behavior of always probing all memory methods; that way all the memory information is available to the kernel. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Jordan Crouse <jordan.crouse@amd.com> Cc: Joerg Pommnitz <pommnitz@yahoo.com>
* | xen: execve's error paths don't pin the mm before unpinningJeremy Fitzhardinge2007-09-26
|/ | | | | | | | | | execve's error paths don't activate (and therefore pin) the mm before calling exit_mmap to free it up, so don't try to unpin unless it is actually pinned. This prevents a BUG_ON from triggering. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Christian Ostheimer <osth@freesurf.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [x86 setup] Fix typo in arch/i386/boot/header.SPaul Bolle2007-09-20
| | | | | | | | There's an obvious typo in arch/i386/boot/header.S (in your linux-2.6-x86setup.git) that I noticed by just studying the code. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* [acpi] Correct the decoding of video mode numbers in wakeup.SH. Peter Anvin2007-09-20
| | | | | | | | | | | | | | | wakeup.S looks at the video mode number from the setup header and looks to see if it is a VESA mode. Unfortunately, the decoding is done incorrectly and it will attempt to frob the VESA BIOS for any mode number 0x0200 or larger. Correct this, and remove a bunch of #if 0'd code. Massive thanks to Jeff Chua for reporting the bug, and suffering though a large number of experiments in order to track this problem down. Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* [x86 setup] Present the canonical video mode number to the kernelH. Peter Anvin2007-09-20
| | | | | | | | | Canonicalize the video mode number as presented to the kernel. The video mode number may be user-entered (e.g. ASK_VGA), an alias (e.g. NORMAL_VGA), or a size specification, and that confuses the suspend wakeup code. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* xen: don't bother trying to set cr4Jeremy Fitzhardinge2007-09-19
| | | | | | | | | | Xen ignores all updates to cr4, and some versions will kill the domain if you try to change its value. Just ignore all changes. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* i386: Fix leak of ../kernel from top levelAndi Kleen2007-09-12
| | | | | | | | | | | Fix a compile error when the directory above the kernel source contains a file named "kernel". Originally from Ben LaHaise, modified based on feedback from Sam Ravnborg Signed-off-by: Andi Kleen <ak@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Ben LaHaise <bcrl@kvack.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* x86_64: Prevent doing anything from cache_remove_dev() when info setup failed.Andi Kleen2007-09-12
| | | | | | | | | | | | AK: Removed the unlikelies because gcc heuristics default to unlikely AK: for test == NULL and for negative returns. Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* revert "highmem: catch illegal nesting"Andrew Morton2007-09-11
| | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 656dad312fb41ed95ef08325e9df9bece3aacbbb Author: Ingo Molnar <mingo@elte.hu> Date: Sat Feb 10 01:46:36 2007 -0800 [PATCH] highmem: catch illegal nesting Catch illegally nested kmap_atomic()s even if the page that is mapped by the 'inner' instance is from lowmem. This avoids spuriously zapped kmap-atomic ptes and turns hard to find crashes into clear asserts at the bug site. Problem is, a get_zeroed_page(GFP_KERNEL) from interrupt context will trigger this check if non-irq code on this CPU holds a KM_USER0 mapping. But that get_zeroed_page() will never be altering the kmap slot anyway due to the GFP_KERNEL. Cc: Christoph Lameter <clameter@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: irq and pci_ids patch for Intel TolapaiJason Gaston2007-09-11
| | | | | | | | This patch adds the Intel Tolapai LPC and SMBus Controller DID's. Signed-off-by: Jason Gaston <jason.d.gaston@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: Remove __devinit from pcibios_get_irq_routing_tableRalf Baechle2007-09-11
| | | | | | | | | | | pcibios_get_irq_routing_table is an exported symbol. This results in a modpost warning: WARNING: vmlinux.o(.text+0xdca51): Section mismatch: reference to .init.text:pcibios_fixup_bus (between 'pci_scan_child_bus' and 'pci_scan_bus_parented') Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* i386: fix a hang on stuck nmi watchdogDaniel Walker2007-09-10
| | | | | | | | | | | | | | In the case when an nmi gets stucks the endflag stays equal to zero. This causes the busy looping on other cpus to continue, even though the nmi test is done. On my machine with out the change below the system would hang right after check_nmi_watchdog(). The change below just sets endflag prior to checking if the test was successful or not. Signed-off-by: Daniel Walker <dwalker@mvista.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* x86_64: Remove CLFLUSH in text_poke()Andi Kleen2007-09-10
| | | | | | | | | | | | The CLFLUSH for the modified code line in text_poke was supposed to speed up CPU recovery. Unfortunately it seems to cause hangs on some VIA C3s (at least on VIA Esther Model 10 Stepping 9) Remove it. Thanks to Stefan Becker for reporting/testing. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* i386: Fix perfctr watchdog on core duoStephane Eranian2007-09-10
| | | | | | | | | | | | | | | | | | | Fix the NMI watchdog on Intel CoreDuo processor where the kernel would get stuck during boot. The issue is related to errata AE49, where the PERFEVTSEL1 counter does not have a working enable bit. Thus it is not possible to use it for NMI. The patch creates a dedicated wd_ops for CoreDuo which falls back to using PERFEVTSEL0. The other Intel processors supporting the architectural PMU will keep on using PERFEVTSEL1 as this allows other subsystems, such as perfmon, to use PERFEVTSEL0 for PEBS monitoring in particular. Bug initially reported by Daniel Walker. AK: Added comments Signed-off-by: Stephane Eranian <eranian@hpl.hp.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Fix spurious syscall tracing after PTRACE_DETACH + PTRACE_ATTACHRoland McGrath2007-09-10
| | | | | | | | | | | | | | | | | | | | | | When PTRACE_SYSCALL was used and then PTRACE_DETACH is used, the TIF_SYSCALL_TRACE flag is left set on the formerly-traced task. This means that when a new tracer comes along and does PTRACE_ATTACH, it's possible he gets a syscall tracing stop even though he's never used PTRACE_SYSCALL. This happens if the task was in the middle of a system call when the second PTRACE_ATTACH was done. The symptom is an unexpected SIGTRAP when the tracer thinks that only SIGSTOP should have been provoked by his ptrace calls so far. A few machines already fixed this in ptrace_disable (i386, ia64, m68k). But all other machines do not, and still have this bug. On x86_64, this constitutes a regression in IA32 compatibility support. Since all machines now use TIF_SYSCALL_TRACE for this, I put the clearing of TIF_SYSCALL_TRACE in the generic ptrace_detach code rather than adding it to every other machine's ptrace_disable. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [x86 setup] Work around bug in Xen HVMChristian Ehrhardt2007-09-04
| | | | | | | | | | | | | | | | | | Apparently XEN does not keep the contents of the 48-bit gdt_48 data structure that is passed to lgdt in the XEN machine state. Instead it appears to save the _address_ of the 48-bit descriptor somewhere. Unfortunately this data happens to reside on the stack and is probably no longer availiable at the time of the actual protected mode jump. This is Xen bug but given that there is a one-line patch to work around this problem, the linux kernel should probably do this. My fix is to make the gdt_48 description in setup_gdt static (in setup_idt this is already the case). This allows the kernel to boot under Xen HVM again. Signed-off-by: Christian Ehrhardt <lk@c--e.de> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* Merge branch 'for-linus' of ↵Linus Torvalds2007-08-31
|\ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup: [x86 setup] Don't rely on the VESA BIOS being register-clean
| * [x86 setup] Don't rely on the VESA BIOS being register-cleanH. Peter Anvin2007-08-31
| | | | | | | | | | | | | | | | | | | | | | | | The VESA BIOS is specified to be register-clean. However, we have now found at least one system which violates that. Thus, be as paranoid about VESA calls as about everything else. Huge thanks to Will Simoneau for reporting, diagnosing, and testing this out on Dell Inspiron 5150. Cc: Will Simoneau <simoneau@ele.uri.edu> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* | x86: be even more careful about checking the stack frame on dumpingLinus Torvalds2007-08-31
|/ | | | | | | | | | | | | | | lguest didn't initialize the kernel stack the way a real i386 kernel does, and ended up triggering a corner-case in the stack frame checking that doesn't happen on naive i386, and that the stack dumping didn't handle quite right. This makes the frame handling more correct, and tries to clarify the code at the same time so that it's a bit more obvious what is going on. Thanks to Rusty Russell for debugging the lguest failure- Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* hugepage: fix broken check for offset alignment in hugepage mappingsDavid Gibson2007-08-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For hugepage mappings, the file offset, like the address and size, needs to be aligned to the size of a hugepage. In commit 68589bc353037f233fe510ad9ff432338c95db66, the check for this was moved into prepare_hugepage_range() along with the address and size checks. But since BenH's rework of the get_unmapped_area() paths leading up to commit 4b1d89290b62bb2db476c94c82cf7442aab440c8, prepare_hugepage_range() is only called for MAP_FIXED mappings, not for other mappings. This means we're no longer ever checking for an aligned offset - I've confirmed that mmap() will (apparently) succeed with a misaligned offset on both powerpc and i386 at least. This patch restores the check, removing it from prepare_hugepage_range() and putting it back into hugetlbfs_file_mmap(). I'm putting it there, rather than in the get_unmapped_area() path so it only needs to go in one place, than separately in the half-dozen or so arch-specific implementations of hugetlb_get_unmapped_area(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Cc: Adam Litke <agl@us.ibm.com> Cc: Andi Kleen <ak@suse.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'release' of ↵Linus Torvalds2007-08-25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (30 commits) ACPI: work around duplicate name "VID" problem on T61 acpiphp_ibm: add missing '\n' to error message ACPI: add dump_stack() to trace acpi_format_exception programming errors make drivers/acpi/scan.c:create_modalias() static ACPI: Fix a warning of discarding qualifiers from pointer target type ACPI: "ACPI handle has no context!" should be KERN_DEBUG ACPI video hotkey: export missing ACPI video hotkey events via input layer ACPI: Validate XSDT, use RSDT if XSDT fails ACPI: /proc/acpi/thermal_zone trip points are now read-only, mark them as such ACPI: fix ia64 allnoconfig build PNP: remove null pointer checks PNP: remove MODULE infrastructure ISAPNP: removed unused isapnp_detected and ISAPNP_DEBUG PNPACPI: remove unnecessary casts of "void *" PNPACPI: simplify irq_flags() PNP: fix up after Lindent ACPI: enable GPEs before calling _WAK on resume asus-laptop: Fix rmmod of asus_laptop sony-laptop: call sonypi_compat_init earlier sony-laptop: enable Vaio FZ events ...
| * Pull bugzilla-1641 into release branchLen Brown2007-08-24
| |\
| | * ACPI: boot correctly with "nosmp" or "maxcpus=0"Len Brown2007-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In MPS mode, "nosmp" and "maxcpus=0" boot a UP kernel with IOAPIC disabled. However, in ACPI mode, these parameters didn't completely disable the IO APIC initialization code and boot failed. init/main.c: Disable the IO_APIC if "nosmp" or "maxcpus=0" undefine disable_ioapic_setup() when it doesn't apply. i386: delete ioapic_setup(), it was a duplicate of parse_noapic() delete undefinition of disable_ioapic_setup() x86_64: rename disable_ioapic_setup() to parse_noapic() to match i386 define disable_ioapic_setup() in header to match i386 http://bugzilla.kernel.org/show_bug.cgi?id=1641 Acked-by: Andi Kleen <ak@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'for-linus' of ↵Linus Torvalds2007-08-24
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup: [x86 setup] Make sure AH=00h when setting a video mode [x86 setup] Volatilize asm() statements
| * | [x86 setup] Make sure AH=00h when setting a video modeH. Peter Anvin2007-08-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | Passing a u8 into a register doesn't mean gcc will zero-extend it. Also, don't depend on thhe register not to change. Per bug report from Saul Tamari. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| * | [x86 setup] Volatilize asm() statementsH. Peter Anvin2007-08-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | asm() statements need to be volatile when: a. They have side effects (other than value returned). b. When the value returned can vary over time. c. When they have ordering constraints that cannot be expressed to gcc. In particular, the keyboard and timer reads were violating constraint (b), which resulted in the keyboard/timeout poll getting loop-invariant-removed when compiling with gcc 4.2.0. Thanks to an anonymous bug reporter for pointing this out. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* | | sched: sched_clock_idle_[sleep|wakeup]_event()Ingo Molnar2007-08-23
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | construct a more or less wall-clock time out of sched_clock(), by using ACPI-idle's existing knowledge about how much time we spent idling. This allows the rq clock to work around TSC-stops-in-C2, TSC-gets-corrupted-in-C3 type of problems. ( Besides the scheduler's statistics this also benefits blktrace and printk-timestamps as well. ) Furthermore, the precise before-C2/C3-sleep and after-C2/C3-wakeup callbacks allow the scheduler to get out the most of the period where the CPU has a reliable TSC. This results in slightly more precise task statistics. the ACPI bits were acked by Len. Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Len Brown <len.brown@intel.com>
* | Xen i386 xen-head.S fix sections mixupMathieu Desnoyers2007-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Xen i386 xen-head.S fix sections mixup xen-head.S does not come back to the data section, leaving the text section as current section. It causes problems with a slightly enhanced DEBUG_RODATA that supports CONFIG_HOTPLUG and bringing a CPU up after the text has been marked read-only: reference to early_gdt_descr causes a page fault. Updates: - It should be using pushsection/popsection. - Actually, the push/popsections around the ELFNOTEs are redundant; ELFNOTE() does its own push/popsection to put things into the appropriate .note* section anyway. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Acked-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Chris Wright <chrisw@sous-sol.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Fix lazy mode vmalloc synchronization for paravirtZachary Amsden2007-08-22
| | | | | | | | | | | | | | | | | | | | Touching vmalloc memory in the middle of a lazy mode update can generate a kernel PDE update, which must be flushed immediately. The fix is to leave lazy mode when doing a vmalloc sync. Signed-off-by: Zachary Amsden <zach@vmware.com> Acked-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | i386: Mark NUMA support experimentalAndi Kleen2007-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | | I did some testing and found quite a lot of problems (doesn't boot at all on non NUMA and misassigns cores on Opteron systems). Mark it as experimental and warn against its use for now. It's still default y for SUMMIT/NUMAQ because it'll presumably work on these systems. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | x86: properly initialize temp insn buffer for paravirt patchingChris Wright2007-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With commit ab144f5ec64c42218a555ec1dbde6b60cf2982d6 the patching code now collects the complete new instruction stream into a temp buffer before finally patching in the new insns. In some cases the paravirt patchers will choose to leave the patch site unpatched (length mismatch, clobbers mismatch, etc). This causes the new patching code to copy an uninitialized temp buffer, i.e. garbage, to the callsite. Simply make sure to always initialize the buffer with the original instruction stream. A better fix is to audit all the patchers and return proper length so that apply_paravirt() can skip copies when we leave the patch site untouched. Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | x86_64: Check for .cfi_rel_offset in CFI probeAndi Kleen2007-08-18
| | | | | | | | | | | | | | | | | | Very old 64bit binutils have .cfi_startproc/endproc, but no .cfi_rel_offset. Check for .cfi_rel_offset too. Cc: Jan Beulich <jbeulich@novell.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | x86_64: Fix to keep watchdog disabled by default for i386/x86_64Daniel Gollub2007-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed wrong expression which enabled watchdogs even if nmi_watchdog kernel parameter wasn't set. This regression got slightly introduced with commit b7471c6da94d30d3deadc55986cc38d1ff57f9ca. Introduced NMI_DISABLED (-1) which allows to switch the value of NMI_DEFAULT without breaking the APIC NMI watchdog code (again). Fixes: https://bugzilla.novell.com/show_bug.cgi?id=298084 http://bugzilla.kernel.org/show_bug.cgi?id=7839 And likely some more nmi_watchdog=0 related issues. Signed-off-by: Daniel Gollub <dgollub@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Add some help texts to recently-introduced kconfig itemsJan Engelhardt2007-08-18
| | | | | | | | | | | | Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (edited MACINTOSH_DRIVERS per Geert Uytterhoeven's remark) Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | [x86 setup] edd.c: make sure MBR signatures actually get reportedH. Peter Anvin2007-08-14
| | | | | | | | | | | | | | | | When filling in the MBR signature array, the setup code failed to advance boot_params.edd_mbr_sig_buf_entries, which resulted in the valid data being ignored. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* | [x86 setup] Don't use EDD to get the MBR signatureH. Peter Anvin2007-08-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least one machine has been identified in the field which advertises EDD for all drives but locks up if one attempts an extended read from a non-primary drive. The MBR is always at CHS 0-0-1, so there is no reason to use an extended read, other than the possibility that the BIOS cannot handle it. Although this might break as many machines as it fixes (a small number either way), the current state is a regression but the reverse is not. Therefore revert to the previous state of not using extended read. Quite probably the Right Thing to do is to read using plain (CHS) read and extended read on failure, but that change would definitely have to go through -mm first. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* | [x86 setup] The current display page is returned in %bh, not %blH. Peter Anvin2007-08-14
|/ | | | | | | | | | The current display page is an 8-bit number, even though struct screen_info gives it a 16-bit number. The number is returned in %bh, so it needs to be >> 8 before storing. Special thanks to Jeff Chua for detailed bug reporting. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* genirq: mark io_apic level interrupts to avoid resendThomas Gleixner2007-08-12
| | | | | | | | | | | Level type interrupts do not need to be resent. It was also found that some chipsets get confused in case of the resend. Mark the ioapic level type interrupts as such to avoid the resend functionality in the generic irq code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'release' of ↵Linus Torvalds2007-08-12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (28 commits) ACPI: thermal: add DMI hooks to handle AOpen's broken Award BIOS ACPI: thermal: create "thermal.act=" to disable or override active trip point ACPI: thermal: create "thermal.nocrt" to disable critical actions ACPI: thermal: create "thermal.psv=" to override passive trip points ACPI: thermal: expose "thermal.tzp=" to set global polling frequency ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support ACPI: thinkpad-acpi: fix sysfs paths in documentation ACPI: static ACPI EC: remove potential deadlock from EC ACPI: dock: Send key=value pair instead of plain value ACPI: bay: send envp with uevent - fix acpi-cpufreq: Fix some x86/x86-64 acpi-cpufreq driver issues ACPI: fix "Time Problems with 2.6.23-rc1-gf695baf2" ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help ACPI: EC: fix run-together printk lines ACPI: sbs: remove dead code ACPI: EC: acpi_ec_remove(): fix use-after-free ACPI: EC: Switch from boot_ec as soon as we find its desc in DSDT. ACPI: EC: fix build warning ACPI: EC: If ECDT is not found, look up EC in DSDT. ...
| * Pull processor into release branchLen Brown2007-08-12
| |\
| | * acpi-cpufreq: Fix some x86/x86-64 acpi-cpufreq driver issuesFenghua Yu2007-08-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch addresses some issues in x86/x86-64 acpi-cpufreq driver: 1. Current memory allocation for acpi_perf_data is actually open-coded alloc_percpu(). The patch defines and handles acpi_perf_data as percpu data. The code will be cleaner and easier to be maintained with this change. 2. Won't load driver in acpi_cpufreq_early_init() failure case. 3. Add __init for acpi_cpufreq_early_init(). Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* | | i386: Fix broken mmiocfg accessesLinus Torvalds2007-08-12
|/ / | | | | | | | | | | | | | | | | Commit 3320ad994afb2c44ad34b3b34c3c5cf0da297331 broke mmio config space accesses totally on i386 - it dropped the "reg" offset to the address. Cc: dean gaudet <dean@arctic.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | i386: Fix double fault handlerChuck Ebbert2007-08-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new percpu code has apparently broken the doublefault handler when CONFIG_DEBUG_SPINLOCK is set. Doublefault is handled by a hardware task, making the check SPIN_BUG_ON(lock->owner == current, lock, "recursion"); fault because it uses the FS register to access the percpu data for current, and that register is zero in the new TSS. (The trace I saw was on 2.6.20 where it was GS, but it looks like this will still happen with FS on 2.6.22.) Initializing FS in the doublefault_tss should fix it. AK: Also fix broken ptr_ok() and turn printks into KERN_EMERG AK: And add a PANIC prefix to make clear the system will hang AK: (e.g. x86-64 will recover) Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | i386: Fix start_kernel warningAndi Kleen2007-08-11
| | | | | | | | | | | | | | | | | | Fix WARNING: vmlinux.o(.text+0x183): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87') Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | i386: Use global flag to disable broken local apic timer on AMD CPUs.Andi Kleen2007-08-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Averatec 2370 and some other Turion laptop BIOS seems to program the ENABLE_C1E MSR inconsistently between cores. This confuses the lapic use heuristics because when C1E is enabled anywhere it seems to affect the complete chip. Use a global flag instead of a per cpu flag to handle this. If any CPU has C1E enabled disabled lapic use. Thanks to Cal Peake for debugging. Cc: tglx@linutronix.de Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | i386: really stop MCEs during code patchingAdrian Bunk2007-08-11
| | | | | | | | | | | | | | | | It's CONFIG_X86_MCE, not CONFIG_MCE. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | i386: Make patching more robust, fix paravirt issueAndi Kleen2007-08-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 "x86: Fix alternatives and kprobes to remap write-protected kernel text" uses code which is being patched for patching. In particular, paravirt_ops does patching in two stages: first it calls paravirt_ops.patch, then it fills any remaining instructions with nop_out(). nop_out calls text_poke() which calls lookup_address() which calls pgd_val() (aka paravirt_ops.pgd_val): that call site is one of the places we patch. If we always do patching as one single call to text_poke(), we only need make sure we're not patching the memcpy in text_poke itself. This means the prototype to paravirt_ops.patch needs to change, to marshal the new code into a buffer rather than patching in place as it does now. It also means all patching goes through text_poke(), which is known to be safe (apply_alternatives is also changed to make a single patch). AK: fix compilation on x86-64 (bad rusty!) AK: fix boot on x86-64 (sigh) AK: merged with other patches Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-25 13:08:15 -0500