Import 2.1.127pre7

>> Btw, I've been looking at why Andrea thinks he's patches are needed,
>> because I looked very deep and the patches really shouldn't have made any
>> real difference..
>> The reason - tadaam - is so silly that it's embarrassing. The thing is,
>> that the things that should use GFP_USER don't. They use GFP_KERNEL
>> instead, and that is sufficient to explain all the problems that Andrea
>> saw. Becuase GFP_KERNEL will continue to allow allocations even after the
>> freeing up of another page has failed.
>> After fixing that in mm/memory.c and mm/filemap.c, the problem seems to be
>> properly fixed.

> I thought to change that but I was not sure (and infact some email ago I
> asked that to you too). I have not changed that myself because I was
> worryed that userspace allocation could be too much light. It would be
> nice to know if using GFP_USER and disabling kswapd (at the end of
> vmscan.c) causes process to segfaults (so that we can know if a real time
> process can alloc/swapout memory safely).

I wonder why it wasn't GFP_USER - that's exactly what the thing is there
for, and I don't know when it was changed. Probably with the new page
cache or something. I just looked at the memory allocator, and it looked
like it was doing the right thing, and it _was_ - but because it was
called with GFP_KERNEL it tried harder than it should have to return a
good page even when it ran out of memory.
Anyway, I made a pre-patch-2.1.127-6 and put it on ftp.kernel.org (pre-4
and pre-5 have been my internal pre-patches and don't show up there). This
has the timeout code basic fixes and the mm fixes, and doesn't fall over
for me with Andreas memory load case.

Linus

Import 2.1.127pre3

Linux 2.1.127pre2

I just found a case that could certainly result in endless page faults,
and an endless stream of __get_free_page() calls. It's been there forever,
and I bascially thought it could never happen, but thinking about it some
more it can happen a lot more easily than I thought.

The problem is that the page fault handling code will give up if it cannot
allocate a page table entry. We have code in place to handle the final
page allocation failure, but the "mid-way" failures just failed, and
caused the page fault to be done over and over again.

More importantly, this could happen from kernel mode when a system call
was trying to fill in a user page, in which case it wouldn't even be
interruptible.

It's really unlikely to happen (because the page tables tend to be set up
already), but I suspect it can be triggered by execve'ing a new process
which is not going to have any existing page tables. Even then we're
likely to have old pages available (the ones we free'd from the previous
process), but at least it doesn't sound impossible that this could be a
problem.

I've not seen this behaviour myself, but it could have caused Andrea's
problems, especially the harder to find ones. Andrea, can you check this
patch (against clean 2.1.126) out and see if it makes any difference to
your testing?

