Only include mca.h if CONFIG_MCA: only ia32 and ia64 have <asm/mca.h>

From: Nick Piggin <piggin@cyberone.com.au>

as_completed_request() can be called for requests which were not generated by
the generic block layer.  Handle these, to avoid a subsequent WARN_ON (at
least).

Also kill a separate WARN_ON which is bogusly triggering.

into hera.kernel.org:/home/davem/BK/net-2.5

An extra dput was introduced in nfsd_rename 20 months ago....

time to remove it.

The __start___ex_table and __start___bug_table symbols could end up
pointing a few bytes before the actual __ex_table and __bug_table
sections, if the preceding section had an odd length.  This led to
oopses in some situations.  Patch from Sam Ravnborg.

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

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

If we are unable to deliver a signal to the process (eg, due to stack
pointer corruption) block the signal so other fatal signals can kill
off the process.

K8 has an erratum (#100) that essentially causes some compat mode processes
to fault occassionally. The issue can be worked around in the OS. It only
applies to x86-64, in 32bit it is fine.

This adds a check to the page fault handler that checks for addresses >4GB
from compat mode. If they happen just return; the CPU will reexecute
the instruction and the condition that caused the problem is gone.

More details in Opteron/Athlon64 specification update on the AMD website.

Also I removed a left over debugging printk in the prefetch handling code.

default values after probing

This sets the mouse to 100 samples/second, 200 dpi, 1:1 mapping, which
is a standard setting, as close to 2.4 XFree86 behavior as possible, and
a good performance setting, too. 

It also in the case of 'psmouse_noext' doesn't probe and set anything
all, though it still issues the RESET command. This is as safe as one
can get.

The only real problem remaining is that the report rate and resolution
cannot be set from XFree86 config and only is available as a
kernel/module parameter. The fix is, howewer not 2.6.0 material.

The K8 IOMMU code had some broken BUG_ON()s that hit with <4K aligned IO
through the IOMMU.

This patch fixes this. Without this database raw IO is often broken.

into hera.kernel.org:/home/davem/BK/net-2.5

While using PRIVACY extensions, I sometimes get a hang when I remove the
interface. But I can reproduce this every time using the test script at
the end of the mail (hang depends on the order of address deletion).

The bug is in ipv6_del_addr() where if a temp address is being deleted, it
does an __in6_ifa_put() of the main address from which it was derived
(basically the autoconf prefix address). So if the main address was
deleted first, it's ifp ref count would be 1 and it would 'wait' to be
freed till it's temp address was freed first. When the temp address is
deleted, the __put() routine drops the main address's ifp ref count to 0,
but not free it. unregister_netdevice() hangs giving message that ref
count is 1. Fix tested overnight.

Also, the code at the top of the routine is unnecessary, the same is being
done when the address is found a little later in that routine.

The code that sends a signal needs to "kick" the target process if it
runs on another CPU and wasn't woken up by the signal to let it know
that it has a new event.

Otherwise it might take a long time until the target actually notices
and acts on the signal.

Fix a nasty typo found by Albert Cahalan.

This lead to an oops when a invalid syscall was called under strace in 2.6.

The limit of the TSS segment was incorrectly set to a too big value
on x86-64. This lead to the CPU reading random memory behind the main
TSS when iopl was >0, but there was no ioperm bitmap set. This caused
random failures in port accesses in this state.

Set the correct limit.

The latter has buggy restart functionality and is a lot
more complicated anyway.

When a kobject is associated with a kset, the kset MUST be set before
the kobject is initialized (by either a call to kobject_register() or
kobject_init()).  This patch fixes the class code which improperly set
the kset after the kobject was initialized, which would cause improper
reference counts on the kset.

Thanks to Mike Anderson for locating the source of this bug.

The hammer branch based gcc 3.3 in SuSE 9.0 has a more aggressive
optimizer. ip_send_check has this code:

	iph->check = 0;
	iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);

The new gcc optimizes the first store away because it doesn't know
that ip_fast_csum reads its input memory. This leads to occassionally
packets with wrong IP header checksum getting sent; this happens especially
with NFS. Fixing it in the constraints would have been ugly and probably
not future proof, so this patch just adds a memory clobber to ip_fast_csum.

