getcpu system call returns cpu# and node# on which this system call and
its caller are running. This patch hooks up its implementation on IA64.
Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Eliminate arch specific memory_present call ia64 NUMA by utilizing
sparse_memory_present_with_active_regions.
Acked-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NBob Picco <bob.picco@hp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

On the ia64 architecture only this patch upgrades show_mem() for sparse
memory to be the same as it was for discontig memory.  It has been shown to
work on NUMA and flatmem architectures.
Signed-off-by: NGeorge Beshers <gbeshers@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Add missing exports to allow several drivers to be built as module with
CONFIG_IA64_HP_ZX1_SWIOTLB.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Occasionally the FSYS_RETURN patch list can have an odd length, causing other
data structures to get out of alignment.  In OpenVZ it is odd and we get
misaligned kernel image, which does not boot.
Signed-off-by: NAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: NKirill Korotaev <dev@openvz.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

While pursuing and unrelated issue with 64Mb granules I noticed a problem
related to inconsistent use of add_active_range.  There doesn't appear any
reason to me why FLATMEM versus DISCONTIG_MEM should register memory to
add_active_range with different code.  So I've changed the code into a
common implementation.

The other subtle issue fixed by this patch was calling add_active_range in
count_node_pages before granule aligning is performed.  We were lucky with
16MB granules but not so with 64MB granules.  count_node_pages has reserved
regions filtered out and as a consequence linked kernel text and data
aren't covered by calls to count_node_pages.  So linked kernel regions
wasn't reported to add_active_regions.  This resulted in free_initmem
causing numerous bad_page reports.  This won't occur with this patch
because now all known memory regions are reported by
register_active_ranges.
Acked-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NBob Picco <bob.picco@hp.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Don't force CONFIG_SWIOTLB on when not actually needed (i.e. HP_ZX1 and
SGI_SN2).
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The shub2 error interrupt handler must check for TIO errors.

Signed-off-by: Russ Anderson (rja@sgi.com)
Signed-off-by: NTony Luck <tony.luck@intel.com>

When we offline a CPU, migrate_irqs() tries to determine whether the
affinity bits of the IRQ descriptor match any of the remaining online
CPUs.  If not, it fixes up the interrupt to point somewhere else.
Unfortunately, if an IRQ is unregistered the IRQ descriptor may still
have affinity to the CPU being offlined, but the no_irq_chip handler
doesn't provide a set_affinity function.  This causes us to hit the
WARN_ON in migrate_irqs().

The easiest solution seems to be setting all the bits in the affinity
mask when the last interrupt is removed from the vector.  I hit this on
an older kernel with Xen/ia64 using driver domains (so it probably needs
more testing on upstream).  Xen essentially uses the bind/unbind
interface in sysfs to unregister a device from a driver and thus
unregister the interrupt.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

All IA64 systems except IA64_HP_SIM include ACPI and PCI.
So prevent IA64 Kconfigs that try to do irritating things like building
PCI without building ACPI.
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch fixes a NULL-pointer dereference in ia64_machine_kexec().

The variable ia64_kimage is set in machine_kexec_prepare() which is
called from sys_kexec_load(). If kdump wasn't configured before,
ia64_kimage is NULL.  machine_kdump_on_init() passes ia64_kimage() to
machine_kexec() which assumes a valid value.

The patch also adds a few sanity checks for the image to simplify
debugging of similar problems in future.
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Signed-off-by: NTony Luck <tony.luck@intel.com>

I encountered one problem when running ptrace test case the situation
is this: traced process's syscall parameter needs to be accessed, but
for sys_clone system call with clone_flag (CLONE_VFORK | CLONE_VM |
SIGCHLD) parameter.  This syscall's parameter accessing result is wrong.

The reason is that vforked child process mm point is the same, but
tgid is different. Without this patch find_thread_for_addr will return
vforked process if vforked process is also stopped, but not the thread
which calls vfork syscall.
Signed-off-by: NTony Luck <tony.luck@intel.com>

Some patches have turned up on xen-devel recently to convert strcpy()
to safer alternatives and so forth.  While reviewing those patches
I noticed that the features string building could be cleaned up.

This patch uses snprintf() instead of strcpy() and direct character
pointer manipulation.  It makes the features string building safe and
gets rid of the special case for features output in show_cpuinfo()

