Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | kernelnotes.org | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies
Table Of Contents
|1.||23 Dec 2000 - 1 Jan 2001||(22 posts)||CPU Configuration And Autoconfiguration|
|2.||28 Dec 2000 - 4 Jan 2001||(62 posts)||Tove|
|3.||28 Dec 2000 - 1 Jan 2001||(13 posts)||Network Card Recommendations|
|4.||31 Dec 2000 - 4 Jan 2001||(24 posts)||2.4.0-prerelease: Approaching 2.4.0|
|5.||31 Dec 2000 - 3 Jan 2001||(6 posts)||The Future Of modutils|
|6.||1 Jan 2001 - 2 Jan 2001||(10 posts)||devices.txt Cleanup|
|7.||1 Jan 2001||(1 post)||user-mode Port Of 2.4.0-prerelease|
|8.||2 Jan 2001||(5 posts)||Possible Filesystem Corruption In 2.4.0-prerelease|
|9.||2 Jan 2001 - 4 Jan 2001||(3 posts)||ac Patches Against 2.4.0-prerelease|
|10.||3 Jan 2001 - 5 Jan 2001||(17 posts)||Rik And Andrea: As The Saga Turns|
|11.||3 Jan 2001 - 4 Jan 2001||(25 posts)||Preemption Patch For 2.4.0-prerelease|
|12.||4 Jan 2001 - 6 Jan 2001||(15 posts)||2.4.0 Is Released|
|13.||4 Jan 2001 - 6 Jan 2001||(9 posts)||ac Patches Against 2.4.0|
|14.||4 Jan 2001||(3 posts)||Problems Trying To Download 2.4.0|
|15.||4 Jan 2001 - 6 Jan 2001||(3 posts)||Crypto In 2.4|
|16.||4 Jan 2001||(1 post)||user-mode Port Of 2.4.0|
|17.||4 Jan 2001||(1 post)||Kernel Debugger For 2.4.0|
|18.||5 Jan 2001||(1 post)||Linux/m68k 2.4.0|
|19.||5 Jan 2001||(2 posts)||Minor LVM Problems In 2.4.0|
|20.||5 Jan 2001 - 6 Jan 2001||(8 posts)||Alan Still Maintaining 2.2|
|21.||5 Jan 2001||(2 posts)||Linux On The Intel IXP1200|
|22.||5 Jan 2001 - 6 Jan 2001||(5 posts)||Configuration Cleanup In 2.4.0|
|23.||5 Jan 2001 - 6 Jan 2001||(2 posts)||uClinux 220.127.116.11pre0 Released|
|24.||6 Jan 2001||(3 posts)||"Wonderful World of Linux 2.4"|
|25.||7 Jan 2001||(7 posts)||"VM: do_try_to_free_pages" Lockups: The Saga Ends Peacefully|
Mailing List Stats For This Week
We looked at 1466 posts in 6087K.
There were 464 different contributors. 207 posted more than once. 108 posted last week too.
The top posters of the week were:
1. CPU Configuration And Autoconfiguration
23 Dec 2000 - 1 Jan 2001 (22 posts) Archive Link: "About Celeron processor memory barrier problem"
People: Michael Chen, Erik Mouw, Linus Torvalds, Tim Wright, Alan Cox, Kai Henningsen, Riley Williams
Michael Chen noticed that comiling a Celeron as a P3 or P4 chip would cause a system hang at the early stages of boot-up. He explained, "the problem is cause by the fact that Intel Celeron doesn't have a real memory barrier,but when you choose the Pentium III option, the kernel assume the processor has a real memory barrier." He posted a patch, but Erik Mouw replied:
I think there is some confusion in the name "Celeron". AFAIK there are two kinds of Celerons: the original PII based Celeron, or the newer PIII based Celeron. My laptop has a PIII (Coppermine) based Celeron, and it boots perfectly well without your patch.
If you are using a PII based Celeron, you should compile the kernel with support for the "Pentium-Pro/Celeron/Pentium-II". You certainly should not try to run a kernel with support for P4 on a "lower" CPU, read the documentation about CONFIG_M386 in Documentation/Configure.help for more information.
There was no reply to that, but Linus Torvalds also said it was a mistake to configure the processor as a chip is was not. He said, "The whole point of being able to choose the CPU to optimize for is that we can optimize things at compile-time." Several folks pointed out that some Celeron's were based on the P3, and Erik explained at one point, "The confusion is because Intel reused the name Celeron for a completely different CPU. The original Celeron was based on a PII core, the new Celeron is based on a PIII core. Both Celerons have the same features as the CPU they are based on, but with less cache memory. Selecting PIII for the new PIII based Celeron will indeed give you slightly better performance."
Elsewhere, Kai Henningsen suggested that the kernel ought to detect misconfigured CPUs at boot time. Tim Wright replied, "if you choose the wrong processor type, you may not even be able to complain. This is a user issue. All the distributions of which I am aware boot happily on any x86 machine, because they build the kernel for the lowest common denominator. Some detect the CPU type and install an appropriate kernel subsequently. So... the only way you can get into this mess is if you build a kernel yourself and choose the wrong options. There are many ways of producing a non-bootable kernel. The expectation is that if you want to go off and build your own kernel, you need to know what you're doing :-)"
Linus suggested having a boolean "Optimize for current CPU" option during configuration. Several folks liked this idea, and Riley Williams posted a patch to do it. But Alan Cox said, also in reply to Linus, "If we do that I'd rather see a make autoconfig that does the lot from proc/pci etc 8)" . Linus replied:
Good point. No point in adding a new config option, we should just have a new configurator instead. Of course, it can't handle many of the questions, so it would still have to fall back on asking.
That _would_ be a nice addition eventually. It's a bigger project than the one I envisioned, though.
28 Dec 2000 - 4 Jan 2001 (62 posts) Archive Link: "test13-pre5"
People: Linus Torvalds, Marcelo Tosatti, Rik van Riel
In the course of hacking, Linus Torvalds asked:
If somebody (you? hint, hint) wants to do this, I'd be very happy - I can do it myself, but because it's my birthday I'm supposed to drag myself off the computer soon and be social, or Tove will be grumpy.
And you don't want Tove grumpy.
Marcelo Tosatti replied, "Ok, I'll do it because I love Tove." Rik van Riel dove betwixt Marcelo and blackest night, saying:
Marcelo, you should buy some glasses ;)
Tove != Tux
It's ok and probably safe to love Tux, the nice cuddly penguin everybody loves.
However, loving the (6-time ??) Finnish female karate champion, who happens to be married to Linus is probably quite a bit less safe ...
Marcelo replied, "Marcelo runs like hell."
3. Network Card Recommendations
28 Dec 2000 - 1 Jan 2001 (13 posts) Archive Link: "Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again"
Topics: Networking, PCI
People: Linus Torvalds, Andrew Morton, Barry K. Nathan
In the course of discussion, Linus Torvalds gave this recommendation:
There are always problems with some hardware, but my personal recommendation for a card would definitely be the Intel Ethernet Pro 100 series (82557).
Unlike the tulip cards (which are pretty good too), there aren't a million different versions of it. There's a few, but it's not a big mess. It performs well, and is stable. It's pretty well documented (apart from the magic extensions), and it's common.
That said, some people have trouble even with that card. Nobody knows why, but at least the driver is actively maintained etc, so I still am not nervous about recommending it.
I bet that others will have other recommendations, but so far I have at least personally had good luck with the eepro100.
Andrew Morton gave his take on the situation:
The 3c905C is a well manufactured and very feature-rich NIC which at present appears to have fewer problem reports than eepro100, 8139 or tulip.
Available in PCI, Cardbus, Mini-PCI. A dual-interface PCI version has just been released (3c982), although we've yet to hear of anyone trying it with Linux.
3com provide full specs without any NDA restrictions, plus a GPL'ed driver.
Perhaps most significantly, the 905 has full scatter/gather support. This isn't used at present, but Alexey's zerocopy-sendfile patches do utilise it. He currently has scatter-gather support for acenic, 3c905 and sunhme. I don't know what the plans are to support other 100 mbps NICs.
The in-kernel 3c59x.c isn't the world's fastest driver. On the todo list for 2.5 is MMIO support, scatter-gather maintenance, optional use of DPD polling and implementation of the onboard multicast hash filter. And implementation of the on-board VLAN support if 2.5 becomes VLAN-capable.
Barry K. Nathan replied:
3c905c is a bit expensive, though. pcnet32 cards also work very well for me, and are less expensive. The 905c could be a better card (I don't really know), but pcnet32's might be more cost-effective, depending on your needs. (I've seen pcnet32-based cards selling for $15-20, and I bought a new 10-pack (of HP NightDirector 10/100's) for about $36, including shipping, on eBay.)
In any case, tulips have been more problematic for me than 8139, pcnet32, or 3c905c (whose reliability are all comparable IME). I've never tried eepro100, though. (Also, I'm speaking in terms of my experiences across all OS's which I've used the cards under, not just under Linux, although my Linux experiences are similar to the experiences I've had overall.)
4. 2.4.0-prerelease: Approaching 2.4.0
31 Dec 2000 - 4 Jan 2001 (24 posts) Archive Link: "Happy new year^H^H^H^Hkernel.."
People: Linus Torvalds, Keith Owens, Rik Faith, Alan Cox, Adam Sampson, Adam J. Richter
Linus Torvalds dropped the '2.4.0-test' naming system, and announced 2.4.0-prelelease, saying:
Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some last-minute stuff that needed fixing (ie the dirty page lists etc), and the best I can do is make a prerelease.
There's a 2.4.0-prerelease out there, and this is basically it. I want people to test it for a while, and I want to give other architectures the chance to catch up with some of the changes, but read my lips: no more recounts. There is no "prerelease1", to become "prerelease2" and so on.
One thing other architectures will want to catch up with is the changes to handle 2GHz+ machines, which due to overflow issues caused "loops_per_sec" to become "loops_per_jiffy". And some architectures have not had much chance to synchronize with me due to other fires to put out.
Give it your worst. After you recover from being hung-over, of course.
Adam Sampson pointed out that the drm modules had unresolved symbols, and posted some linker output. Linus posted a patch, and Adam and Frank Jacobberger reported complete success; but Keith Owens cautioned:
That will break for anybody compiling a DRM card into the kernel and compiling a second DRM card as a module. drmlib.a will get a split personality, it will be compiled twice, once for kernel and once for module, which version actually gets linked will depend on the phase of the moon. Either that or it only gets compiled for kernel, which is where we came in.
DRM maintainers: can we remove this restriction on needing multiple copies of the library? It makes no sense anyway. If you build a new library with the same function names then you cannot have two DRM cards built into the kernel, the function names will collide within vmlinux. So you have to use different function names for a new library, but then the old cards can share the old library and the new cards can share the new library, i.e. there is no need for each driver to have its own copy of the library.
I strongly recommend that you remove the restriction on having multiple copies of the library. Then Adam J. Richter's patch does the job nicely, making drmlib.a a helper module.
Rik Faith explained:
We plan to remove the need to have multiple copies of drmlib.a and make the kernel Makefile fully compatible with the 2.4 make system -- but we haven't finished this work yet. With this new work, however, the end-user will still load a single module (e.g., tdfx.o), just like now. (Loading a single kernel module is a significant win when dealing with end users: there is no possibility of version skew or of having two modules that were compiled with different options.)
Linus -- Please use your patch or Keith Owens' patch as a bandaid to solve this problem until we can do it the right way. Whatever patch you select, please do *NOT* make drmlib into a separate helper module -- this will only lead to user confusion (especially since we'll move back to a single-module solution soon). From the user's standpoint, I'm not concerned that you can't mix modules with in-kernel versions, since most users don't do that [and we could fix the configuration file to prevent this -- that's another way to bandage this problem that I'll send you a patch for tomorrow]. I am very concerned that users will see us move from 1 DRM module to 2 and then back to 1 -- that would be very confusing for them.
Alan Cox gave his assessment of this, saying, "So with 3 video cards I have 3 wasted chunks of ram just because of a tiny tiny possibility that someone would manage to build two copies of the library with matching ksyms. That doesnt strike me as a good tade off." There was no more discussion in that subthread.
5. The Future Of modutils
31 Dec 2000 - 3 Jan 2001 (6 posts) Archive Link: "Announce: modutils 2.3.24 is available"
Topics: Backward Compatibility
People: Keith Owens, Matthias Andree
Keith Owens announced the latest version of modutils, at ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.3. He added, "Assuming no problems are found in modutils and assuming that kernel 2.4.0-prerelease is followed by the official 2.4 kernel then this version of modutils will be repackaged as modutils 2.4.0." Matthias Andree pointed out that depmod gave a warning when invoked with the --version option. He figured nothing but the version information should really be output, and asked about it. Keith replied, "Historical accident. I want to clean that up but it breaks existing behaviour; somewhere, somebody is bound to rely on depmod -V updating modules.dep at the same time. modutils 2.5 will clean up a lot of backwards compatibility crud, including this one. But you will not see modutils 2.5 until Linus rolls kernel 2.5 and we start the next development cycle." This made sense to Matthias, though he suggested documenting the current behavior in the --help output and the man page. Keith felt it wasn't worth the trouble, since the whole thing would change once the kernel hit 2.5; Matthias urged, "I was just thinking to write -V "output version in addition to normal operation" in --help, nothing bigger than like 5 minutes." But there was no reply.
6. devices.txt Cleanup
1 Jan 2001 - 2 Jan 2001 (10 posts) Archive Link: "devices.txt inconsistency"
People: Ari Pollak, Robert Read, H. Peter Anvin, Geert Uytterhoeven
Ari Pollak reported, "This has not been fixed for at least a year that i can remember - in Documentation/devices.txt, it says /dev/js* should be char-major-15*, but in Documentation/joystick.txt it says it should be char-major-13. I'm assuming joystick.txt is the correct one, and devices.txt should be updated to reflect this.. before 2.4.0 would be nice." Robert Read replied, "devices.txt does need some updating. It still lists char-major-13 as the PC Speaker, but 13 appears to be the major for new input driver, and the joystick driver is now a minor off the that. Are there now two Joystick drivers, or can char-major-15 be obsoleted/deleted?" H. Peter Anvin said, "I think there are two; at least, the number will remain reserved for a long time," and gave a link to the current devices.txt. Robert and others posted patches, and the thread ended.
Elsewhere, under the Subject: [PATCH] devices.txt bugs, Geert Uytterhoeven posted a patch against devices.txt, and explained:
This patch fixes two things:
7. user-mode Port Of 2.4.0-prerelease
1 Jan 2001 (1 post) Archive Link: "user-mode port 0.36-2.4.0-prerelease"
People: Jeff Dike
Jeff Dike announced:
The user-mode port of 2.4.0-prerelease is available.
hostfs is more improved. Writing files really works now. Executing binaries also works. There is still some memory corruption, though.
I fixed the swapoff crash.
The input to consoles and serial lines is now much more general. You can attach them to ptys, ttys, and ports now, with a few more interfaces to come.
The project's home page is http://user-mode-linux.sourceforge.net
The project's download page is http://sourceforge.net/project/filelist.php?group_id=429
See his later announcement at Issue #102, Section #16 (4 Jan 2001: user-mode Port Of 2.4.0)
8. Possible Filesystem Corruption In 2.4.0-prerelease
2 Jan 2001 (5 posts) Archive Link: "2.4.0-prerelease problems (it corrupted my ext2 filesystem)"
People: Vedran Rodic, Daniel Phillips
Vedran Rodic reported filesystem corruption with 2.4.0-prerelease. He put the complete kernel log of the session up on the web, and reported that he hadn't seen any new errors since that first report. Daniel Phillips asked if it was possible at all to reproduce the problem, and Vedran replied, "I can't reproduce this problem easily. You see at the log files that it happened after some hours of uptime." End of thread.
9. ac Patches Against 2.4.0-prerelease
2 Jan 2001 - 4 Jan 2001 (3 posts) Archive Link: "Linux 2.4.0prerelease-ac4"
Topics: Disks: IDE, FS: FAT, Framebuffer, I2O, Ioctls, Networking, Power Management: ACPI, SMP, Sound: i810
People: Alan Cox, Arnaldo Carvalho de Melo, Marc Zyngier, Cort Dougan, Rik van Riel, Geert Uytterhoeven, Bill Nottingham, Roberto Nibali, Tigran Aivazian, Jari Ruusu, Arjan van de Ven, Andreas Bombe, Paul Gortmaker, Marcelo Tosatti, Neil Brown, Russell King, Byron Stanoszek, Keith Owens
Alan Cox announced:
There was no reply, but the next day, under the Subject: Linux 2.4.0-prerelease-ac5, Alan announced:
There was no reply, but the next day, under the Subject: Linux 2.4.0prerelease-ac6, Alan announced:
10. Rik And Andrea: As The Saga Turns
3 Jan 2001 - 5 Jan 2001 (17 posts) Archive Link: "[PATCH] dcache 2nd chance replacement"
Topics: Virtual Memory
People: Rik van Riel, Andrea Arcangeli, Alan Cox
This thread started innocently enough, but Rik van Riel and Andrea Arcangeli just don't get along. Maybe it's because they're working on two competing versions of the Virtual Memory subsystem, maybe it goes back further. In this particular incarnation, Rik posted a variant of a performance patch originally written by Andrea; he added, "I know this probably isn't of any help under very low and very high loads, but it should provide a nice improvement under medium loads..." Andrea corrected him, saying, "It should provide an improvement under high VFS load (lots of files lookedup and not kept referenced all the time)." But Rik disagreed, saying, "Not really. Under very high VFS loads we'd just scan through the list twice and free the entries anyway." Andrea then threw the first stone, with, "You're obviously wrong." He went on to give a technical explanation of his point, and they quipped back and forth for a couple posts, at which point Andrea said, "Your arguments are senseless." Rik finally took the bait, with, "I could say the same of yours if I let myself sink to that level ;) </obflamebait>" . He gave his own technical explanation, at which point Andrea accused him of going off-topic. Rik said he'd just been arguing against Andrea's point; and added, "Unfortunately you seem to ignore my arguments, so lets close this thread." Andrea replied, "I've not ignored them, as said they were either obviously wrong of offtopic." To which Rik quipped, "Without giving any arguments ;)"
At around this point, Alan Cox stepped in and pulled them to opposite corners, saying, "Would the two of you ajourn this debate to alt.flame" .
11. Preemption Patch For 2.4.0-prerelease
3 Jan 2001 - 4 Jan 2001 (25 posts) Archive Link: "[PATCH] 2.4.0-prerelease: preemptive kernel."
Topics: FS: ramfs, Real-Time, Samba
People: Rik van Riel, Nigel Gamble, Ludovic Fernandez, Daniel Phillips
Ludovic Fernandez posted a patch against 2.4.0-prerelease, to make the kernel preemptive. Rik van Riel replied, "I think this would be a nice thing to start testing once 2.5 is forked off." There was some technical discussion of the patch, and at one point elsewhere, Nigel Gamble said:
I didn't realise you were still working on this. Did you know that I am also? Our most recent version is at:
although I have yet to put up a 2.4.0-prerelease patch (coming soon). We should probably pool our efforts on this for 2.5.
Ludovic explained, "I was on vacation and had a little time to kill... Going through your README, you seem much more advanced than this simple patch." He agreed that pooling their efforts sounded like the way to go. He suggested they research some possible benchmarks, and added that maybe the discussion had started to go off-topic for linux-kernel. But Daniel Phillips interceded:
No! Not off topic. And I hope you don't throw away that simple patch, it will always be useful for doing reality checks on the performance of the fancy system, and who knows, maybe it's useful in its own right.
The current fashion is to use dbench:
I think this is good for your patch because it's inherently parallel. Interesting numbers of tasks are, e.g., 1, 2, 10, 50. Of course dbench is not the last word in benchmarks but it's been pretty useful so far. You probably want something entirely cpu-bound too. How about dbench with ramfs?
There was no reply.
12. 2.4.0 Is Released
4 Jan 2001 - 6 Jan 2001 (15 posts) Archive Link: "And oh, btw.."
People: Linus Torvalds, Miles Lane
Linus Torvalds rocked the world, saying:
In a move unanimously hailed by the trade press and industry analysts as being a sure sign of incipient braindamage, Linus Torvalds (also known as the "father of Linux" or, more commonly, as "mush-for-brains") decided that enough is enough, and that things don't get better from having the same people test it over and over again. In short, 2.4.0 is out there.
Anxiously awaited for the last too many months, 2.4.0 brings to the table many improvements, none of which come to mind to the exhausted release manager right now. "It's better", was the only printable quote. Pressed for details, Linus bared his teeth and hissed at reporters, most of which suddenly remembered that they'd rather cover "Home and Gardening" than the IT industry anyway.
Anyway, have fun. And don't bother reporting any bugs for the next few days. I won't care anyway.
Miles Lane couldn't find a patch against 2.4.0-test12, and Linus replied:
patch-2.4.0-prerelease.gz - patch from test12 to the prerelease
prerelease-to-final.gz - patch from prerelease to final.
And it will apparently take some time for the ftp servers to sync up: when I moved the test-kernels away from the main v2.4 directory I didn't think of the fact that the mirror scripts will spend quite a bit of time just synchronizing everything (the fact that _I_ did it with a simple "mv" on the master copies doesn't mean that the mirror services will be able to do it ;)
Right now the sync from the master copy has gotten to the patches in the test directory, which means that it shouldn't take more than maybe 15 minutes until everything has been synched - but I suspect that if people pound on ftp.kernel.org it will only slow stuff down further, so try to see if you can find other mirrors that got in early and don't synchronize the test-kernels...
One thing that must be on everyone's mind is the famous 'brown-paper-bag' bug that hit 2.2.0, as covered in Issue #3, Section #14 (26 Jan 1999: 2.2.0 Exploit To Crash The System) . Will a similar exploit be found for 2.4.0?
13. ac Patches Against 2.4.0
4 Jan 2001 - 6 Jan 2001 (9 posts) Archive Link: "Linux 2.4.0ac1"
Topics: I2O, Ioctls, Networking, Power Management: ACPI, Sound: Maestro
People: Alan Cox, Bill Wendling, Arnaldo Carvalho de Melo, Tim Waugh, Kirk Reiser, Chris Mason, Geert Uytterhoeven, Krzysztof Halasa, David Wragg, Matti Aarnio, Paul Gortmaker, Douglas Gilbert, Miles Lane, Oliver Neukum, Zach Brown, Keith Owens, Chris Rankin, Andrew Morton
Alan Cox put out 2.4.0-ac1, saying:
Miles Lane had some problems compiling, and Keith Owens posted a Makefile fix, adding that the change might prevent ACPI from working with module symbol versions; so Miles would not be able to select module symbol versions. Bill Wendling proposed another solution as well, which worked fine for Miles. Bill replied, "Great! I just wish I knew where this line was being generated so that I could send a patch in :)."
Alan announced -ac2 in Issue #102, Section #20 (5 Jan 2001: Alan Still Maintaining 2.2) .
Later, under the Subject: Linux 2.4.0-ac3, Alan announced:
Some folks pointed out that Alan had forgotten to update the Makefile's EXTRAVERSION version number from ac2 to ac3.
14. Problems Trying To Download 2.4.0
4 Jan 2001 (3 posts) Archive Link: "You've Been Slashdotted"
People: Michael D. Crawford, Scott Laird
Michael D. Crawford reported:
Even mighty ftp.kernel.org has fallen under the /. effect after they ran the annoucenement:
You're probably not going to have much luck getting any source off any servers tonight. Might I suggest you pop over to Slashdot and give the clueless some clues on getting their new kernels working? They need help.
Scott Laird replied, "my mirror (ftp-mirror.internap.com, or ftp15.us.kernel.org) is only seeing 1-2 Mbps worth of traffic, out of 10 Mbps available to it. I suspect that a lot of mirrors are similar." After awhile, Michael added:
I gather from the combination of what I read on Slashdot and what folks replied here that the mirrors are actually lightly loaded, but Slashdot readers don't know about them because they couldn't read the home page at http://www.kernel.org that directed them to the mirror list.
So I posted the algorithm for calculating the URL to your nearest mirror on Slashdot. Maybe that'll help some
15. Crypto In 2.4
4 Jan 2001 - 6 Jan 2001 (3 posts) Archive Link: "Crypto in 2.4"
People: Marc Mutz, Jon Masters
Jon Masters asked about the status of crypto for 2.4.0, and Marc Mutz replied:
A 18.104.22.168 should be on ftp://ftp.kernel.org/pub/linux/kernel/crypto/v2.4/. But it has been heavily re-worked. I haven't got my hands on that one and will keep quiet as to what extend that patch is produiction-ready, but I remember that the loop driver in 2.4.0 still can stall your box. Since the kerneli crypto relies on loop, this would count in favor of "don't do that yet".
BTW: You might want to join email@example.com (majordomo) if you are interested in kerneli.
Jon was very excited to learn about the mailing list, and joined it on the spot.
16. user-mode Port Of 2.4.0
4 Jan 2001 (1 post) Archive Link: "user-mode port 0.37-2.4.0"
People: Jeff Dike
Jeff Dike announced:
The user-mode port of 2.4.0 is available.
It was updated to 2.4.0 and that's it.
The project's home page is http://user-mode-linux.sourceforge.net
The project's download page is http://sourceforge.net/project/filelist.php?group_id=429
17. Kernel Debugger For 2.4.0
4 Jan 2001 (1 post) Archive Link: "[Announce] kdb v1.7 is available for 2.4.0"
People: Keith Owens
Keith Owens announced, "http://oss.sgi.com/projects/kdb/download/ix86/ contains patches for kdb v1.7 against kernel 2.4.0. No significant changes since 2.4.0-test13 and 2.4.0-prerelease. Just fitting the patch to the new kernel."
18. Linux/m68k 2.4.0
5 Jan 2001 (1 post) Archive Link: "Linux/m68k 2.4.0"
People: Geert Uytterhoeven
Geert Uytterhoeven announced:
Of course 2.4.0 runs on m68k as well :-)
Sorry, no real changes since last release, but I wanted to get something out of the door as soon as possible. Today is my last holiday, so my Linux development efforts will be much smaller next week. Someone to take over again?
The patch is quite short. Looks like the stressy period just before a new major release is good for our patch acceptance rate. It's like a duel: who can handle the most stress, and who gives up... Linus might have lost this time :-)
If you can live without `exotic' architectures (Atari, Mac, Sun3, ... :-), the patch is... tiny.
Good luck! Enjoy!
19. Minor LVM Problems In 2.4.0
5 Jan 2001 (2 posts) Archive Link: "2.4.0 LVM"
Topics: Disk Arrays: LVM
People: Alan Cox
Samuli Kaski reported that LVM wouldn't compile with the CONFIG_LVM_PROC_FS config option, and Alan Cox replied, "Fixed in -ac for ages. Linus didnt think it important enough for 2.4.0 - which compared to 'it crashes when I..' is reasonable enough I think." End Of Thread.
20. Alan Still Maintaining 2.2
5 Jan 2001 - 6 Jan 2001 (8 posts) Archive Link: "Linux 2.4.0-ac2"
People: Alan Cox, Bill Wendling, Geert Uytterhoeven, Ben Greear, Ulrich Weigand, Arjan van de Ven
Alan Cox gave a link to his latest -ac2 patch against 2.4.0 and announced:
Octave Klaba asked if Alan intended to release new 2.2 kernels, or if he planned on working only on 2.4 from then on. Alan replied, "2.2.19 is still cooking nicely. Im aiming for a month or two."
21. Linux On The Intel IXP1200
5 Jan 2001 (2 posts) Archive Link: "port of linux to Intel IXP1200"
People: Russell King
Josh Fryman asked if Linux had been successfully ported to the Intel IXP1200 programmable network processor. He'd heard rumors that it had, but had been unable to dig up anything definite. Russell King replied, "Yes there is. Look at: http://www.netwinder.org/~urnaik/ixp1200_howto.html for more information on getting Linux running." End Of Thread (tm).
22. Configuration Cleanup In 2.4.0
5 Jan 2001 - 6 Jan 2001 (5 posts) Archive Link: "PROBLEM: 2.4.0 Kernel Fails to compile when CONFIG_IP_NF_FTP is selected"
People: David S. Miller, Rusty Russell
Matthew Schumacher reported that the 2.4.0 kernel wouldn't compile when CONFIG_IP_NF_FTP was selected during the configuration phase. David S. Miller pointed out that CONNTRACK and full NAT both had to be enabled as well. He asked Rusty Russell, "Rusty, why doesn't the Config stuff just enforece this if it is necessary when enabling FTP support etc.?" Rusty replied, "Deja Vu: we've been through this before. But someone else fuck^H^H^H^Hfixed the makefiles recently." He posted a fix, which seemed fine to David, and the thread ended.
23. uClinux 22.214.171.124pre0 Released
5 Jan 2001 - 6 Jan 2001 (2 posts) Archive Link: "uClinux 126.96.36.199pre0 released."
People: D. Jeff Dionne
D. Jeff Dionne announced:
I've put up a patch against linux-2.4.0 for uClinux 2.4. The supported platforms are listed below, in the announcement which was sent to the uClinux-dev list.
We would like to merge into the mainline Linux tree in 2.5, so we've taken an approach which touches as little as possible of the generic kernel :-)
He added from the release notes:
This relase includes support for Motorola ColdFire MCF5307 and MC68328. The MCF5307 support targets Lineo NetTEL and the 68328 support targets XCoPilot.
MCF5307 support is the most complete. It includes networking and drivers for the NetTEL. There are a few memory leaks and there is a bug in wait4().
MC68328 support has been carried forward from test11, and still has a little breakage (the interrupt vector table stuff got broken along the way). We'll fix that in the next couple of days.
Use gcc-2.95.2 configured --target=m68k-elf to build these targets.
Many thanks to David McCullough he did the heavy lifing moving this to release from my early work on test5, Michael Leslie who did the merge from Randy Buchanan's 68328 work. And of course Linus and the entire community that produced the Linux 2.4 release.
24. "Wonderful World of Linux 2.4"
6 Jan 2001 (3 posts) Archive Link: "New features in Linux 2.4 - Wonderful World of Linux 2.4"
Topics: BSD, Networking
People: Joe Pranevich, Jean-Christian de Rivaz, Andi Kleen
Joe Pranevich said, "This document has already been picked up by some Linux news sites, but it really belongs here. This is my list of new features since Linux 2.2, gathered by reading this list, playing with patches, and getting input from people. Parts of it are non-technical, but there is some good info here. I hope that someone out there finds this list useful." He included his list, which you can find on Linux Today. Jean-Christian de Rivaz had a question about the "Networking And Protocols" section, in which Joe had said, "It should also be mentioned at this point that Linux is still the only operating system completely compatible with the letter of the IPv4 specification." Jean-Christian replied, "I am very interesting about the proof of this. I work on a project witch need to be certified. Any informations about the compliance of Linux to some specification is very welcome." Andi Kleen replied:
It's very dubious at least. AFAIK no RFC1122/RFC1812 evulation has been done recently (since 2.0 or so). Also part of these RFCs have been superseeded by later RFCs that have not reached Internet standard status yet, so it would not be very useful anyways (today's internet looks very different from 1989's when 1122 was written)
The mechanism the comment refers to (asynchronous error notification for UDP, which is not in traditional BSD) is not used by 99.9% of all apps BTW ;)
End of thread
25. "VM: do_try_to_free_pages" Lockups: The Saga Ends Peacefully
7 Jan 2001 (7 posts) Archive Link: "Which kernel fixes the VM issues?"
Topics: Virtual Memory
People: Jim Olsen, Ville Herva, Rik van Riel, Andrea Arcangeli, Alan Cox
Jim Olsen had been a victim of the do_try_to_free_pages problem reported in the recent past. He had some idea from following linux-kernel that the problem had been fixed or at least modified, and asked, "exactly which kernel should I use in order to rid my server of this VM issue? I'm uncomfortable (and always have been) with running pre* kernels on production machines, so i'd like to stick with 2.2.18, but I would like to know if it truly does fix the problem(s) with the VM. If I need to, though, I will (hesitantly) put a 2.2.19pre* kernel on the box." Alan Cox, Rik van Riel, and Ville Herva pointed out that 2.2.19pre2 had the actual fix. As Ville put it, "It's fixed 2.2.19pre2 (which includes the Andrea Arcangeli's vm-global-7 patch that (among other things) fixes this.) You can also apply the vm-global-patch to 2.2.18 if you like."
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.