|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
Table Of Contents
|1.||4�Oct�2000�-�12�Oct�2000||(5 posts)||Problems With The 'dbri' Sound Module|
|2.||6�Oct�2000�-�11�Oct�2000||(6 posts)||Low Latency Patch For 2.4.0-test9|
|3.||6�Oct�2000�-�13�Oct�2000||(141 posts)||VM Looking Good; 'OOM Killer' Discussion|
|4.||9�Oct�2000�-�10�Oct�2000||(10 posts)||Maximum Size For DVD Images.|
|5.||10�Oct�2000||(3 posts)||Approaching 2.0.39|
|6.||9�Oct�2000�-�10�Oct�2000||(3 posts)||'kernel.org' Verification Key Updated|
|7.||9�Oct�2000�-�11�Oct�2000||(14 posts)||Does Everything But Make Coffee (Till Now)|
|8.||10�Oct�2000�-�11�Oct�2000||(14 posts)||Nonexistent Functions In The Kernel - And Staying|
|9.||10�Oct�2000�-�11�Oct�2000||(12 posts)||Problems With Kernel CVS Tree|
|10.||13�Oct�2000�-�14�Oct�2000||(6 posts)||'modprobe' 'exec()'ed From The Kernel|
|11.||13�Oct�2000�-�14�Oct�2000||(6 posts)||Sparc Fixes|
|12.||13�Oct�2000�-�14�Oct�2000||(4 posts)||Ambiguous References To The GPL In Kernel Sources|
Mailing List Stats For This Week
We looked at 1027 posts in 4036K.
There were 334 different contributors. 148 posted more than once. 131 posted last week too.
The top posters of the week were:
1. Problems With The 'dbri' Sound Module
4�Oct�2000�-�12�Oct�2000 (5 posts) Archive Link: "aaaah! complete lockup 2.4.0-test9 SPARC32"
People: Anton Blanchard,�Joshua Uziel,�Dr. Kelsey Hudson,�Pete Zaitcev
Dr. Kelsey Hudson reported that loading and unloading the 'dbri.o' sound driver would lock the system up solid. Anton Blanchard replied, "Short answer: don't use the dbri module :) It is buggy and requires someone to fix it." Joshua Uziel replied that he and Pete Zaitcev had taken a look at this, and had managed to generate and analyze several oopsen. He posted a patch and said:
Pete noticed that _sparc_free_io() wasn't aligning plen properly... problem solved.
While we were there, we noticed a few more problems in the file (misuse of a #define, and poor renaming of copied code).
At this point, the dbri driver is properly loadable and unloadable... now it just needs to be fixed... the patch follows...
2. Low Latency Patch For 2.4.0-test9
6�Oct�2000�-�11�Oct�2000 (6 posts) Archive Link: "lowish-latency patch for 2.4.0-test9"
Topics: FS: ext2, Networking, Real-Time, SMP, Virtual Memory
People: Andrew Morton,�Rik van Riel
Andrew Morton announced:
The little-low-latency patch for test9 is at
Set TASK_RUNNING in conditional_schedule().
This is probably unnecessary - current->state appears to be always equal to TASK_RUNNING in the places I'm using it.
So we test for this beforehand to avoid unnecessarily dirtying cache lines.
(This optimisation should be done anyway, especially for SMP).
This entire feature has been *disabled* for SMP. This patch is now UP-only.
It is completely stable on SMP and the scheduling latency is just grand, as long as you don't push things too hard. It then comes unstuck.
This is because of the following scenario:
You lose. Nothing happens until CPU1 releases the lock a week later.
There are a number of ways of fixing this, but they're messy.
One way is to identify those locks and to add a test for current->need_resched into the spin. This gets nastier if the BKL is held at the same time.
Another way is to write a fully-preemptible SMP kernel patch :)
3. VM Looking Good; 'OOM Killer' Discussion
6�Oct�2000�-�13�Oct�2000 (141 posts) Archive Link: "[PATCH] VM fix for 2.4.0-test9 & OOM handler"
Topics: OOM Killer, Virtual Memory
People: Byron Stanoszek,�Rik van Riel,�Tom Rini,�Linus Torvalds,�Andrea Arcangeli,�David Weinehall,�James Lewis Nance,�Ingo Molnar,�Ingo Oeser
Rik van Riel posted some fixes to the virtual memory subsystem. James Lewis Nance and David Weinehall reported good results with the patch. David ran a number of tests, configuring different amounts of memory and swap, and found no problems at all.
Regarding the 'OOM Killer' (logic to kill the proper process when the system runs out of memory), Byron Stanoszek asked, "Can you give me your rationale for selecting 'nice' processes as being badder?" Rik replied, "They are niced because the user thinks them a bit less important." A lot of people disagreed with that idea, and several folks argued that a high nice value was completely orthogonal to the importance of the task. Ingo Molnar located the specific part of Rik's algorithm that he wanted removed, and Rik said, "OK, done." Ingo replied that he thought all the other heuristics were fair.
Andrea Arcangeli suggested that the 'OOM Killer' should have special heuristics to avoid killing 'init'; and there was a big debate over it. Some folks argued that killing 'init' was the same as killing the machine, and so they should never kill 'init'. Others argued that if the 'OOM Killer' was ever going to kill 'init', that would in itself represent a bug in the 'OOM Killer' or 'init' that should be reported, and so any attempt to prevent the 'OOM Killer' from killing 'init' would amount to obscuring the bug.
At one point, Ingo Oeser posted a patch to enable any 'OOM Killer' as a loadable module, so anyone could test out their favorite out-of-memory handler. Rik thought the patch was a "cool toy", and Tom Rini thought it was better than just a toy. Rik remarked, "I suspect most of the people trying this would fall into the trap of over-engineering their OOM killer, after which it mostly becomes less predictable ;)" and Tom replied, "I was thinking more along the lines of ones w/ "safety" features that not everyone might like/need (ie /usr/local/bin/foo is always good, those sugjestions). It seems like useful functionality at little/no cost. And a neat toy for now. :)"
In the course of discussion, Linus Torvalds posted a few messages. Among them, he said:
Nothing is perfect.
In fact, a lot of engineering is _recognizing_ that you can never achieve "perfect", and you're much better off not even trying - and having a simple system that is "good enough".
This is the old adage of "perfect is the enemy of good" - trying too hard is actually _detrimental_ in 99% of all cases. We should have simple heuristics that work most of the time, instead of trying to cajole a complex system like X to help us do some complicated resource management system.
Complexity will just result in the OOM killer failing in surprising ways.
A simple heuristic will mean that the OOM killer will still fail, but at least it won't be be in subtle and surprising ways.
Elsewhere, Rik added in response to various suggestions:
Sure we could do all of this, but does OOM really happen that often that we want to make the algorithm this complex ?
The current algorithm seems to work quite well and is already at the limit of how complex I'd like to see it. Having a less complex OOM killer turned out to not work very well, but having a more complex one is - IMHO - probably overkill ...
4. Maximum Size For DVD Images.
9�Oct�2000�-�10�Oct�2000 (10 posts) Archive Link: "MAX iso9660 size?"
People: H. Peter Anvin,�Alan Cox,�Jens Axboe,�Andre Hedrick
Andre Hedrick asked if there were a limit on how big an iso9660 image could be. He was having trouble creating 4.5G images, and wondered if there was any fundamental limit. H. Peter Anvin replied, "I belive kernels had a problem with ISO 9660 > 2^31 or 2^32 bytes until recently. Also, mkisofs might not be able to handle it." He and Alan Cox said DVD disks should be burned UDF formatted. Andre asked where the tools were for handling UDF, and Alan replied, "I dont know where the DVD format building tools are, but the isofs code won't handle > 4Gig. I guess you could rewrite bits of it to do so if you needed the size." Jens Axboe also gave a link to the UDF project on sourceforge.
5. Approaching 2.0.39
10�Oct�2000 (3 posts) Archive Link: "When do release linux-2.0.39"
People: David Weinehall
Seiichi Nakashima asked when 2.0.39 would be coming out, and David Weinehall replied, "Well, I'm still investigating some problems that some users are experiencing. However, if I can't resolve those within a reasonable time, I'll release v2.0.39." Seiichi thanked him for the information and mentioned that he had no problems using 2.0.39-pre8.
6. 'kernel.org' Verification Key Updated
9�Oct�2000�-�10�Oct�2000 (3 posts) Archive Link: "kernel.org verification key updated"
People: H. Peter Anvin,�Walter Hofmann
H. Peter Anvin announced:
I just wanted to let everyone know that we have changed the cryptographic key for the Linux Kernel Archives. The reason is that the original key was generated with an expiration date, and unfortunately it appears that too much software out there doesn't support changing the expiration date on an already valid key (the ability to do that, arguably, makes the expiration date useless anyway.)
Therefore, we have revoked key 1E1A8782 generated 1999-10-15 and replaced it with key 517D0F0E generated 2000-10-10. Please see http://www.kernel.org/signature.html for more information.
The archive machine is currently in process of generating new signature files; they should be distributed to mirrors shortly thereafter in normal order.
However, the signature he used to sign this email was apparently mangled during transmission; Walter Hofmann saw an error from 'gpg' while trying to verify it. H. Peter resent the post with an updated signature, and the thread ended.
7. Does Everything But Make Coffee (Till Now)
9�Oct�2000�-�11�Oct�2000 (14 posts) Archive Link: "[PATCH] drivers/usb/Config.in"
People: Randy Dunlap,�James Simmons,�Matthew Dharm
In the course of discussion, Randy Dunlap remarked, "select USB HID support, that builds the hid driver, which handles mice, keyboards, joysticks, gamepads, speaker buttons, any-old-kind-of buttons, toaster buttons, etc." An impressed James Simmons remarked, "I didn't realize USB had this level of functionality." Matthew Dharm mused, "Hrm... I wonder if anyone out there is making USB Toasters.... That would be really nice -- have a nice snack waiting for me when I get home, etc. ;)" and James mentioned the Coffee HOWTO from the Linux Documentation Project.
8. Nonexistent Functions In The Kernel - And Staying
10�Oct�2000�-�11�Oct�2000 (14 posts) Archive Link: "__bad_udelay in 2.2.18pre15"
People: Horst von Brand,�Alan Cox,�Chris Swiedler,�Marcelo Tosatti,�Andreas Schwab
Marcelo Tosatti noticed that '__bad_udelay()' was used in 'udelay()' for handling large values, but wasn't defined anywhere in the sources. Horst von Brand explained, "That is precisely the idea: Flag the places where udelay() is called with a large constant value. Just won't find out uses with large _variable_ arguments, but it is a start. Netted one in PCMCIA-CS..." Alan Cox added succinctly, "Its a compile time error trap." Chris Swiedler suggested, "Wouldn't it be better to use an #error directive? I'm sure this could turn into a FAQ, even though the symbol is called "__bad_udelay()"." Alan and Andreas Schwab pointed out that the test couldn't be done in the pre-processor, where #error would be handled, but had to be done in the compiler itself.
9. Problems With Kernel CVS Tree
10�Oct�2000�-�11�Oct�2000 (12 posts) Archive Link: "CVS for kernel"
Topics: Samba, Version Control
People: Keith Owens,�David S. Miller,�Larry McVoy,�Oliver Xymoron,�Alan Cox,�David Lang,�Andi Kleen
Keith Owens asked about the kernel CVS tree. the linux-kernel FAQ pointed to a README file, but this file (and site) didn't seem to exist. And he added, "The mirror at samba.org is too slow, to the extent that even doing a sync at 6AM local time gives up part way through." David S. Miller replied that the samba.org tree was "the only anoncvs available sorry. We'll have to work out the performance problems with this site." Andi Kleen asked about the mirror at openprojects.org, and David replied, "Unmaintained, was falling apart, then shut down because of that."
Elsewhere, David Lang pointed out that as far as he could remember, the BitKeeper site kept an uptodate copy of the kernel. But David M. replied that Keith wanted his (David M.'s) live CVS tree, "which has all of my current Sparc and networking patches applied." Larry McVoy offered to set up a Bitkeeper repository to mirror David M.'s tree, if a lot of people were interested.
Keith replied, "The ability to see checked in changes before Linus/Alan sends out a new kernel patch would be the only reason for me to even look at BK. Without the ability to get absolutely up to date sources, I may as well wait for Linus/Alan to release a pre patch." Larry asked, "So what's your point? It's only useful if we are tracking Dave's tree on a frequent basis?" Keith replied, "Yes. I am usually up to date on pre patches within a few hours of their release, but then I have to play catch up to get my own patches up to date. What I would like is the ability to see what is in the kernel CVS tree before the pre patch is sent out so I can get modutils/ksymoops/kdb patches ready ahead of the kernel patch release." Oliver Xymoron replied, "You're out of luck - Linus doesn't use CVS (at least for the kernel). Perhaps we can convince Alan to do it for 2.2.x and set a precedent.." But Alan Cox said, "It wouldnt help you anyway. I tend to apply all the patches I approve in one batch, run through them test them and then do a release, then go do other useful stuff, so you wouldnt get get anything but a tree of 'applied all but untested' out of it."
10. 'modprobe' 'exec()'ed From The Kernel
13�Oct�2000�-�14�Oct�2000 (6 posts) Archive Link: "why is modprobe (and nothing else) exec()'d?"
People: Keith Owens,�Chris Swiedler,�Brian Gerst,�Ingo Oeser
Chris Swiedler noticed that the user-space tool 'modprobe' was called by the kernel, which seemed odd. He suggested compiling it into the kernel directly, but Keith Owens, Brian Gerst, Ingo Oeser, and Harald Welte pointed out that 'modprobe' had user-space uses, and could be run at any time. Keith added, "It shares a lot of code with insmod and depmod, another pair of user space tools." Chris said, "Ok, I should have thought of that ;-). I've never used modprobe directly myself, and had forgotten that was possible. Thanks to everyone who replied."
11. Sparc Fixes
13�Oct�2000�-�14�Oct�2000 (6 posts) Archive Link: "[PATCH] Rewritten drivers/sbus/[audio,char]/Makefile"
People: David S. Miller,�Linus Torvalds,�Andre Hedrick,�Bartlomiej Zolnierkiewicz
Bartlomiej Zolnierkiewicz posted a Makefile patch which was apparently accepted. David S. Miller complained:
Linus, why did you apply this? It was totally untested and breaks both Sparc builds. I was going to work on fixing it and then submit it to you tonight.
Please, people, submit Sparc patches to me when possible. This makes my life a lot simpler as I can sanity check all submissions. A lot of folks simply don't have sparcs with which to do even a compile check, and thats ok, just put the changes through me first and all those problems are solved.
12. Ambiguous References To The GPL In Kernel Sources
13�Oct�2000�-�14�Oct�2000 (4 posts) Archive Link: "Documentation glitch."
People: Mike A. Harris,�Alan Cox,�Tim Waugh
Mike A. Harris reported that in 'Documentation/SubmittingDrivers', the GPL was referred to as the "GNU public license". He pointed out, "This should be worded correctly as "GNU General Public License" to avoid any confusion or ambiguity. There is no such thing as the "GNU public license" and newcomers may be confused. This is just a minor point, but valid nonetheless for proper documentation." Alan Cox agreed, and said he'd fix it, and Tim Waugh pointed out that there were tons of similar things throughout the kernel sources. Mike volunteered to grep around and find them all, in 2.2 and 2.4, and the thread ended.
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.