Patch to cciss driver in 2.4.8-pre2 to use pdev->irq
and other pci_dev structure elements only after calling
pci_enable_device.

Morten Helgesen <admin@nextframe.net> sent me this.

The latest ACPI merge accidentally clobbered another change in pci-irq.c.
Here's the original patch again (applies fine except for an offset)
Thanks -- Andy

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

More places where we want the size of block device and have relevant
struct block_device * available,

Fixes races in jffs2_get_sb() - current code has a window when two
mounts of the same mtd device can miss each other, resulting in two
active instances of jffs2 fighting over the same device.

Assorted compile fixes in mtdblock.c

All places where we do blkdev_size_in_bytes(sb->s_dev) are bogus - we
can get the same information from ->s_bdev without messing with kdev_t,
major/minor, etc.

There will be more patches of that kind - in the long run I'd expect
only one caller of blkdev_size_in_bytes() to survive.  One if
fs/block_dev.c, that is - called when we open device.

Pretty simple.

- use a timer to kick off a pdflush thread every five seconds
  to run the kupdate code.

- wakeup_bdflush() kicks off a pdflush thread to run the current
  bdflush function.

There's some loss of functionality here - the ability to tune
the writeback periods.  The numbers are hardwired at present.
But the intent is that buffer-based writeback disappears
altogether.  New mechanisms for tuning the writeback will
need to be introduced.

This is pdflush's first application!  The writeback of
the unused inodes list by keventd is removed, and a
pdflush thread is dispatched instead.

There is a need for exclusion - to prevent all the
pdflush threads from working against the same request
queue.  This is implemented locally.  And this is a
problem, because other pdflush threads can be dispatched
to writeback other filesystem objects, and they don't
know that there's already a pdflush thread working that
request queue.

So moving the exclusion into the request queue itself
is on my things-to-do-list.  But the code as-is works
OK - under a `dbench 100' load the number of pdflush
instances can grow as high as four or five.  Some fine
tuning is needed...

This patch implements a gang-of-threads which are designed to
be used for dirty data writeback. "pdflush" -> dirty page
flush, or something.

The number of threads is dynamically managed by a simple
demand-driven algorithm.

"Oh no, more kernel threads".  Don't worry, kupdate and
bdflush disappear later.

The intent is that no two pdflush threads are ever performing
writeback against the same request queue at the same time.
It would be wasteful to do that.  My current patches don't
quite achieve this; I need to move the state into the request
queue itself...

The driver for implementing the thread pool was to avoid the
possibility where bdflush gets stuck on one device's get_request_wait()
queue while lots of other disks sit idle.  Also generality,
abstraction, and the need to have something in place to perform
the address_space-based writeback when the buffer_head-based
writeback disappears.

There is no provision inside the pdflush code itself to prevent
many threads from working against the same device.  That's
the responsibility of the caller.

The main API function, `pdflush_operation()' attempts to find
a thread to do some work for you.  It is not reliable - it may
return -1 and say "sorry, I didn't do that".  This happens if
all threads are busy.

One _could_ extend pdflush_operation() to queue the work so that
it is guaranteed to happen.  If there's a need, that additional
minor complexity can be added.

page->buffers is a bit of a layering violation.  Not all address_spaces
have pages which are backed by buffers.

The exclusive use of page->buffers for buffers means that a piece of
prime real estate in struct page is unavailable to other forms of
address_space.

