To simplify the scripted move of the mach-xxx directories, change
the makerules to the full arch/.... path.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
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>
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>
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>
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>
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>
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>
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 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>
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>
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
commit 656dad312f
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
For hugepage mappings, the file offset, like the address and size, needs to
be aligned to the size of a hugepage.
In commit 68589bc353, 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 4b1d89290b, 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>
* '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
...
* '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
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>
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>
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 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>
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>
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>
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>
With commit ab144f5ec6 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>
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>
Fixed wrong expression which enabled watchdogs even if nmi_watchdog kernel
parameter wasn't set. This regression got slightly introduced with commit
b7471c6da9.
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=298084http://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>
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>
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>
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>
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>
* '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.
...
Commit 3320ad994a 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>
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>
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>
Commit 19d36ccdc3 "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>
It turns out CLFLUSH support is still not complete; we
flush the wrong pages. Again disable it for the release.
Noticed by Jan Beulich who then also noticed a stupid typo later.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some broken devices have been discovered to require %al/%ax/%eax registers
for MMIO config space accesses. Modify mmconfig.c to use these registers
explicitly (rather than modify the global readb/writeb/etc inlines).
AK: also changed i386 to always use eax
AK: moved change to extended space probing to different patch
AK: reworked with inlines according to Linus' requirements.
AK: improve comments.
Signed-off-by: dean gaudet <dean@arctic.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch finishes the i386 and x86-64 ->sysdata conversion and hopefully
also fixes Riku's and Andy's observed bugs. It is based on Yinghai Lu's
and Andy Whitcroft's patches (thanks!) with some changes:
- introduce pci_scan_bus_with_sysdata() and use it instead of
pci_scan_bus() where appropriate. pci_scan_bus_with_sysdata() will
allocate the sysdata structure and then call pci_scan_bus().
- always allocate pci_sysdata dynamically. The whole point of this
sysdata work is to make it easy to do root-bus specific things
(e.g., support PCI domains and IOMMU's). I dislike using a default
struct pci_sysdata in some places and a dynamically allocated
pci_sysdata elsewhere - the potential for someone indavertantly
changing the default structure is too high.
- this patch only makes the minimal changes necessary, i.e., the NUMA node is
always initialized to -1. Patches to do the right thing with regards
to the NUMA node can build on top of this (either add a 'node'
parameter to pci_scan_bus_with_sysdata() or just update the node
when it becomes known).
The patch was compile tested with various configurations (e.g., NUMAQ,
VISWS) and run-time tested on i386 and x86-64. Unfortunately none of my
machines exhibited the bugs so caveat emptor.
Andy, could you please see if this fixes the NUMA issues you've seen?
Riku, does this fix "pci=noacpi" on your laptop?
Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Chuck Ebbert <cebbert@redhat.com>
Cc: <riku.seppala@kymp.net>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
Add a missing =m constraint to the EDD-probing code, that could have
caused improper dead-code elimination.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add memory operand constraint and write-only modifier to the inline
assembly to effect the writing of the EDID block to boot_params.edid_info.
Without this, gcc would think the EDID query was dead code and would
eliminate it.
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup:
[x86 setup] EDD: Fix the computation of the MBR sector buffer
[x86 setup] Newline after setup signature failure message
x86 boot code comments typos
C files should include the header files that prototype their functions.
Eliminates a sparse warning:
warning: symbol 'check_bugs' was not declared. Should it be static?
Signed-off-by: Josh Triplett <josh@kernel.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>
On make install I get the this error:
...
sh /work/crazy/linux-git/linux-2.6/arch/i386/boot/install.sh
2.6.22-g4eb6bf6b arch/i386/boot/bzImage System.map "/boot"
/work/crazy/linux-git/linux-2.6/arch/i386/boot/install.sh: line 54:
/etc/lilo/install: No such file or directory
make[1]: *** [install] Error 127
...
I don't use and don't have lilo installed on this system. The attached
patch fixes the problem for me.
Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Cc: Sam Ravnborg <sam@ravnborg.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>
arch/i386/kernel/apm.c: In function 'apm_init':
arch/i386/kernel/apm.c:2240: warning: format '%lx' expects type 'long
unsigned int', but argument 3 has type 'u32'
apm_info.bios.offset is of type 'u32'.
Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert 7e92b4fc34. It broke Sébastien Dugué's
machine and Jeff said (persuasively)
This seems like it will break decades-long-working stuff, in favor of
breaking new ground in our favorite area, "trusting the BIOS."
It's just not worth it for serial ports, IMO. Serial ports are something
that just shouldn't break at this late stage in the game. My new Intel
platform boxes don't even have serial ports, so I question the value of
messing with serial port probing even more... because... just wait a year,
and your box won't have a serial port either! :)
I certainly don't object to the use of platform devices (or isa_driver),
but the probe change seems questionable. That's sorta analagous to
rewriting the floppy driver probe routine. Sure you could do it... but why
risk all that damage and go through debugging all over again?
It seems clear from this report that we cannot, should not, trust BIOS for
something (a) so simple and (b) that has been working for over a decade.
Much discussion ensued and we've decided to have another go at all of this.
Cc: Sébastien Dugué <sebastien.dugue@bull.net>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Sascha Sommer <saschasommer@freenet.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The local variable "covered" is used without initialization in i386
acpi-cpufreq driver. The initial value of covered should be 0. The bug
will cause memory leak when hit. The following patch fixes this bug.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some BIOSes require that sector buffers not cross 64K
boundaries. As a result, we compute a dynamic address on the
setup heap. Unfortunately, this address computation was just
totally wrong.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
End the "No setup signature found..." with a newline (the puts
routine will automatically add a carriage return.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Commit 296699de6b broke building APM
support if CONFIG_PM_SLEEP is not set.
Reported by Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
[ Simplified a bit as suggested by Rafael. -Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Restore the 2.6.22 CONFIG_ACPI_SLEEP build option, but now shadowing the
new CONFIG_PM_SLEEP option.
Signed-off-by: Len Brown <len.brown@intel.com>
[ Modified to work with the PM config setup changes. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION to avoid
confusion (among other things, with CONFIG_SUSPEND introduced in the
next patch).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts most of commit 19d36ccdc3.
The way to DEBUG_RODATA interactions with KPROBES and CPU hotplug is to
just not mark the text as being write-protected in the first place.
Both of those facilities depend on rewriting instructions.
Having "helpful" debug facilities that just cause more problem is not
being helpful. It just adds complexity and bugs. Not worth it.
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes the following compile error introduced by
commit e8666b2718 and reported
by Alexey Dobriyan:
<-- snip -->
CC arch/i386/kernel/acpi/cstate.o
In file included from arch/i386/kernel/acpi/cstate.c:17:
include/acpi/processor.h:88: error: expected specifier-qualifier-list before 'acpi_integer'
<-- snip -->
If you select something you must ensure that the dependencies of what
you are selecting are fulfilled.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Alexey Dobriyan <adobriyan@sw.ru>
Cc: Joshua Hoblitt <jhoblitt@ifa.hawaii.edu>
Cc: Dave Jones <davej@redhat.com>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Make "struct ist_info" valid on both i386 and x86-64, and use the
structure by name in the setup code. Additionally, "Intel SpeedStep
IST" is redundant, refer to it as IST consistently.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For APM calls, BX contains the device index, which is zero for
the system BIOS. Disconnect requres BX = 0.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Starting with kernel 2.6.23-rc1, the i386 APM driver fails
on several of my machines with the message:
apm: BIOS not found
This happens because of a bug in the i386 boot code rewrite
from assembler to C. The original assembly code had the
following code in its APM BIOS presence test (boot/setup.S):
andw $0x02, %cx # Is 32 bit supported?
je done_apm_bios # No 32-bit, no (good) APM BIOS
That is, the code bails out if bit 2 is zero.
In the new C version, this is coded as (boot/apm.c):
if (cx & 0x02) /* 32 bits supported? */
return -1;
Here we see that the test has been accidentally inverted.
The fix is to negate the test. I've verified that this
allows the APM driver to work again on my affected machines.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
As it was a synonym for (CONFIG_ACPI && CONFIG_X86),
the ifdefs for it were more clutter than they were worth.
For ia64, just add a few stubs in anticipation of future
S3 or S4 support.
Signed-off-by: Len Brown <len.brown@intel.com>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (77 commits)
ACPI: Populate /sys/firmware/acpi/tables/
ACPI: create CONFIG_ACPI_DEBUG_FUNC_TRACE
ACPI: update ACPI proc I/F removal schedule
ACPI: update feature-removal-schedule.txt, /sys/firmware/acpi/namespace is gone
ACPI: export ACPI events via acpi_mc_group multicast group
ACPI: fix empty macros found by -Wextra
ACPI: drivers/acpi/pci_link.c: lower printk severity
sony-laptop: Fix event reading in sony-laptop
sony-laptop: Add Vaio FE to the special init sequence
sony-laptop: Make the driver use MSC_SCAN and a setkeycode and getkeycode key table.
sony-laptop: Invoke _INI for SNC devices that provide it
sony-laptop: Add support for recent Vaios Fn keys (C series for now)
sony-laptop: map wireless switch events to KEY_WLAN
sony-laptop: add new SNC handlers
ACPI: thinkpad-acpi: add locking to brightness subdriver
ACPI: thinkpad-acpi: bump up version to 0.15
ACPI: thinkpad-acpi: make EC-based thermal readings non-experimental
ACPI: thinkpad-acpi: make sure DSDT TMPx readings don't return +128
ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key
ACPI: thinkpad-acpi: allow use of CMOS NVRAM for brightness control
...
The performance counters on K7 are only 48 bits wide, so using bit 63 to
check if the counter overflowed is wrong. Let's use bit 47 instead.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Cc: Don Zickus <dzickus@redhat.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I got an oops while booting a 32bit kernel on KVM because it doesn't
implement performance counters used by the NMI watchdog. Handle this
case.
Cc: Avi Kivity <avi@qumranet.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Due to index register access ordering problems, when using macros a line
like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions this line will work as expected.
Note about a side effect: Seems on Geode GX1 based systems the
"suspend on halt power saving feature" was never enabled due to this
wrong macro expansion. With inlined functions it will be enabled, but
this will stop the TSC when the CPU runs into a HLT instruction.
Kernel output something like this:
Clocksource tsc unstable (delta = -472746897 ns)
This is the 3rd version of this patch.
- Adding missed arch/i386/kernel/cpu/mtrr/state.c
Thanks to Andres Salomon
- Adding some big fat comments into the new header file
Suggested by Andi Kleen
AK: fixed x86-64 compilation
Signed-off-by: Juergen Beisert <juergen@kreuzholzen.de>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kstat_irqs(0) includes the count of interrupt 0 from all cpus, not just
the current cpu. The updated interrupt 0 on other cpus can stop the
nmi_watchdog from tripping, so only include the current cpu's int 0.
Signed-off-by: Keith Owens <kaos@ocs.com.au>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This mainly changes the nops for alternative, so not very revolutionary.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When a machine check or NMI occurs while multiple byte code is patched
the CPU could theoretically see an inconsistent instruction and crash.
Prevent this by temporarily disabling MCEs and returning early in the
NMI handler.
Based on discussion with Mathieu Desnoyers.
Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reenable kprobes and alternative patching when the kernel text is write
protected by DEBUG_RODATA
Add a general utility function to change write protected text. The new
function remaps the code using vmap to write it and takes care of CPU
synchronization. It also does CLFLUSH to make icache recovery faster.
There are some limitations on when the function can be used, see the
comment.
This is a newer version that also changes the paravirt_ops code.
text_poke also supports multi byte patching now.
Contains bug fixes from Zach Amsden and suggestions from Mathieu
Desnoyers.
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: Zach Amsden <zach@vmware.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch makes the i386 behave the same way that x86_64 does when a
segfault happens. A line gets printed to the kernel log so that tools
that need to check for failures can behave more uniformly between
debug.show_unhandled_signals sysctl variable to 0 (or by doing echo 0 >
/proc/sys/debug/exception-trace)
Also, all of the lines being printed are now using printk_ratelimit() to
deny the ability of DoS from a local user with a program like the
following:
main()
{
while (1)
if (!fork()) *(int *)0 = 0;
}
This new revision also includes the fix that Andrew did which got rid of
new sysctl that was added to the system in earlier versions of this.
Also, 'show-unhandled-signals' sysctl has been renamed back to the old
'exception-trace' to avoid breakage of people's scripts.
AK: Enabling by default for i386 will be likely controversal, but let's see what happens
AK: Really folks, before complaining just fix your segfaults
AK: I bet this will find a lot of silent issues
Signed-off-by: Masoud Sharbiani <masouds@google.com>
Signed-off-by: Andi Kleen <ak@suse.de>
[ Personally, I've found the complaints useful on x86-64, so I'm all for
this. That said, I wonder if we could do it more prettily.. -Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch introduces struct pci_sysdata to x86 and x86-64, and
converts the existing two users (NUMA, Calgary) to use it.
This lays the groundwork for having other users of sysdata, such as
the PCI domains work.
The Calgary bits are tested, the NUMA bits just look ok.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dead or misnamed CONFIG_BALANCED_IRQ_DEBUG found by Robert P. J. Day.
It's not a Kconfig variable.
Since this debug code is ancient, I suggest to get rid of this
misleading CONFIG_ macro by deleting all of this debug code.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "Robert P. J. Day" <rpjday@mindspring.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Insert HPET resources after pci probing has been completed in order to
avoid resource conflicts with PCI resource reservation. With this change
the HPET firmware resources will be identified, but it should also not
cause issues when the HPET address falls on a BAR in a PCI device, and the
PCI enumeration cannot reserve the resources.
Signed-off-by: Aaron Durbin <adurbin@google.com>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This builds upon the existing geode infrastructure, but adds southbridge
support, some GPIO functions, and a header file (asm-i386/geode.h) with some
useful GX/LX detection tests.
The majority of this code was written by Jordan Crouse.
Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Signed-off-by: Andres Salomon <dilinger@debian.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
get_vm_area always returns an area with an adjacent guard page. That guard
page is included in vm_struct.size. iounmap uses vm_struct.size to
determine how much address space needs to have change_page_attr applied to
it, which will BUG if applied to the guard page.
This patch adds a helper function - get_vm_area_size() in linux/vmalloc.h -
to return the actual size of a vm area, and uses it to make iounmap do the
right thing. There are probably other places which should be using
get_vm_area_size().
Thanks to Dave Young <hidave.darkstar@gmail.com> for debugging the
problem.
[ Andi, it wasn't clear to me whether x86_64 needs the same fix. ]
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
setup_pit_timer is declared in asm-i386/timer.h. Move it to the pit header
file, so it can be used by x86_64 as well.
Move also the PIT constants.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: john stultz <johnstul@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I fixed this in x86_64. Looks like the kind of thing that will break voyager
on i386.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: john stultz <johnstul@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove the volatile in apic. We have a cpu_relax() in the wait loop. Fix a
coding style issue while at it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We are seeing corruption of the decompressed kernel. It is suspected that
this is platform specific as it has yet to be seen on any other x86. Move
the kernel to the 16MB boundary.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove unneeded test of task != NULL from
arch/i386/kernel/traps.c::dump_trace()
At the start of the function we have this test:
if (!task)
task = current;
so further down there's no need to test 'task'.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
PAE is useful for more than supporting more than 4GB RAM. It supports
expanded swapspace and NX executable protections. Some users may want NX
or expanded swapspace support without the overhead or instability of
highmem. For these reasons, the following patch divorces CONFIG_X86_PAE
from CONFIG_HIGHMEM64G.
Cc: Mark Lord <lkml@rtr.ca>
Signed-off-by: William Irwin <wli@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some systems have a HPET which is not incrementing, which leads to a
complete hang. Detect it during HPET setup.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: john stultz <johnstul@us.ibm.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The following patch enables reboot through BIOS on the Dell Optiplex 745
Small Form Factor base, on which reboot hangs. The larger form factor does
not require this, hence the match on DMI_BOARD_NAME.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On some systems the ACPI NVS area is located in the first 1 MB of RAM and
it is overwritten by the i386 code during the restore after hibernation.
This confuses the ACPI platform firmware that doesn't update the AC adapter
status appropriately as a result
(http://bugzilla.kernel.org/show_bug.cgi?id=7995).
The solution is to register the reserved memory in the first 1 MB as
'nosave', so that swsusp doesn't touch it during the restore. Also, this
has been done on x86_64 for a long time now, so this patch makes the i386
restore code behave like the x86_64 one.
[akpm@linux-foundation.org: build fix]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix following warning:
WARNING: arch/i386/kernel/built-in.o(.init.text+0x3818): Section mismatch: reference to .exit.text:cache_remove_dev (between 'cacheinfo_cpu_callback' and 'cache_sysfs_init')
It points out that a function marked __cpuexit is calling a function marked
__cpuinit => oops.
The call happens only in an error-condition which may explain why we have
not seen it before.
The offending function was not used anywhere else - so marked it __cpuexit.
Note: This warning triggers only with a local copy of modpost
but that version will soon be pushed out.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
pgd_{c,d}tor() can now become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Rise CPUs were only very short-lived, and there are no reports of
anyone both owning one and running Linux on it.
Googling for the printk string "CPU: Rise iDragon" didn't find any dmesg
available online.
If it turns out that against all expectations there are actually users
reverting this patch would be easy.
This patch will make the kernel images smaller by a few bytes for all
i386 users.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
