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>
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>
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>
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>
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>
Thomas Gleixner
Rafal Bilski
H. Peter Anvin
Andi Kleen
Daniel Walker
Stephane Eranian
Roland McGrath
Linus Torvalds