Additionally I removed the (int) cast of ARRAY_SIZE, which seems to
serve no purpose.
Signed-off-by: NAron Griffis <aron@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

As is pointed out in
http://www.gelato.org/community/view_linear.php?id=1_1036&from=authors&value=Ian%20Wienand#1_1039,
if single step on break instruction, the break fault has higher
priority than the single-step trap. When the break fault handler
is entered, it advances the IP by 1 instruction so break instruction
single-stepping is skipped, actually it is next instruction which
is single stepped.

This patch modifies this, it adds TIF_SINGLESTEP bit for thread
flags, and generate a fake sigtrap when single stepping break
instruction. Test case in attachment can verify this. Any comments
is welcome.
Signed-off-by: Nbibo, mao <bibo.mao@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This moves the ia64 implementation of machine_shutdown() from
machine_kexec.c to process.c, which is in keeping with the implelmentation
on other architectures, and seems like a much more appropriate home for it.
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Remove the Remove inline declaration of efi_get_pal_addr() as it is
declared in linux/efi.h.
Signed-Off-By: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

linux/uaccess.h was being included, but it seems that
really the following includes are needed.

asm/page.h: for __va() and PAGE_SHIFT
asm/uaccess.h: for copy_to_user()

I guess that linux/uaccess.h pulls in both asm/page.h and asm/uaccess.h.
I notices this while backporting the code to xen's linux-2.6.16.33,
which does not have linux/uaccess.h. I'm posting it as I think it is a
correct, though somewhat cosmetic fix.
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Fix a typo in the saved_max_pfn description in contig.c
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Set saved_max_pfn when discontig memory is in use.

This sets up saved_max_pfn when disctontig memory is in use.
This mirrors the code for contig memory.

This patch does not entirely solve the problem of making vmcore work,
however it does appear to be neccessary. Please consider applying.
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Kexec support for 2.6.20 on ia64 does not build properly using a config
made up by CONFIG_SMP=n and CONFIG_HOTPLUG_CPU=n:
Signed-off-by: NMagnus Damm <magnus@valinux.co.jp>
Acked-by: NSimon Horman <horms@verge.net.au>
Acked-by: NJay Lan <jlan@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

When calling into the EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
(efi.get_time is called during the suspend phase).
Signed-off-by: NFrederic Riss <frederic.riss@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The SN Altix platform does not conform to the IOSAPIC IRQ routing model.
Add code in acpi_unregister_gsi() to check if (acpi_irq_model ==
ACPI_IRQ_MODEL_PLATFORM) and return.

Due to an oversight, this code was not added previously when
similar code was added to acpi_register_gsi().

http://marc.theaimsgroup.com/?l=linux-acpi&m=116680983430121&w=2Signed-off-by: NJohn Keller <jpk@sgi.com>
Acked-by: NLen Brown <lenb@kernel.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch fixes up ia64 kexec support for HP rx2620 hardware.  It does
this by skipping migration of already disabled irqs.  This is most likely a
problem on other ia64 platforms as well, but I've only been able to
reproduce it on one machine so far.

The full story is that handle_bad_irq() gets invoked before starting the
new kernel without this patch.  This seems to happen when fixup_irqs()
calls generic_handle_irq() on already migrated (and disabled) irqs.  So by
avoiding migration of disabled irqs we stay away of handle_bad_irq().

The code has been tested on three different ia64 machines, all with good
results.  It is possible to trigger the same bug by offlining a processor
using echo 0 > /sys/devices/system/cpu/cpuX/online.

More detailed information is available in the following mail thread:
http://lists.osdl.org/pipermail/fastboot/2007-January/thread.html#5774Signed-off-by: NMagnus Damm <magnus@valinux.co.jp>
Acked-by: NSimon Horman <horms@verge.net.au>
Acked-by: NZou, Nanhai <nanhai.zou@intel.com>
Acked-by: NJay Lan <jlan@sgi.com>
Acked-by: N"Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit e4f0ae0e.

It's not wrong, but it's not right either, and everybody seems to agree
that the right fix is probably to do the ccr3 write after the ccr4 one
(and that we also should clean it up a bit).  And after that we need to
really validate that all the bits that we write to ccr4 actually do
work.

The old 2.6.19 code was insane, and basically didn't change ccr4 at all
(even though it certainly looks like it was the *intent* to do so).  So
let's revert the change that may fix things, just because it's not what
was actually ever tested when the code was written, even if it _was_ the
intent.

