From: Andy Wihitcroft <apw@shadowen.org>

The generic-subarch patch broke visws builds.

From: Christoph Hellwig <hch@lst.de>

memory_lseek() should return a loff_t.

From: Christoph Hellwig <hch@lst.de>

Remove smp.h leftovers.  From the ia64 tree.

From: Paul Fulghum <paulkf@microgate.com>

* Remove PCMCIA release from timer context
* Add irqreturn_t to ISR
* Add dosyncppp module parameter

It needs fs.h for struct inode.

From Badari Pulavarti.

Fixes lots of error-path memleaks which the Stanford guys found.

From: Petr Vandrovec <vandrove@vc.cvut.cz>

While I was trying to hunt down problem with spin_lock_irq in
send_sig_info, I noticed that debugging spinlocks are a bit unusable.

The problem is that these spinlocks first print warning, and then
decrement babble.  So if the lock is used by printk code (like runqueue
lock was), we get nothing, just a lockup or a double fault...  When we
first decrement babble and then print the error message we can break
this unfortunate situation and the error message (5 of the same...)
appear on screen.

From: john stultz <johnstul@us.ibm.com>

I've been having problems with ACPI on a box here in our lab.  Some of our
more recent hardware requires that SMIs are routed through the IOAPIC, thus
when we clear_IO_APIC() at boot time, we clear the BIOS initialized SMI
pin.  This basically clobbers the SMI so we can then never make the
transition into ACPI mode.

This patch simply reads the apic entry in clear_IO_APIC to make sure the
delivery_mode isn't dest_SMI.  If it is, we leave the apic entry alone and
return.

With this patch, the box boots and SMIs function properly.

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"