For some reason the issue only hits in 2.6, we haven't seen it in 2.4.
Problem occurs on both i386 and x86-64.

Credit goes to Olaf Kirch for tracking this down.

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

The dma hooks whereby EHCI can pass 64bit DMA support
up the driver stack (to avoid buffer copies) turn out
to broken on most architectures(*).  This patch just
disables them all, since it looks like those mechanisms
won't get fixed before 2.6.0-final.  For now it'd only
matter on a few big Intel boxes anyway.

Please merge.

- Dave

(*) On x86, mips, and arm dma_supported() doesn't
     even compare with the device's mask.  On several
     other architectures (reported on ppc, alpha,
     and sparc64), asking that question for non-PCI
     devices will just BUG() -- even though all info
     needed to answer the question is right at hand.

This patch fixes a thread-exit problem when the usb-storage module is
unloaded with a preemptable kernel.  Please refer to the comments in the
code for more detail.

I have a VIA cardbus 1394 controller which oops on insertion
after an APM suspend/resume cycle (without card inserted):

bounds: 0000 [#1]
CPU:    0
EIP:    0060:[<c0300060>]    Tainted: PF
EFLAGS: 00010206
EIP is at quirk_via_bridge+0x4/0x1c
eax: 0000ffff   ebx: c02982e0   ecx: d1958000   edx: 000c0010
esi: d1958000   edi: 00000001   ebp: 00000000   esp: da401ee8
ds: 007b   es: 007b   ss: 0068
Process pccardd (pid: 1093, threadinfo=da400000 task=da4c8780)
Stack: c019fb85 d1958000 00000001 d1958000 00000000 c019fbc2 d1958000 00000001
         c02980a0 d1958000 dfdebf14 c019d828 00000001 d1958000 00000000 dec2802c
         dfdebf00 dfdebf14 00000000 e3dfe7c7 dfdebf00 00000000 dec2802c da401f48
Call Trace:
   [<c019fb85>] pci_do_fixups+0x52/0x54
   [<c019fbc2>] pci_fixup_device+0x3b/0x49
   [<c019d828>] pci_scan_slot+0x46/0x8f
   [<e3dfe7c7>] cb_alloc+0x29/0xf7 [pcmcia_core]
   [<e3dfb9aa>] socket_insert+0x90/0x102 [pcmcia_core]
   [<e3dfbc0d>] socket_detect_change+0x54/0x7e [pcmcia_core]
   [<e3dfbdbc>] pccardd+0x185/0x1f9 [pcmcia_core]

quirk_via_bridge (which is marked device PCI_ANY_ID) triggers on
my 1394 controller which vendor=VIA but is not a bridge.

Making the quirk __devinit solves the problem.

There's a few places that use incorrect exclusion for the cramfs raw
data access buffers.  The proper lock is "read_mutex" (and BKL does
nothing).

 - fix mount-time read and block number initialization without the mutex
   held. 
 - cramfs_readdir() needs to copy the name and inode information into a
   separate buffer since it can't hold the semaphore over the
   (potentially blocking) user mode access
 - cramfs_lookup() needs to hold the access lock over the whole
   function, not just the read itself
 - use generic_file_llseek on directories to get i_sem exclusion on
   readdir/lseek

From Herbert Xu

There's a problem with bio segment accounting for pages that reside
above the bounce limit of a queue. When submitted, they may be
considered part of another segment. A condition that changes when the
page gets bounced. This can cause us to send bio's that have too many
segments to a driver.

The best fix is to always consider pages above q->bounce_pfn as seperate
segments. That's the conservative approach and the easy fix.

Problem identified and fixed by Herbert Xu.

This fixes visws subarch which was broken by asm-i386/hw_irq.h changes

From Ronald Lembcke.

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

- Missing spin_lock*() calls before tp->link_config twiddling.
- Missing assignment to tp->link_config.autoneg

IRDA was restoring IRQ flags in a different function from which they
were saved which explodes on certain platforms.  It did not need to
use _irq{save,restore}() anyways since the seqfile layer always invokes
these routines from user context with interrupts enabled, so using
plain spin_{lock,unlock}_irq() works just fine.