There's a discussion on http://lkml.org/lkml/2007/1/9/63 that was
started by the patch that now gets reverted, and that discussion may
well contain the proper long-term fix.
Suggested-by: NAdrian Bunk <bunk@stusta.de>
Acked-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

a) sun4d_boot_one_cpu() should be __cpuinit (called only from
   __cpuinit __cpu_up(), for one thing, leads to calls of __cpuinit
   functions for another).
b) got externs in arch/sparc/kernel/smp.c to match reality.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

i386 boot/compressed/relocs checks for absolute symbols and warns about
unexpected ones.  If you build with modversions, you get ~2500 warnings
about __crc_<symbol>.  These suckers are really absolute symbols - we
do _not_ want to modify them on relocation.

They are generated by genksyms - EXPORT_... generates a weak alias, then
genksyms produces an ld script with __crc_<symbol> = <checksum> and it's
fed to ld to produce the final object file.  Their only use is to match
kernel and module at modprobe time; they _must_ be absolute.

boot/compressed/relocs has a whitelist of known absolute symbols, but
it doesn't know about __crc_... stuff.  As the result, we get shitloads
of false positives on any ld(1) version.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

... and having it __init is a bad idea.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use the same signal frame alignment calculations as the underlying
architecture.  x86_64 appeared to do this, but the "- 8" was really
subtracting 8 * sizeof(struct rt_sigframe) rather than 8 bytes.

UML/i386 might have been OK, but I changed the calculation to match
i386 just to be sure.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Cc: <stable@kernel.org>
Cc: Adrian Bunk <bunk@stusta.de>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: NAntoine Martin <antoine@nagafix.co.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Kconfig recognizes the end of help text by receding indentation depth.
Recent patch had broken HOST_VMSPLIT_... choice in arch/um/Kconfig.i386 -
all alternatives are interpreted as part of help text now.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When the world was a simple and static place setting up irqs was easy.
It sufficed to allocate a linux irq number and a find a free cpu
vector we could receive that linux irq on.  In those days it was
a safe assumption that any allocated vector was actually in use
so after one global pass through all of the vectors we would have
none left.

These days things are much more dynamic with interrupt controllers
(in the form of MSI or MSI-X) appearing on plug in cards and linux
irqs appearing and disappearing.  As these irqs come and go vectors
are allocated and freed,  invalidating the ancient assumption that all
allocated vectors stayed in use forever.

So this patch modifies the vector allocator to walk through every
possible vector before giving up, and to check to see if a vector
is in use before assigning it.  With these changes we stop leaking
freed vectors and it becomes possible to allocate and free irq vectors
all day long.

This changed was modeled after the vector allocator on x86_64 where
this limitation has already been removed.  In essence we don't update
the static variables that hold the position of the last vector we
allocated until have successfully allocated another vector.  This
allows us to detect if we have completed one complete scan through
all of the possible vectors.
Acked-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Reported by Robert P. J. Day <rpjday@mindspring.com>.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NJan Altenberg <jan@linutronix.de>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The S3C2412 DMA selection code has the
arguments to writel() the wrong way around.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This workaround unnecessarily cripples functionality to work
around an errata that doesn't seem possible to hit due to
us using the automatic clock throttling in the p4 mcheck code.

See http://lkml.org/lkml/2006/10/28/148 for complete reasoning
and lack of disconsent.
Signed-off-by: NDave Jones <davej@redhat.com>

A stupid bug has been plaguing the sys_pciconfig_iobase on ppc64. It wasn't
noticed until recently as it seems to not affect G5s but it's been causing
problems running X servers on some other machines recently. The bus number
matching was bogus.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Add a comment to the PS3 config option to inform users that the current
implementation is not yet complete.
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Mirror the logic in the sun4u handler, we have to update
both registers even when we branch out to window fault
fixup handling.

The way it works is that if we are in etrap processing a
fault already, g4/g5 holds the original fault information.
If we take a window spill fault while doing etrap, then
we put the window spill fault info into g4/g5 and this is
what the top-level fault handler ends up processing first.

Then we retry the originally faulting instruction, and
process the original fault at that time.

This is all necessary because of how constrained the trap
registers are in these code paths.  These cases trigger
very rarely, so even if there is some performance implication
it's doesn't happen very often.  In fact the rarity is why
it took so long to trigger and find this particular bug.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>