thus inodes) under low-memory circumstances.  It may be _too_ aggressive
right now, but if so that just gives a good mid point to strive for.

I'd really like to hear comments about how this "feels" (and numbers
too, if you have them).  It's fairly hard for me to judge, as whenever I
run Linux on small-memory machines it always feels slower than I'm used
to, regardless of whether Linux does the right thing or not ;)

                Linus

Ok, it's out there now in all its glory...
2.1.109 does the following thing:

 - CPU detection in C code (and thus much easier to expand upon,
   especially as it's all thrown away after booting now that it is
   "initfunc()").  This should finally get the Cyrix case right, for
   example. Please test.
 - too meny people convinced me that sendfile() really wants to act like
   writep().
 - sound driver updates from Alan.
 - console updates, so now we have the full old functionality again as far
   as I'm concerned (but I'm sure people will tell me something is still
   missing)
 - task switch and user space return cleanly handles bad segment
   descriptors etc, so people shoul dno longer be able to cause kernel
   messages by misusing the LDT (and I was just informed that you could
   actually completely hang a 2.1.x SMP kernel by doing nasty things -
   this fixes it)
 - wine should work again thanks to Bill Hawes (other LDT fixes)
 - de4x5 driver update
 - token ring driver update
 - ppp driver update
 - coda-fs update
 - "shared writable" bug fixed (thanks to a lot of people for testing and
   working on this - the actual fix was trivial once the problem was
   understood)

In addition, I've spent a large part of my day running with a 12MB
machine, and low-memory behaviour seems to be reasonable. People who have
been unhappy with low-memory behaviour should check out 109 and comment on
it - the heuristics are fairly different, and seem to be better.

As of this release, I won't be looking at the "incoming" directory at the
linux-patches site any more. I'll only be looking at "urgent" things, on
the theory that I'm (a) lazy and (b) getting into code freeze.

If you have important patches in "incoming", feel free to move them to
"urgent". However, I will warn that if I don't consider them to be 2.2
material, I'll just move them to "discarded".

The same goes for patches in email. I will accept patches, but I've just
raised the bar for acception.

                Linus

To get people away from their normally scheduled copyright discussions, I
made a pre-2.1.109 to try out. I woul dhave made a real 2.1.109, but my
computer room has been taken over by visiting relatives, and they want to
go to sleep. Ye Gods!

Get it from ftp.kernel.org, /pub/linux/kernel/testing as usual. It has
 - CPU detection in C code (and thus much easier to expand upon,
   especially as it's all thrown away after booting now that it is
   "initfunc()").  This should finally get the Cyrix case right, for
   example. Please test.
 - too meny people convinced me that sendfile() really wants to act like
   writep().
 - sound driver updates from Alan.
 - console updates, so now we have the full old functionality again as far
   as I'm concerned (but I'm sure people will tell me something is still
   missing)
 - task switch and user space return cleanly handles bad segment
   descriptors etc, so people shoul dno longer be able to cause kernel
   messages by misusing the LDT.
 - wine should work again thanks to Bill Hawes (other LDT fixes)
 - de4x5 driver update
 - token ring driver update
 - ppp driver update
 - coda-fs update
 - "shared writable" bug fixed (thanks to a lot of people for testing and
   working on this - the actual fix was trivial once the problem was
   understood)
Check it out,

                Linus

I just made a pre-2.1.108 and put it on ftp.kernel.org - it fixes a
problem where my sendfile() forgot to get the kernel lock (blush), so it
randomly didn't work correctly on SMP.

I've also done some more testing of sendfile(), and the nice thing is that
when I compared doing a file copy with sendfile compared to a plain "cp",
the sendfile implementation was about twice as fast (at least my version
of "cp" will just do read+write pairs over and over again). When I copied
a 38MB file the "cp" took 1:58 seconds while sendfile took 1:08 seconds
according to "time" (I have 512MB of RAM, so this was all cached,
obviously)..

