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

Following patch seperates elevator noop, and allows it to be treated
like the other schedulers.

From: Mark Haverkamp <markh@osdl.org>

Properly implement elevator_t..elevator_requeue_req_fn for the anticipatory
scheduler.

This fixes some rarely-occurring oops in the IO scheduler.

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

Gets rid of the silly (and undocumented) trinary stateness of
ad->changed_batch.

Kernel style flags field could now save 20 bytes per asd (request queue) and
4 per arq.  But I figure that change can wait until I do autotuning...

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

The crazy HASH_VALID stuff now makes no difference now.  It was there to
try to enforce no merging over a barrier, but it turned out that requests
can just be reordered.  Jens picked this up a a while ago and fixed
deadline (and I AS) by simply dispatching all reqs on the queue on
encountering a barrier.  The hash valid stuff didn't get cleaned up.

From: Ingo Molnar <mingo@elte.hu>

It unifies the functionality of add_timer() and mod_timer(), and makes any
combination of the timer API calls completely SMP-safe.  del_timer() is still
not using the timer lock.

this patch fixes the only timer bug in 2.6 i'm aware of: the del_timer_sync()
+ add_timer() combination in kernel/itimer.c is buggy.  This was correct code
in 2.4, because there it was safe to do an add_timer() from the timer handler
itself, parallel to a del_timer_sync().

If we want to make this safe in 2.6 too (which i think we want to) then we
have to make add_timer() almost equivalent to mod_timer(), locking-wise.  And
once we are at this point i think it's much cleaner to actually make
add_timer() a variant of mod_timer().  (There's no locking cost for
add_timer(), only the cost of an extra branch.  And we've removed another
commonly used function from the icache.)

From: Albert Cahalan <albert@users.sourceforge.net>

This should improve timekeeping a bit @ 1000 HZ.

From: Neil Brown <neilb@cse.unsw.edu.au>

Fix "bio too big" problem with md

Whenever a device is attached to an md device, we make sure the sector
limits of the md device do not exceed those of the added device.

Alas, both POSIX and I got the fadvise() interface wrong.  It needs to take a
64-bit length, not a 32-bit one.  Because fadvise(POSIX_FADV_DONTNEED) on a
4TB file will require 1000 syscalls.  Silly.

There are glibc's in the wild which use the existing syscall, so we must
make a new one.

invalidate_mapping_pages() takes start/end, but fadvise is currently passing
it start/len.

This fixes the DMA interface to be backwards compatible with older
XFree86 versions, by looking at the I810_INIT_DMA parameters and
figuring out old version semantics.

CLONE_THREAD without CLONE_DETACHED will now return -EINVAL, and
for a while we will warn about anything that uses it (there are no
known users, but this will help pinpoint any problems if somebody
used to care about the invalid combination).

A part of the 64 bit kdev_t patch already got merged, and it changes the
format of /sys/block/<dev>/dev from %02x%02x to %u:%u.  The partition
could must also be changed.

e.g. cat /sys/block/hda/hda5/dev should return 3:5 instead of 0305

It was caused by improper IV calculation in loop.c

cryptoloop won't oops anymore if ECB mode is requested.

Just call them from the x86-64 entry code.

Also implement the x86-64 specific sys32_timer_create.

Add 32bit->64bit conversion functions for POSIX timers.

I kept timer_create architecture specific, because it does signal specific
stuff which is not portable enough for generic compat.

Add compat_sys_utimes for 32bit->64bit utimes conversion

Add compat_* functions for statfs64. The 32bit layout unfortunately
does not match x86-64.

This patch allows modules to work for ARM, and is the one thing which
prevents the standard tree from building for any ARM machine.

After reviewing the /proc/kcore and kclist issues, I've decided that I'm
no longer prepared to even _think_ about supporting /proc/kcore on ARM -
it just gets too ugly, and adds too much code to make it worth the effort,
the time or the energy to implement a solution to that problem.

/proc/kcore should probably go away, but in the meantime this just allows
ARM to ignore the issues.

makes 2.4->2.6 diff noticeable smaller

and add stripped down buffer_head variant (struct idetape_bh).

ide-tape is accessed by a char device (not a block one!),
it uses block layer only to queue requests.

also add missing Kconfig help entry from 2.4.x

- more locking fixes
- preserve gendev.parent of the old hwif in the new one

Noticed by Andries.Brouwer@cwi.nl.

Also:
- kill probe_lba_addressing() wrapper
- rename hwif->addressing to hwif->no_lba48

From Andries.Brouwer@cwi.nl.

- always use drive->capacity48 and kill drive->capacity

I've changed drive->capacity48 to drive->capacity64 to avoid confusion.

From Andries.Brouwer@cwi.nl.

- kill redundant, never executed code in lba_capacity_is_ok()
- add idedisk_supports_{hpa,lba48}() helpers
- don't recalculate drive->cyl for drives using LBA addressing,
  we never fall-back to CHS, so its useless and confusing
- remove wrong drive->head and drive->sect assignments for LBA-48
- don't overwrite id->lba_capacity and id->lba_capacity_2

HDIO_GETGEO_BIG_RAW is an ide specific hack introduced in 2.3.99-pre3.
There are no known programs using this ioctl.

Its aim was to provide current CHS translation to the user-space,
but very often it provides what driver thinks is a current translation
(drive with LBA have to support only one physical translation, also
 drive may not support chosen translation and there is no return value check).

hdparm -I can be used instead, it provides correct information
(and bogus data is still accessible through /proc/ide/hdX/geometry).

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

into jen.americas.sgi.com:/src/lord/bitkeeper/xfs-2.5

by moving blk queue manipulation down into pagebuf. 
Fix some busted comments in page_buf.h, use a more
descriptive name for __pagebuf_iorequest.

SGI Modid: 2.5.x-xfs:slinx:155788a

The help for CONFIG_DEVPTS_FS claims that devfs "is a more general
facility".  But that apparently hasn't been true since 2.5.68.  This patch
removes that claim, and adds a warning to the DEVFS_FS help.

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

into kernel.bkbits.net:/home/lord/xfs-2.5

From A1tmblwd@netscape.net

This updates my email address.

This corrects the following problem:

- release user buffer mapping early in read path (prevent oops in some
  HBA drivers)

Patch by Ivan Gyurdiev.

Here are some minor updates to the IPMI driver.  They fix the following:

    * A missing check for copy_to_user() in the watchdog driver.
    * Removal of unnecessary check_region() calls.
    * Fixes for the ACPI configuration. The previous one would only work
      with memory addresses, this will work with memory addresses,
      ports, and hadle checking that the type is correct.

The HPT366 code is broken - it tries to set the interface to too high a
speed, which leads to error messages at boot time and/or to data
corruption.

The typical effect at boot time is

 hde: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
 hde: set_drive_speed_status: error=0x04 { DriveStatusError }

Fixed thus.