into nuts.ninka.net:/disk1/davem/BK/sparc-2.5

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

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

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

algorithm in it.  The old algorithm appeared to look for the first
place to put a new data block, and thus a new freespace block (this is
where the 'foundindex' variable came from).  However, new space in a
directory is always added at the lowest file offset as determined by
the extent list.  So this stuff is never used.

I completely ripped out the reminants of the old algorithm, and
(again) moved the freespace block add code inside the conditional
where a data block is added.

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

[XFS] Use an xfs_ino_t to hold the result of inode extraction from a handle, not a possibly 32-bit number

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

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

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

If you have a 4gig or greater system, some versions of aacraid firmware
have problems if you set HostPhysMemPages >= 0x100000.  This can
potentially cause data corruption.  If you have 4gig or greater memory,
this patch sets the HostPhysMemPages to something that the firmware can
deal with.

I propose the 2.6.0-test8 two-line patch below to teach
SG_SET_RESERVED_SIZE to reject a negative size, rather than oops-ing.

This patch removes the delay in calling device_del on the sdev struct
device during a surprise removal event. Reference counting functions for
sd's scsi_disk structure where also added to fix issues of unregistering
when a sd is open.

I have tested this patch using scsi_debug with differnt combinations of
adds / removes. I mounted both partitioned and un-partitioned sd disks,
remove the host, and then did a umount. The ref count debug output shows
the objects staying in place prior to the umount and cleaning up once
the umount is called.

This patch fixes an issue with a delayed call of device_del on the
sdev_gendev struct device.
	- Remove the delayed call to device_del.
	- Add kobject to sd scsi_disk structure.
	- Add release function for scsi_disk kobject.
	- Add get / put functions for scsi_disk and calls to these
	  functions.

 drivers/scsi/scsi.c       |    4 --
 drivers/scsi/scsi_sysfs.c |    3 --
 drivers/scsi/sd.c         |   63 ++++++++++++++++++++++++++++++++++++++++------
 3 files changed, 57 insertions(+), 13 deletions(-)

Apparently some laptops (Compaq EVO N620c for one) have something
hidden at IO port range 0x1000, and the 2.4.x default of allocating
IO starting at 0x4000 is safer.

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

It's incorrect for any user of the non-synchronizing irq_disable_nosync().

Cset exclude: torvalds@home.osdl.org|ChangeSet|20031013020955|28777

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

I stumbled on a couple trivial bugs in ia64 numa/discontig support.
The first just sets the default number of nodes to something reasonable
for a generic kernel, otherwise it's really easy to start walking over
your initdata (more error checking should probably be added).  The
second fixes a memcpy to a physical address.

Without this patch, if a signal handler tried to access TLS data (via %gs), things break, because the GS descriptor is zero.

To be compatible with i386, we shouldn't be touching the segment descriptors
before getting into signal handlers.

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

their NR_IRQ_VECTORS.

	do_tty_hangup() does fput() on redirect struct file too early -
it could've been the only holder of tty_struct we are working with and in
that case we'll end up freeing it from fput() and then both reading and
modifying kfreed memory.

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

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

early_serial_setup() doesn't validate the array index, so a caller could
corrupt memory after serial8250_ports[] by supplying a value of port->line
that's too large.

I haven't seen a failure related to this, but it seems fragile to rely on
callers to know how many ports the driver supports.

Need to null-terminate that table.

From: Patrick Gefre <pfg@sgi.com>

Add ia64 Altix serial console driver.

From: Luiz Capitulino <lcapitulino@prefeitura.sp.gov.br>

when PROC_FS=n, arlan.h will define init_arlan_proc() and
cleanup_arlan_proc() as macros.  So, whitout the #ifdef/#endif here, we have
two definitions.

From: Pavel Machek <pavel@ucw.cz>

This printk is unneccessary for quite a long time, please kill it. [I
added it, so it should be okay for me to request it being killed..]

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

ia64 needs more complete checking on the offset which is passed into reads
or writes of /dev/mem.

This patch factors out the range checking so that the architecture can
implement a private version.

From: "Noah J. Misch" <noah@caltech.edu>

Two gameport drivers need __devexit_p wrapped around their remove
functions.  A newer binutils caught this is a link error.  This patch fixes
that.

Wrapped a __devexit_p around the 'remove' functions of two gameport
drivers.  The lack of __devexit_p was wrong according to linux/init.h,
differed from the practices in nearby files, and caused a link error with
binutils 2.14.90.0.5.

From: miles@lsi.nec.co.jp (Miles Bader)

The cb_pic_handle_irq function on this platform hadn't been updated to
use irqreturn_t; do so.

From: miles@lsi.nec.co.jp (Miles Bader)

This reservation is handled by platform-independent code in 2.6.0, but some
platforms _also_ did it in platform-specific code (left over from 2.4.x).

From: miles@lsi.nec.co.jp (Miles Bader)

Use `late_initcall' instead of just `__initcall' as a workaround for
the fact that (1) simcons_tty_init can't be called before tty_init,
(2) tty_init is called via `module_init', (3) if statically linked,
module_init == device_init, and (4) there's no ordering of init lists.

We can do this easily because simcons is always statically linked, but
other tty drivers that depend on tty_init and which must use
`module_init' to declare their init routines are likely to be broken.

From: "Noah J. Misch" <noah@caltech.edu>

Allows the Toshiba SMM driver to compile with CONFIG_PROC_FS=n.

It is missing an up() on an error path.

Peter Osterlund <petero2@telia.com> notes oopses in the anticipatory
scheduler with slab poisoning enabled due to arq->rb_node.rb_right being
uninitialised.  So wipe the whole thing when we allocate it.

deadline seems to have the same problem.

Backport this fix from 2.4

If you have an MCA kernel on non-MCA hardware and load an MCA driver,
mca_find_unused_adapter() ends up dereferencing NULL. 

Teach it about the absence of MCA buses.

With CONFIG_MCA=y and no MCA bus present, drivers go oops deep in the kobject
code when calling mca_register_driver().  Because there is no MCA subsystem
registered against the driver.

Plug this in mca_register_driver().