Check for last adapter link is done by next member,
   because entries are not removed yet.

They all have 128 bytes of ACPI/TCO IO space pointed to
by config space register 0x40, and 64 bytes of GPIO space
pointed to by 0x58.

Thanks to Jun Nakajima for the full list.

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

We don't have DMA support for AMBA devices yet.

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

      read-write (re)mount is requested, empty $LogFile by overwriting it
      with 0xff bytes to ensure that Windows cannot cause data corruption
      by replaying a stale journal after Linux has written to the volume.

into cantab.net:/home/src/ntfs-2.6

      and force a read-only mount if not (fs/ntfs/super.c and fs/ntfs/logfile.c).  This
      is a little bit of a crude check in that we only look at the restart areas and
      not at the actual log records so that there will be a very small number of cases
      where we think that a volume is dirty when in fact it is clean.  This should only
      affect volumes that have not been shutdown cleanly and did not have any pending,
      non-check-pointed i/o.

This fixes a (very very small) preempt race window when we
invalidate the IO permission bitmap on process exit.

There is a bug where if any process that obtained an IO access
permissions via ioperm() does not explicitly "drop" that permissions,
the IO permissions don't get properly invalidated on process exit.

The cause is that exit_thread() only invalidates the per-thread
io_bitmap pointer, but doesn't invalidate the per-TSS io_bitmap pointer
as well. 

As the per-thread pointer is invalidated, __switch_to() doesn't take
care of that one either, so the per-TSS pointer stays valid as long as
some other process does ioperm().

This fixes the problem - it invalidates the per-TSS io_bitmap pointer
and the problem goes away. 

When Patrick removed ide_notify_reboot() in 2.5.42, he didn't notice
that it meant that IDE no longer had any shutdown() functionality.

So we did the right thing on suspend, but not on shutdown.

ide_notify_reboot() was only doing STANDBY on shutdown (because FLUSH
'doesn't work' in 2.4 too) but it worked okay and we still should do STANDBY
on shutdown because some broken disks flush their caches.

Thus just calls bus->suspend() (FLUSH+STANDBY) at shutdown time.  We can
add some safety delay later - 2.4 doesn't have any.

There is a typo in the PTE freeing code causing us to possibly
overflow the batch structure.

Obvious fix (look at the closing parentheses).

into cantab.net:/home/src/ntfs-2.6

I've updated the logips2pp driver to detect the MX310 and MX510 mice
and also made it more maintainable by putting everything into one
table instead of having 4 arrays for them (the MX700 support wasn't
added correctly in the last revision).

This makes the idedisk_release function only flush the cache on final
release; with the recent 2.6 blocklayer updates release gets called
somewhat frequently, and at times where IO is outstanding to the disk.

This bug didn't trigger before simply because ide_cacheflush_p() always
was a nop.

gconf doesn't correctly toggle through the values of a symbol, so use
sym_toggle_tristate_value() instead.

Problem reported by Martin Persenius <martin@persenius.net>

This enables proper mxcsr register masking: the magic mask "0xffbf"
is not necessarily correct for all CPU's, and there is an architected
way to discover the proper MXCSR feature bits by examining the fxsave
results.

Please refer to IA32 Software Developer's Manual, Volume 1, Section
11.6.6 for more details.

ncpfs was forgetting to update iovec's iov_base field whenever partial
transmission occured. This was causing data corruption during large
(60kB) writes.

The code now also passes copy of iovec to the sock_sendmsg, so it does
not rely on network stack updating (or not updating) passed iovec in
case of success (or failure).

I was going through the code looking for bits and pieces to pull across
into the new LSI Logic beta megaraid driver /sys fs code and came across
this one.

LSI Logic have already fixed this issue for the 2.4 driver, and the new
beta driver does not use the /proc filesystem at all, so no problem
there.

The problem is that resources are not freed upon certain error
conditions in the in-kernel megaraid driver, to quote from Lester
Hightower (who originally found the issue):

   "The problem occurs only in the circumstance where one reads one of
    the /proc/megaraid/hba<X>/diskdrives-ch<N> files where the card <X>
    does not have channel <N> on it.  Most people would likely not
    notice this leak in normal operation, but due to the way that we
    monitor our MegaRaid cards in our company (we read these /proc
    entries every 180s) so we found the leak rather quickly, and
    unpleasantly (when your kernel eats all your RAM)."

Anyway, here is the fix, compiled and tested OK for me.

From: Alan Cox <alan@redhat.com>, Arjan van de Ven <arjanv@redhat.com>

 - calculate drive->wcache for non-removable disks too
 - flush the cache before unlocking the door on removable media,
   otherwise you have a small race with the human

This replaces some usages of sempahores on the stack with completions.

We think we have had at least one bug report that could be caused by the
inherent race in the semaphore usage.

There is an bug in bigsmp sub-architecture, due to which it will not
enable all the CPUs when the BIOS-APICIDs are not 0 to n-1 (where n is
total number of CPUs). Particularly, only 2 CPU comes up on a system
that has 4 CPUs with BIOS APICID as (0, 1, 6, 7).=20

The bug is root caused to check_apicid_present(bit) call in smpboot.c,
when bigsmp is expecting apicid in place of bit.
check_apicid_present(bit) in bigsmp subarchitecture checks the bit with
phys_id_present_map (which is actually map representing all apicids and
not bit).

One solution is to change check_apicid_present(bit) to
check_apicid_present(apicid), in smp_boot_cpus().  But, it can affect
all the other subarchitectures in various subtle ways.  So, here is a
simple alternate fix (Thanks to Martin Bligh), which solves the above
problem. 

[ Confirmation from Martin:

     Looks fine, it's exactly the same fix we use for Summit.  Since
     we're using the other method instead of the bitmap, this check
     isn't needed, so we can just bypass it.  This way also has the
     great advantage of being isolated to the bigsmp subarch, so it only
     needs testing there ;-)
 ]

From: <mikem@beardog.cca.cpqcorp.net>

This patch adds support for 2 new controllers.  The first is a PCI-Express
version of the 6400.  The second is actually a SATA controller using the cciss
interface.

   Accept negative level3cnt value in register_application
   for special b-channel calculation. Necessary to work with
   capidrv.

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

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

Based on information provided by "Allen Martin" <AMartin@nvidia.com>:

A hang is caused when the CPU generates a very fast CONNECT/HALT cycle
sequence.  Workaround is to set the SYSTEM_IDLE_TIMEOUT to 80 ns.
This allows the state-machine and timer to return to a proper state within
80 ns of the CONNECT and probe appearing together.  Since the CPU will not
issue another HALT within 80 ns of the initial HALT, the failure condition
is avoided.

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

into debian.org:/usr/src/kernel/ieee1394-2.6

Here is an updated lapic NMI ownership tracking patch which
should address the issues that were raised with the first one:

- Simplified the API function names to {reserve,release}_lapic_nmi().

- Rewrote the ownership tracking code to use two individually named
  flags instead of using arithmetic and the sign. The code is now
  simple enough that no "hiding" macros are needed. (Thanks Albert
  for that suggestion.)

degerrit@web.de wrote:
   "I caused an oops in unusual circumstances by accidentally "forcing" a
    video device number which was too high or already taken (don't know
    which). I assume this probably shouldn't give an oops (though it was my
     fault), so here's a bugreport..."

Fixed by adding a range check for the number passed in by the driver.

From: Hugh Dickins <hugh@veritas.com>

Remove this development-only debug code - Hugh thinks that its BUG_ON() can
trigger by accident.