into home.osdl.org:/home/torvalds/v2.5/linux

Some machines with the SIS 96x southbridge have it set up
to claim it is a SIS 503 chip. That breaks irq routing logic
among other things. Fix it properly by making everybody aware
of the duplicity.

into home.osdl.org:/home/torvalds/v2.5/linux

into nuts.ninka.net:/disk1/davem/BK/net-2.5

into kernel.bkbits.net:/home/davem/sparc-2.5

into home.osdl.org:/home/torvalds/v2.5/linux

JFS isn't happy it thinks a file has been removed, and link() increases
its nlink count back from zero.  In 2.4, i_zombie prevented this race
condition.

http://bugzilla.kernel.org/show_bug.cgi?id=866

__invalidate_metapages references mp->page after after releasing the
meta_lock spinlock, without increasing the use count.  This is racy and
unnecessary since setting the META_discard flag is sufficient.
block_invalidatepage() will be called when the metapage is released.

Bug reported by Paul Mackerras: if a module parameter fails, we didn't
call module_arch_cleanup().

On x86 this was harmless (module_arch_cleanup() is a no-op), but on
other architectures like PPC this causes inconsistent data structures
and subsequent oopses.

into home.osdl.org:/home/torvalds/v2.5/linux

This bug prevents Alphas with older firmware from booting if there
is a card with PCI-PCI bridge that supports 32-bit IO.
This has happened on AS2100 with a quad-tulip card, for example:
 - initially, the I/O window of 21152 bridge was 0x10000-0x10fff,
   as set up by firmware;
 - pci_setup_bridge() is going to change this, say, to 0xa000-0xafff:
   first, it updates PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16
   registers, so that IO window temporarily is at 0x0000-0x0fff,
   which effectively blocks up all legacy IO ports in the lower
   4K range, such as serial, floppy, RTC an so on;
   does debugging printk - machine dies here with recursive
   machine checks as the serial console has gone.

Moving (or disabling) the debugging printk is not a solution -
there is possibility that timer interrupt (which might access RTC
ports) occurs between writes to lower and upper parts of the
base/limit registers.

The patch temporarily disables the IO window of the bridge by
setting PCI_IO_BASE_UPPER16 > PCI_IO_LIMIT_UPPER16 before doing
an update. It's safe, as we don't have any active IO behind
the bridge at this point. Also, it's a NOP for bridges with
16-bit-only IO.
Similar (but simpler, as we always clear upper 32 bits) fix
for 64-bit prefetchable MMIO range.

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

into flint.arm.linux.org.uk:/usr/src/bk/linux-2.6-serial

into flint.arm.linux.org.uk:/usr/src/bk/linux-2.6-serial

into home.osdl.org:/home/torvalds/v2.5/linux

(x >> 32) is undefined on a 32 bit integral variable in C; In contrast
(x >>16 >> 16) is fine (and gets optimized out to 0, while (x >> 32)
gets optimized out to a nop). 

Fix for starfire below

This fix got missed in the bonding patchset applied a while ago.

Ensure that arm ether drivers print the correct ether device name rather
than "eth%d".

Fixes build on some platforms.

From: "M.H.VanLeeuwen" <vanl@megsinet.net>

The level of isapnp_init was moved to after apci sometime ago.  Since it is
now after net_dev_init, ISA PNP NICs fail to initialized at boot.  This is
particularily problematic for NFS root filesystems like mine, or none
modular systems.

This fix allows ISA PNP NIC cards to work during net_dev_init, and still
leaves isapnp_init after apci_init.

This driver is freeing skb's from timer context, with local irq's disabled.

It generates warnings from local_bh_enable() because local_bh_enable()
reenables interrupts, exposing the machine to deadlocks.

So use the deferred dev_kfree_skb_irq() instead.

into gmx.de:/suse/kernel/BK/linux-2.5

Other protocols do this as soon as they discover over what interface the
packet will be routed, but LLC isn't routable, so, to provide similar
semantics to the other protocols, I'm just binding it to the first interface
of the type specified, perhaps we'll need a tunable for this or some sort of
routing table done manually by the admin, later we'll see, for now this
allows an application like openssh, with patched getaddrinfo/getnameinfo to
use PF_LLC sockets with a very small patch.