We should not send an ack if we don't have any pending
  (in which case the DACK timer will be set)     (Dave Miller)

- the first cut of my spinlock changes wrt the task lists (Linus)

seems to have found and fixed the TCP performance problem, which means
that the code-freeze for 2.2 is going to go into effect shortly..

pre-90 does a few other minor things, like for example getting rid of
kerneld because the new kmod thing is a lot simpler in many ways. Let's
see what the reaction to that is, but I'm fairly certain that this was a
major good thing: I've personally never liked kerneld, but kmod seems to
be a much nicer and more controlled way of handling the same issues that
kerneld tried to do. I'd actually almost be willing to use the thing
myself, something that was never true of kerneld.

This also moves the WD7000 SCSI driver to a working status again, thanks
to Miroslav Zagorac.

But the interesting and important part of the patches are the networking
fixes from David and Bill Hawes..

                Linus

Subject: Re: INN doesn't work on pre-2.1.89-4 (mmap problem ?)
From: Linus Torvalds <torvalds@transmeta.com>

I fixed _one_ silly bug wrt writeback to shared files in pre-5

It should fix the problem another way that I'm happier with (fixing that
problem also revealed a few other misuses of close_fp() due to historical
reasons - the uses really needed to be "fput()"s instead).
2.1.89-4 also uses "struct file" for mmap's, which means that the problem
that somebody was complaining about with mmap (that the mapping would
exist even after the last "release()" on that file, and thus the file
would still be active) are gone. As of -4 the kernel will guarantee that
it will call the file->f_op->release() onle after there really aren't any
uses of that file pointer any more..

                Linus

[sct] a patch against ipc/shm.c was missing from my swap patches,
      and another fix for spurious warnings about shared dirty pages.

[changelog pieced together by davej]

* 2.1.88, adds a bunch of new functionality to
  the swapper.  The main changes are:

* All swapping goes through the swap cache (aka. page cache) now.

* There is no longer a swap lock map.  Because we need to atomically
  test and create a new swap-cache page in order to do swap IO, it is
  sufficient just to lock the struct page itself.  Having only one
  layer of locking to deal with removes a number of races concerning
  swapping shared pages.

* We can swap shared pages, and still keep them shared when they are
  swapped back in!!!  Currently, only private shared pages (as in pages
  shared after a fork()) benefit from this, but the basic mechanism will
  be appropriate for MAP_ANONYMOUS | MAP_SHARED pages too
  (implementation to follow).  Pages will remain shared after a swapoff.

* The page cache is now quite happy dealing with swap-cache pages too.
  In particular, write-ahead and read-ahead of swap through the page
  cache will work fine (and in fact, write-ahead does get done already
  under certain circumstances with this patch --- that's essentially how
  the swapping of shared pages gets done).  Support code to perform
  asynchronous readahead of swap is included, but is not actually used
  anywhere yet.

  I've tested with a number of forked processes running with a shared
  working set larger than physical memory, and with SysV shared memory.
  I haven't found any problems with it so far.

Linus: I've also changed the way we consider us to need more memory in kswapd,
       but that was entirely orthogonal and did not impact these patches. ]

[Changelog pieced together by davej]

Ok, 2.1.87 is out there on ftp.kernel.org now, and it has the clever
PROT_NONE thing done. It seems to work for the little test-case I wrote,
and I also verified that swapping still works, so it seems to be all ok.
I'd still like people who have test programs or similar to actually check
it out,

                Linus

- Update makefile version (forgot to in .83)
- fixes a (very obscure, possibly never happens) autofs bug.
- fix missing ; compile error in mm/filemap.c
- MS_NODIRATIME support.

[changelog summary by davej]

I just made a pre-2.1.81 available on ftp.kernel.org.
This fixes the known problems of 2.1.80, and also makes the interrupt
routing by default look like it always used to look - everything goes
through the traditional external 8259A-compatible logic.
The code to handle IO-APIC interrupt routing is still there, but as no
interrupts are actually marked as io-apic interrupts you don't see it in
action yet. The advantage of this is that people who want to work on this
have a base that contains all the logic, and that we only need to figure
out how to reliably make all the IRQ routing decisions.

                Linus

This release should fix a few networking problems, and the NFS client is
hopefully fairly stable even under the kinds of loads we have here at
Transmeta.

The 2.1.80 release also contains some initial ARM support, and contains
Ingo Molnar's better SMP interrupt handling.

NOTE NOTE NOTE! The new SMP interrupt handling is currently not very good
at autodetection. This can be a real problem, and _before_ booting the
2.1.80 kernel as compiled for SMP you should probably try to figure out a
possible IRQ override line by doing:

        echo -n pirq=; echo `scanpci -f | grep T_L | cut -c56-` | sed 's/ /,/g'
which for me gives
        pirq=0x00,0x09,0x0b

Then, after doing the above, boot into 2.1.80 and see if it finds your PCI
interrupt lines correctly. If it does, everything is fine. If it doesn't,
you need to boot with the pirq setting that you determined earlier, by
giving the kernel the pirq data at the bootup command line or by using the
LILO "append=" feature (or similar features in other bootloaders).
We'll certainly have to make the autodetection work reliably, but in the
meantime the command-line approach at least gives us a way to test the
more fundamental impacts of better interrupt handling.

                Linus

 I just put a pre-2.1.80 on ftp.kernel.org that should fix the fat-related
problems. The reason I put it there is because I got several patches that
fixed the FAT problems _and_ something else, and they all obviously
clashed with each other so neither part got applied.

 So I'd ask people who sent me patches to maybe re-send the parts of the
patches that are still relevant,

                Linus