Patch from Zwane Mwaikambo <zwane@linuxpower.ca>

This patch fixes what seems to have been a longstanding bug. Ever since we
moved cpu bringup later into the boot process, we end up programming the
ioapics before we have any of our possible cpus in the cpu_online_map.
Therefore leading to the following current situation;

For walmart-smp, bigsmp and summit we set the logical destination for cpu
to TARGET_CPUS which can depend on the cpu_online_map, so what you would
normally see with noirqbalance would be all interrupts handled on cpu0
since at that stage no other cpu apart from the BSP is online.

You can check for this by looking at the ioredtbls at boottime for a two
way system;

.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59

Notice that 'Log' is set to 1 instead of 3.

This patch will simply reprogram all the ioredtbls to handle the other
online cpus.

Patch tested on my 2way P2-400 and a 16way NUMAQ both with noirqbalance.
It will not affect the irqbalance case because we are simply setting
TARGET_CPUS which is done anyway.

before:
  CPU0       CPU1
  0:    1495632          0    IO-APIC-edge  timer
  1:       4270          0    IO-APIC-edge  i8042
  2:          0          0          XT-PIC  cascade
  8:          1          0    IO-APIC-edge  rtc
 12:      83592          0    IO-APIC-edge  i8042
 14:      93791          0    IO-APIC-edge  ide0
 15:     103167          0    IO-APIC-edge  ide1
 17:    1396088          0   IO-APIC-level  EMU10K1, eth0
 18:      56125          0   IO-APIC-level  aic7xxx, aic7xxx
 19:       2258          0   IO-APIC-level  uhci-hcd, eth1, serial
NMI:          0          0
LOC:    1495566    1497133

after:
           CPU0       CPU1
  0:    1046157    1015670    IO-APIC-edge  timer
  1:       4923       4173    IO-APIC-edge  i8042
  2:          0          0          XT-PIC  cascade
  8:          1          0    IO-APIC-edge  rtc
 12:      48596      48968    IO-APIC-edge  i8042
 14:       4238       3416    IO-APIC-edge  ide0
 15:      25362      31525    IO-APIC-edge  ide1
 17:       3757       4014   IO-APIC-level  EMU10K1, eth0
 18:        335        366   IO-APIC-level  aic7xxx, aic7xxx
 19:       1052        908   IO-APIC-level  uhci-hcd, eth1
NMI:          0          0
LOC:    2061856    2061893

