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:
Anton replied,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...
Looks good, committed to vger. Thanks guys!
Andrew Morton announced:
Rik van Riel replied that he'd taken a very quick look and hadn't found any problems.The little-low-latency patch for test9 is at
http://www.uow.edu.au/~andrewm/linux/2.4.0-test9-low-latency.patch
Notes:
- It now passes Benno's tests with 50% headroom (thanks to Ingo's scheduler race fix).
- Updated to follow the wandering ext2 truncate code.
- Updated for the new VM. (I'll have to ask Rik to take a look at this part sometime).
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).
- net/ipv4/tcp_minisocks.c:tcp_twkill() can spend tens or even hundreds of milliseconds within a timer handler. I have a fix for this, but Alexey agrees that this needs to be addressed independently of the low-latency patch. So this file is untouched.
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:
- CPU1 holds a long-lived spinlock such as dcache_lock in select_parent().
- CPU0 is spinning on the same lock.
- An interrupt occurs and the kernel tries to wake up your SCHED_FIFO task on CPU0.
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 :)
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 ...
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.
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.
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.
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.
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.
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.
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.
Bartlomiej Zolnierkiewicz posted a Makefile patch which was apparently accepted. David S. Miller complained:
Linus Torvalds replied thatLinus, 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.
sparc is broken anyway, and this way those Makefiles _will_ get fixed.Andre Hedrick commiserated with David,
Neither your or I have the time to dork with Makefiles, and Bart understands them. Be thankful, because the script rules of these puppies are worth a bottle of bayer(tm).David pointed out that Sparc64 had been fine before the patch, and that he'd told Linus specifically that only Sparc32 had been in a broken state. But he ended the thread with,
It's a non-issue now I suppose, as I'll fix this up.
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.