While running a few tests on a RHEL3 ia64 box, I noticed
that the new "ps -a" function was failing to access user
space stack addresses.

As it turns out, it was a regression in the ia64 4-level page
table support put into 4.0-3.1.  The 3-level ia64_vtop()
function was working for most user addresses, and for kernel
vmalloc addresses, by dumb luck, but user stack addresses
failed due to the use of an incorrect PGDIR_SHIFT value.

In your patch, you indicate this:

#define PGDIR_SHIFT_4L          (PUD_SHIFT + (PTRS_PER_PTD_SHIFT))
#define PGDIR_SHIFT_3L          (PMD_SHIFT + (PTRS_PER_PTD_SHIFT))
/* Turns out 4L & 3L PGDIR_SHIFT are the same (for now) */
#define PGDIR_SHIFT             PGDIR_SHIFT_4L

But PGDIR_SHIFT_3L is 36 and PGDIR_SHIFT_4L is 47.  And in
the 3-level ia64_vtop() function, PGDIR_SHIFT was being
used.  By changing ia64_vtop() to use PGDIR_SHIFT_3L instead,
all translations work.

FWIW, the problem only manifested itself with user space
addresses in the last two vm areas, which have bits set
in the address space affected by the shift value:

crash> vm
PID: 1      TASK: e000004040200000  CPU: 0   COMMAND: "init"
       MM               PGD          RSS    TOTAL_VM
e00000409ef47b00  e00000404579c000  1168k    2960k
      VMA              START             END        FLAGS FILE
e00000409ef3f8b8                0             4000  84011
e00000409ef3fe08 2000000000000000 2000000000038000    875 /lib/ld-2.3.2.so
e00000409ef3fe90 2000000000038000 2000000000040000 100877 /lib/ld-2.3.2.so
e00000409ef3f830 200000000005c000 20000000002a4000     75 /lib/tls/libc-2.3.2.so
e00000409ef3fad8 20000000002a4000 20000000002ac000     70 /lib/tls/libc-2.3.2.so
e00000409ef3f9c8 20000000002ac000 20000000002b8000 100077 /lib/tls/libc-2.3.2.so
e00000409ef3f940 20000000002b8000 20000000002c4000 100077
e00000409ef3fd80 4000000000000000 4000000000010000   1875 /sbin/init
e00000409ef3fc70 600000000000c000 6000000000010000 101877 /sbin/init
e00000409ef3fa50 6000000000010000 6000000000034000 100073
e00000409ef3fcf8 60000fff80000000 60000fff80004000    233
e00000409ef3ff18 60000fffffff8000 60000fffffffc000 100177

...so the incorrect use of 47 worked by mistake for the
other user space and vmalloc addresses.

It's always something...    ;-)

Thanks,
  Dave