We should set CONFIG_PCI_DOMAINS=y unconditionally on alpha to avoid
ifdefs - jensen has dummy PCI infrastructure anyway.

This fixes an oversight in the reboot code, making some reboot
incantations fail mysteriously.

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

Here is a simplified version of the earlier /dev/mem cleanup.  This version
of the patch no longer pretends to support uncached accesses via
read()/write().  Instead, all it does is:

- consolidate much of the ugly code in uncached_access()

- move pgprot_noncached() macro to pgtable.h for i386, m68k, ppc, ppc64,
  and x86_64

- fix the ia64 implementation to use efi_mem_attributes() to determine
  the cacheability of an address

Eventually, we may want to replace the #ifdef CONFIG_IA64 with #ifdef
CONFIG_EFI, but we can do this "on demand", if and when EFI-based x86
machines become more common.

driver initializations

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

The S390 hardware has the interesting characteristic that the storage key
hardware which records a page's pte-dirtiness is also marked dirty when a
page is modified by the disk hardware.

Consequently, reading data from disk makes the page appear to be dirty and
things which were read from disk need to be written back.

Up to now s390 uses a special bit in the pte that is set in mk_pte for the
first user of a page and makes set_pte to clear the storage key.  The problem
is that this is a race condition if two processes want to access the same
page simultaneously.  Then the page count is already > 1 in mk_pte and nobody
will clear the storage key.  It doesn't lead to any data loss because what
happens is that a clean page is considered dirty and is written back to the
disk.  The worst scenario is a read only disk where this results in i/o
errors (but no data loss).

Martin's fix to this is to clear the page's dirty flag in SetPageUptodate().
Which seems a bit kludgey, but I cannot think of a case in which this in
incorrect, inadequate or inappropriate.  So...

From: Jorn Engel <joern@wohnheim.fh-wedel.de>

Reduce stack usage in the cpqarray ioctl byt several hundred bytes.

From: Christoph Hellwig <hch@lst.de>

There may be multiple gendisks with the same .devfs_name in scsi and we
call devfs_mk_dir on each of them.  At present that causes a nasty error
message.  It is better to permit devfs_mk_dir() to appear to have succeeded.

ie: it's a `mkdir -p'.

An NFS mount of localhost hangs the system under heavy writeout loads.

This is because knfsd gets stuck in balance_dirty_pages().  It is not allowed
to exit from there until the amount of dirty+writeback+unstable memory
subsides.  But it will never subside because knfsd itself is responsible for
cleaning the memory.

This is just like the drivers/block/loop.c hang, only more complex.  We
cannot simply disable knfsd's throttling because it would then swamp the
machine under real loads when the clients are remote.

So we introduce the concept of a "less throttled" process.  These processes
are allowed to exceed the preset dirty memory limits by a little.  This
allows knfsd to make progrws in writing things out while the local NFS
clients are throttled.  It also ensures that knfsd will not swamp the machine
when working on behalf of remote clients.

Note that even though knfsd is allowed to exceed the default system-wide
dirty memory threshold, this does _not_ cause other memory-dirtying tasks to
get starved out.  This is because they are allowed to exit
balance_dirty_pages() after having written their quota of pages, regardless
of the current dirty memory state.

From: hugang <hugang@soulinfo.com>

It has a rather blatant null pointer deref and attempted memory leak.

From: Dave Hansen <haveblue@us.ibm.com>

We didn't notice this for a while because we didn't have any memory holes
on the NUMA-Q, but on the x440, we do.

From: "Martin J. Bligh" <mbligh@aracnet.com>

rebalance_tick is not properly passing the idle argument through to
load_balance in one case.  The fix is trivial.  Pointed out by John Hawkes.

From: Manfred Spraul and Brian Gerst

The patch performs the kmalloc cache lookup for constant kmalloc calls at
compile time.  The idea is that the loop in kmalloc takes a significant
amount of time, and for kmalloc(4096,GFP_KERNEL), that lookup can happen
entirely at compile time.

