I was confused about this bit
of code in acpi_boot_init():

        smp_boot_data.cpu_count = available_cpus;
        if (available_cpus == 0) {
                printk(KERN_INFO "ACPI: Found 0 CPUS; assuming 1\n");
                available_cpus = 1; /* We've got at least one of these, no? */
        }

        smp_build_cpu_map();

because it first saves available cpus in smp_boot_data, then potentially
modifies available_cpus.  This looked at first like a bug, but I think
actually works out correctly, because smp_boot_data.cpu_count is only
used in smp_build_cpu_map(), and if cpu_count is zero, it prevents us
from looking at smp_boot_data.cpu_phys_id[0], which hasn't been
initialized.

This should only happen with really buggy firmware, so I'm not even
sure it's worth doing more than panicking, but if we're going to deal
with it, I propose the following patch to avoid even the appearance
of a bug.  This just does what acpi_parse_lsapic() would have done
if the firmware tables were correct.

I have revised the oprofile patch for ia64 to provide just the basic
timer interrupt mechanism to avoid interferring with the perfmon 2.0
support. I have verified the oprofile ia64 patch applies cleanly and
build a working kernel with the 2.6.0-test4 kernel and the
linux-2.6.0-test4-ia64-030826.diff.bz2 patch.

More work is required to get oprofile to work with the perfmon 2.0.
However, the patch as it is currently implements should not cause
problems for the perfom 2.0 support.

	not "correctable").

gotten lost.  Please apply the attached for the cpe side of the
fix.

 - IGNORE_FLAGS_OBJS is no longer honoured (this is the only reference to
   it in the tree).
 - Change the .o.S rule to look the same as the one in
   scripts/Makefile.build.  This means we'll generate .cmd files instead
   of the .d files which makes CVS happier.

Currently the generic kernel won't build if you turn off NUMA
support.  Seems discontig support is too entangled with NUMA
support to live without it.  This patch makes it behave a bit
more friendly.

Here is a small patch for paddr_to_nid().  This fix is already in 2.4
and is used in the case where a NUMA kernel is running on a machine
without a SRAT ACPI table.  Without this patch the node info is not
correctly located.

i386 defaults to building bzImage (as well as modules) if you just type
make.  This patch mirrors that on ia64 by building compressed.

into tiger.hpl.hp.com:/data1/bk/lia64/to-linus-2.5

sound/pcmcia/vx/vx_entry.c:

This patch removes the PCMCIA timer release functionality which is no
longer required. Without this the module does not compile.

Too much cut-and-paste, noticed by Dmitry Torokhov <dtor_core@ameritech.net>

into samba.org:/home/paulus/kernel/for-linus-ppc

On PPC32 we reorder the arguments so they fit into 6 registers.  Glibc will
need a two-line stub to change them from the standard order to the ordering
used by the system call: (fd, advice, offset, len).

into samba.org:/home/paulus/kernel/for-linus-ppc

into samba.org:/stuff/paulus/kernel/for-linus-ppc

into samba.org:/stuff/paulus/kernel/for-linus-ppc

into samba.org:/stuff/paulus/kernel/for-linus-ppc

into samba.org:/stuff/paulus/kernel/for-linus-ppc

In both 2.4 and in 2.6, error handling for bad cdrom media is
wrong.  And it is my fault I'm afraid, since I botched an earlier
fix for the problem by putting the fix in the wrong spot.

My kids have a "Jumpstart Toddlers" cd they have long since
completely killed, which makes a great test disc.  Without this
fix, the best time projection I can get for completing a dd type
sector copy is about 2 years...  Most of that is spent thrashing
about in kernel space trying to re-read sectors we already know
are not correctable....  After the fix, I was able to rip a copy
the CD (or rather muddle through it getting lots of EIO errors)
in about 15 minutes.

Attached is the fix for 2.6.x,

into samba.org:/stuff/paulus/kernel/for-linus-ppc

of requiring users to select SCSI in order to see it.

The attached patch by Tony Luck fixes a memory leak in the ia32 execve code
path.

into fys.uio.no:/home/linux/bitkeeper/nfsclient-2.5

From Christoph Hellwig

From David Mosberger:

> We definitely are seeing some strange crashes in get_ksymbol_core().
> I think the reason is the lack of iterator initialization.

Yes, looks good: reset the iterator at allocation.

Remove the PCMCIA release timer that got missed in earlier patch.  This
is required for successful compilation of the driver.

into fys.uio.no:/home/linux/bitkeeper/nfsclient-2.5

nfsroot_mount().

Problem analysis and fix provided by Andries Brouwer.
Cleanup of nfs_lookup() by me...

o inline assembler funcs cleanup
o machine depend header cleanup
o interrupt management fix

o build script update
o interrupt management fix
o mtd support fix
o signal handling fix

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