(Right now it does the wrong error code: it will cause a SIGSEGV instead
of a SIGBUS when we run out of memory, but that's a small detail).
Essentially, instead of trying to call "oom()" and sending a signal (which
doesn't work for kernel level accesses anyway), the code returns the
proper return value from handle_mm_fault(), which allows the caller to do
the right thing (which can include following the exception tables). That
way we can handle the case of running out of memory from a kernel mode
access too..

(This is also why the fault gets the wrong signal - I didn't bother to fix
up the x86 fault handler all that much ;)
Btw, the reason I'm sending out these patches in emails instead of just
putting them on ftp.kernel.org is that the machine has had disk problems
for the last week, and finally gave up completely last Friday or so. So
ftp.kernel.org is down until we have a new raid array or the old one
magically recovers.  Sorry about the spamming.

                Linus

Linux 2.1.127pre1

I have an alternate patch for low memory circumstances that I'd like you
to test out.
The problem with the old kswapd setup was at least partly that kswapd was
woken up too late - by the time kswapd was woken up, it really had to work
fairly hard. Also, kswapd really shouldn't be real-time at all: normally
it should just be a fairly low-priority process, and the priority should
grow as there is more urgent need for memory.
This alternate approach seems to work for me, and is designed to avoid the
"spikes" of heavy real-time kswapd activity during which the machine is
fairly unusable in the old scheme.

                Linus

Linux-2.1.126

 - architecture updates for alpha and MIPS (and some minor PPC updates
   too)
 - joystick updates
 - MCA stuff from Alan. The guy has too much free time on his hands.
 - stallion driver cosmetic update
 - nasty SMP race with "task queues" (not the scheduling kind), where we
   were mixing atomic metaphores, resulting in a mess. Usually a benign
   one, but occasionally you could force oopses.
 - some floppy and ide updates
 - PS/2 mouse driver integrated into the PC keyboard controller. That got
   rid of a lot of really nasty problems (it's the same controller,
   accessing it from two different drivers was always messy)
 - various driver updates: floppy, ide, network drivers, sound, video..
 - various small FS fixes - finally _really_ getting the ENOENT vs ENOTDIR
   stuff right, nfsd updates, remounting fixes, filesize limits on NFS
   and smbfs, ntfs and ufs updates...
 - shm updates from Alan
 - cleanup of some MM stuff, I hope Andrea will re-do the patches and I'll
   look at the other parts.
 - unix fd garbage collection fix, getting rid of circular dependencies..

And probably various other small fixes that I have thankfully forgotten
about.

Import 2.1.126pre2

Import 2.1.126pre1

Linux-2.1.125 ... pre-2.2 imminent

It seems that I've finally found the mysterious bug that caused some SMP
machines to lock up at bootup if they had no keyboard enabled. It turns
out that the keyboard was a complete red herring, and that it just changed
timings of bottom half handling in particular. The real culprit was some
misguided locking attempts by the console driver at a really bad time.

Anyway, that means that the last of my personal show-stopper bugs in 2.1.x
seems to be finally history. I still expect to sync up with Alan Cox's
patches in particular, but I'm mentally getting ready for a real 2.2.

I still haven't decided on whether I'll make the same kind of "pre-2.2"
that I did before the 2.0 release, but there are strong psychological
reasons to do so to get people to more actively test it out with a "this
really should be stable" mindset.

In the meantime, there's now 2.1.125. Most of 2.1.125 is driver updates
for various things, most notably perhaps joystick and the new 5.10 version
of the Adaptec aic7xxx driver by Doug Ledford (but there are various other
driver updates). The fix for the mysterious lock-up is a few embarrassing
lines removed, but makes me feel a lot better ;)

Go forth, multiply, and fill the earth

Import 2.1.125pre2

Import 2.1.125pre1

Linux-2.1.124...

.. is out there now, and includes:

 - subtle fix for lazy FP save and restore on x86. The bug has been there
   for a long time, but was apparently triggered by the re-write of the
   low-level scheduling function. It could result in corrupted i387 state
   under certain (admittedly fairly unlikely) circumstances.
 - various networking updates. Some of the bugs fixed could result in
   kernel Oopses. None of them were common, though.
 - fixes for both filesystem accounting and quota handling.
 - the much-ado-about-little video driver merge.
 - PPC and Sparc updates
 - i386/SMP interrupt handling falls back on the safe mode.. Please tell
   me whether there are still machines with problems.
 - some new network drivers and updates
 - final (we hope) IP masquerade update

I still have a problem with certain machines that apparently don't want to
boot with the keyboard not plugged in even though they should. Kill me
now. If you have problems with i386/SMP on a machine without a keyboard,
plug one in and send me a report..

Import 2.1.124pre2

Import 2.1.124pre1

Import 2.1.123

Import 2.1.123pre3

Import 2.1.123pre2

Import 2.1.123pre1

Import 2.1.122

Import 2.1.122pre3

Import 2.1.122pre2

2.1.122pre1

This may or may not fix the APM problems, and the INITRD ones.  The
INITRD one in particular was a case of a fairly inexplicable test that
shouldn't have been there in the first place breaking when something
completely unrelated was cleaned up..

The APM breakage was simply due to it being in the wrong place.  The
patch looks bigger than it really is - it really only moves the file to
the proper directory, and makes sure that it should compile with the
standard assembler..

                Linus

Import 2.1.121

Import 2.1.121pre1

Import 2.1.120

- Add QNX4 file system.

Import 2.1.120pre2

Import 2.1.120pre1

Import 2.1.119

Import 2.1.119pre1

Import 2.1.118

Linux 2.1.117

I made a 117 to fix the silly things left in 116 in my excitement over it
passing all my crashtests. This should fix the things with the kernel
thinking it was out of memory much sooner than it actually was etc.

Alan still reports some funnies with unix domain sockets, but he's
reportedly fixed the behaviour of NFS over TCP. He didn't make it sound as
if you really want to use it yet, though ;)

                Linus

