Nobody seems to have any outstanding work against devfs, so...

From: Rusty Russell <rusty@rustcorp.com.au>

From: "Petri T. Koistinen" <petri.koistinen@iki.fi>

1) Various URLs in the Kconfig files are out of date: update them.

2) URLs should be of form <http://url-goes-here>.

3) References to files in the source should be of form
   <file:path-from-top>

4) Email addresses should be of form <foo@bar.com>

From: Andi Kleen <ak@muc.de>

Current x86-64 patchkit for 2.6.5.

- Add drivers/firmware/Kconfig

- Clarify description of CONFIG_IOMMU_DEBUG

- Use correct gcc option to optimize for Intel CPUs

- Add EDD support (Matt Domsch)

- Add workaround for broken IOMMU on VIA hardware.  Uses swiotlb there now.

- Handle more than 8 local APICs (Suresh B Siddha) 

- Delete obsolete mtrr Makefile

- Add x86_cache_alignment and set it up properly for P4 (128 bytes instead
  of 64bytes).  Also report in /proc/cpuinfo

- Minor cleanup in in_gate_area

- Make asm-generic/dma-mapping.h compile with !CONFIG_PCI Just stub out all
  functions in this case.  This is mainly to work around sysfs.

- More !CONFIG_PCI compile fixes

- Make u64 sector_t unconditional

Herbert Xu noted:
  "The current stxncpy on alpha is still broken when it comes to single
   word, unaligned, src misalignment > dest misalignment copies.

   I've attached a program which demonstrates this problem."

Ugh, indeed. It fails when there is a zero byte before the data.
Thanks.

Here is the fix for this (both regular and ev6 version).

We default to "long" (which is what POSIX says), but since
a number of architectures have used "int" for historical
reasons, we need to allow overrides.

At least sparc64 needs this. Possibly others, but so far
architecture maintainers haven't spoken up. ppc64 and x86-64
are known to be ok with the default "long".

From Ivan Kokshaysky <ink@jurassic.park.msu.ru>.

into heffalump.twiddle.home:/home/rth/work/linux/axp-2.6

From: Matt Porter <mporter@kernel.crashing.org>

Patch fixes a latent bug in the PPC44x tlb management code.

From: Matt Porter <mporter@kernel.crashing.org>

Make a couple 4xx defconfigs functional again.

From: Matt Porter <mporter@kernel.crashing.org>

IDs new PPC44x silicon.

From: Matt Porter <mporter@kernel.crashing.org>

Patch fixes the build for PPC40x platforms.

From: Tom Rini <trini@kernel.crashing.org>

When I was updating ppc/boot/simple/relocate.S to work on PPC_PREP systems, I
in advertantly broke 4xx systems.  On classic PPC, the first three
instructions are nops, of which the first two can be overwritten.  This is
not true of 4xx (or 8xx, but that's not working right now anyhow).  The
following is needed to fix this.

The commoncap module calls this.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

- Use -march=armv6 where available.
- CFLAGS_BOOT isn't needed - the decompressor uses CFLAGS, remove it.
- PROCESSOR is never used, remove it.
- LDFLAGS_BLOB is never used, remove it.
- Remove MACHINE macro.
- Correct comments for include/asm-arm/.arch target.
- Copy format of include/asm symlink rule.
- Arrange for configuration to be split before making
  include/asm-arm/arch symlink.
- This means that asm-offsets.s no longer depends on
  include/config/MARKER.

diva_os_cancel_soft_isr() may not call tasklet_kill(), because it is
interrupt context.  This will be done correctly in the cleanup function
anyway.

The patch to check "maxcpus=N" early broke by putting maxcpus (a
variable which is only exported by mpparse.c) into
parse_cmdline_early().

The fix is to make it depend on the correct CONFIG_ option. 

In the subarchitectures:

CONFIG_X86_SMP is the one that means "I want standard x86 smp code" and
that's what this should depend on.

This patch from Christoph Hellwig does much welcomes cleanup of
the old mac53c94 and mesh SCSI drivers, removing sillycaps etc...

From: Sam Ravnborg <sam@ravnborg.org>

Fix this:

 	  Building modules, stage 2.
 	  MODPOST
 	LANG := en_US.UTF-8
 	make: LANG: Command not found
 	make: *** [all] Error 127

by removing the tab in front of the LANG assignment.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

From: Martin Schwidefsky <schwidefsky@de.ibm.com>

This fixes a problem in sys_swapon that can cause the creation of invalid
swap ptes.  This has its cause in the arch-independent swap entries vs. 
the pte coded swap entries.  The swp_entry_t uses 27 bits for the offset
and 5 bits for the type.  In sys_swapon this definition is used to find how
many swap devices and how many pages on each device there can be.  But the
swap entries encoded in a pte can be subject to additional restrictions due
to the hardware besides the 27/5 division of the bits in the swp_entry_t
type.  This is solved by adding pte_to_swp_entry and swp_entry_to_pte calls
to the calculations for maximum type and offset.

In addition the s390 swap pte division for offset/type is changed from 19/6
bits to 20/5 bits.

Two callsites, 48 bytes saved

Two callsites, 456 bytes saved

Four callsites, 104 bytes saved

Three callsites, 1104 bytes saved.

Seven callsites and an out-of-line copy is a bit excessive.  562 bytes saved.

Display number of slab, mapped and pagetable pages in the sysrq-M output.

If someone runs page_address() before page_address_init(), the kernel locks
up over uninitialised spinlocks.

This only happens with the 4:4 patch, but it is more robust to run
page_address_init() before setup_arch().  page_address_init() simply
initialises statically allocated storage.

From: Chris Mason <mason@suse.com>

I think Andrew and I managed to mismerge the loop setup race fix. 
loop_set_fd is using get_capacity() to read the size of the disk and
sending that to bd_set_size.

But, it is doing this before calling set_capacity, so the size being used
is wrong.  This should clean things up.

From: David Mosberger <davidm@napali.hpl.hp.com>

Below is a warmed up version of a patch originally done by Werner Almesberger
(see http://tinyurl.com/25zra) to replace the MAX_MAP_COUNT limit with a
sysctl variable.  I thought this had gone into the tree a long time ago but
alas it has not and as luck would have it, the hard limit bit someone today
once again with a large app on a large machine.

Here is a small test app:

Spotted by Andrea: we need the barriers in there to prevent reads passing
ahead of the setting of current->state.

All architectures now make this `long', so we can remove the arch override.