Fix byte order of info parameter in ip6ip6_err().

From: "Bryan O'Sullivan" <bos@serpentine.com>

This patch adds documentation for the contents of the /proc/stat file.

If journal_start() fails it returns an ERR_PTR.  Best not pass that into
journal_stop().

Ancient bug, reported by Hiroshi Inoue <inoueh@uranus.dti.ne.jp>:

 1. login to tty2 (not tty1)
 2. start kon (Kanji cONsole emulator, console which support
    Japanese characters)
 3. exit kon
 4. logout

It oopses in the debugging function check_tty_count(), walking a list_head
which has been list_del()'d.   Call trace is:

#0  check_tty_count (tty=0x10d42000, routine=0xc817b00 ".paths") at include/asm/processor.h:583
#1  0x022c6c00 in do_tty_hangup (data=0x10d42000) at drivers/char/tty_io.c:426
#2  0x022c6f60 in tty_vhangup (tty=0xc817b00) at drivers/char/tty_io.c:536
#3  0x022c6fcc in disassociate_ctty (on_exit=1) at drivers/char/tty_io.c:574
#4  0x02127aee in do_exit (code=0) at kernel/exit.c:718
#5  0x02127caa in do_group_exit (exit_code=0) at kernel/exit.c:796
#6  0x02127cbc in sys_exit_group (error_code=0) at kernel/exit.c:807

The tty refcount is zero, so everything seems consistent and sensible.  The
fix just uses list_del_init() on that list_head.


Heaven knows what the locking for tty->count is though.  Some bizarre mixture
of BKL, tty_sem and nothing at all.

Some drivers such as aha1542 and aic7xxx_old will call scsi_register() and
then, if some succeeding operations fails they will call scsi_unregister(),
without an intervening scsi_set_host().

This causes an oops in scsi_put_device(), because kobj->parent is NULL.

In other words, scsi_register() immediately followed by scsi_unregister()
is guaranteed to oops.

The patch makes scsi_host_dev_release() more robust against this usage
pattern.

From: Hugh Dickins <hugh@veritas.com>

It's good that swapon fails on a tmpfs file ("swapfile has holes"), but not
good that it then hangs up: note error from setup_swap_extents.

From: Adrian Bunk <bunk@fs.tum.de>

The patch below fixes a compile error in drivers/scsi/advansys.c if
!CONFIG_PROC_FS.

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>

acpi boot time parsing changes to look for HPET

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>

This can be a standalone patch.  With this patch we basically try to emulate
RTC interrupt functions in software using HPET counter 1.

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>

All changes required to support timer services (gettimeofday) with HPET.

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>

All the changes required to use HPET in place of PIT as the kernel base-timer
at IRQ 0.

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>

Miscallaneous makefile and config changes

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>

High Precision Event Timer (HPET) is next generation timer
hardware and has various advantages over legacy 8254
(PIT) timer, like:
- Associated registers are mapped to memory space. So, we no
  longer require in and out on legacy ioports
- Memory map address is reported by ACPI (and are not
  hard-coded)
- Each timer can be configured to generate separate interrupts,
  even sharing lines with PCI devices
- HPET has a minimum period of 100 nanosecs and is not fixed.
  Giving a flexibility of increasing the resolution in future.
- Most current implementations has 3 counters, but in future,
  we can have as many as 32 timers per block, and 8
  HPET timer blocks (total 256 timers)
- Can support 32bit and 64bit counting

(Refer to http://www.intel.com/labs/platcomp/hpet/hpetspec.htm
 for complete specs)

The patchset that follow adds support for High Precision Event
Timer (HPET) based timer in kernel. This uses the HPET in
LegacyReplacement mode (so that counter 0 will be tied to IRQ0,
and counter 1 will be tied to IRQ 8). In this mode, HPET overrides
PIT and RTC interrupt lines. The patch will enable HPET by default,
on systems where ACPI tables reports this feature. The patch will
have no impact on systems that do not support this feature.




A major change from previous version is elimination of fixmap for HPET. 
Based on Andrew Morton's suggestion, we have a new hook in init/main.c for
late_time_init(), at which time we can use ioremap, in place of fixmap. 
Impact on other archs: Calibrate_delay() (and hence loops_per_jiffy
calculation) has moved down in main.c, from after time_init() to after
kmem_cache_init().

1/6 - hpet1.patch - main.c change to introduce late_time_init()

From: Andi Kleen <ak@muc.de>

Remove some dead code.

CONFIG_SSE2 hasn't been defined for some time, because everything
SSE related is handled at runtime based on cpuid.

The zone->pressure field is supposed to record the amount of reclaim pressure
which this zone is under.  We need this info so we know whether to unmap
pages from pagetables right from the outset of a balance_pgdat() or
try_to_free_pages() invokation.

The problem with the current code is that the exponential average gets tugged
around too much: as we perform the increasing-priority scan, the pressure
metric is made artificially low by the early part of the scan.