Import 2.1.117pre1

Linux 2.1.116

I just released Linux-2.1.116. I've tested it fairly extensively on my SMP
box, both with little memory and much, and I cannot make it lock up any
more.

Special thanks to Dean Gaudet who helped me set up a apache configuration
that finally made me able to repeat the lockup, and made me able to debug
the thing.

Most of the 2.1.116 patches are "just" alpha and m68k updates, and can be
ignored by most people. The bugfixes are, roughly:

 - fixed serious low-memory situation problem, where a critical resource
   allocation problem could result in nasy behaviour. Notably, doing TCP
   under low memory could result in TCP trying to allocate memory in a
   tight loop and locking out kswapd completely so that the situation
   would never be rectified. In short, the machine hung.
   This problem has been there forever, the only reason it doesn't show up
   under 2.0.x seems to be because under 2.0.x the TCP allocation was
   always for a single page, for which this situation never arises. Under
   2.1.x the slab code forced multi-page allocations.
   If you've seen lockups with 2.1.x, this may be the cause. This was what
   held up 2.1.116 for so long.
 - various minor driver updates. Networking, radio, bttv.
 - NFS over TCP still doesn't work, but at least it fails due to new
   reasons.

Alan, try your squid thing under 2.1.116. I suspect it will hold up now,

                Linus

Import 2.1.116pre2

Import 2.1.116pre1

Linux-2.1.115 - code freeze.

Ok, we've been in a tentative code freeze for a long time, and now it's
final. I've made a 2.1.115 that I hope is good enough, and I won't be
accepting anything but bug-fixes until 2.2..
There are two long-standing patches that I'm still considering:

 - devfs
 - dynamic fd's

and I kind of expect that they'll go in (devfs is configurable, so if you
don't want it you don't need to care, and the dynamic fd's save some
memory and speed certain things up a bit). The reason they're not in now
is mainly that I've been trying to get everything else off my plate, and I
want to ruminate on them in peace for a while.
Bug-fixes are still (and will always be) accepted,

                Linus

Import 2.1.115pre4

Import 2.1.115pre3

Import 2.1.115pre2

Import 2.1.115pre1

Import 2.1.114

Import 2.1.113

Import 2.1.112

Import 2.1.112pre2

Import 2.1.112pre1

Import 2.1.111

Import 2.1.111pre1

Import 2.1.110

