Instead of copying the i386 Makefile and handling path substitutions
just use the i386 cpufreq Makefile.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This reverts commit e66485d747, since
Rafael Wysocki noticed that the change only works for his in -mm, not in
mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken
on his hardware, but that's apparently not a regression, just a symptom
of the same issue that causes the automatic apic timer disable to not
work).
It turns out that it really doesn't work correctly on x86-64, since
x86-64 doesn't use the generic clock events for timers yet.
Thanks to Rafal for testing, and here's the ugly details on x86-64 as
per Thomas:
"I just looked into the code and the logic vs. noapictimer on SMP is
completely broken.
On i386 the noapictimer option not only disables the local APIC
timer, it also registers the CPUs for broadcasting via IPI on SMP
systems.
The x86-64 code uses the broadcast only when the local apic timer is
active, i.e. "noapictimer" is not on the command line. This defeats
the whole purpose of "noapictimer". It should be there to make boxen
work, where the local APIC timer actually has a hardware problem,
e.g. the nx6325.
The current implementation of x86_64 only fixes the ACPI c-states
related problem where the APIC timer stops in C3(2), nothing else.
On nx6325 and other AMD X2 equipped systems which have the C1E
enabled we run into the following:
PIT keeps jiffies (and the system) running, but the local APIC timer
interrupts can get out of sync due to this C1E effect.
I don't think this is a critical problem, but it is wrong
nevertheless.
I think it's safe to revert the C1E patch and postpone the fix to the
clock events conversion."
On further reflection, Thomas noted:
"It's even worse than I thought on the first check:
"noapictimer" on the command line of an SMP box prevents _ONLY_ the
boot CPU apic timer from being used. But the secondary CPU is still
unconditionally setting up the APIC timer and uses the non
calibrated variable calibration_result, which is of course 0, to
setup the APIC timer. Wreckage guaranteed."
so we'll just have to wait for the x86 merge to hopefully fix this up
for x86-64.
Tested-and-requested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
commit 3556ddfa92 titled
[PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64
X2) with C1E enabled:
When both cores go into idle at the same time, then the system switches
into C1E state, which is basically the same as C3. This stops the local
apic timer.
This was debugged right after the dyntick merge on i386 and despite the
patch title it fixes only the 32 bit path.
x86_64 is still missing this fix. It seems that mainline is not really
affected by this issue, as the PIT is running and keeps jiffies
incrementing, but that's just waiting for trouble.
-mm suffers from this problem due to the x86_64 high resolution timer
patches.
This is a quick and dirty port of the i386 code to x86_64.
I spent quite a time with Rafael to debug the -mm / hrt wreckage until
someone pointed us to this. I really had forgotten that we debugged this
half a year ago already.
Sigh, is it just me or is there something yelling arch/x86 into my ear?
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 34feb2c83b.
Suresh Siddha points out that this one breaks the fundamental
requirement that you cannot free page table pages before the TLB caches
are flushed. The quicklists do not give the same kinds of guarantees
that the mmu_gather structure does, at least not in NUMA configurations.
Requested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Strictly it's only needed for eax.
It actually does a little more than strictly needed -- the other registers
are already zero extended.
Also remove the now unnecessary and non functional compat task check
in ptrace.
This is CVE-2007-4573
Found by Wojciech Purczynski
Signed-off-by: Andi Kleen <ak@suse.de>
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>
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>
Very old binutils (2.12.90...) seem to have trouble with newlines
in assembler macro invocation. They put them into the resulting
argument expansion. In this case this lead to a parse error because
a .rept expression ended up spread over multiple lines. Change the PMDS()
invocation to a single line.
Signed-off-by: Andi Kleen <ak@suse.de>
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>
This should fix an oops with PCMCIA PATA devices
http://bugzilla.kernel.org/show_bug.cgi?id=8424
This is not a full fix for the problem, but probably
still the right thing to do.
[ I'm almost certain it's *not* the right thing to do, but it avoids an
oops, and I want comments from others on what the right thing would
actually be.. I suspect we should just remove the use of dma_mask
entirely in this function, and just use coherent_dma_mask. - Linus ]
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
Current code assumed that devices were directly connected to a Calgary
bridge, as it tried to get the iommu table directly from the parent bus
controller.
When we have another bridge between the Calgary/CalIOC2 bridge and the
device we should look upwards until we get to the top (Calgary/CalIOC2
bridge), where the iommu table resides.
Signed-off-by: Murillo Fernandes Bernardes <mfb@br.ibm.com>
Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I have had four seperate system lockups attributable to this exact problem
in two days of testing. Instead of trying to handle all the weird end
cases and wrap, how about changing it to look for exactly what we appear
to want.
The following patch removes a couple races in setup_APIC_timer. One occurs
when the HPET advances the COUNTER past the T0_CMP value between the time
the T0_CMP was originally read and when COUNTER is read. This results in
a delay waiting for the counter to wrap. The other results from the counter
wrapping.
This change takes a snapshot of T0_CMP at the beginning of the loop and
simply loops until T0_CMP has changed (a tick has happened).
<later>
I have one small concern about the patch. I am not sure it meets the intent
as well as it should. I think we are trying to match APIC timer interrupts up
with the hpet counter increment. The event which appears to be disturbing
this loop in our test environment is the NMI watchdog. What we believe has
been happening with the existing code is the setup_APIC_timer loop has read
the CMP value, and the NMI watchdog code fires for the first time. This
results in a series of icache miss slowdowns and by the time we get back to
things it has wrapped.
I think this code is trying to get the CMP as close to the counter value as
possible. If that is the intent, maybe we should really be testing against a
"window" around the CMP. Something like COUNTER = CMP+/2. It appears COUNTER
should get advanced every 89nSec (IIRC). The above seems like an unreasonably
small window, but may be necessary. Without documentation, I am not sure of
the original intent with this code.
In summary, this code fixes my boot hangs, but since I am not certain of the
intent of the existing code, I am not certain this has not introduced new bugs
or unexpected behaviors.
Signed-off-by: Robin Holt <holt@sgi.com>
Acked-by: Andi Kleen <ak@suse.de>
Cc: Vojtech Pavlik <vojtech@suse.cz>
Cc: "Aaron Durbin" <adurbin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
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>
Remove unused TIF_NOTIFY_RESUME flag for all processor architectures. The
flag was not used excecpt on IA-64 where the patch replaces it with
TIF_PERFMON_WORK.
Signed-off-by: stephane eranian <eranian@hpl.hp.com>
Cc: <linux-arch@vger.kernel.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix section mismatch warnings:
these functions are called only from __init functions.
WARNING: vmlinux.o(.text+0x1861c): Section mismatch: reference to .init.text:free_bootmem (between 'free_tce_table' and 'build_tce_table')
WARNING: vmlinux.o(.text+0x187e5): Section mismatch: reference to .init.text:__alloc_bootmem_low (between 'alloc_tce_table' and 'kretprobe_trampoline_holder')
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
