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

Display of cpumask for /proc/irq/prof_cpu_mask has a botch in the print
loop - should consume 2 bytes per loop.

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

Found by Russell King.

Since 2.6.x by default does not remap the disk partitions any more, it
would be a good idea to warn when we see EZD or DM signatures.  That
informs the user to fix his setup (or pass in "hdx=remap" on the kernel
command line).

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

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

* flush host FIFO after sending data to DIMM window
* don't set SCR addresses, as the hardware doesn't have SCRs
  (cosmetic)

From: James Bottomley <James.Bottomley@SteelEye.com>

The cpu_callout_map differs from the prototype in asm-i386/smp.h by a
volatile.  gcc-3.3 now treats this as an error, so voyager support will
only compile with older gcc's.  The fix is to remove the spurious volatile.

This fixes a JBD assertion failure (goes BUG) in __journal_remove_journal_head().

When the journal had aborted due to earlier internal consistency errors (or
I/O errors) it is possible that we free journal_heads which still have
attached copyout buffers.  So just free them up.

From: Mike Tran <mhtran@us.ibm.com>

This fixes the RAID1 recovery problems; it seems to be a simple thinko:
sync_request_write() is passing "ok=0" into md_done_sync().  Clearly, `ok'
should be true here.

(acked by neilb)

From: Rusty Russell <rusty@rustcorp.com.au>

Module aliases are all of form "char-major-<major>-<minor>".  char_dev.c
calls request_module with "char-major-<major>".

It's not ready for prime time yet, so hide it until the additional work has
been done.

If this CPU decides that an ext2 block group has a free block it will then go
in and try to acquire it.  No locks are held, so another CPU can come in and
steal the last block.

In this case we will bogusly report a corrupted filessytem.

Fix it by just restarting the scan - this will choose a different blockgroup
or will generate -ENOSPC.

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.

a patch for the pcnet32.c driver which adds a missing call to
pci_dma_sync_single.  If a received packet is smaller than rx_copybreak
the pcnet driver will recycle the receive buffer which requires calling
pci_dma_sync_single.  Patch is against 2.6 but I it's also needed in 2.4.

Without that call the processor might still have old stale data in
the data cache when the processor accesses the recycled buffer.

Also, add suspend/resume functions.

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.