So instead what we do here is to record within the zone the scanning priority
from the zone's previous scan.  It is defined as the priority at which the
zone achieved the "enough pages free" state.  This prev_priority is used on
the next scan for the do-we-need-to-be-unmapping-pages decision.

Off-by-one in balance_pgdat(): `priority' can never go negative.  It causes
the scanning priority thresholds to be quite wrong and kswapd tends to go
berzerk when there is a lot of mapped memory around.

From: Andrea Arcangeli <andrea@suse.de>

aka: "vmalloc allocations in ipc needs smp initialized (and vm must be
allowed to schedule in 2.6)"

In short if you change SEMMNI to 8192 the kernel will crash at boot, beause
it tries to call vmalloc before the smp is initialized.  The reason is that
vmalloc calls into the pte alloc code, and the fast pte alloc is tried
first, but that reads into the pte_quicklist, that requires the cpu_data to
be initialized (and that happens in smp_init()).

the patch is obviously safe, since no piece of kernel (especially the code
in the check_bugs and smp_init paths ;) calls into the ipc subsystem.

The reason this started to trigger wasn't really that we increased SEMMNI,
but what happend is that some IPC data structure grown, and for some reason
the corruption due the uninitalized pte_quicklist triggers only for smp
boxes with less than 1G (not very common anymore ;).  So it wasn't
immediatly reproducible on all setups.

2.6 doesn't suffer from the same problem, simply because 2.6 isn't using
the quicklist anymore, but I think it would be much more correct to make
the same change in 2.6 too, since whatever cond_resched() in the vm paths
(and they're definitely allowed to call it), will lead to a crash since the
init task isn't initialized and the scheduler can't be invoked yet.  (and
2.6 already has the bigger data structures that should trigger the vmalloc
all the time on all setups)

From: Dave Olien <dmo@osdl.org>

The raw.c character device Oopses dereferencing a NULL pointer in
bd_claim() This problem occurred after bd_claim() in block_dev.c was
modified to "claim the whole device when a partition is claimed".

raw_open() made the mistake of calling bd_claim BEFORE calling blkdev_get().
At that time, the bdev->bd_contains field has not yet been initialized. 
Switching the order allows blkdev_get() to initialize those fields before
calling bd_claim().

Also fixed up some error return paths:

igrab() should never fail under these circumstances since the caller
already has a reference to that inode through the bdev at that time.

In the event of blkdev_get() failure or set_blocksize() failure, not all
the work to unwind from the error was done.

The arch ioctl tables are doing this:

	struct foo ioctl_start[] = {
		...
	};
	struct foo ioctl_end[0];

and fs/compat.c expects that the table lies between &ioctl_end and
&ioctl_start.

Problem is, gcc-3.3 puts ioctl_end into bss, even if it is initialised.  It
doesn't work.

So we do away with the ioctl_end thing and add

	int ioctl_table_length = ARRAY_SIZE(ioctl_start);

to each architecture.

- Remove duplicated implementation of attrib_to_str()

- Make mtrr_strings[] static to if.c

From: James Bottomley <James.Bottomley@SteelEye.com>

Most is just simple fixes; however, the needless change from atomic to
non-atomic operations in smp_invalidate_interrupt() caused me a lot of
pain to track down since it introduced some very subtle bugs.

I've also taken phys_cpu_present_map out of smp.h.  Since it
physid_mask_t is defined in mpspec.h anyway, and contains a duplicate
definition, I don't believe it can hurt anything.

extern decls in .c files are evil.  Put the send_sigio(), fcntl_setlease()
and fcntl_getlease() into fs.h.

From: Ulrich Drepper <drepper@redhat.com>

I'm not entirely sure about this change.  But it seems to be necessary. 
The dnotify code stores the PID in the file structure.  The entire process
shares the file and any signal (is it used for that?) should be sent to the
process (thread group), not the individual thread.  Also keep in mind that
threads can go away while the process (and therefore file descriptor)
remain.  And the ID of the thread can be reused.

Somebody who knows this code should take a good look.

(Looks right to me...)

From: "Randy.Dunlap" <rddunlap@osdl.org>

- use kernel.h min() and max();

- C99 initializers;

- Tidy up the scheule_work() callbacks (none of them take an arg)

From: "Randy.Dunlap" <rddunlap@osdl.org>

fix arcnet printk parameter types

From: Valdis.Kletnieks@vt.edu, Sam Ravnborg <sam@ravnborg.org>

Adds an explicit check for the new modutils in the build system.

Generally we should avoid these sorts of hardwired checks for the right
versions of things, but we are still getting a significant number of problem
reports due to people not having the new tools.  Let's help them out.

From: "John Stoffel" <stoffel@lucent.com>

Quick patch to get my 8 port Cyclades Cyclom-Y ISA card to work.

(It doesn't look to be very SMP-robust, but then the 2.4 dirver probably
isn't either).

From: Christoph Hellwig <hch@lst.de>

I moved a while ago and I'm also not at SGI anymore.