o Fix build on 2.5.X

into overdrive.btc.adaptec.com:/usr/home/gibbs/bk/linux-2.5

  Remove pre-2.2.X kernel support. 

 o Switch to handling bad SCSI status as a sequencer interrupt
   instead of having the kernel proccess these failures via
   the completion queue.  This is done because:

    - The old scheme required us to pause the sequencer and clear
      critical sections for each SCB.  It seems that these pause
      actions, if coincident with a sequencer FIFO interrupt, would
      result in a FIFO interrupt getting lost or directing to the
      wrong FIFO.  This caused hangs when the driver was stressed
      under high "queue full" loads.
    - The completion code assumed that it was always called with
      the sequencer running.  This may not be the case in timeout
      processing where completions occur manually via
      ahd_pause_and_flushwork().
    - With this scheme, the extra expense of clearing critical
      sections is avoided since the sequencer will only self pause
      once all pending selections have cleared and it is not in
      a critical section.

 o Revert ahd_pause_and_flushwork() behavior so that ENSELO can
   be cleared.  This makes ahd_pause_and_flushwork() more effective
   when the bus is hung.

 o Correct "Unexpected PKT Busfree" error observed under high
   tag loads.

 o Perform a few firmware optimizations
 o Correct the packetized status handler so that
   it can handle CRC errors during status data packets.

 o Auto disable PCI parity error reporting after 10 parity errors
   are observed.  The user is given a loud warning message telling
   them that eiter a device plugged into their motherboard or their
   motherboard is not very healthy.

 o Correct type safty of option parsing logic
 o Make option toggling work correctly
 o Add "probe_eisa_vlb" as an alias for the "no_probe" option so
   that there is a clearly defined name associated with the command
   line feature that allows eisa_vlb probes to be enabled/disabled
   in the aic7xxx driver.
 o PCI parity error checking defaults to being enabled.

 o Fix style nits.

 o Remove extra complexity and code duplication in processing
   the completeq now that the completeq can be run while holding
   both the ah?_lock and the done_lock.

 o Work around peculiarities in the scan_scsis routines
   that could, due to having duplicate devices on our
   host's device list, cause tagged queing to be disabled
   for devices added via /proc.

 o Correct channel information in our /proc output.

o Avoid pre-2.5.X mid-layer deadlock due to SCSI malloc fragmentation

For pre-2.5.X kernels, attempt to calculate a safe value
for our S/G list length.  In these kernels, the midlayer
allocates an S/G array dynamically when a command is issued
using SCSI malloc.  This list, which is in an OS dependent
format that must later be copied to our private S/G list, is
sized to house just the number of segments needed for the
current transfer.  Since the code that sizes the SCSI malloc
pool does not take into consideration fragmentation of the
pool, executing transactions numbering just a fraction of our
concurrent transaction limit with list lengths aproaching
AH?_NSEG in length will quickly depleat the SCSI malloc pool
of usable space.

Unfortunately, the mid-layer does not properly handle this
scsi malloc failure.  In kernels prior to 2.4.20, should
the device that experienced the malloc failure be idle and
never have any new I/O initiated (block queue is not "kicked"),
the process will hang indefinitely.  In 2.4.20 and beyond,
the disk experiencing the failure is marked as a "starved
device", but this only helps if I/O is initiated to or completes
on that HBA.  If the failure was induced by another HBA, and
no other I/O is pending on the HBA and no new transactions are
queued, we are still succeptible to the hang.  (Also note that
many 2.4.X kernels do not properly lock the "some_device_starved"
and "device_starved" fields calling into question their overall
effectiveness).

By sizing our S/G list to avoid SCSI malloc pool fragmentation,
we will hopefully avoid this deadlock at least for configurations
where our own HBAs are the only ones using the SCSI subsystem.

Linus, could you please apply this patch so all thos poor devfs
users get their disks back?

The patch is obviously correct and has been floating on lkml for some time.

From Manfred Spraul:
 "My init_irq cleanup introduced a bug: on error, the function must return 1."

Looks like my finger fell off the control key..

Fix some warnings from the new code-patching stuff.

- Fix printk bug in the diagnostic code.

- If an error occurs, print the address of all the offending action
  handlers.  Also the symbol name if CONFIG_KALLSYMS.

The invalidate_buffers in ->release is wrong, get a reference to the
discipline in the beginning of ->open.

This one probably crept in during an ide merge from 2.4..

It looks like no one even tried to use it on 2.5..

Return an error code instead of a devfs_handle_t.  The handle isn't
useful for anything and the !CONFIG_DEVFS_FS stub in fact returned
NULL which made it entirely useless.  Thus only one driver is actually
checking the retval in the current tree..

Now that devfs_handle_t is gone from all structs there is no
reason to include it in headers.

Fix the fallout by including previously implicit headers and fixing
the drivers that didn't include devfs_fs_kernel.h explicitly.

They are obsfucating aliases for SetPageReserved/ClearPageReserved.
And once they're gone we can nuke <linux/wrapper.h>

And uninline end_request - it's calling to many functions to be useful
inline.

They don't have any code in common, so the initrd support can
go into a separate file and not require ramdisk support.

Lots of ifdefs gone and smaller kernel images for initrd users.

not be marked __init.

Noted by Petr Vandrovec

	* we allow tty_driver to cover more than 256 devices
	* pty.c cleaned up - now we only one driver for UNIX98 masters and
only one driver for UNIX98 slaves, so a lot of ugliness can be killed.
	* get_tty_driver() became an analog of get_gendisk() - it does
a lookup by device number and gives (pointer to tty_driver,index).
	* registration/unregistration of tty_driver updated
	* /proc/tty/drivers code updated (now one structure can be responsible
for several lines)

	tty->device switched to dev_t
	There are very few uses of tty->device left by now; most of
them actually want dev_t (process accounting, proc/<pid>/stat, several
ioctls, slip.c logics, etc.) and the rest will go away shortly.

Preparations to cleanup:
	* call of get_tty_driver() moved from init_dev() to its callers
	* instead of kdev_t dev we pass struct tty_struct *driver and int index

	* drivers/char/rio/* supports up to 4 boards, each with up to 128
lines.  It used to share termios for 1st/3rd and 2nd/4th boards,  Fixed.
	* cleanups and kdev_t removals - we pass tty instead of tty->device
in a couple of helper functions and instead of comparisons on major(tty->device)
we check where does tty->driver point to.

	* generic_serial.c typo fix (->driver used instead of correct
->driver_data)
	* tubio cleaned up

	sanitized driver->driver_name initialization and use

	tty->tty_index added; we initialize it with minor(tty->device) -
tty->driver->minor_start.  Majority of remaining tty->device uses had
that form and are switched to use of tty->index.

	new field - tty->tty_name;
	initialized to <driver->name><tty index+driver->base_name>
when we allocate tty_struct.  Drivers code switched to use of that
beast (in debugging printks, mostly).  Large, but trivial.

	Instead of registering "drivers" for /dev/tty, /dev/vc/0, /dev/ptmx
and /dev/console (they are never looked up since tty_open() special-cases
them and they should not be looked up - these devices are remapped on open)
we register corresponding chrdev ranges and devfs nodes directly.
	/proc/tty/drivers code updated to keep the contents unchanged

	/proc/tty/drivers converted to seq_file

	Instead of copying tty_driver into tty_struct we put a reference
in there.  tty->driver turned into a pointer, users updated.  Large, but
trivial

	Christoph's fix for devfs problems with pty.