I haven't done any network tests, because I don't think I'd be able to see
any difference, and it does need the "SO_CONSTIPATED" thing and a way to
push the end of data for best performance.

Some final words on sendfile():
 - it does report errors correctly. That doesn't mean that you necessarily
   can know _which_ fd produced the error, that you have to find out on
   your own. A file real access can generally result in EIO and EACCES
   (the latter with NFS and other "protection-at-read-time" non-UNIX
   filesystems), while the output write() can result in a number of errors
   as the output fd can be any kind of socket/tty/file. Depending on the
   mode of the output file, the output errors can include EINTR, EAGAIN
   etc, and you can mix sendfile() with select() on the output socket, for
   example.
 - you can give it a length of MAX_ULONG, and it will write as much as it
   can. This is entirely consistent with the notion that it is equivalent
   with write(out, tmpbuf, read(in, tmpbuf, size)) where "tmpbuf" is
   essentially infinite - the read() will read al of the file and return
   the file length in the process. Thus you don't even need to know the
   size of the file beforehand.
   The file copy test was essentially done with a single
        error = sendfile(out, in, ~0);
   and I'm appending my current test-program.

This is going to be in 2.2, btw. The changes are so small and so obviously
have to work that it would be ridiculous not to have this - the only
question is whether I'll try to make it a "copyfd()" system call instead,
falling back on read+write when I can't use the page cache directly. I
suspect I won't.

                        Linus

Are there people out there that use the loopback device with SMP, and have
been irritated at it not working lately?
I gave up on waiting for any real loop device maintainer to step up and
fix this, so I made a very small patch that I suspect may fix the problem.
I'm not going to test it myself, and I'm fairly disgusted with how badly
the loop device is being maintained at all. But if people feel they want
to test it out, go to

        ftp.kernel.org//pub/linux/kernel/testing

