Trying to port some patches from i386 to ia64 I've found that
show_trace_task is the only portable way to show tasks' call
traces(perhaps because it is called from ./kernel/sched.c:)).
But its ia64 implementation can't work with running task.

Attached patch fixes this issue.

As I understand show_trace and show_stack are platform
dependent or have different sense/args.

Here's patches for 2.4 & 2.5 to use PAL_HALT_LIGHT in cpu_idle.
This helps to reduce CPU temp a little on boxes with firmware that
takes advantage of this lower power state.  I've tried this on a
rx2600 (2x900MHz McKinley) and an i2000 (fw 117) and it shows some
benefit.  On McKinley systems, only the very latest PAL from Intel
actually reduces power consumption in the halt_light state.  For HP
rx2600/zx6000/zx2000, this means you need to be running firmware 1.82.

  Rohit Seth, at Intel, has run some benchmarks with this kind of
modification and found the effects of enabling halt_light to fall
within the noise of mosts tests.  I replaced pal_halt(1) in safe_halt
with pal_halt_light() since halt_light is required to be implemented,
but pal_halt(1) is an optional halt state.  I'd be interested to hear
of any measurements anyone does using this, where it works/fails, and
if any benchmarks/applications are impacted.

David, here's an updated patch that doesn't mess with
arch/ia64/Makefile in case you hadn't applied the last one yet

Here is a simple patch to also print isr during the handling of a
floating point assist fault.

The consensus on lkml was that devices should do reads from safe
registers to ensure PIO write ordering, which means we no longer need
mmiob.  This patch removes the mmiob entries from the machine vector
headers and io.h and updates the documentation about PIO ordering.

should not use such innocent variable names like tmp because they
have a high probability to clash with (part of) the argument.

The patch allows unw_access_gr() to read from r0, to support unwind
directives such as .save ar.pfs,r0 and .save rp,r0.

Here is a patch to have the POSIX timer interface completly integrated
in ia64 (2.5.64). The programs in userland can now access the siginfo
structure. With that patch the test programs of the high resolution
timers pass without error but one which seems to also be triggered on
ix86: nanosleeps too short.

do_fork is declared as:
struct task_struct *do_fork(unsigned long clone_flags,
                            unsigned long stack_start,
                            struct pt_regs *regs,
                            unsigned long stack_size,
                            int *parent_tidptr,
                            int *child_tidptr)
ie. parent_tidptr is out4 and child_tidptr is out5, but
the comments in clone2 were suggesting otherwise.
So, we either need a patch which will codify current order
of clone arguments (ie. ptid, ctid, tls; attached below - has the advantage
that clone2 stays with the same ABI as in 2.5.[56]x), or the arguments
of clone2 and clone should be reordered to match the IA-32 order
(which is ptid, tls, ctid).

While you're fixing bitops.h, making test_bit take a const qualified
arg will kill some warnings in reiserfs...

Here's another feature I'd like to add to MCA support; the ability
to detect a flood of CMCs and switch to polling mode for retrieving
CMC logs.  Once no more CMC logs are found, return to and interrupt
driven handler.  If the flood threshold is never reached, the CMC
handler simply behaves as it does today.

   It's useful to get the CMC logs to know that something isn't
quite right, but if you end up with some bad memory it's too easy for
them to interfere with useful work.  I've tested this on an HP rx2600,
with a known bad DIMM.  This DIMM acts like it has a completely dead
DRAM on it.  With the current CMC handler, once I hit that range of
memory addresses, the system essentially dies, constantly handling
CMC errors.  With this patch, the system hits the threshold quickly,
but remains functional with no performance degredation once in polling
mode.  This patch applies against linux-2.4.20-ia64-021210 and 
includes:

 - Switching CMCs to polling mode at predeterimined threshold
 - If polling for CPEs, poll on all processors
 - Fix timestamp on log output

	in kernel unwinder.

Make CONFIG_SYSCTL control sys32_sysctl as well.  Based on a patch from Peter Chubb.

Andy Grover told me this should be posted here.  It allows ACPI to
compile even with PCI turned off.  Patch against 2.5.60.

ia 64 part of the patch.  This gives you a 32 bit version of sys_futex (hopefully).

	triggered by NaT-page-consumption faults.

	can be optimized properly.

	ensure that PCI line-size gets programmed properly.  Based
	on patch by Grant Grundler.

	Keith Owens.

Latest premption patch.

Please find attached a small hugetlb page support update for 2.5.60
IA-64 kernel (+ my previous hugetlb page patch).  This patch adds the
HAVE_ARCH_HUGETLB_UNMAPPED_AREA define for IA-64 arch.
hugetlb_get_unmapped_area function is added in
arch/ia64/mm/hugetlbpage.c

Please find attached a hugetlb page patch for IA-64 2.5.60 kernel .
Changes in generic files are mostly backported from 2.5.62 (to get
hugetlb support functioning properly).

 - Cleanup Makefile.
 - Fix potentional crash in dv1394 module unload.
 - Why does ARM's memcpy not return void*? Oh well, work around it in
  eth1394 by not expecting standard behavior.

And here's the SN specific part of the update.  This should get an SN2
compile all the way to the link stage, where I still have some devfs
stuff to cleanup.

Here's an update to the ia64 mmzone.h file that adds some SN2 specific
defines (which will probably have to be changed later, but it's a
start).

IA64 ABI specifies that globals > 8 bytes need to be aligned to 16 bytes.
gcc doesn't follow this convention. Current kernel code will fail to work with
a compiler which follows the ABI.

size of structure ia64_machine_vector is > 8 bytes and not multiple of 16 bytes.
When we have CONFIG_IA64_GENERIC, each machine specific vector from different
object files gets linked into a user defined section(forming array of
structures).

Now with a compiler conforming to ABI, there will be holes in this array
resulting in the code failure when it goes through this array of structures.

Following patch will make the size of the structure to be multiple of 16 bytes
making both ABI confirming/non-conforming compilers happy.