What 2.1.110-3 does is to much more aggressively throw out dentries (and
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

Import 2.1.110pre2

Import 2.1.110pre1

Linux-2.1.109.. preliminary code freeze.

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

pre-2.1.109-2..

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

Import 2.1.109pre1

Linux 2.1.108

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

Import 2.1.108pre1

Import 2.1.107

Linux 2.1.107pre2

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

Import 2.1.107pre1

Import 2.1.106

Import 2.1.106pre1

Linux 2.1.105

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

[tytso] include/asm-i386/posix_types.h
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.

pre-104

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

Linux 2.1.103

>   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

Import 2.1.102

Import 2.1.102pre2

Import 2.1.102pre1

Import 2.1.101

Import 2.1.100

Import 2.1.100pre3

Import 2.1.100pre2

Linux 2.1.100pre1

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

Import 2.1.99

pre-2.1.99-3

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

Import 2.1.99pre2

Linux 2.1.99pre1

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

Linux 2.1.98

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

2.1.97 - for brave people only.

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

Import 2.1.96

Import 2.1.96pre1

Linux 2.1.95

This is finally the kind of feature-freeze patch I like: it only contains
fixes for outright bugs. The fixes are:
 - SMP-safe disk drivers (more on this below)
 - various PCI fixes: /proc/bus/pci works again, and it should compile and
   work on Alpha with TGA.
 - parport interrupt detection uses the standard probe routines, and
   doesn't leave bogus "probe" entries hanging around to confuse people
   (and make other device registration fail)
 - the ever-popular PCI ne netdriver fix
 - the getcwd() system call works again.
 - "mb()" does the right thing on x86 too. Few drivers use it, but more of
   them should. Right now there are drivers that depend on luck making
   sure that the memory accesses will be in the same order outside the CPU
   as inside it.

The conceptually big one is the SMP-safe disk driver change: it's not a
very big patch, but it's fairly subtle. And it still requires help from
the disk drivers themselves, although all of them should be safe in UP,
and I made sure the BusLogic and the NCR driver are safe on SMP.
The change is really a change in locking defaults: we used to default to
no locking, and depended on the disk driver getting the locking right.
None of them did so on SMP, for understandable reasons (there really
wasn't any support for getting it right).

The new default is to do the locking for the driver, and the driver
actually has to do some work if it wants to do anything outside the lock.
This has the obvious advantage that it _defaults_ to being safe, and
people who know what they are doing can choose to thread the driver if
they want to.

The only change needed to drivers is to make sure they get the lock on an
interrupt, which usually involves just doing the following around the
low/level interrupt handler (the same handler that you register using
"request_irq()"):

        void handle_irq(int irq, void *dev, struct pt_regs *regs)
        {
+               unsigned long flags;
+               spin_lock_irqsave(&io_request_lock, flags);
                ... call to the proper action routines ...
+               spin_unlock_irqrestore(&io_request_lock, flags);
        }

which guarantees that everything inside the driver is correctly locked
from the outside world (with the exception of ioctl's etc things that the
driver traps - they need to be protected too).

                Linus

Import 2.1.95pre1

Import 2.1.94

Linux 2.1.93

2.1.93 is out there. It is broken on other platforms than x86, because I
had to move some initialization code around, but this shoul dbe very easy
to fix (moving the device init code later makes a _lot_ of things easier:
the system is essentially up and running, and "kmalloc()" etc actually
works).

Now the PCI init code actually has the full SMP knowledge, which it needs
in order to get the interrupt mapping stuff right (for example - it might
eventually need it for other reasons too).

The PCI code has generally been cleaned up - thanks to Martin Mares (the
PCI cleanup is what forced me to do the other changes - anything else
would simply have been too ugly).

2.1.93 should also fix the stupid things in 92 (modules don't load due to
missing symbols, and NULL pointer dereferences in /proc under certain
circumstances etc).

The kernel should also be better at detecting the really low memory
circumstances, and eventually return NULL instead of just looping forever
trying to find a page that it won't ever find.

                        Linus

[tytso on ext2fs changes:]
These patches provide the following enhancements to ext2.
        * Fixed a bug where we weren't byte-swapping the feature set
                flags before checking EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER
        * Added Stephen Tweedie's patches to allow the number of file
                blocks which will be preallocated to be tuned (instead
                of being fixed at 8 blocks).
        * Added Stephen Tweedie's patches to allow directory blocks to
                be preallocated.  This change is only activated if the
                EXT2_FEATURE_COMPAT_DIR_PREALLOC is enabled.  (There
                will soon be a new release of e2fsprogs that will
                allow you to turn this on.)  The change is compatible
                with older kernels (that's why it's a COMPAT feature),
                but we need to flag it in the feature set because the
                e2fsck needs a few changes to support this.
        * Added future support for B-trees in directories.  I have a
                design in mind which is fully read/only compatible
                with the existing ext2 directories, which will make
                its debut in the 2.3 kernel series.  This patch will
                allow 2.2 kernels to mount filesystems with B-tree
                directories read-write; if a 2.2 kernel tries to
                modify a B-tree directory, the B-tree valid bit will
                be turned off, since the B-tree structures won't be
                updated by 2.2 kernels.  2.0 kernels will be able to
                mount filesystems with B-tree directories read-only.
                This defines a new feature, EXT2_FEATURE_RO_COMPAT_BTREE_DIR.
        * Added Jakub Jelinek's support for large files on 64-bit
                platforms.  On a 64-bit platform, the first time you
                expand a file past the 32-bit boundary, the
                EXT2_FEATURE_RO_COMPAT_LARGE_FILE is turned on.
                2.0 machines will be able to mount such filesystems
                read-only.  2.2 kernels on 32-bit platforms will be
                able such filesystems read-write, but they will only
                be able to see the first 2**32 bytes of the file, and
                any attempt to open a large file for read/write access
                will cause an EBIGF error.
        * Added support for storing the file type in the directory
                entry.  This optimization was added to BSD 4.4 and
                makes a very big difference for a number of
                operations, since application programs can avoid doing
                a stat in a number of situations.  Support for this is
                in the GNU user-land utilities, and is in glibc
                already.  Beyond this patch, we also need to implement
                a new getdents system call that will return the
                information all the way to libc.
                The reason why it's important to get this change into
                2.2 is that it requires "stealing" 8-bits from the
                name_len field of the directory entry.  Ext2fs limits
                you to 255 characters in a file name, so the high-byte
                of name_len is always zero.  However, older kernels
                look at both bytes of name_len, and will get confused
                if we try to store something there.  So we can only
                update the file type field if the feature
                EXT2_FEATURE_INCOMPAT_FILETYPE is enabled.
                I want to get this support into the 2.2 kernel, since
                even if it isn't used much (because people will want
                their filesystems to be compatible with 2.0 kernels),
                we will be able to migrate smoothly to using this
                feature by default in the future.

Linux 2.1.92 - Feature Freeze

Ok, there's a fairly large patch out there, but as of 2.1.92 I think we
have a real feature-freeze, and we'll try to get a real code-freeze going
soon. There are known problems with the sound drivers etc, which is why a
code-freeze isn't the best suggestion right now, and there are probably
still bugs with some of the new code, but I'll freeze new features for the
upcoming 2.2 kernel.

Yes, some people will scream bloody murder, but others will be relieved
that it finally happened. Thanks especially to David Miller who has been
doing a great job of getting the TCP stack from its problems just a few
weeks ago to really shining new heights. That was my main worry about 2.2
not all that long ago, and was the main reason for having such a slushy
period for a while.

2.1.92 does:
 - ISDN updates
 - alpha update (yes, SMP finally works, although not really stable yet)
 - networking fixes
 - "getcwd()" system call (not very long, the dcache makes this so
   trivial it is scary)
 - the mm responsiveness updates (they were in 2.1.92-pre2, people seemed
   to have found them very effective)
 - some other (mainly driver updates)

Please do test it all out. Feature-freeze doesn't mean that it is supposed
to be bug-free yet, but it does mean that we should be moving into
bugfixing mode in quick order.
And no, this is not an April 1 thing. But this way I can use April 1 as an
excuse if something doesn't actually compile.

                Linus

Import 2.1.92pre2

Import 2.1.92pre1

Linux 2.1.91

I just made a real 91 on ftp.kernel.org, let's hope that this has all the
sillies gone. As usual, it is prefectly smooth on my machine, but this
time we also have a better chance of it being smooth on machines with less
memory too, as Rik has done some good work in testing the algorithms out.
So throw some problems at it to see just how good it is..

                Linus

Import 2.1.91pre2

Import 2.1.91pre1

Import 2.1.90

- Revert TCP delayed ACK fix, and fix correctly.
  We should not send an ack if we don't have any pending
  (in which case the DACK timer will be set)     (Dave Miller)

- Fix TCP delayed ACK stall  (Andrea Arcangeli)
- the first cut of my spinlock changes wrt the task lists (Linus)

I just put a pre-90 on ftp.kernel.org, and I'm happy to report that Davem
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

Import 2.1.89

Date: 1 Mar 1998 05:08:07 GMT
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

Linux 2.1.89-4

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

Import 2.1.89pre3