From: Faik Uygur <faikuygur@ttnet.net.tr>:

mtrr_file_del() is using the wrong thing for fcount.  This causes it to
print mtrr: MTRR 2 not used" twice when exiting X.

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

loop.c has one of those places where manipulating own refcounts is safe: to
get into the ioctl handler you need to have the device open, so that holds a
refcount already (verified that this actually happens).

The compile warning is irritating.

From: Dave Olien <dmo@osdl.org>

I'm forwarding this patch to the DAC9690 driver from Christoph.  I've
applied it to the 2.5.69 DAC960 driver, compiled it, and ran it through
some tests on both V1 and V2 type controllers.  It looks good.

From: norbert_wolff@t-online.de (Norbert Wolff)

In arch/i386/mm/hugetlbpage.c htlbzone_pages and htlbpage_freelist are
declared static at the Top of the File and later in set_hugetlb_mem_size()
as extern.

gcc-3.4 does not accept this conflict.

put_dirty_page() currently assumes PAGE_COPY for the stack page's ptes.  But
for x86_64 (at least) this is not the case.

The patch adds the extra arg to put_dirty_page(), updates all callers and fixes
x86_64.

From: Hal Duston <hduston@speedscript.com>

This fixes a bug that appears to have crept in between 2.5.69-mm1 and
2.5.69-mm2 with the "switch most remaining drivers over to devfs_mk_bdev"
patch

CPU flags are unsigned long.

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

Originally from Matt Dobson. I've been running with this for a while
in -dj, with no noticable side-effects.

Matt:

node_zonelists looks like it should really be declared of size
MAX_NR_ZONES, not GFP_ZONEMASK.  GFP_ZONEMASK is currently 15, making
node_zonelists an array of 16 elements.  The extra zonelists are all
just duplicates of the *real* zonelists, namely the first 3 entries.
Again, if anyone can explain to me why I'm wrong in my thinking, I'd
love to know.  There's certainly no way you could bitwise-and something
with any combination of the GFP_DMA and GFP_HIGHMEM flags to refer to
the 12th zonelist or some such!  Or am I crazy?

Syncs up with 2.4

From 2.4 long long ago.

From 2.4 from way back 13 months ago..

Single spin_unlock path cuts this down a little..

Patch from Steven Cole to fix up ver_linux output on a system
with no module-init-tools, just modutils.

As noted in bugzilla #267 and at
http://marc.theaimsgroup.com/?l=linux-kernel&m=104492524815220&w=2

Erk, that's a really funny looking switch.
Every case fell through..

From Dominik Brodowski, comments says it all..

This went into 2.4 nearly a year back with the wonderfully
descriptive  "Fix from maintainer" comment.

This went into 2.4 back last August with the comment in $subject.

There are still a few places where we play with the RTC
directly, with no locking. This catches some of them.

This went into 2.4 with the following comments..

ide-scsi driver starts DMA as soon as it writes the ATAPI PACKET command
in command register and before sending the ATAPI command. This will
cause problems on many drives. Right way to do it is to start DMA after
sending the ATAPI command. I am attaching a patch that fixes this. This
patch will allow many more CD-RW drives to work reliably in DMA mode
than do today

Alan's comment to this diff previously..
"Thats the least of the 2.5 ide-scsi problems, but yes its probably one to add"

wrmsr is ok, but needs cleans up, second part (rdmsr)
is currently broken.

This patch from Alan went into 2.4 last august with the comment
"get the types right on the lib/inflate.c constants"

into nuts.ninka.net:/home/davem/src/BK/net-2.5

As it has to happen before pktsched_init, that is called from
net_dev_init that is a subsys_initcall, making it the same
init level as netlink_proto_init, that ends up being called
_after_ net_dev_init, so when pktsched_init is called it finds
rtnetlink_links[PF_UNSPEC] as null and therefore not sets
the ->dumpit entry for RTM_GETQDISC (and the others too):
b00m, rtnetlink_rcv sends a failure message to tc.

into nuts.ninka.net:/home/davem/src/BK/net-2.5