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.

- Prevent 'self' leak on error in irlmp_open.
  ASSERT is compiled in only with DEBUG option => risk = 0.

Original patch from Chris Wright.

- Prevent sending status event to dead/kfree sockets
- Disable PPP access before deregistration
  PPP deregistration might sleep -> race condition

- Do not do copy_from_user() under spinlock
- Always access self->skb under spinlock

Original patch from Martin Diehl.

This fixes a panic-at-boot when ACPI Hotplug PCI is compiled in, but
ACPI is disabled.  It just makes sure that the list is properly
initialized statically instead of depending on runtime initialization
that may or may not happen.

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

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

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

Bug noticed by Russell King.

ioremap_nocache() doesn't need to check for physical address
wraps because __ioremap() has already done that;
fix calculation of npages to handle non-aligned phys_addr;

get_unique_tuple doesn't check that the tuple is unique if it finds
a hash_by_src match.

Noticed by Stuart_Hayes@Dell.com:

I've noticed that, in the 2.6 (test 9) kernel, the "cmd" field (of type int)
in struct request has been removed, and it looks like all of the code in
ide-tape has just had a find & replace run on it to replace any instance of
rq.cmd or rq->cmd with rq.flags or rq->flags.

The values being put into "cmd" in 2.4 (now "flags", in 2.6) by ide-tape are
8-bit numbers, like 90, 91, etc... and the actual flags that are being used
in "flags" cover the low 23 bits.  So, not only do the flags get wiped out
when, say, ide-tape assigns, say, 90 to "flags", but also the 90 gets wiped
out when one of the flags is modified.

I noticed this, because ide-tape checks this value, and spews error codes
when it isn't correct--continuously--as soon as you load the module, because
ide-tape is calling ide_do_drive_cmd with an action of ide_preempt, which
causes ide_do_drive_cmd to set the REQ_PREEMPT flag, so "flags" isn't the
same when it gets back to idetape_do_request.

Set filp->private_data in idetape_chrdev_open() to point to a opened drive,
otherwise driver oopses during future access to tape character device.

Thanks to Stef van der Made <svdmade@planet.nl> for testing ide-tape fixes.

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

Moving isapnp further down in the bus initialization obviously sparked
some new problems.

Instead, remove the legacy netdev probing function from dev.c and give
it its own initcall later in the cycle.