A problem has been seen with gcc-3.2.2-5 from RedHat.  This code:

    if(__builtin_constant_t(size)) {
          if(size < 32) return kmem_cache_alloc(...);
          if(size < 64) return kmem_cache_alloc(...);
          if(size < 96) return kmem_cache_alloc(...);
          if(size < 128) return kmem_cache_alloc(...);
          ...
    }

doesn't work, because gcc only optimizes the first two or three comparisons,
and then suddenly generates code.

But we did it that way anyway.  Apparently it's fixed in later compilers.

From: "Ni, Michael" <Michael.Ni@hp.com>

Update the MAINTANERS file for the various Compaq mass-storage drivers

From: "Martin J. Bligh" <mbligh@aracnet.com>

Patch from Martin Bligh, based on observations by Andrew Theurer and Bill
Irwin.

TARGET_CPUS is used as a cpu mask by some things, and an apic mask for
others.  For SMP, that doesn't matter (they're the same), but for Summit it
does.  This patch changes TARGET_CPUS to consistently be a cpu mask
everywhere.  Should be a no-op for normal platforms.

Invalid arguments to cpu_mask_to_apicid for clustered apic mode
architectures will now return the broadcast apicid, in order to ensure
someone still gets the interrupt (was the default init value, and is
safest).

From: Dave Hansen <haveblue@us.ibm.com>

In order to turn an 8-way x440 into a 4-way for testing, we often use
mem=(1/2 of total) and maxcpus=4.  maxcpus has always worked, but mem=
hasn't.  The mem= parameter actually changes the kernel's e820 structure,
which manifests itself as max_pfn.  node_end_pfn[] obeys this because of
find_max_pfn_node(), but node_start_pfn[] wasn't modified.

If you have a mem= line that causes memory to stop before the beginning of
a node, you get a condition where start > end (because start was never
modified).  There is a bug check for this, but it was placed just _before_
the error was made :)

Also, the bootmem alloc functions die if you request something of zero size
from them.  This patch avoids that too.  This shouldn't have much of an
effect on non-NUMA systems.

If two processes are waiting in rtc_read(), only one will get the data.  The
other will madly spin around theloop in state TASK_RUNNING until another
interrupt happens.

Fix it by resetting TASK_INTERRUPTIBLE _inside_ the retry loop.

From: Andi Kleen <ak@suse.de>

This makes the 2.5 kernel with common ioctl32 code compile with DRM enabled
again.  The DRM code in the kernel is obsolete anyways and has been long
removed.  It definitely does not belong in the common ioctl emulation
layer.

Egbert Eich is working on proper 32bit DRM emulation, but it will be likely
directly integrated in the DRI/DRM sources.

for the default "pci_domain_nr()" definition. The inline function
will evaluate the argument.

Milton Miller noticed a free-after-use problem in the cleanup path of a
failed module load.

The problem is that mod is moved to point from the sucked-in file
(always freed last) to the module core, after which time the
"free(mod->core), reference mod->percpu" sequence is bogus, eg.  when
the module_init function fails.

This is fixed by keeping the pointer in a local variable, which solves
the problem. We no longer need to reference the free'd data structure.

This should fix most (all??) of the recently reported problems with MD:

Recent changes to md malloced some data structures differently and
didn't zero out those data structures, where the old code had zeroed it
out.

This adds the relevant memsets.

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

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

into kroah.com:/home/greg/linux/BK/pci-2.5

so hackish.

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

into kroah.com:/home/greg/linux/BK/gregkh-2.5

so that __d_drop() can safely be done multiple times on
a dentry without corrupting other hash entries.

Noticed by Trond Myklebust.

list pointers to give us a nice oops if somebody is doing something
bad.

Also introduce hlist_del_rcu_init() - same as hlist_del_init().

The endpoint disable() change resolved the bug
identified by the FIXME ... this updates the comment.

The main thing this fixes is making the control-OUT path work.
Drivers like RNDIS and DFU need it; this should resolve one
bug report.  It also has some minor cleanups.

Rather than just saying that USBDEVFS_CONTROL failed,
say also which process it failed for ... so it's easier
to figure out what's happen.