and fetch the current pre-107-2 patch.
It also has some other patches to the loop device that I picked up and
that looked like the right thing to do (use dentry pointers instead of
inodes to make mount/umount happy.

                Linus

Linux-2.1.105 is out there, and is mainly a "synch to other people and fix
silly problems" release. It has the 104 kmod and compilation problems
fixed, and updates some pending patches (notably sound and ham radio
drivers).

                Linus

This quick fix eliminates a lot of warning messages when
compiling e2fsprogs under glibc.  This is because the glibc header files
defines its own version of FD_SET, FD_ZERO, etc., and so if you need to
#include the kernel include files, you get a lot of duplicate defined
macro warning messages.  This patch simply #ifdef's out the kernel
versions of these function if the kernel is not being compiled and the
glibc header files are in use.

The bulk of the pre-patch is just some speeling error fixes, but there's a
one-liner that gets rid of the double interrupts with level-triggered
irq's on the IO-APIC, and that is known to have fixed one persons SCSI
tape driver (the fact that there were problems with too many interrupts
implies that something is slightly buggered in the driver, but..)

This should also have a ne2000 driver that doesn't get a NULL pointer
fault for some people, and the irq changes should hopefully make it work
on UP systems again even if the kernel is compiled as SMP.
And there are some MTRR updates.

                Linus

>   I finnaly get the IRQ detection working with this patch,
>  in linux-2.1.102/arch/i386/kernel/irq.c :
Ok, does it still work with 2.1.103?
2.1.103 has this patch, and also changes certain other things wrt interrupts in
a way that both Edgar and Ingo seem to agree on, and it's been stable on
certain boxes where plain 2.1.102 wasn't.

2.1.103 also disables the early Cyrix cpuid stuff, because we now seem to
have confirmation that this is what corrupts DMA IDE transfers (the cyrix
code steps on magic motherboard IO ports - which Intel probably put there
specially to mess with Cyrix. But maybe I'm just cynical). So people that
have had problems with disk corruption and are brave enough to try, this
could be an interesting experiment.
[ Thanks to Gerard Roudier and Alan Cox for chasing down the IDE
  corruption issue, btw ]

                Linus

pre-100 (on ftp.kernel.org now), moves the dcache shrinking into the regular
memory de-allocation loop, and while the exact shrinking speed is probably
completely off, it should be able to react much better to small-memory machines
than the hardcoded shrink did..

Also, for those that appear to still have SMP interrupt stability
problems, Ingo pointed out that we may have problems with PCI
level-triggered interrupts. Could those people please test an additional
small patch that involves moving the "ack_APIC_irq();" inside
arch/i386/kernel/irq.c: do_ioapic_IRQ() from the top of the function to
the very bottom of that function (that will move it to outside the irq
controller lock, but it should actually be perfectly ok in this case).

                Linus

There's a new pre-patch on ftp.kernel.org, that does:

 - the networking fixes that didn't get into 98 due to various mess-ups
 - mtrr patches are there by default
 - all the irq fixes we know of to date are there (and hopefully even the
   ne2000 things should work with the SELF-IPI change)
 - various documentation updates and bugfixes (the best way to know that a
   stable kernel is approaching is to notice that somebody starts to
   spellcheck the kernel - it has so far never failed)

in short, all known bugs should be fixed, but hey, what else is new?

                Linus

a cleanup of my previous patches wrt irq handling, and also fixes
a real bug (we used to ACK the io-apic outside the irq-controller lock,
which meant that the ack's we did and "ipi_pending[]" might have gotten
out of sync - which could certainly have resulted in bad behaviour).
This also re-enables the code that replays interrupts in enable_irq(),
because it should be ok now that the rest of the code is cleaned up.
People that had the earlier problem with locking up with floppies, please
test: if this re-introduces the lockup, please just #if 0 out all the code
inside trigger_pending_irqs(), and send me a note telling me that that
code still doesn't work.

                Linus

I just released a fairly small patch to 97 to bring it up to 98.

I've gotten a lot of patches in the mail for the last week, and I've been
ignoring most of them for obvious reasons. They aren't in any in-queue,
you can more-or-less consider them lost - but don't resend them all
immediately, because if I get another huge batch of patches then I'll just
have to ignore them again.

We're going slow and easy, and the plan is to not only keep me sane in the
midst of all the diapers, but I'll also at the same time take the
opportunity to actually enforce the feature-freeze. You've known about it
for a long time, _tough_.

Anyway, 2.1.98 _should_ fix:

 - the IDE/SCSI lockups. The irq enable/disable code was broken, and could
   do some really bad things. This tended to lock up the machine if you
   accessed your IDE disks heavily, or in particular if you had a mixture
   of IDE and SCSI and used them at the same time. Tell me if you still
   have problems - I'm sure there are still bugs left, and I want to hear
   about them.
 - memory management especially on small-memory machines. I think I made a
   good change to the allocation logic, and I'm hoping it will fix the bad
   bahevaiour on those wimpy machines that all you losers out there are
   using that have less than half a Gig of RAM. It certainly still works
   fine on my machine, and I'm certainly still too lazy to test it out on
   anything smaller.

There's a few other updates too: the asm constraints are fixed, so it
should compile again with other compiler versions than the particular one
I happen to be using. And some of the SCSI drivers have been updated a
bit.

There's been a lot of discussion and patches on capabilities, and I
haven't applied them yet, I'll let them simmer a bit. Similarly, I've seen
so many pathes to kmod that my head is spinning, and as I don't use
modules myself I'd really like to get feedback from users about the
different patches, so that maybe I'll get something that everybody can
agree on as acceptable. Right now I don't know which patch I should even
begin looking at.

                Linus

I made a 2.1.97 release, in order to synch up with some large patch-sets
I've gotten (non-x86 architecture updates). But due to the new baby this
really hasn't been through my usual exhaustive stress-test ("make bzImage"
+ "boot") so buyer beware.

                Linus