This patch turns page->buffers into `unsigned long page->private' and
sets in place all the infrastructure which is needed to allow other
address_spaces to use this storage.

This change alows the multipage-bio-writeout patches to use
page->private to cache the results of an earlier get_block(), so
repeated calls into the filesystem are not needed in the case of file
overwriting.

Devlopers should think carefully before calling try_to_free_buffers()
or block_flushpage() or writeout_one_page() or waitfor_one_page()
against a page.  It's only legal to do this if you *know* that the page
is buffer-backed.  And only the address_space knows that.
Arguably, we need new a_ops for writeout_one_page() and
waitfor_one_page().  But I have more patches on the boil which
obsolete these functions in favour of ->writepage() and wait_on_page().

The new PG_private page bit is used to indicate that there
is something at page->private.  The core kernel does not
know what that object actually is, just that it's there.
The kernel must call a_ops->releasepage() to try to make
page->private go away.  And a_ops->flushpage() at truncate
time.

I'd like to be able to claim amazing speedups, but
the best benchmark I could find was diffing two
256 megabyte files, which is about 10% quicker.  And
that is probably due to the window size being effectively
50% larger.

Fact is, any disk worth owning nowadays has a segmented
2-megabyte cache, and OS-level readahead mainly seems
to save on CPU cycles rather than overall throughput.
Once you start reading more streams than there are segments
in the disk cache we start to win.

Still.  The main motivation for this work is to
clean the code up, and to create a central point at
which many pages are marshalled together so that
they can all be encapsulated into the smallest possible
number of BIOs, and injected into the request layer.

A number of filesystems were poking around inside the
readahead state variables.  I'm not really sure what they
were up to, but I took all that out.  The readahead
code manages its own state autonomously and should not
need any hints.

- Unifies the current three readahead functions (mmap reads, read(2)
  and sys_readhead) into a single implementation.

- More aggressive in building up the readahead windows.

- More conservative in tearing them down.

- Special start-of-file heuristics.

- Preallocates the readahead pages, to avoid the (never demonstrated,
  but potentially catastrophic) scenario where allocation of readahead
  pages causes the allocator to perform VM writeout.

- Gets all the readahead pages gathered together in
  one spot, so they can be marshalled into big BIOs.

- reinstates the readahead ioctls, so hdparm(8) and blockdev(8)
  are working again.  The readahead settings are now per-request-queue,
  and the drivers never have to know about it.  I use blockdev(8).
  It works in units of 512 bytes.

- Identifies readahead thrashing.

  Also attempts to handle it.  Certainly the changes here
  delay the onset of catastrophic readahead thrashing by
  quite a lot, and decrease it seriousness as we get more
  deeply into it, but it's still pretty bad.

Before the mempool was added, the VM was getting many, many
0-order allocation failures due to the atomic ratnode
allocations inside swap_out.  That monster mempool is
doing its job - drove a 256meg machine a gigabyte into
swap with no ratnode allocation failures at all.

So we do need to trim that pool a bit, and also handle
the case where swap_out fails, and not just keep
pointlessly calling it.

This changes everything arch specific PPC and i386 which should have
been unsigned long (it doesn't *matter*, but bad habits get copied to
where it does matter).

No object code changes

This removes gratuitous & operators in front of tty->process_char_map
and tty->read_flags.

No object code changes

This changes over some bogus casts, and converts the ext2, hfs and
minix set-bit macros.  Also changes pte and open_fds to hand the
actual bitfield rather than whole structure.

No object code changes

driver needs this.  This is already done in 2.4.x

fixed linker bug when driver is compiled into the kernel.

removed the list-multi targets, as they aren't needed anymore.

Only build the IBM PCI hotplug driver if CONFIG_X86_IO_APIC is selected

This patch implements the following calls to set and retrieve a task's
CPU affinity:

    int sched_setaffinity(pid_t pid, unsigned int len,
    				      unsigned long *new_mask_ptr)
    int ched_getaffinity(pid_t pid, unsigned int len,
    				      unsigned long *user_mask_ptr)

	a) part of open_namei() done after we'd found vfsmount/dentry of
the object we want to open had been split into a helper - may_open().

	b) do_open() in fs/nfsctl.c didn't do any permission checks on
the nfsd file it was opening - sudden idiocy attack on my part (I missed
the fact that dentry_open() doesn't do permission checks - open_namei()
does).  Fixed by adding obvious may_open() calls.

As per David Mosberger's request, splits into per-arch files (solves the
#include mess), and fixes my "was not an lvalue" bug.

Cosmetic change: x86_capability.  Makes it an unsigned long, and
removes the gratuitous & operators (it is already an array).  These
produce warnings when set_bit() etc. takes an unsigned long * instead
of a void *.

Originally from Rusty Russell

i810_rng: add support for other i8xx chipsets to the Random Number Generator module.
This is being done by adding the detection of the 82801BA(M) and 82801CA(M) I/O Controller Hub's.

- Eliminate the mate member of the ata_channel structure. The information
   provided by it is already present. This patch may have undesirable
   effects on the ns87415.c and trm290.c host chip drivers, but it's worth
   for structural reasons to have it.

- Kill unused code, which was "fixing" interrupt routing from ide-pci.c Don't
   pass any "mate" between the functions there.

- Don't define SUPPORT_VLB_SYNC unconditionally in ide-taskfile.c

- Apply Vojtech Pavliks fix for piix host-chip driver crashes.

- Add linux/types.h to ide-pnp.c.

- Apply latest sis5513 host chip driver patch from by Lionel Bouton by hand.

- Apply patch by Paul Macerras for power-mac.

- Try to make the ns87415 driver a bit more reentrant.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

cleaned up the comments to put them in proper docbook format.

sanity checking and cleanup on device disconnect.
  
    - Splits apart usb_dec_dev_use(), for driver use, and
      usb_free_dev(), for hub/hcd use.  Both now have
      kerneldoc, and will BUG() if the refcount and the
      device tree get out of sync.  (Except for cleanup of
      root hub init errors, refcount must go to zero only
      at the instant disconnect processing completes.)
  
    - More usbcore-internal function declarations are
      now moved out of <linux/usb.h> into hcd.h
  
    - Driver-accessible refcounting is now inlined; minor
      code shrinkage, it's using atomic inc/dec instructions
      not function calls.

<note from greg k-h, there is still some work to be done with USB device
 reference counting, but this patch is a step in the right direction.>

This fixes some kerneldoc bugs for USB.  It catches up with
the recent rename, and includes a couple minor tweaks/fixes
I happened to notice.

- Documentation updates
- BKL removal (devfs doesn't need the BKL)
- Changed <devfs_rmdir> to allow later additions if not yet empty
- Added calls to <devfs_register_partitions> in drivers/block/blkpc.c
  <add_partition> and <del_partition>
- Bug fixes in unique number and devnum allocators.

This patch moves the generation of the asm interrupt entry stubs from
i8259.c to entry.S.  This allows it to be done with less code and
without needing duplicate definitions of SAVE_ALL, GET_CURRENT, etc.

It is a step on the road to removal of the arrays.
It also solves other things, like the fact that Linux
is unable to read the last sector of a disk or partition
with an odd number of sectors.

Unfortunately the proc filesystem has a limit on the number of dynamic
proc entries it can create. On large systems we can exhaust the default
(4096) very quickly. The following patch increases the default to
something more reasonable.

We forgot to include linux/init.h in fs/nfsd/nfsctl.c.

Since we do not set the task state to TASK_INTERRUPTIBLE, we busy loop.

On larger SMP this can actually result in a lockup due to the way
migration thread initalisation is done (nr_cpus threads are created
and they all busy loop until the scheduler evenly distributes them,
one on each cpu. With this rogue thread busy looping things can become
unbalanced and the migration threads never distribute themselves onto
all cpus).