Re:Changes/Improvements
by
Eslyjah
·
· Score: 5, Informative
More readable version.
final:
- David Miller: sparc/scsi scatterlist fixes
- Martin Mares: PCI ids, email address update
- David Miller: revert TCP hash optimizations that need more checking
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
- Peter Anvin: cramfs/zisofs missing pieces
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
- me: clena up page dirty handling
- Tim Waugh: parport IRQ probing and documentation fixes
- Greg KH: USB updates
- Michael Warfield: computone driver update
- Randy Dunlap: add knowledge about some new io-apics
- Richard Henderson: alpha updates
- Trond Myklebust: make readdir xdr verify the reply packet
- Paul Mackerras: PPC update
- Jens Axboe: make cpqarray and cciss play nice with the request layer
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
- Richard Gooch: devfs symlink deadlock fix
- Anton Altaparmakov: make NTFS compile on sparc
pre7:
- me: reinstate "delete swap cache on low swap" code
- David Miller: ksoftirqd startup race fix
- Hugh Dickins: make tmpfs free swap cache entries proactively
pre6:
- me: remember to bump the version number;)
- Hugh Dickins: export "free_lru_page()" for modules
- Jeff Garzik: don't change nopage arguments, just make the last a dummy one
- David Miller: sparc and net updates (netfilter, VLAN etc)
- Nikita Danilov: reiserfs cleanups
- Jan Kara: quota initialization race
- Tigran Aivazian: make the x86 microcode update driver happy about
hyperthreaded P4's
- me: shrink dcache/icache more aggressively
- me: fix up oom-killer so that it actually works
pre5:
- Andrew Morton: remove stale UnlockPage
- me: swap cache page locking update
pre4:
- Mikael Pettersson: fix P4 boot with APIC enabled
- me: fix device queuing thinko, clean up VM locking
pre3:
- René Scharfe: random bugfix
- me: block device queuing low-water-marks, VM mapped tweaking.
pre2:
- Alan Cox: more merging
- Alexander Viro: block device module race fixes
- Richard Henderson: mmap for 32-bit alpha personality
- Jeff Garzik: 8139 and natsemi update
pre1:
- Michael Warfield: computone serial driver update
- Alexander Viro: cdrom module race fixes
- David Miller: Acenic driver fix
- Andrew Grover: ACPI update
- Kai Germaschewski: ISDN update
- Tim Waugh: parport update
- David Woodhouse: JFFS garbage collect sleep
incorrect mirrors link
by
fonebone
·
· Score: 4, Informative
On 31 Oct 2001, Michael Peddemors wrote:
>
> Lets' let this testing cycle go a little longer before making any
> changes.. Let developers catch up..
My not-so-cunning plan is actually to try to figure out the big problems
now, then release a reasonable 2.4.14, and then just stop for a while,
refusing to take new features.
Then, 2.4.15 would be the point where I start 2.5.x, and where Alan gets
to do whatever he wants to do with 2.4.x. Including, of course, just
reverting all my and Andrea's VM changes;)
I'm personally convinced that my tree does the right thing VM-wise, but
Alan _will_ be the maintainer, and I'm not going to butt in on his
decisions. The last thing I want to be is a micromanaging pointy-haired
boss.
(2.5.x will obviously use the new VM regardless, and I actually believe
that the new VM simply is better. I think that Alan will see the light
eventually, but at the same time I clearly admit that Alan was right on a
stability front for the last month or two;)
> My own kernel patches I had to stop because I couldn't keep up.... Can
> we go a full month with you just hitting us over the head with a bat
> yelling 'test, dammit, test', until this is tested fully before
> releasing another production release?
I think we're really close.
[ I'd actually like to thank Gary Sandine from laclinux.com who made the
"Ultimate Linux Box" for an article by Eric Raymond for Linux Journal.
They sent me one too, and the 2GB box made it easier to test some real
highmem loads. This has given me additional load environments to test,
and made me able to see some of the problems people reported.. ]
But I do want to make a real 2.4.14, not just another "final" pre-kernel,
and let that be the base for a reasonably orderly switch-over at 2.4.15
(ie I'd still release 2.4.15, everything from then on is Alan).
Linus
-- w o r l d w i d e w e b e r
Re:release often
by
C0vardeAn0nim0
·
· Score: 2, Informative
Well, if you think this is fast wait for 2.5.x to start. it's not unusual for a development kernel to go above x.x.100.
Ohhh, and 2.0.x was in 36 revisions when i shifted to 2.2.0
I still don't know why 2.2.x had so few releases. only 17 before 2.4.0... weird...
Preemptible kernel patch
by
tarka69
·
· Score: 4, Informative
Once again it's worth mentioning the preemptible kernel patch. I've been running this for the last couple of releases, and for a developer's desktop system it give noticable results.
Case in point from yesterday: Running gnome desktop, with a kernel build going in the background, while ripping a CD, running mozilla and netscape 4.x, and running and testing a mod_perl/mysql system, all on the same machine, xmms didn't miss a beat.
No, I'm not exaggerating. This was all on a 700MHz Athlon, 256M, IDE.
-- The comfort you demanded is now mandatory - Jello Biafra
2.4.14 not ready yet either
by
(startx)
·
· Score: 5, Informative
looks like this one isn't ready yet either. loop.c needs some sergery, or else the whole thing won't even compile, dying at
drivers/block/block.o: In function `lo_send':
drivers/block/block.o(.text+0x894f): undefined reference to `deactivate_page'
drivers/block/block.o(.text+0x8999): undefined reference to `deactivate_page'
make: *** [vmlinux] Error 1
it's allready been posted to the lkml, look for a 2.4.15-pre1 or at least a loop.c patch to come around soon.
Re:2.4.14 not ready yet either
by
loopkin
·
· Score: 2, Informative
actually, there are already two bugs. the one for loop.c is by far the worst.
Re:Changes/Improvements
by
BJH
·
· Score: 4, Informative
It's not easy to bring the summaries down to the level of your average user; certainly, there's plenty of stuff that I don't undertand fully. But anyway, here's some additional explanations for the last two updates:
final:
- David Miller: sparc/scsi scatterlist fixes SCSI on Sparc machines is now more stable.
- Martin Mares: PCI ids, email address update The kernel now identifies some PCI hardware more precisely.
- David Miller: revert TCP hash optimizations that need more checking Remove some changes to the TCP stack, as they're not quite ready for primetime
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc) Changes to Alpha-specific, er, stuff
- Peter Anvin: cramfs/zisofs missing pieces Properly merge the cramfs/zisofs changes
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache Virtual memory handling is now more stable
- me: clena up page dirty handling This also improves VM
- Tim Waugh: parport IRQ probing and documentation fixes Automatic IRQ assignment for parallel ports works better
- Greg KH: USB updates USB subsystem improved
- Michael Warfield: computone driver update Erm... dunno. What's a computone?
- Randy Dunlap: add knowledge about some new io-apics Improve the kernel's handling of particular chipsets' IRQ assignment
- Richard Henderson: alpha updates Who knows?
- Trond Myklebust: make readdir xdr verify the reply packet Since it's Trond, it's probably a RAID or VFS update...
- Paul Mackerras: PPC update Bring Linus's kernel more up-to-date with respect to the PPC tree
- Jens Axboe: make cpqarray and cciss play nice with the request layer Probably RAID stuff...
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000 Make the kernel work better on a particular type of laptop
- Richard Gooch: devfs symlink deadlock fix Fix a bug in devfs's handling of symlinks
- Anton Altaparmakov: make NTFS compile on sparc Allow people to read NTFS filesystems on Sun Sparc hardware
I'm subscribed to l-k, so if I actually bothered to read the 200-odd messages coming in each day, I could probably give a better summary... anybody know how to stretch a day to 30 hours?
Re:That's nice, but its not really news...
by
cvincent
·
· Score: 4, Informative
I don't read freshmeat. I search for things there. It isn't something I really care to see everyday.
you dont have to, you can subscribe to the linux kernel entry on freshmeat and recieve an email when a new version is out.
I don't subscribe to the kernel announce list. I don't care to read a bunch of garbage everday.
so release information is not garbage when its on slashdot but it is garbage when it comes from the actual source?
If they tell us when the release of XP is, or when the release of a new variant of Code Red or the like is out, why not the kernel.
Then by this very logic, CNN should be running stories on the latest Linux kernel release? XP is a bit different from 2.4.13 to 2.4.14 and Code Red made quite an impact on the Internet.
If you don't, tough. It obviously is going to stay no matter how many of you comment on it
That may be so, but dont expect the opposite and rely on slashdot to only run the stories you want. I bet if slashdot wasnt running stories on kernel updates that stories would still be submitted every release.
It was left out... the.14 patch deleted deactivate_page from other places, but missed loop.c. Since it was a straight deletion everywhere else (not replaced with anything) that's the correct
answer.
The latest Kernel Traffic suggests that Alan is considering using the AA VM anyway. Looks like Rik's stuff is getting dumped entirely. That is unless they can figure out how to parameterize VM's and make it a compile time option as they've been talking about.
More readable version.
;)
final:
- David Miller: sparc/scsi scatterlist fixes
- Martin Mares: PCI ids, email address update
- David Miller: revert TCP hash optimizations that need more checking
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
- Peter Anvin: cramfs/zisofs missing pieces
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
- me: clena up page dirty handling
- Tim Waugh: parport IRQ probing and documentation fixes
- Greg KH: USB updates
- Michael Warfield: computone driver update
- Randy Dunlap: add knowledge about some new io-apics
- Richard Henderson: alpha updates
- Trond Myklebust: make readdir xdr verify the reply packet
- Paul Mackerras: PPC update
- Jens Axboe: make cpqarray and cciss play nice with the request layer
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
- Richard Gooch: devfs symlink deadlock fix
- Anton Altaparmakov: make NTFS compile on sparc
pre7:
- me: reinstate "delete swap cache on low swap" code
- David Miller: ksoftirqd startup race fix
- Hugh Dickins: make tmpfs free swap cache entries proactively
pre6:
- me: remember to bump the version number
- Hugh Dickins: export "free_lru_page()" for modules
- Jeff Garzik: don't change nopage arguments, just make the last a dummy one
- David Miller: sparc and net updates (netfilter, VLAN etc)
- Nikita Danilov: reiserfs cleanups
- Jan Kara: quota initialization race
- Tigran Aivazian: make the x86 microcode update driver happy about
hyperthreaded P4's
- me: shrink dcache/icache more aggressively
- me: fix up oom-killer so that it actually works
pre5:
- Andrew Morton: remove stale UnlockPage
- me: swap cache page locking update
pre4:
- Mikael Pettersson: fix P4 boot with APIC enabled
- me: fix device queuing thinko, clean up VM locking
pre3:
- René Scharfe: random bugfix
- me: block device queuing low-water-marks, VM mapped tweaking.
pre2:
- Alan Cox: more merging
- Alexander Viro: block device module race fixes
- Richard Henderson: mmap for 32-bit alpha personality
- Jeff Garzik: 8139 and natsemi update
pre1:
- Michael Warfield: computone serial driver update
- Alexander Viro: cdrom module race fixes
- David Miller: Acenic driver fix
- Andrew Grover: ACPI update
- Kai Germaschewski: ISDN update
- Tim Waugh: parport update
- David Woodhouse: JFFS garbage collect sleep
I think they meant to link to this url.
when the rain comes, they run and hide their heads. they might as well be dead.
From: Linus Torvalds
;)
;)
.... Can
CC: Kernel Mailing List
On 31 Oct 2001, Michael Peddemors wrote:
>
> Lets' let this testing cycle go a little longer before making any
> changes.. Let developers catch up..
My not-so-cunning plan is actually to try to figure out the big problems
now, then release a reasonable 2.4.14, and then just stop for a while,
refusing to take new features.
Then, 2.4.15 would be the point where I start 2.5.x, and where Alan gets
to do whatever he wants to do with 2.4.x. Including, of course, just
reverting all my and Andrea's VM changes
I'm personally convinced that my tree does the right thing VM-wise, but
Alan _will_ be the maintainer, and I'm not going to butt in on his
decisions. The last thing I want to be is a micromanaging pointy-haired
boss.
(2.5.x will obviously use the new VM regardless, and I actually believe
that the new VM simply is better. I think that Alan will see the light
eventually, but at the same time I clearly admit that Alan was right on a
stability front for the last month or two
> My own kernel patches I had to stop because I couldn't keep up
> we go a full month with you just hitting us over the head with a bat
> yelling 'test, dammit, test', until this is tested fully before
> releasing another production release?
I think we're really close.
[ I'd actually like to thank Gary Sandine from laclinux.com who made the
"Ultimate Linux Box" for an article by Eric Raymond for Linux Journal.
They sent me one too, and the 2GB box made it easier to test some real
highmem loads. This has given me additional load environments to test,
and made me able to see some of the problems people reported.. ]
But I do want to make a real 2.4.14, not just another "final" pre-kernel,
and let that be the base for a reasonably orderly switch-over at 2.4.15
(ie I'd still release 2.4.15, everything from then on is Alan).
Linus
w o r l d w i d e w e b e r
Well, if you think this is fast wait for 2.5.x to start. it's not unusual for a development kernel to go above x.x.100.
Ohhh, and 2.0.x was in 36 revisions when i shifted to 2.2.0
I still don't know why 2.2.x had so few releases. only 17 before 2.4.0... weird...
What ? Me, worry ?
Linus posted this note to the linux kernel mailing list before the story of Nov. 2, so this should not be seen as a reversal of that story.
:).
Alan is free to do what he wants with the kernel including pass on its maintenance to someone else
w o r l d w i d e w e b e r
"from the 14-and-counting dept."
:)
We're actually at 15 (not 14) and counting - kernel version numbers are 0-based, and sequential.
Sorry moderators - I just had to
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
make clean dep, please
My other car is first.
make[2]: Nothing to be done for `all_targets'. /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
ld -m elf_i386 -T
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o \
net/network.o \
--end-group \
-o vmlinux
drivers/block/block.o: In function `lo_send':
drivers/block/block.o(.text+0x8c9b): undefined reference to `deactivate_page'
drivers/block/block.o(.text+0x8cd7): undefined reference to `deactivate_page'
make: *** [vmlinux] Error 1
any quick fix for an non kernel-hacker?
Case in point from yesterday: Running gnome desktop, with a kernel build going in the background, while ripping a CD, running mozilla and netscape 4.x, and running and testing a mod_perl/mysql system, all on the same machine, xmms didn't miss a beat.
No, I'm not exaggerating. This was all on a 700MHz Athlon, 256M, IDE.
The comfort you demanded is now mandatory - Jello Biafra
looks like this one isn't ready yet either. loop.c needs some sergery, or else the whole thing won't even compile, dying at
drivers/block/block.o: In function `lo_send':
drivers/block/block.o(.text+0x894f): undefined reference to `deactivate_page'
drivers/block/block.o(.text+0x8999): undefined reference to `deactivate_page'
make: *** [vmlinux] Error 1
it's allready been posted to the lkml, look for a 2.4.15-pre1 or at least a loop.c patch to come around soon.
Try this:
r =1&s=promise+ultra66&q=b
http://marc.theaimsgroup.com/?l=linux-kernel&w=2&
Other people seem to be running it OK, and there's a patch or two that might be related...
yeah, I know replying to ones' self if lame, whatever. Here is a patch from the lkml.
/home/chris/dontdiff -Naur linux-2.4.14/drivers/block/loop.c
diff -X
+linux-2.4.14-loop/drivers/block/loop.c
--- linux-2.4.14/drivers/block/loop.c Thu Oct 25 13:58:34 2001
+++ linux-2.4.14-loop/drivers/block/loop.c Mon Nov 5 17:06:08 2001
@@ -207,7 +207,6 @@
index++;
pos += size;
UnlockPage(page);
- deactivate_page(page);
page_cache_release(page);
}
return 0;
@@ -218,7 +217,6 @@
kunmap(page);
unlock:
UnlockPage(page);
- deactivate_page(page);
page_cache_release(page);
fail:
return -1;
use at your own risk, or some of that legal junk.
It's not easy to bring the summaries down to the level of your average user; certainly, there's plenty of stuff that I don't undertand fully. But anyway, here's some additional explanations for the last two updates:
final:
- David Miller: sparc/scsi scatterlist fixes
SCSI on Sparc machines is now more stable.
- Martin Mares: PCI ids, email address update
The kernel now identifies some PCI hardware more precisely.
- David Miller: revert TCP hash optimizations that need more checking
Remove some changes to the TCP stack, as they're not quite ready for primetime
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
Changes to Alpha-specific, er, stuff
- Peter Anvin: cramfs/zisofs missing pieces
Properly merge the cramfs/zisofs changes
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
Virtual memory handling is now more stable
- me: clena up page dirty handling
This also improves VM
- Tim Waugh: parport IRQ probing and documentation fixes
Automatic IRQ assignment for parallel ports works better
- Greg KH: USB updates
USB subsystem improved
- Michael Warfield: computone driver update
Erm... dunno. What's a computone?
- Randy Dunlap: add knowledge about some new io-apics
Improve the kernel's handling of particular chipsets' IRQ assignment
- Richard Henderson: alpha updates
Who knows?
- Trond Myklebust: make readdir xdr verify the reply packet
Since it's Trond, it's probably a RAID or VFS update...
- Paul Mackerras: PPC update
Bring Linus's kernel more up-to-date with respect to the PPC tree
- Jens Axboe: make cpqarray and cciss play nice with the request layer
Probably RAID stuff...
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
Make the kernel work better on a particular type of laptop
- Richard Gooch: devfs symlink deadlock fix
Fix a bug in devfs's handling of symlinks
- Anton Altaparmakov: make NTFS compile on sparc
Allow people to read NTFS filesystems on Sun Sparc hardware
I'm subscribed to l-k, so if I actually bothered to read the 200-odd messages coming in each day, I could probably give a better summary... anybody know how to stretch a day to 30 hours?
you dont have to, you can subscribe to the linux kernel entry on freshmeat and recieve an email when a new version is out.
I don't subscribe to the kernel announce list. I don't care to read a bunch of garbage everday.
so release information is not garbage when its on slashdot but it is garbage when it comes from the actual source?
If they tell us when the release of XP is, or when the release of a new variant of Code Red or the like is out, why not the kernel.
Then by this very logic, CNN should be running stories on the latest Linux kernel release? XP is a bit different from 2.4.13 to 2.4.14 and Code Red made quite an impact on the Internet.
If you don't, tough. It obviously is going to stay no matter how many of you comment on it
That may be so, but dont expect the opposite and rely on slashdot to only run the stories you want. I bet if slashdot wasnt running stories on kernel updates that stories would still be submitted every release.
It was left out... the .14 patch deleted deactivate_page from other places, but missed loop.c. Since it was a straight deletion everywhere else (not replaced with anything) that's the correct
answer.
--Dan
The latest Kernel Traffic suggests that Alan is considering using the AA VM anyway. Looks like Rik's stuff is getting dumped entirely. That is unless they can figure out how to parameterize VM's and make it a compile time option as they've been talking about.