Kernel Traffic #243 by Zack Brown
[email protected] Sun, 30 Nov 2003 20:38:53 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E1AQfpl-0005MQ-00@renegade> |
Kernel Traffic #243 For 1 Dec
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 12 Nov - 25 Nov (45 Linux 2.6.0-test9-mm3 Released
posts)
2. 18 Nov - 24 Nov (84 New ndiswrapper Project To Load Certain
posts) Windows Drivers In Linux
3. 18 Nov - 24 Nov (18 Linux 2.6.0-test9-mm4 Released
posts)
4. 19 Nov - 20 Nov (5 Linux 2.4.23-rc2 Released
posts)
5. 19 Nov - 20 Nov (7 udev 006 Released
posts)
6. 19 Nov - 20 Nov (14 Status Of udev
posts)
7. 19 Nov - 20 Nov (3 New cuecat Serio Driver For 2.6
posts)
8. 21 Nov (1 Graphs Comparing Various STP Test Runs For
post) 2.4 And 2.6
9. 22 Nov - 24 Nov (7 SIGTRAP Handling Change From 2.4 To 2.6 Under
posts) x86
10. 23 Nov - 25 Nov (13 Status Of Hyperthreading-Aware Scheduler
posts)
11. 23 Nov (1 perfctr 2.6.2 Performance Monitoring Tool
post) Released
12. 23 Nov (1 udev 007 Released
post)
13. 23 Nov - 24 Nov (18 Linux 2.6.0-test10 Released; Handoff To
posts) Andrew Immanent
14. 24 Nov (8 Status Of Intel Centrino Drivers
posts)
15. 24 Nov (1 New 'Tinderbox' Kernel Debugging Tool
post)
16. 24 Nov (1 New iswraid Intel Software RAID Driver For
post) 2.4
Mailing List Stats For This Week
We looked at 1424 posts in 7485K.
There were 465 different contributors. 233 posted more than once. 141 posted
last week too.
The top posters of the week were:
* 52 posts in 365K by William Lee Irwin III
* 43 posts in 203K by Andrew Morton
* 41 posts in 140K by Linus Torvalds
* 37 posts in 142K by Zwane Mwaikambo
* 23 posts in 87K by Nick Piggin
* Full Stats
1. Linux 2.6.0-test9-mm3 Released
12 Nov - 25 Nov (45 posts) Subject: "2.6.0-test9-mm3"
Topics: FS: ext2, FS: ext3, SMP
People: Andrew Morton, Zwane Mwaikambo, Martin J. Bligh, Linus Torvalds
Andrew Morton announced:
http://www.zip.com.au/~akpm/linux/patches/2.6.0-test9-mm3.gz
kernel.org is being slow. Will appear at:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/
2.6.0-test9-mm3/
+ Various new fixes; generally uncritical ones.
+ Significant changes to the AIO and direct-io code. This needs beating
on; hopefully we're now close to a solution to the fairly complex
problems in there.
+ Several ext2 and ext3 allocator fixes. These need serious testing on
big SMP.
+ Anyone who has patches in here which they think should go into 2.6.0,
please retest them in -mm3 and let me know, thanks.
At one point Zwane Mwaikambo remarked, "It's actually triple faulting my laptop
(K6 family=5 model=8 step=12) when i have CONFIG_X86_4G enabled and try and run
X11. The same kernel is fine on all my other test boxes." Martin J. Bligh said,
"Linus had some debug thing for triple faults, a few months ago, IIRC ...
probably in the archives somewhere ..." And Linus Torvalds replied:
Triple faults you can't debug, they raise a line outside the CPU, and
normal PC hardware will cause that to just trigger a reboot.
But double faults do get caught, and that debugging stuff actually is in
the standard kernel. It won't give _nearly_ as good a debug report as a
"normal" oops, since I didn't want the double-fault handler to touch
anything even remotely unsafe, but it often gives a good hint about what
might be wrong. Certainly better than triple-faulting did (which we still
do for _catastrophic_ corruption, eg totally munged kernel page tables etc
- it's just very hard to avoid once you get corrupted enough).
2. New ndiswrapper Project To Load Certain Windows Drivers In Linux
18 Nov - 24 Nov (84 posts) Subject: "Announce: ndiswrapper"
Topics: Assembly, BSD, Microkernels, Microsoft
People: Pontus Fuchs, Maciej Zenczykowski, Richard B. Johnson, Pavel Machek,
Bill Davidsen, H. Peter Anvin, Linus Torvalds, Nuno Silva, Christian Axelsson
Pontus Fuchs announced:
Since some vendors refuses to release specs or even a binary Linux-driver
for their WLAN cards I desided to try to solve it myself by making a kernel
module that can load Ndis (windows network driver API) drivers. I'm not
trying to implement all of the Ndis API but rather implement the functions
needed to get these unsupported cards working.
Currently it works fine with my Broadcom 4301 but I would like to get in
touch with people that have similar cards that are willing to do some
testing/hacking.
Visit this page for more info: http://ndiswrapper.sourceforge.net/
Please! I don't want to start a flamewar if this is a good thing to do. I'm
just trying to scratch my own itch and I doubt that this project changes
the way Broadcom treats Linux users.
Christian Axelsson thought this was a great plan, and Maciej Zenczykowski
agreed. But Maciej said:
are you loading these drivers into ring 0 (kernel space)? As far as I know
linux only supports ring 0 (kernel) and 3 (userspace). However this would
seem to be the perfect place to load the binary modules in ring 1 (or even
userspace if that was possible...). I can't say I trust any binary only and
/or windows driver to not make a mess of my kernel :) actually the driver
may actually be errorless - it's just designed for a different operating
system and thus some unexplainable misshaps could easily happen...
While we're at it, loading binary only modules into ring 1 would probably
also be a good idea for the NV module et al. Although I have no idea how
hard it would be to make ring 1 function (and whether there actually is any
point to doing it in ring 1 instead of ring 3 with iopl/ioperm anyway) and
how big the performance penalty for non-ring 0 would be...
Richard B. Johnson replied:
Do the NDIS drivers work in 32-bit land? Some kludges do! They were the
real-mode DOS driver interface to MS-DOS. Now there is a kludge on top of a
kludge called NDIS-6. They also used the Pascal calling convention which
screws up 'C' code (you need an assembly wrapper).
They are a waste-of-time. Why would you clone a Microsoft interface for a
non-Microsoft Operating System when you can't allow such junk to run inside
the kernel anyway.
The problem with third-party binary drivers is not the interface to the
kernel. Linux has a public interface, well established and well known. The
problem is that any third-party driver can completely f**k up the kernel,
either by mistake or by design. So the third-party drivers MUST provide
source-code so they can be fixed or made to behave if (read when) problems
are found.
Pavel Machek also replied to Pontus' original announcement, saying, "Wow, works
for me, Broadcom 94306. [Well, I do not have second wifi to test right now, but
module loads, I can iwconfig it etc.]"
Elsewhere, at one point in the conversation Bill Davidsen remarked, "I'm
curious if the NDIS stuff could be run in ring 1 or 2, being an old MULTICS
guy. Not for political reasons, just good tech." H. Peter Anvin said,
"Unfortunately the segmentation and paging were so poorly integrated in i386
that rings 1-2 are pretty much totally useless." And Linus Torvalds said:
That may be the politically sensitive (except to Intel) correct answer, but
in the end I suspect that the _real_ answer is that ring 1/2 are just
fundamentally useless, and it has nothing to do with x86 implementation
semantics or anything else.
Any kind of reasonable performance driver requires direct access to the
buffers it is going to fill in. And not just the actual data contents, but
to the metadata too - the pointers that comprise the skb (or in BSD, mbuf)
lists, etc.
So even if you were to use ring1/2 for the driver, you'd really need to
give write access to a large portion of the data structures that the "core"
kernel networking would use.
Which means that you either put the core kernel in ring1/2 as well (at
which point you don't actually use ring0 for anything interesting at all -
you could put a microkernel there, but hey, there's no real point), or you
map in a _lot_ of ring0 metadata into ring1/2, at which point you lost the
whole point of using a different protection domain.
And quite frankly, if you're willing to actually dynamically map all the
ranges and be careful, why use ring1/2 at all? You might as well use ring3
and make the whole thing be a user-mode wrapper. You'd never perform really
well, but for debugging it is acceptable.
Anyway, whatever way you turn, ring1/2 just don't actually _give_ you
anything. Which is, in the end, the _real_ reason nobody uses them.
(I agree, the fact that the x86 paging hardware makes 1/2/3 be equivalent
makes it an even _less_ useful abstraction, but I think it is a mistake to
think that it would be any more useful even if the page tables wasted
precious bits on unnecessary level information).
Multi-ring was a failure. Let it go. The only reason it is making something
of a comeback (Palladium-whatever-it-is-called-today) has no good technical
reasons, and is purely about other things.
Nuno Silva mentioned:
The good people at Cambridge made a (very nice) VMM that exploits ring0/1/3
to let one machine run various kernels independently (the kernels need to
be ported to the xen arch).
Xen itself executes in ring0 and the "guest" operating systems execute in
ring1. User code runs in ring3, as usual. They have linux running under xen
;)
The project's home page is at http://www.cl.cam.ac.uk/Research/SRG/netos/
xen/ and one paper describing the whole thing is here: http://
www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf
And Linus replied:
This is what I alluded to a few lines later - saying that if you move the
driver down to ring1, then you should move _everything_ down to ring1 and
just leave a microkernel at ring0.
Now, I'm not big on microkernels, but a pure virtual machine abstraction is
at least not the distateful academic mental masturbation that we saw in the
80's.
3. Linux 2.6.0-test9-mm4 Released
18 Nov - 24 Nov (18 posts) Subject: "2.6.0-test9-mm4"
Topics: Power Management: ACPI
People: Andrew Morton, Gene Heskett
Andrew Morton announced:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/
2.6.0-test9-mm4/
+ Several fixes against patches which are only in -mm at present.
+ Minor fixes which we'll queue for post-2.6.0.
+ The interactivity problems which the ACPI PM timer patch showed up
should be fixed here - please sing out if not.
Gene Heskett reported, "I've rebooted to various elevators and run each for at
least a day, and for mm3, I'd have to say that the diffs are tolerable, but the
smoothest, most responsive is the deadline version. as still gives an
occasional 20 millisecond stutter, and cfq might be 10 milliseconds. Even as is
a far cry from the near show stopper 15 to 20 second hangs of the performance
in the later 2.4's. Great work guys!"
4. Linux 2.4.23-rc2 Released
19 Nov - 20 Nov (5 posts) Subject: "Linux 2.4.23-rc2"
Topics: Networking, Power Management: ACPI, Version Control
People: Marcelo Tosatti, Samuel Flory, Len Brown
Marcelo Tosatti announced:
Here it goes -rc2.
Important netfilter fixes, several ACPI fixes, few driver corrections
(tulip, tg3, megaraid2), amongst others.
If no problems shows up this should become final in a few days.
Samuel Flory reported, "The amd64 compile is still breaking for me." Marcelo
replied that Len Brown had just sent him a fix for that, and suggested that
Samuel try the current BitKeeper tree. Samuel said he didn't use BitKeeper, and
asked if a particular patch would work; but there was no reply.
5. udev 006 Released
19 Nov - 20 Nov (7 posts) Subject: "[ANNOUNCE] udev 006 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Klibc, USB, Version Control
People: Greg KH, Dave Jones, Arnd Bergmann, Chris Friesen, Robert Love, Olaf
Hering
Greg KH announced:
I've released the 006 version of udev. It can be found at: kernel.org/pub/
linux/utils/kernel/hotplug/udev-006.tar.gz (http://www.kernel.org/pub/linux
/utils/kernel/hotplug/udev-006.tar.gz)
Due to me being on paternity leave for all of November, I've not built up
any rpms, but the spec file is in the tarball, so you can do it if you
wish.
udev is a implementation of devfs in userspace using sysfs and /sbin/
hotplug. It requires a 2.6 kernel to run.
The major changes since the 005 release are:
+ rules now are applied in the proper priority, instead of the order they
showed up in the config files.
+ partitions work properly for all types of rules, instead of just the
LABEL rule type.
+ format modifiers have been added so that the NAME is now dynamic. See
the udev.config file and the man page for more documentation about
these (NOTE, if you have any rules that named partitions in the past,
they will have to be changed to take advantage of these modifiers in
order to work properly now.)
+ subdirectories under /udev are now handled properly.
+ better parsing logic can handle broken files saner.
+ added
+ moved the tests to a test/ directory, along with the beginnings of a
regression test suite.
+ lots of tiny fixes
Many, many thanks to Kay Sievers, for this release, for implementing many
of the new features. I really appreciate it.
Thanks also to Dan Stekloff, Robert Love, Paul Mundt, Chris Friesen, Arnd
Bergmann, and Olaf Hering, all of whom submitted patches for this release.
The full ChangeLog can be found below.
The udev FAQ can be found at: kernel.org/pub/linux/utils/kernel/hotplug/
udev-FAQ (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ)
The udev BitKeeper tree has moved for now, due to kernel.bkbits.net being
off the air to: bk://linuxusb.bkbits.net/udev
Note, to build using klibc, please read the klibc README in the klibc/
directory, and build using 'make -f Makefile.klibc'.
If anyone ever wants a snapshot of the current tree, due to not using
BitKeeper, or other reasons, is always available at any time by asking.
He replied to himself, saying:
Oops, two more major changes I forgot to mention:
+ udev.permissions can now handle wild cards. So the following line would
apply for all ttyUSB devices:
ttyUSB*:::0666
+ I've added two external programs to the udev tarball, under the extras/
directory. They are the scsi-id program from Pat Mansfield, and the
multipath program from Christophe Varoqui. Both of them can work as
CALLOUT programs. I don't think they currently build properly within
the tree, by linking against klibc, but patches to their Makefiles to
fix this would be gladly accepted :)
Thanks a lot to both Pat and Christophe for letting me include their
programs in the main udev release, I appreciate it. And if there's any
other small programs that people want me to bundle within udev, please let
me know.
Dave Jones said, "I just changed my sparse snapshotter to a generic bitkeeper
repo snapshotting script. Daily tarballs of udev as well as a daily unpacked
tree can now also be found at http://www.codemonkey.org.uk/projects/bitkeeper/
udev/" And Greg thanked him.
6. Status Of udev
19 Nov - 20 Nov (14 posts) Subject: "[2.6 patch] document that udev isn't yet
ready (fwd)"
Topics: FS: devfs, FS: initramfs, FS: ramfs, FS: sysfs, Klibc
People: Martin Schlemmer, Greg KH, Adrian Bunk
Adrian Bunk posted a patch to document the fact that udev was not ready yet to
fully replace DevFS. Grek KH asked what Adrian found lacking in udev as of
release 006, and Martin Schlemmer replied:
I am guessing its more driver support, etc. Input devices for instance do
not seem to have any sysfs support yet, and full initramfs support with
udev in there, and udev.permissions setup to get general permissions, etc
right, might make it more advertisable for the masses (no need to maintain
/dev or the initial costs for users not so interested in the workings of
things).
Lets just say from what I have seen from users talking/asking, the initial
setup and seeming 'lack of functionality' is the biggest blocker.
Greg agreed that more driver support would be good, but said there was not much
to be done for that at the udev side of things. But he did say, "I have a
number of patches pending for 2.6.1 that will add more driver support for
sysfs." For initramFS support, Greg also said, "The people keeping the klibc
kernel bk tree have enough support in it to place udev into initramfs. Again,
nothing that udev needs to do for this." Regarding the udev.permissions
situation, Greg said, "We now support wildcards in udev.permissions, forgot to
mention that in the 006 release. So it's just a matter of distros building up a
permissions file that matches their needs." He admitted that "udev still has a
way to go to be solid and mature, but it is usable for the most part :)" And he
concluded that the main task remaining was just for the various distributions
to put in the work to get themselves set up properly to use udev.
7. New cuecat Serio Driver For 2.6
19 Nov - 20 Nov (3 posts) Subject: "[ANNOUNCE] cuecat serio driver for linux
2.6.0-test9"
Topics: FS: devfs
People: Zinx Verituse, Christoph Hellwig
Zinx Verituse announced:
my cuecat driver is ready for testing.
http://zinx.xmms.org/cuecat/cuecat-2.6-0.0.2.tar.gz
It does not use the same output format as the driver floating around for
2.2.x/2.4.x kernels.
It currently requires a patch which changes the order serio drivers are
searched in (the newest driver is searched first now), and adds a function
to walk through the serio port list.
I'm hoping the patch will be included in to the kernel at some point in
time -- It's available separately at: http://zinx.xmms.org/cuecat/
linux-2.6.0-test9-serio.diff
The driver has some pitfalls, such as standing between -all- serio devices
capable of supporting a cuecat, and not just the ones with a cuecat on them
(And it has no way to specify which ports to use), but hopefully I'll think
of a good way to fix that before 0.0.3.
The major number is dynamicly allocated -- If you aren't using devfs, check
/proc/devices.
The minor number for reading all cuecats is 0, and the minor number for
individual cuecats is their [driver-assigned] index plus 1. Recommended
names are:
/dev/cuecat/cuecats
/dev/cuecat/0
/dev/cuecat/1
and so on.
Christoph Hellwig remarked, "A 2.6 input driver shouldn't create devices by
itself but rather use the input core to communicated with the upper drivers
like evdev or moused." Zinx replied:
The input core really is designed for actual input devices, rather than
devices that send out arbitrary largish amounts of data.
The driver would probably be simplified a bit (superficially) by sending
barcodes as events (it would have to be multiple events per barcode -- the
input core has very small communications with userland), but it would
complicate userspace quite a bit, and it's really just not the sort of
thing I'd expect in the input core.
However, if you can think of a way to send the barcodes as a single event,
without changing the userland input core interface, I'm all ears :)
There was no reply.
8. Graphs Comparing Various STP Test Runs For 2.4 And 2.6
21 Nov (1 post) Subject: "[OSDL] Graphical reaim comparisons"
People: Cliff White
Cliff White said:
For those who like data visual, i've created some graphs comparing various
STP test runs. I'm using 2.6.0-test9 and 2.4.22/23-rc1 as comparison
targets. Data updated as new tests run on STP.
Graphs here: http://developer.osdl.org/cliffw/reaim/compares/index.html
Other test runs here:
http://developer.osdl.org/cliffw/reaim/index.html
Reaim test code here: http://sourceforge.net/project/showfiles.php?group_id
=71019
9. SIGTRAP Handling Change From 2.4 To 2.6 Under x86
22 Nov - 24 Nov (7 posts) Subject: "x86: SIGTRAP handling differences from
2.4 to 2.6"
Topics: BSD: FreeBSD, Virtual Memory
People: Daniel Barlow, Linus Torvalds, Paul Mackerras, H. Peter Anvin
Daniel Barlow reported:
There is a difference between 2.4 (tested in 2.4.23-rc2) and 2.6 (tested in
2.6.0-pre9) in the handling of "int 3" inside a SIGTRAP handler.
In 2.4, the handler appears to be recursively re-entered. In 2.6 the task
is killed, along with any other tasks that share the same VM (I'm not
talking about thread groups; I have CLONE_PARENT and CLONE_VM set but not
CLONE_THREAD).
I'm not sure what the correct answer is, if indeed it's specified. For
contrast, in FreeBSD 5.1 I'm told that the signal handler runs to
completion and only on exit is it called again. I would suggest that this
behaviour is probably more in keeping with the principle of least
astonishment, but maybe I astonish in atypical ways.
Linus Torvalds confirmed the change from 2.4 to 2.6, explaining:
The basic change is basically:
+ some signals are "thread synchronous", ie the thread _cannot_ continue
without taking them. Basically, any instruction fault does this, since
just returning would generally cause the instruction to just be done
again, and cause the same fault.
+ the difference between 2.4.x and 2.6.x is that in 2.4.x such a
thread-synchronous instruction will just blow through being blocked. So
even if you block them, they'll still happen. In 2.6.x, trying to block
a thread-synchronous signal will just cause the process to be killed
with that signal ("it can't be delivered, it can't be ignored, let's
just tell the user")
The reason for the change is that the 2.4.x behaviour ends up hiding bugs,
and can cause surprising deadlocks in threaded programs. The 2.6.x
behaviour is "You did something fundamentally wrong, just _die_ now".
Linus went on to explain, regarding the FreeBSD behavior:
This works because "int 3" and "into" is what Intel calls a "trap" as
opposed to a "fault", and as such we _could_ delay handling the signal and
just continue along - when the exception happens, the CPU has already
executed the instruction, and the exception will return to _after_ the
instruction.
However, Linux will refuse to do that because delaying the SIGTRAP is
pointless:
+ you'd get it at the wrong spot, making it pointless
+ the wrong thread could get it if you just consider it a normal signal.
So Linux considers both "int 3" and "into" to be thread-synchronous, even
though they are trivially recoverable. Which means that we have two
options, and two options only: punch through the fact that the signal is
blocked, or just say "that's wrong", and kill it.
NOTE NOTE NOTE!! If you actually _want_ the 2.4.x behaviour of recursive
signal invocation, you should just tell the kernel so: use the SA_NODEFER
flag to sigaction() to tell the kernel that you don't want to defer
recursive signals.
In short, the 2.6.x behaviour is the right one. 2.4.x was a strange
violation of the signal blocking, and I consider the FreeBSD behaviour to
be just bizarre.
And with 2.6.x, if you actually _want_ recursive signal handlers, you can
do so (fairly portably, I might add - putting the SA_NODEFER flag there
should make everybody do the same thing, even *BSD).
Coming back to the kernel change itself, Paul Mackerras remarked on the
particular behavior in question, saying:
Occasionally I have had a situation where the init process hits an
instruction fault (often because of a kernel bug, actually), such as an
access to a bad address. On embedded platforms we sometimes get the
situation where init uses floating-point instructions but the CPU doesn't
have floating point and the kernel has been compiled without FP emulation.
In these situations the system looks like it just hangs, since init is
doing nothing but take the same signal over and over again.
In this case the signal would not actually be set to be blocked or ignored
but would end up being ignored because of the rule that "init gets no
signals it doesn't want". I would prefer to see thread-synchronous signals
kill init if they are not handled, so that at least we get a panic with a
message that says what went wrong rather than the system just spinning its
wheels uselessly.
Linus replied:
Hmm.. Right now the init special case is in the signal _delivery_ path,
which makes it hard to do something like that, since by then we no longer
know/care who sent the signal.
We could move the special case into the send path instead (and then only do
it for "external signals" and not special case init at all for internal
signals).
Hmm.. Looking at the signal sending code, we actually do special-case
"init" there already - but only for the "kill -1" case. If the test for
"pid > 1" was moved into "group_send_sig_info()" instead, that would pretty
much do it, I think.
Feel free to try something like that out. I'm not going to apply it right
now, though ;)
At this point, H. Peter Anvin asked:
Why do we bother special-casing init at all?
It seems the only things init can't ask the kernel to do already for it is
to block SIGSTOP and SIGKILL, and it seems that if you killed (or stopped?)
init you should just get the kernel panic.
If there is anything that should be special-cased, then perhaps it should
be that init should be allowed to block/catch/ignore SIGSTOP/SIGKILL.
Perhaps that should be a capability?
Linus said that the kernel special-cased init...
Because the kernel depends on it existing. "init" literally _is_ special
from a kernel standpoint, because its' the "reaper of zombies" (and, may I
add, that would be a great name for a rock band).
So without init, the kernel wouldn't have anybody to fall back on when a
parent process dies, and would become very very unhappy. Historically it
actually oopsed the kernel.
UNIX semantics literally _require_ that "getppid()" should return 1 if your
parent dies, and that's "current->p_parent->tgid". So we have to have a
parent with pid 1, and thus init really _is_ special.
Yeah, we could have _other_ special cases (we could create another process
that is invisible and has pid 1), but the fact is, _some_ special case is
required. It might as well be "you can't kill init".
10. Status Of Hyperthreading-Aware Scheduler
23 Nov - 25 Nov (13 posts) Subject: "[RFC] generalise scheduling classes"
Topics: Feature Freeze, Hyperthreading, SMP
People: Nick Piggin, Ingo Molnar
Nick Piggin proposed:
We still don't have an HT aware scheduler, which is unfortunate because
weird stuff like that looks like it will only become more common in future.
I made a patch on top of my recent NUMA/SMP scheduling stuff to implement
generalised scheduling classes. With this modification we can allow
architectures to control scheduling policy in a much finer way.
Hyperthreading should be no problem, hierarchical (NUMA) nodes should be
doable as well.
I'm not exactly sure how architecuture specific code is supposed to be
handled, I'll have to have a look at some examples. Basically architectures
build up your own scheduling "classes".
I have supplied a default function to build up the classes if none is
supplied. It builds them so functionality should be similar to the previous
standard local / remote behaviour.
Haven't done much testing yet, just asking for comments. Will these classes
be sufficient for everyone?
Class is struct sched_class in include/linux/sched.h Default classes are
built by arch_init_sched_classes in kernel/sched.c
http://www.kerneltrap.org/~npiggin/w23/. The patch in question is this one:
http://www.kerneltrap.org/~npiggin/w23/broken-out/sched-domain.patch
Ingo Molnar asked, "uhm, have you seen my HT scheduler patches, in particular
the HT scheduler in Fedora Core 1, which is on top of a pretty recent 2.6
scheduler? Works pretty well." Nick replied, "I have seen it. Sorry I know you
have done so and it looks good. I wouldn't be adverse to it being included,
although Linus seems to be. The changes I have made nearly give you it for free
anyway. I just meant that there is not one in Linus' tree yet." Ingo replied,
"yes, because when i wrote it we were already in a feature freeze, and the
changes are intrusive. And being the scheduler maintainer i'm supposed to show
a certain level of self restraint :-)"
11. perfctr 2.6.2 Performance Monitoring Tool Released
23 Nov (1 post) Subject: "perfctr-2.6.2 released"
Topics: Profiling, SMP
People: Mikael Pettersson
Mikael Pettersson announced:
Version 2.6.2 of perfctr, the Linux/x86 performance monitoring counters
driver, is now available at the usual place: http://www.csd.uu.se/~mikpe/
linux/perfctr/
I've now also made .rpm files for the user-space components. Please try
them out and report any glitches.
Version 2.6.2, 2003-11-23
+ libperfctr.so is now installed with proper versioning.
+ ABI control and info structures padded to accommodate some extensions
without breaking application/library binary compatibility. ABI version
incremented to '5'.
+ Driver checks that only P4 models <= 2 use IQ_ESCR0/1.
+ Added support for Fedora Core 1's 2.4.22-1.2115.nptl kernel.
+ Driver compile fix for AMD64 in SMP 2.6 kernels.
12. udev 007 Released
23 Nov (1 post) Subject: "[ANNOUNCE] udev 007 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Klibc, Version Control
People: Greg KH, Marco d'Itri, Dave Jones, Olaf Hering
Greg KH announced:
I've released the 007 version of udev. It can be found at: kernel.org/pub/
linux/utils/kernel/hotplug/udev-007.tar.gz (http://www.kernel.org/pub/linux
/utils/kernel/hotplug/udev-007.tar.gz)
udev is a implementation of devfs in userspace using sysfs and /sbin/
hotplug. It requires a 2.6 kernel to run. Please see the udev FAQ for any
questions about it: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ)
Note:
The CALLOUT rule format has changed. If you have a config file using
this rule, please change it to follow the new order. See the man page
for the proper style.
The major changes since the 006 release are:
+ better parsing of the udev.permissions file
+ string owner and group names in the udev.permissions file will now work
if you build against glibc.
+ fix the CALLOUT rule to look the same as the other rules.
+ add format char for CALLOUT rule output
+ support arguments in callout exec
+ add ability for CALLOUT program to accept format modifiers.
+ drop Makefile.klibc. To build using klibc, use:
make KLIBC=true
+ updated man page documenting new changes.
Again, many thanks to Kay Sievers, for lots of great patches in this
release. Thanks also to Marco d'Itri and Olaf Hering, both of whom
submitted patches for this release.
I think with the ability to capture the output of the CALLOUT rule,
combined with the ability to put format modifiers in the CALLOUT program
string, we now have everything in place to emulate the existing devfs
naming scheme. Anyone want to verify this or not?
The full ChangeLog can be found below.
udev development is done in a BitKeeper repository loacated at: bk://
linuxusb.bkbits.net/udev
Daily snapshots of this tree can be found at: http://www.codemonkey.org.uk/
projects/bitkeeper/udev/. Many thanks to Dave Jones for managing this.
13. Linux 2.6.0-test10 Released; Handoff To Andrew Immanent
23 Nov - 24 Nov (18 posts) Subject: "Linux 2.6.0-test10"
Topics: Disks: SCSI, Real-Time, USB, Version Control
People: Linus Torvalds, John Cherry
Linus Torvalds announced:
it's been almost a month between test9 and test10, with a constant but
diminishing trickle of small patches. The full changes are slightly larger
than I was hoping for, but considering that the patch is barely over 100kB
compressed for a month worth of work, I'm still fairly pleased.
There is still something strange going on that seems to be triggered by
preemption, so for now we suggest not enabling CONFIG_PREEMPT if you want
the highest stability. On the other hand, I'd love to have more testing, so
that we can try to figure out what the pattern is - but please mention
explicitly that you ran with preemption if you have problems.
Quite a lot of the -test10 patches are one-liners and quite trivial. I've
tried to be quite strict in patch acceptance, so the changes are largely
fixes for things that can crash the machine, and they are also of the type
"this can't possibly break anything". But hey, we all know that theory and
practice don't always match ;)
I'm planning/hoping on basically turning this over to Andrew, and let him
decide to make the final 2.6.0 or not. Timing-wise Andrew is apparently
going to be off for a few weeks, so regardless of whether this turns out to
be rock solid or not, we'll have a few weeks of final testing before that
were to happen. Which means that I might still end up making a test11 if
Andrew hasn't come back and we find something that warrants it.
Btw, I'm happy to say that maintainers have been self-policing themselves
quite admirably. Thanks to everybody involved.
The changelog gives more details, but the bigger things here are various
networking fixes, and the SCSI layer being better at refcounting some data
structures (the oopses on USB storage removal that some people have seen
should hopefully be fixed).
[ Btw, I tried to come up with a good name for this release. But the
fact is, that as Scott Adams has so often pointed out, you can't do
much better than "weasel" when it comes to funny. Ever since the
"greased weasel" series of kernel releases I have been stuck for a good
name.
This release is tentatively called the "stoned beaver" release (beavers
are _almost_ as good as weasels, as I'm sure Scott Adams would agree).
If you feel strongly about the issue, please send your votes and ideas
to "[email protected]", I'm sure somebody will find your
insight fascinating.
Thank you in advance. ]
John Cherry posted some stats:
Linux 2.6 Compile Statistics (gcc 3.2.2) Warnings/Errors Summary
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.0-test10 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e
2.6.0-test9 0w/0e 0w/0e 174w/ 0e 12w/0e 3w/0e 217w/0e
2.6.0-test8 0w/0e 0w/0e 178w/ 0e 12w/0e 3w/0e 219w/0e
2.6.0-test7 0w/0e 0w/0e 173w/ 1e 8w/0e 3w/0e 226w/0e
2.6.0-test6 0w/0e 1w/0e 188w/ 1e 12w/0e 3w/0e 260w/2e
2.6.0-test5 0w/0e 2w/0e 205w/ 9e 15w/1e 0w/0e 305w/5e
2.6.0-test4 0w/0e 2w/0e 797w/55e 68w/1e 3w/0e 1016w/34e
2.6.0-test3 0w/0e 2w/0e 755w/66e 62w/1e 7w/9e 984w/42e
2.6.0-test2 0w/0e 1w/0e 952w/65e 63w/2e 7w/9e 1201w/43e
2.6.0-test1 0w/0e 1w/0e 1016w/60e 75w/1e 8w/9e 1319w/38e
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Daily compiles (ia64):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running64.txt
Latest changes in Linus' bitkeeper tree:
http://linux.bkbits.net:8080/linux-2.5
14. Status Of Intel Centrino Drivers
24 Nov (8 posts) Subject: "Intel centrino drivers being withheld?"
Topics: Microsoft
People: Andrew Walrond, Felipe Alfaro Solana
Andrew Walrond asked:
Is anybody liasing, asisting or pressuring Intel wrt centrino wireless
drivers?
It seems to me that it could have been written at least 20 times over
during the time they've supposedly been in development.
This quote from back in March annoys me somewhat:
"The Santa Clara, Calif., chip maker is running Linux drivers in its labs,
but whether or not those drivers make it out of the labs depends on
customer demand, said Scott McLaughlin, an Intel spokesman"
Well, I am demanding, and my patience is running very thin. And Amd look to
be releasing 64bit mobile parts soon, and appear to be very linux friendly.
Am I the only one getting annoyed about this?
Can anybody put my mind at rest, or suggest reasons why Intel may be
reluctant to release the drivers?
Felipe Alfaro Solana said:
No, you're not alone... Although I don't have a Centrino-powered machine at
the moment, the way Intel is behaving is stopping for me for even thinking
on buying a new laptop replacement.
I think this kind of disinterest on Linux Centrino drivers is motivated by
the fact that Microsoft has a strong relationship with Intel and since,
like it or not, Windows has 90% of the desktop market, Intel doesn't see
the motivation to spend a few hundred dollars in building the driver
themselves.
However, they could at least release the documentation. Since the driver
is, I think, going to be GPL'ed, they don't have to fear releasing the
internals of Centrino.
15. New 'Tinderbox' Kernel Debugging Tool
24 Nov (1 post) Subject: "Announce: Kernel Tinderbox (OSDL)"
People: Cliff White
Cliff White announced:
We are pleased to announce Tinderbox-based tool which Linux kernel
developers can leverage to flag defects and regressions in the Linux kernel
and to relate these defects and regressions to recent change sets for the
kernel. The tool is under continuing development and it allows for
distributed testing of the kernel using multiple hardware platforms and
software configurations.
This tool is derived from the Mozilla Tinderbox infrastructure, with much
help from the kind people at Async (http://www.async.com.br/) The Linux
Kernel Tinderbox is a client-server system: The clients do a continuous
cycle of checking out, compiling and testing the latest code integrated
into the source repository. The server provides output as a set of web
pages, showing current changes to the kernel tree and state of the client
machines. Client status is displayed as a set of time-ordered coloured
boxes arranged into columns, one per client.
A prototype for the Linux Kernel Tinderbox is viewable at:
http://tinderbox.osdl.org/showbuilds.pl?tree=linux2.5-bk
Project documentation is located at:
http://www.osdl.org/cgi-bin/osdl_development_wiki.pl?Linux_Kernel_Tinderbox
This project will support any architecture capable of running Linux. It is
our intent to encourage owners of these various hardware platforms to
contribute Tinderbox clients.
The basic kernel tinderbox client is at: http://developer.osdl.org/cliffw/
kernel_tinderclient.tar.gz
Support is via a mailing list: [email protected] http://
lists.osdl.org/mailman/listinfo/kernel-tinderbox
Let us know if you can provide a non-Intel client machine
16. New iswraid Intel Software RAID Driver For 2.4
24 Nov (1 post) Subject: "Announce: "iswraid" (ICH5R) ataraid sub-driver for
2.4.22"
Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, Serial ATA
People: Boji Tony Kannanthanam, James Bottomley, Arjan van de Ven, Jeff Garzik
Boji Tony Kannanthanam announced:
Attached to this email is a patch for a new ataraid sub-driver "iswraid"
(Intel Software RAID) for Kernel 2.4 series. The patch is taken against
Kernel 2.4.22.
The driver (along with the ata_piix driver) can be used with Intel's ICH5R
chipset. You will need the Option ROM to do RAID configuration. This driver
differs slightly from the other ataraid sub-drivers in that it operates on
SCSI block devices rather than the ATA/IDE ones. "iswraid" depends on
"ata_piix" driver to detect and load the SATA disks connected to ICH5R.
Note that the driver is still considered experimental, use at your own
risk.
Thanks to Arjan van de Ven (ataraid), Jeff Garzik (ata_piix) and James
Bottomley (scsi) for patiently answering my questions.
FYI: ata_piix patch for 2.4.22: ftp://ftp.kernel.org/pub/linux/kernel/
people/jgarzik/libata/
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.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.