PA-RISC patches for 2.5.65:

 - Only remove palo.conf on a `make mrproper'
 - Add a \ continuation to kernel/Makefile
 - Reindent cache.c
 - Always call schedule_tail
 - Fix some typos in the hardware database
 - Signal handling changes
 - RAID, Device Mapper & BLKSZGET ioctl32 translations
 - Clean up pci host bridge handling a bit.
 - Make IDE link again
 - Fix up compat changes
 - Improve stack dumping code

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

This is a fix made almost a month ago, during the flurry of signal changes.
I didn't realize until today that this hadn't made it into 2.5.  Sorry
about the delay.

This fix is necessary to avoid sometimes wedging in uninterruptible sleep
when doing a multithreaded core dump triggered by a process signal (kill)
rather than a trap.  You can reproduce the problem by running your favorite
multithreaded program (NPTL) and then using "kill -SEGV" on it.  It will
often wedge.  The actual fix could be just a two line diff:

+                       if (current->signal->group_exit)
+                               goto dequeue;

after the group_exit_task check.  That is the fix that has been used in
Ingo's backport for weeks and tested heavily (well, as heavily as core
dumping ever gets tested, but it's been in our production systems).

But I broke the hair out into a separate function.  The patch below has the
same effect as the two-liner, and no other difference.  I have tested
2.5.64 with this patch and it works for me, though I haven't beat on it.

The way the wedge happens is that for a core-dump signal group_send_sig_info
does a group stop of other threads before the one thread handles the fatal
signal.  If the fatal thread gets into do_coredump and coredump_wait first,
then other threads see the group stop and suspend with SIGKILL pending.
All other fatal cases clear group_stop_count, so this is the only way this
ever happens.  Checking group_exit fixes it.  I didn't make do_coredump
clear group_stop_count because doing it with the appropriate ordering and
locking doesn't fit the organization that code.

Mounting a non-affs filesystem as affs crashes the kernel.
The reason is the
	sbi = kmalloc(sizeof(struct affs_sb_info), GFP_KERNEL);
	memset(sbi, 0, sizeof(*AFFS_SB));
where the second sizeof is 1, so that sbi is not zeroed at all.

Also, avoid a warning for printk of sector_t in amigaffs.h.

Previously, we only honored barriers wrt merging. Really honor them now,
move all pending requests to dispatch list and add the hard barrier at
the back.

gen-asm-offsets, the most common user of the new filechk function, needs
to be fed input from $< (the first prerequisite).

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

Patch from Adrian Bunk <bunk@fs.tum.de>

It would be nice if everyone would try to compile the patched files
before submitting patches...

raid0 doesn't have a thread, so md_wakeup_thread() derefs NULL.

Neil may end up doing this differently, but meanwhile....

Patch from Roman Zippel <zippel@linux-m68k.org>

- remove lock_kernel() (It was buggy too - there are at present two missing
  unlock_kernel()s)

- fixes a bitmap corruption problem.

From latest -aa kernels.

Patch from: Suparna Bhattacharya <suparna@in.ibm.com>

Just an obvious fix.
The kiocbClearX macros were doing a set_bit !
They should be calling clear_bit.
Ran into this now that I'm actually using kiocbClearKicked.

Patch from Alex Tomas <bzzz@tmi.comex.ru>

There is a logic error in ext2_new_block().  If we manage to reserve some
blocks in the final blockgroup, local variable `bit' will be equal to
sbi->s_groups_count and we erroneously assume that the allocation failed.

