This removes platform_pci_dma_address.  Since the scatterlist
in 2.5 has a dma_address, seems like we can expect a certain usage
of it.  SGI folks may want to verify this doesn't break their DMA
engines.

trivial build fix for the generic kernel target

      Fix spelling of Hewlett-Packard.

3) with CONFIG_NUMA set, there are undefined symbols building modules:

scripts/modpost vmlinux drivers/md/dm-mod.o drivers/net/e1000/e1000.o drivers/net/eepro100.o drivers/md/md.o drivers/net/mii.o fs/xfs/xfs.o
*** Warning: cpu_info__per_cpu [fs/xfs/xfs.ko] undefined!
*** Warning: cpu_info__per_cpu [drivers/md/md.ko] undefined!
*** Warning: cpu_to_node_map [drivers/md/md.ko] undefined!

exporting them in ia64_ksyms.c fixes the problem.

Consolidate the uses of
cpu_is_online() to use the (relatively) new
cpu_online() macro.

We need readX() to be machine vectors since some platforms don't provide
DMA coherence via PIO reads (PCI drivers and the spec imply that this is
a good idea).  Writes are ok though for all existing ia64 platforms (and
hopefully it'll stay that way).

	ia64 compilers, not just GCC.

When an ia32 process triggers request_module the kernel cannot execute
modprobe because the kernel thread still has the ia32 address limits in
force.  I think a kernel thread should always have the ia64 address
limits, similar to what sys32_execve is doing.

A small patch for 2.4 that stops the kernel from trying to syncrhonize
ITC clocks between CPUs if we know that the ITC isn't synchronized
across the backplane.

My e-mail address changed and I'd like to update it in arch/ia64/kernel/acpi.c.

I've found this by inspecting the code: pt_regs_off returns an offset into
struct pt_regs.  Relative to latest bk, 2.5 has the same bug.

Eric Piel wrote:
> However, now, it still gives negative difference:
> # ./a.out
> requested:      1047572128s 2564ns
> new:            1047572128s 1588ns
> diff is -0.000976000sec
> 
> That's better but there is still something...
> Can anyone reproduce this bug? Any idea about what may cause this
> shifted results?
> 
> I don't understand what does the line in settimeofday():
>         nsec -= (jiffies - wall_jiffies ) * (1000000000 / HZ);

Finally I read the code to do the same thing for i386 (get and
settimeofday()). This explains the meaning of this line, in the i386
it's associated with the equivalent line in do_gettimeofday()! On ia64
everything is done inside of gettimeoffset(). Therefore I'm now
confident that suppressing this line is a Good Thing ;-) The patch doing
it wrt the bk tree is attached.

The test case confirms that it works:
requested:      1048681051s 194873ns
new:            1048681051s 194874ns
diff is  0.000001000sec

That's the same result than on a 2.4.19 . 
This also solved an error on the high resolution timers test suite.

	the handling of loader-created sections.

the attached patch (against bk-current) fixes a cross 
compilation problem by using the target specific objdump 
tool instead of the host specific one.

	ia64_sal_mc_rendez().  Also prefix local-variables in
	SAL macros to avoid name collisions.

We are not setting the 'always rendezvous for mca' flag.  kdb needs it
set to get decent mca debugging on all cpus but I do not want kdb to
change sal behaviour.  Since we do not recover from mca without a
debugger, I see no reason why this flag should not be on for all
kernels.

The rendezvous timeout was set to 100 * HZ, but SAL expects the timeout
to be in milliseconds, HZ may not be 1 millisecond.  The patch makes
the timeout an explicit 20 seconds, semi-arbitrary value.

thoroughly broken ia64 patch).  Not all relocs are supported yet and the reloc
code needs to be cleaned up, but simply stuff like loading the palinfo module
works.  Also, linkage-stubs are optimized with brl for McKinley or better.

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).