into redhat.com:/spare/repo/libata-2.5

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

into redhat.com:/spare/repo/libata-2.5

It turns out that the SiS irq routing logic doesn't go by chipset
after all - it's just that some pirq entries are "legacy" numbers,
while others are raw offsets into PCI config space (and the legacy
numbers are more commonly used with the older chipsets, which
explains the correlations).

This simplifies the router code substantially.

A bug prevents the PnP layer from reserving some of the resources
specified by the PnPBIOS.  As a result some systems will have
unpredicable (random crashes etc.) problems because of resource
conflicts, especially when PCMCIA support is enabled.  This patch
fixes the problem by ensuring that the proper resource data is
reserved.

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

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

It did not account for extension headers properly.  If we get
this length wrong, we do not determine if a multicast packet
is MLDv1 vs. MLDv2 correctly.

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

This caused the system call code to test for the wrong number of
system calls, with resulting exciting results. 

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

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

	for 2.6.0.  The proper fix is to replace ia64_ni_syscall with
	sys_ni_syscall, but that would make the patch quite large, so
	we defer that till 2.6.1.

	restore_sigcontext().  Also update ia32 subsystem accordingly.

	in practice, but it's clearly wrong and just waiting there to
	get triggered...

Caught by Francois Romieu.

RFC2710 says:
1) MLD messages are never sent for multicast addresses whose scope is 0
   (reserved) or 1 (node-local).
2) MLD messages ARE sent for multicast addresses whose scope is 2
   (link-local), including Solicited-Node multicast addersses [ADDR-ARCH],
   except for the link-scope, all-nodes address (FF02::1).

      The current MLDv1 code does not send reports for link-scope addresses
and doesn't restrict scope 0. This may break switches that snoop reports for
determining which ports should receive particular addresses.  Patch below.

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

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

Fix the creation of the /proc/net/bonding dir.
Patch is against 2.6.

Amir

This patch (against latest 2.6.0) is also waiting for almost a month.
It's already in 2.4 but is still very much needed for 2.6.

Old ifenslave versions (like the one in Red Hat 9) don't work with
the bonding module in the latest 2.6 kernel without it.

Amir

EBUS DMA fixes:
- Add EBUS_DMA_FLAG_TCI_DISABLE that the client can set if it
  wants only to hear device interrupts, not DMA complete ones.
- When initially resetting the EBUS DMA unit, put valid burst etc.
  encodings in the CSR register.  Not doing this appears to leave
  the attached ISA device in a weird state.

PCI FLOPPY fixes:
- Do ebus_dma_enable() before ebus_dma_request()
- In sun_pci_fd_set_dma_mode() do not forget to set the direction.
- Set EBUS_DMA_FLAG_TCI_DISABLE in ebus_dma flags.
- Make sure that in error paths sun_fdc/FCD1 will be -1 (invalid).

Thanks to Soyoung Park for loaning her Ultra5 to me so I could fix this.

Original report and bug fix from: Amit Patel <patelamitv@yahoo.com>

The problem was a signed vs unsigned char problem when computing luns
for scanning.

From: Adrian Bunk <bunk@fs.tum.de>

Modular BINFMT_ELF doesn't build, and is pretty pathological anyway.

So just make it a boolean rather than a tristate.

From: Herbert Xu <herbert@gondor.apana.org.au>

The recent patch produces a message with no terminating newline on the
machine in question.  This is because one of the four bytes that you're
printing out is NUL.  The following patch avoids that problem.

From: Jeremy Higdon <jeremy@classic.engr.sgi.com>

I believe there is a bug in kernel/resource.c.

We (SGI sn2 I/O code) are using this for allocating dma map resources, and
we tracked failures we were seeing to find_resource().

The problem is that when testing bounds in the forever loop, the end bound
would be one higher than it should be if it gets set from another resource
(it's set to the proper value when it gets set from the root), causing
find_resource to return an invalid min/max when the requested size was one
greater than would fit between two existing resources.

From: Andreas Gruenbacher <agruen@suse.de>

64-bit pointer arithmetic bug in xattr code

The int offset is not enought to hold the difference between arbitraty
pointers on 64-bit machines.  Compute the offset of here and last inside
HDR(bh) instead.

From: James Cleverdon <jamesclv@us.ibm.com>

On summit-based machines the cpu_sibling_map data has been hosed for some
time.  I found out why in Intel's IA-32 Software Deveveopers' Manual Vol 2
under CPUID.  Looks like the value that cpuid returns is the one latched at
reset, and doesn't reflect any changes made by the BIOS later:

  * Local APIC ID (high byte of EBX)--this number is the 8-bit ID that
    is assigned to the local APIC on the processor during power up.  This
    field was introduced in the Pentium 4 processor.

Also, the code in init_intel was a bit overdesigned.  Until Intel releases
a chip with a non-power-of-2 sibling count on it, there's no point in all
that bit bashing.

From: Jun Sun <jsun@mvista.com>

It is needed for all those "__attribute_used__" etc to be valid.

Also, it seems that when compiling a file ending in ".S", gcc-2.95.3 does not
expand __GNUC__ at all.  This causes the compiler version check to fail when
building vsyscall.S.  So add __ASSEMBLY__ wrappers in there.

Fix a couple of problems which were introduced by a recent race fix in the
ext2 block allocator:

- if the allocation attempt raced, and lost the race then a new attempt is
  made.  But the earlier reservation must be put back first.

  Add a call to group_release_blocks() to fix this.

- if the filesystem is genuinely corrupted then the code as-is can get
  stuck in an infinite loop, thinking that a blockgroup has free blocks and
  then discovering that its bitmap is full.

  Fix this by baling out after having scanned all blockgroups twice.

  (Thanks Muli Ben-Yehuda <mulix@mulix.org> for spotting this).

From: Alex Tomas <alex@clusterfs.com>

If the ext3 inode allocator tries to claim an inode and fails because
another CPU got in there first it will then advance onto the next
blockgroup and try again.

Change it to advance onto the next inode within the same blockgroup
instead.