★ wanayoo — archive 1999 http://www.kernelnotes.org/kernel/v2.1/90-99.htmlNouvelle recherche | Portail wanayoo

Linux 2.1 Kernel Patches
[Home] [Linux 2.0] [Linux 2.1] [Information] [Software] [Distributions] [Links]

About the Kernel Patch Summaries

These summaries are written after each kernel release by examining the chunks of each patch file and figuring out what has changed. Occasionally, they are supplemented by notes that Linus (and others) posted to the linux-kernel mailing list.

The summaries from 2.1.0 to 2.1.51 were put together by Mark Evans <mevans@ecsnet.com>.

The summaries from 2.1.54 onwards were put together by Myrdraal@deathsdoor.com -- originally appearing on the Cutting Edge Linux website.

New! Yaroslav Rosomakho is now also writing some kernel summaries, including pre-patches!

Older
<<
80-89 		5 Latest
0-9   10-19   20-29   30-39   40-49  
50-59   60-69   70-79   80-89   90-99  
100-109   110-119   120-129   130-132   2.2.0-pre   		Newer
>>
100-109

Kernels 2.1.90 to 2.1.99

*Linux 2.1.99 patch - patch-2.1.99.gz (30-Apr-98 17:21)
    [Patch Browser]

*Linux 2.1.98 patch - patch-2.1.98.gz (23-Apr-98 23:17)
    [Patch Browser]

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:

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

*Linux 2.1.97 patch - patch-2.1.97.gz (18-Apr-98 00:51)
    [Patch Browser]

Note: You will need this patch to compile successfully. And also this patch (from Dmitry Yaitskov) to get your PCI files in /proc.

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

*Linux 2.1.96 patch - patch-2.1.96.gz (14-Apr-98)
    [Patch Browser]

You'll want this patch to make kmod compile.

*Linux 2.1.95 patch - patch-2.1.95.gz (10-Apr-98 11:30)
    [Patch Browser]

I just released 2.1.95 on ftp.kernel.org.

This is finally the kind of feature-freeze patch I like: it only contains fixes for outright bugs. The fixes are:

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

*Linux 2.1.94 patch - patch-2.1.94.gz (8-Apr-98 17:39)
    [Patch Browser]

Note: This kernel seems to have the same PCI flakeyness as 2.1.93. Good news; the sb-module-oops-on-unload problem is gone with the sound driver updates!

*Linux 2.1.93 patch - patch-2.1.93.gz (6-Apr-98 17:39)
    [Patch Browser]

Note: According to Linus, this kernel is broken on non x86. There seems to be some PCI flakeyness, but otherwise it's been running nicely for me.

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

*Linux 2.1.92 patch - patch-2.1.92.gz (1-Apr-98 17:47)
    [Patch Browser]

Note: I'm happy to say that this kernel eliminates the 'swap thrash' problem that the previous kernels (2.1.89-2.1.91) seemed to suffer from. You'll probably need this patch to use modules and prevent your console from being flooded with 'raising capabilities for ' messages whenever a program is executed. I don't promise it'll work for you, but it does for me.

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:

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

*Linux 2.1.91 patch - patch-2.1.91.gz (26-Mar-98 15:53)
    [Patch Browser]

*Linux 2.1.90 patch - patch-2.1.90.gz (17-Mar-98 22:17)
    [Patch Browser]

Kernels 2.1.80 to 2.1.89

Older
<<
80-89 		5 Latest
0-9   10-19   20-29   30-39   40-49  
50-59   60-69   70-79   80-89   90-99  
100-109   110-119   120-129   130-132   2.2.0-pre   		Newer
>>
100-109
[Home] [Up] [Search] [FeedBack]
Copyleft © The LinuxHQ Project. Licensed under the GNU Public License.