Fix that up by testing local variable `group_alloc' instead.

Patch from "Theodore Ts'o" <tytso@mit.edu>

I recently noticed a bug in ext2/3; newly created inodes which inherit
the noatime flag from their containing directory do not respect noatime
until the inode is flushed from the inode cache and then re-read later.
This is because the code which checks the ext2 no-atime attribute and
then sets the S_NOATIME in inode->i_flags is present in
ext2_read_inode(), but not in ext2_new_inode().

I fixed this in 2.4, and then found an even worse bug in the 2.5 code;
the DIRSYNC flag is completely ignored *except* in the case where a
directory is newly created using mkdir and its parent directory has the
DIRSYNC flag.  S_DIRSYNC doesn't get set in the ext2_new_inode() or the
ext2_ioctl() paths (which is used by chattr).

This patch centralizes the code which translates the ext2 flags in the
raw ext2 inode to the appropriate flag values in inode->i_flags in a
single location.  This fixes the bug, makes things cleaner, and also
removes 30 lines of code and 128 bytes of compiled x86 text in the
bargain.

Patch from Oleg Drokin <green@linuxhacker.ru>

    There is a memleak in e100 driver from intel, both in 2.4 and 2.5
    e100_ethtool_gstrings does not free "strings" variable if it cannot
    copy it to userspace.

Patch from Anders Gustafsson <andersg@0x63.nu>

We're getting a division-by-zero in the writeback code during early rootfs
population, because writeback has not yet been initialised.

Fix that by performing an explicit initialisation rather than relying on
initcall ordering.

Patch from Kevin Pedretti <pedretti@ieee.org>

The previous fix for unmapping hugetlb regions could still produce incorrect
alignments if the munmap request covers multiple VMA's.

Fix it by always unmapped the entire hugepage VMA inside the inner loop.

Patch from "Randy.Dunlap" <rddunlap@osdl.org>

Reverts the recent alteration of the format of the `mem=' option.  This is
because `mem=' is interpreted by bootloaders and may not be freely changed.

Instead, the new functionality to set specific memory region usages is
provided via the new "memmap=" option.

The documentation for memmap= is added, and the documentation for mem= is
updated.

The recent (untested?) "cleanup" removed a null-pointer test.

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

As requested by Andrew, this moves the hugetlbfs config option
into the Pseudo filesystems section near tmpfs.

Also fix some spelling.

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

Patch from Ivan Kokshaysky

This fixes long standing typo ('size' instead of 'r_size') which causes
overestimate of the bridge memory ranges calculated in pbus_size_mem().
For example, if we have a device with one 1Mb and one 2Mb memory ranges
behind the bridge, calculated size and alignment of the bridge memory
window will be 4Mb and 2Mb respectively, while the correct values are
3Mb and 1Mb.

In an attempt to "unuse" pci_do_scan_bus() so it can be eventually
killed, make pci_scan_bus_parented() call the new pci_scan_child_bus()
and pci_bus_add_devices().  The only remaining callers are the
hotplug drivers.

Eventually, pci_bus_add_devices() will be removed from this function -
it is intended that architectures should call this after they have
done any setups and fixups to the scanned bus.

It is legal to call pci_bus_add_devices() on a bus which has already
had this function called, so architectures could update today.

Pull out the bits of cardbus configuration - the secondary latency
timer, and the number of bus numbers we reserve.

pci_read_config_dword() takes a u32 pointer, not unsigned long.

Miscellaneous cleanups to probe.c:
        - make code/comments wrap before column 80.
        - remove extraneous space.

Kill pcibios_update_resource(), replacing it with pci_update_resource().
pci_update_resource() uses pcibios_resource_to_bus() to convert a
resource to a device BAR - the transformation should be exactly the
same as the transformation used for the PCI bridges.

pci_update_resource "knows" about 64-bit BARs, but doesn't attempt to
set the high 32-bits to anything non-zero - currently no architecture
attempts to do something different.  If anyone cares, please fix; I'm
going to reflect current behaviour for the time being.

Ivan pointed out the following architectures need to examine their
pcibios_update_resource() implementation - they should make sure that
this new implementation does the right thing.  #warning's have been
added where appropriate.

	ia64
	mips
	mips64

This cset also includes a fix for the problem reported by AKPM where
64-bit arch compilers complain about the resource mask being placed
in a u32.

Convert pcibios_fixup_pbus_ranges() into something more generic, namely
pcibios_resource_to_bus() - we are really trying to convert resources
to something to program into bus registers for bridge windows, and in
fact, PCI device BARs.

This is necessary since some architectures, namely Alpha, ARM and PARISC
have an offset between PCI addressing and host-based addressing, so
resources need to be adjusted when read or when written back to the bus.

We provide a generic version in asm-generic/pci.h, which most
architectures use.

This patch finds the following architectures with something to think
consider:

        - ppc, ppc64
                adjusts resources for devices, but not buses.
		This is inconsistent, and leads to improperly
		programmed windows/BARs.

PPC people (Anton) has a replacement PCI resource implementation
which should do the right thing.

Patch from Ivan Kokshaysky

remove the "parent" or "root" second argument to
pcibios_update_resource().  This highlights the following
architectures doing something wrong in their implementation:

        - ia64
        - mips it8172
        - mips "generic mips boards"
        - mips64 "generic mips boards"
        - mips64 IP27

Fix breakage in pci-3 - we scanned all functions if function 0 was not
present.  This causes some host bridges to lock up when scanning devfn
255 on PPC machines.

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

This removes/fixes a few whitespaces and removes the MAX_PRIO setting in
the init task path which is unnecessary and which might even lead to
bugs - MAX_PRIO is outside the valid range and technically the init
thread is not an idle thread yet at this point.