Patch set from Jay Estabrook:

 - include/asm-alpha/dma.h:
	Add MAX_DMA_ADDR for SABLE and ALCOR

 - include/asm-alpha/floppy.h:
	enable the full CROSS_64KB macro for all platforms

 - include/asm-alpha/core_t2.h:
	fix HAE usage

 - arch/alpha/kernel/pci.c:
	fiddle with quirk_cypress

 - arch/alpha/kernel/traps.c:
	prevent opDEC_check() from multiple calls (EV4 SMP SABLEs)

 - arch/alpha/kernel/proto.h:
	make t2_pci_tbi() real

 - arch/alpha/kernel/time.c:
	shorten timeout delay

 - arch/alpha/kernel/sys_alcor.c:
	use ALCOR_MAX_DMA_ADDR because of the 1GB limit on ISA devices

 - arch/alpha/kernel/core_t2.c:
	add S/G support and allow direct-map to handle 2GB of memory

 - arch/alpha/kernel/core_tsunami.c:
	rework alignment requirements for ISA DMA, esp. for ACER platforms

 - arch/alpha/kernel/sys_sable.c:
	fix MAX_DMA_ADDR for the 1GB limitation

 - arch/alpha/kernel/pci_impl.h:
	add T2_DEFAULT_MEM_BASE to help avoid HAE use

 - arch/alpha/kernel/pci_iommu.c:
	fix ISA_DMA_MASK calculation, and force ISA alignment to 64KB

 - add another argument to do_fork();
 - assorted compile fixes.

Tested on CIA (sparse config space) and Irongate (dense config space);
other platforms should work as they are similar to these two.

Access config space directly on rx164.

Here are the changes I have

  - Fix some bugs I introduced in zap_thread
  - Improve the check for traced children in sys_wait4
  - Fix parent links when using CLONE_PTRACE

My thanks to OGAWA Hirofumi for pointing out the first bit.

The only other issue I know of is something else Hirofumi pointed out
earlier; there are problems when a tracing process dies unexpectedly.  I'll
come back to that later.

I've done the attached patch to collect & clean up all the things that
happened since yesterday.

It is nice that blkdev_ioctl calls blk_ioctl itself, but unfortunately
it does that only if driver's ioctl returns -EINVAL - and IDE returns
-EIO :-(

Patch below is tested for disks - I do not have IDE floppy nor IDE tape.

of something arch-dependent and usually less. 

We may want to do value limiting in generic_fillattr() if people
end up caring.

This is the pid-max patch, the one i sent for 2.5.31 was botched.  I
have removed the 'once' debugging stupidity - now PIDs start at 0 again.
Also, for an unknown reason the previous patch missed the hunk that had
the declaration of 'DEFAULT_PID_MAX' which made it not compile ...

This contains Daniel's suggested fix that allows a parent to
PTRACE_ATTACH to a child it forked.  That fixes the incorrect BUG_ON()
assert that Ogawa's patch was intended to fix, and we thus undo Ogawa's
patch.

I've tested various ptrace uses and they appear to work just fine.

into home.transmeta.com:/home/torvalds/v2.5/linux

We want do so on all architectures for consistency, and i386 will need
the preprocessing soon anyway.

My previous patch added procs i2c_fill_inode and i2c_dir_fill_inode that
Al Viro deemed unnecessary.  i2c developers are in contact with Al to
get the latest scoop.  Meantime lets reverse the change before he flies
off at me about procfs abuse.

Tthis one seems to have been around since 2.5.31 and nobody has fixed it
yet...

BTW, while merging aio from 2.5 to 2.4 and fixing and porting the libaio
(in particular thanks to one of Ben's testcases that was checkin for
this specific case) I found this bug in 2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

	OK, before the next bunch of gendisk merges, here comes a couple
of 2.5 IDE cleanups.

	a) exclusion between rereading partition tables and open() is done
in fs/block_dev.c these days, so homegrown one in ide.c is redundant - that
code _never_ blocks now.  Removed, just as it had been done with counterparts
in other drivers.

	b) blk_ioctl() calls are done in blkdev_ioctl() now; driver doesn't
need to handle them.  Again, removed as it had been done in all other drivers.

if a new edge happened while we were still processing the previous
one.

Then, if a _third_ edge came in, it would actually cause a reentrant
irq handler invocation, because the original INPROGRESS bit was now
lost.

This was actually seen on IDE in PIO mode.

Unify the PCI device ID constants used by AGP with the normal Linux ones.

create_elf_tables in fs/binfmt_elf.c now sets up the list of aux table
entries in a buffer on the kernel stack before copying it to the user
stack.

Unfortunately, while the buffer is big enough for most architectures, it
isn't big enough on PPC, which uses 5 extra aux table entries (put on
with ARCH_DLINFO).  The following patch increases the buffer to be big
enough for PPC.  (Note that each aux table entry uses two elements of
the elf_info array.)

to the bottom of the aux table.

into au1.ibm.com:/fuego/paulus/kernel/for-linus-ppc

The BK merging was a little too smart for the conflicting changes.
Add back what we lost with the last changeset.

We need to sync the blockdevice mapping at umount although sync_blockdev
already does it as we need to make sure everything hits the disk before
we mark the superblock clean.

Found by Dave Kleikamp.

This removes list_t, which is a gratuitous typedef for a "struct
list_head".  Unless there is good reason, the kernel doesn't usually
typedef, as typedefs cannot be predeclared unlike structs.

Frankly, I'm amazed the kernel worked for long without this.

Every linker script thinks the section is called .data.percpu.
Without this patch, every CPU ends up sharing the same "per-cpu"
variable.

This might explain the wierd per-cpu problem reports from Andrew and
Dave, and also that nagging feeling that I'm an idiot...

 This makes daemonize() call reparent_to_init() itself, as long
suggested for 2.5, and fixes the callers so they don't call it again.
Also fixes callers which set current->tty to NULL themselves (also
no longer neccessary).

This sets child_reaper to the idle thread upon creation, so that
ksoftirqd's reparent_to_init call doesn't get the swapper as parent.

RELOC_HIDE got miscompiled on gcc3.1/x86-64 in the access to softirq.c's per
cpu variables.  This fixes the problem.

Clearly to hide the relocation the addition needs to be done after the
value obfuscation, not before.

I don't know if it triggers on other architectures (x86-64 is especially
stressf here because it has negative kernel addresses), but seems like the
right thing to do.