Kernel Traffic #254 For 19 Mar 2004

By Zack Brown

"Recent research, however, suggests that there is a possibility that this gradual global warming could lead to a relatively abrupt slowing of the ocean's thermohaline conveyor, which could lead to harsher winter weather conditions, sharply reduced soil moisture, and more intense winds in certain regions that currently provide a significant fraction of the world's food production. With inadequate preparation, the result could be a significant drop in the human carrying capacity of the Earth's environment." -- Secret Pentagon Report to the White House (dod-climate.pdf) (See Google News ( )

Table Of Contents

Mailing List Stats For This Week

We looked at 1893 posts in 9249K.

There were 557 different contributors. 266 posted more than once. 220 posted last week too.

The top posters of the week were:

1. Gathering All KGDB Implementations Together

27 Jan 2004 - 11 Feb 2004 (25 posts) Archive Link: "BitKeeper repo for KGDB"

Topics: FS: devfs, Networking, Version Control

People: Tom RiniSam RavnborgDave JonesPavel MachekChris Wright

Tom Rini said:

Since I've been talking with George off-list about trying to merge the various versions of KGDB around, and I just read the thread between Andy and Jim about conflicting on KGDB work, I've put up a BitKeeper repository (If anyone here won't / can't use BitKeeper, I'll happily move over to a repo someone else sets up in something else.) to try and coordinate things.

What's in there right now is Amit's kgdb 2.1.0, without the ethernet patch. There's also all of the changes for PPC and for generic stuffs that I've been doing of late.

What I'll be doing shortly (this afternoon even) is to change from a struct of function pointers, for the arch specific functions, into a set of provided, weak, variants and then allow arches to override as needed.

What I'd like is for someone to move the ethernet bits from the -mm tree into here, and for people to merge the fixes / enhancements that're in their per-arch stubs in the -mm tree into the split design that Amit's version has.

Sam Ravnborg suggested that Tom "ask Dave Jones if he can take nightly snapshots - as he does for sparse and udev." And Dave Jones said, "Hmm, reminds me, the scripts to make those snapshots broke when I migrated to the new box. I'll go fix them up. But yeah, sure. If you want me to add them to the snapshot list, just mail me the bk: url and I'll add it."

Elsewhere, Chris Wright also asked for the BitKeeper URL, and Tom gave it as bk:// Dave replied, "daily diffs vs mainline generated at.."

Elsewhere, Pavel Machek and others started hacking on the code, and at some point Tom summarized his own work:

here's the highlights of what I've done so far:

ChangeSet@1.1510, 2004-01-30 11:14:44-07:00,
  Lots of changes to the serial stub driver.
  In sum, it's got many of the features (but not all) of George
  Anzginer's version (+ fix or two), and fully flushed out and tested
  support for SERIAL_IOMEM.

ChangeSet@1.1509, 2004-01-30 11:10:03-07:00,
  Change *kgdb_serial into kgdb_serial_driver.  We will now have
  only one serial driver.

ChangeSet@1.1508, 2004-01-30 10:44:55-07:00,
  Convert the kgdb ethernet driver over to netpoll.
  Patch from Pavel Machek <>, who warns this probably
  doesn't work.

ChangeSet@1.1505, 2004-01-29 14:30:47-07:00,
  Move all KGDB questions into kernel/Kconfig.kgdb.

ChangeSet@1.1504, 2004-01-27 16:59:06-07:00,
  - PPC32: Add KGDB support for PRePs (part of MULTIPLATFORM).
  - PPC32: Add a choice of baud rate for the gen550 backend.

ChangeSet@1.1503, 2004-01-27 14:44:54-07:00,
  Remove the function pointers from kgdb_ops.
  Most have become kgdb_foo, instead of foo.  The exceptions
  are the gdb/kgdb register fiddling functions.
  kgdb_gdb_regs_to_regs makes my head hurt.

ChangeSet@1.1502, 2004-01-27 11:46:13-07:00,
  Merge by hand to current 2.6 bk.
  --- UNTESTED, x86_64 might be broken ---

ChangeSet@1.1474.149.3, 2004-01-27 11:32:54-07:00,
  - Send a 'T' packet initially, not an 'S' followed by 'p'
  - On PPC32, try to pass in the correct signal back.

I'm mostly happy with the serial changes (and I'll set aside the user console bits from George's version for now), but comments and criticisms would be welcome. And as a reminder the BitKeeper version is bk:// and there's snapshots (thanks Dave!) at

2. Status Of Building IPV4 As A Loadable Module

4 Feb 2004 - 15 Feb 2004 (8 posts) Archive Link: "IPV4 as module?"

Topics: Disks: IDE, Networking

People: Andrey BorzenkovJan-Benedict Glaw

Andrey Borzenkov asked if there were "Any technical reaon IPV4 cannot be built as module? Current kernel barely fits on floopy (even with IDE as module); factoring out IPV4 would allow to reduce size even more." Jan-Benedict Glaw replied that this would be very difficult to accomplish; but there was no discussion of this, and the conversation skewed off into why anyone would use a floppy as opposed to a CD in the first place; and the thread petered out.

3. Linux 2.6.3-rc1-mm1 Released; Huge ISDN Patch Problematic For Inclusion

9 Feb 2004 - 13 Feb 2004 (25 posts) Archive Link: "2.6.3-rc1-mm1"

Topics: Access Control Lists, FS: NFS, Hot-Plugging, Kernel Release Announcement, Networking, Version Control

People: Andrew MortonStian JordetBill DavidsenKarsten KeilDominik KublaTrond MyklebustKai GermaschewskiLinus Torvalds

Andrew Morton announced 2.6.3-rc1-mm1, saying:

Stian Jordet begged him to include Karstein Keil's large ISDN patch ( , but Andrew said:

Boggle. That thing is 1.8MB.

163 files changed, 25877 insertions(+), 22424 deletions(-)

This is the first time that anyone told me that it even existed. How on earth could a patch to a major subsystem grow to such a size in such isolation? When we're at kernel version 2.6.3!

How mature is this code? What is its testing status? What is the size of its user base? Is it available as individual, changelogged patches?

It would be crazy to simply shut our eyes and slam something of this magnitude into the tree. And it is totally unreasonable to expect interested parties to be able to review and understand it.

Could someone please tell me how this situation came about, and what we can do to prevent any reoccurrence?

Stian replied:

I don't know more than this:

But I _do_ know that ISDN is non-working for me with 2.6.x kernels without this patch.

Bill Davidsen also said to Andrew:

We've had this discussion before, haven't we? And all the solutions seemed to involve not having just one person approve things, which isn't likely to change. I don't recall seeing WHEN it was sent to Linus, but clearly something working in 2.4 and not in 2.6 probably shouldn't wait years for 2.8.

I guess the real question is how invasive it is, this isn't the first time I've heard that 2.6 ISDN doesn't work, so it's not as if putting it in -mm would break ISDN, the question is how many other things are touched and might break.

At least it seems to have been widely tested, and is based on something which is in a stable kernel. A maintainer's lot is not a happy one, and you have my sympathy.

Maybe leave it in -mm for a bit and not promote it until people have a chance to really beat on it?

Karsten Keil also replied to Andrew, taking responsible for sending the patch only to Linus Torvalds and not Andrew. He quoted an email he had sent to Linus two weeks before, in late January:

here is a really big patch for ISDN in kernel 2.6. The reason for this big patch is, that I give up to fix the bugs in the new implementation of the obsolate (but currently most used) I4L code. Here are too much changes that never work in this code and since the authors of the new implementations don't have time (here was no real effort since half an year) I started a new port of the well working and stable 2.4 I4L code to 2.6.

Note: The new port is only for the old I4L part, which is common used up to now, not for the new CAPI like interface, which got a new design in 2.5 and should become the successor of I4L, but here are only few cards with CAPI drivers at the moment. This will change soon, but since all distributions depend on the old I4L stuff at the moment, here is a strong need to have a working I4L part in the kernel now. Since new year I got ~500 mails dialing with ISDN problems and kernel 2.6.

This stuff is well tested on my equipment (~40 different cards) and also tested by few other people.

The diff is against the current patch-2.6.2-rc1-bk3 version and should apply clean.

He also now offered some more history of the patch:

Kai Germaschewski was maintaining the ISDN code in 2.4/2.5 and did a big redesign in all parts in 2.5, to prepare ISDN4Linux for the CAPI interface, which should make the I4L interface obsolate (CAPI Common ISDN API, is a common standard for ISDN application), my job was to develop a CAPI hardware driver for passive cards as a replacement of hisax, this is known now as mISDN driver (modular ISDN driver), but this driver supports only few of the cards which are supported by hisax at the moment.

Kai did a good job, but he changed also lot of the old (coming obsolate) code in incompatible ways and his changes never were complete and tested in practice, also not from himself, his changes were only academic, because he left Germany to a study in US and in US he had never access to ISDN. I was aware that he is in US, but I was to stupid to recognise this missing ISDN problem, I thought he had some NI1 line in US too. Since also I was too busy to play with his 2.5/2.6 stuff last year and also nobody else did (I got only compiling fixes during 2.5/6) we run into this situation. After first 2.6 versions came out I got many reports about ISDN and 2.6 issues in last august. Since then I tried to fix the code and get a partial working version in october??, but as I had more time during XMas I did lot of regression test and run into lot of problems with the new code, and even fixing some of these bring up a bundle of new problems. So I ask all remaining I4l developers for help, but nobody take care/has time.

So I make a proposal to start a new 2.4 -> 2.6 port of the old I4L interface, since I know the 2.4 code very well (since most of the driver code is from me) and 2.4 ISDN is known as very stable and has got also some certification from telecomunication authorities.

Nobody of the other I4L developers complain and the result was this patch.

I was preparing new patch last days against current 2.6 version but since I got ill last weekend, it is not finished yet, but hopefully during next houres. I have also BitKeeper running here with a clone of the linux-2.5 tree, so if you prefer a bk diff I can also prepare one (but note, I'm a BK beginner).

Andrew replied, "let's find a way in which I can obtain the latest version and also be kept up to date with any fixes." Karsten replied:

Here are the latest versions, since they are so big only as reference: Linus tree:

Andrew tree:

The result of both patches are the same source, but in Andrews tree some smaller fixes were already included, to avoid rejects I created patches for both trees.


These patches are in sync with I4L cvs (kernel 2.6 branch).

Elsewhere, Dominik Kubla responded to Andrew's initial announcement, saying:

How about including the NFSACL patch from One reason for people to move to 2.6 from 2.4 is that they no longer need to patch the kernel to get ACL support. Unless they want to have ACL support over NFSv3 that is... NFSACL support is quite an argument for Linux in an existing Solaris production environments, so i would like to see it included into the mainstream kernel ASAP (Note: I am not speaking for Andreas and the other people working on the ACL code!). Including it into -mm would give it the necessary exposure.

The patch is available in broken up form at:

And before somebody mentions NFSv4: This is not (yet) an option for production environments.

Andrew Morton said that this patch would have to go through the NFS developers and Trond Myklebust in order to get into his tree.

4. Linux 2.6.3-rc2 Released

9 Feb 2004 - 13 Feb 2004 (24 posts) Archive Link: "Linux 2.6.3-rc2"

Topics: FS: NFS, FS: XFS, Hot-Plugging, I2C, Kernel Release Announcement, PCI, Power Management: ACPI, USB

People: Linus Torvalds

Linus Torvalds announced 2.6.3-rc2, saying:

Uhhuh. There was a bit more pending, so here's a -rc2. Now please calm down, I'd like this to have some time to stabilize..

The rc1->rc2 changes are mostly driver side stuff: PnP update, USB, ACPI, IRDA, i2c, hotplug-PCI and netdrivers etc. But there's a NFSv4 update and soem XFS fixes there too.

And some ARM and sparc updates.

5. CVS Repository For KGDB At SourceForge

11 Feb 2004 (1 post) Archive Link: "CVS repository for kgdb"

Topics: Version Control

People: Amit S. Kale

Amit S. Kale announced:

I have setup a cvs repository for kgdb at sourceforge. Those who plan to contribute to kgdb on a regular basis, feel free become add yourself as developers to this project and checkin changes yourself.

Here is cvs access information for users of kgdb:

kgdb project page includes instructions for accessing kgdb cvs tree. Here is a quick download guide for users of kgdb.

cvs login

cvs -z3 co .

These instructions will fetch latest kgdb development version in current directory. The directory kgdb-2 contains kgdb for 2.6 kernels. For further updates, go to the same directory and run cvs update

6. Status Of Copy-On-Write Filesystem

11 Feb 2004 - 14 Feb 2004 (2 posts) Archive Link: "status of copy-on-write filesystem?"

People: Chris FriesenHerbert Poetzl

Chris Friesen asked:

I'm doing some work where it would simplify things greatly to have copy-on-write semantics available.

I've seen overlayfs and the proposed "-union" option for mount, but there doesn't seem to be anything thats really ready for serious use.

Am I missing something? Is someone working on this?

And Herbert Poetzl replied:

no active work atm, but some info/links maybe

7. BitMover Considering ReiserFS For bkbits Server

11 Feb 2004 - 13 Feb 2004 (15 posts) Archive Link: "reiserfs for"

Topics: FS: ReiserFS, Version Control

People: Erik HensemaTomas SzepeNikita DanilovLarry McVoy

Larry McVoy was considering using ReiserFS for bkbits, the server that hosts the Linux kernel BitKeeper tree, among others; and asked if anyone knew of any reasons against ReiserFS. Erik Hensema replied, "If bitkeeper uses lots of small files and/or many files in a directory, then reiserfs is the FS for you. The FS has been stable for a while now and I currently don't see any reason not to use it." Tomas Szepe added:

During the last two years, we have deployed some 400+ linux firewall machines, all of which use reiserfs 3.6 for all of their filesystems. While some of these boxes live in very wild environments (attics, cellars, under the bed, in public block-of-flats corridors, ...) and we've seen hardware die, there have been zero filesystem problems. I think I can say we're happy with how reiser3 has fared so far.

Sounds a bit like from your favorite marketing department, but still I thought you might want to know.

Elsewhere, Nikita Danilov of the ReiserFS team remarked that "concurrent bk clone of kernel repositories is very good file system stress tool that we are using while debugging reiser4."

No one had anything to say against ReiserFS.

8. Linux 2.4.25-rc2 Released

11 Feb 2004 - 13 Feb 2004 (4 posts) Archive Link: "Linux 2.4.25-rc2"

Topics: Power Management: ACPI

People: Marcelo Tosatti

Marcelo Tosatti announced 2.4.25-rc2, saying:

Here goes -rc2, with small number of fixes and corrections.

Most notably acpi4asus and toshiba ACPI updates.

9. Module Debugging And Documentation

11 Feb 2004 - 13 Feb 2004 (8 posts) Archive Link: "[PATCH] Shut up about the damn modules already..."

Topics: FS: sysfs, Networking

People: Rusty RussellAlex GoddardBas MevissenRussell KingRik van Riel

Rusty Russell posted a patch, saying:

Please apply before 2.6.3.

In almost all distributions, the kernel asks for modules which don't exist, such as "net-pf-10" or whatever. Changing "modprobe -q" to "succeed" in this case is hacky and breaks some setups, and also we want to know if it failed for the fallback code for old aliases in fs/char_dev.c, for example.

Just remove the debugging message which fill people's logs: the correct way of debugging module problems is something like this:

echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe

Rik van Riel suggested putting this in the documentation directory, and Alex Goddard replied:

I couldn't think of, or find a good place to put this, so I put the information in it's own file. I'm only moderately sure I've generated the patch correctly. However, it does apply with patch -p1 to a clean 2.6.3-rc2-bk2 tree, so it should be fine.

The wording is a slightly changed version of what Rusty said at the start of this thread.

Elsewhere, Bas Mevissen asked, "I'm wondering why it is that the kernel is asking for non-existing modules so often. Is it that userspace applications try to access all kinds of devices too often (autoprobing) or it this (wanted) kernel behaviour?" Russell King replied:

Userspace probes the kernel to see if IPv6 is available by trying to create an IPv6 socket.

The correct solution is to fix /etc/modprobe.conf such that it doesn't try to load the module when you don't have it configured:

install net-pf-10 /bin/true

Note that if you alias net-pf-10 to ipv6 before this install line, you need to replace net-pf-10 with ipv6 in the install line.

PS, I notice Arjan's RPM packages don't seem to contain the modprobe.conf manual page... maybe this is what's causing some of the confusion?

PPS, It might also help to either mention in the man page that the above corresponds to the original "alias modulename off" _or_ add "install off /bin/true" into modprobe.conf.dist such that the old alias line works as expected.

10. Support For The PowerMac G5 In 2.6

11 Feb 2004 - 12 Feb 2004 (8 posts) Archive Link: "PPC64 PowerMac G5 support available"

Topics: Version Control

People: Benjamin HerrenschmidtLinus Torvalds

Benjamin Herrenschmidt announced a patch to support the PowerMac G5, saying:

If Andrew prefers keeping it into -mm for a while, I can do a big patch from the bk tree, though this patch is putting other ppc64 stuffs on hold for now, so it shall go in asap (as it would be too nasty to deal with conflicts if other things went in at this point).

Linus: you will probably need an updated radeonfb anyway as I told you. I'll start working on it now and will post a patch separately.

Also, there is currently a known build problem with the zImage wrapper in 2.6.3-rc2, unrelated to this patch, it doesn't prevent the build of the plain vmlinux which is what yaboot uses on the G5.

Finally, ieee1394 triggers an oops in kobject since 2.6.3-rc2, 100% reproduceable for me (and apparently x86 users too), so that's also unrelated to the G5 code.

Linus Torvalds pulled the code into his tree, adding, "I didn't realize that the whole aty/radeon driver was new. Regardless, the bits above look obvious enough, and I'll take the new radeon driver too once it's ready." But shortly after that he posted again, saying:

Actually, at least for me, the _old_ radeon driver works without any modifications at all in text mode. Rock stable image, unlike the new one that needed the clock fixes.

But trying to start X hangs the system hard, which may well be an issue with the old radeonfb. Whenever you have a new driver, I will test.

11. RadeonFB Update

11 Feb 2004 - 13 Feb 2004 (3 posts) Archive Link: "[PATCH] New radeonfb"

Topics: FS: sysfs, Framebuffer, PCI

People: Benjamin HerrenschmidtJames Simmons

Benjamin Herrenschmidt announced:

Here is the new radeonfb. It doesn't remove the old one, just in case, though CONFIG_FB_RADEON now builds the new one.

I also had to add an empty fb_set_suspend() function to fbmem.c (the real implementation is in James tree and will be here soon). That means that Power Management on Apple laptops isn't completely right yet until the core fbdev fixes get in, but that's probably enough for 2.6.3.

The patch is too big to put in the email text uncompressed, so here it is as a bzip2 attachment.

James: The version in your tree is good too, when merging your stuff, you should ignore the few radeonfb diffs and let me deal with them.

Linus: This new driver uses framebuffer_alloc/release, so if you back out the fb sysfs patch, make sure to replace it with wrapper functions that just kmalloc/kfree

James Simmons replied, "No need to back out the sysfs patch since I have new patches coming for the drivers. I just finished out how to deal with non pci devices."

12. Linux 2.6.3-rc2-mm1 Released

12 Feb 2004 - 18 Feb 2004 (33 posts) Archive Link: "2.6.3-rc2-mm1"

Topics: Big Memory Support, Device Mapper, Kernel Release Announcement, Networking

People: Andrew MortonMark HaverkampAnton BlanchardNick PigginJames MorrisZwane Mwaikambo

Andrew Morton announced 2.6.3-rc2-mm1, saying:

About an hour later he replied to himself, saying, "This kernel and also 2.6.3-rc1-mm1 have a nasty bug which causes current->preempt_count to be decremented by one on each hard IRQ. It manifests as a BUG() in the slab code early in boot. Disabling CONFIG_DEBUG_SPINLOCK_SLEEP will fix this up. Do not use this feature on ia32, for it is bust." Anton Blanchard wanted to know who wrote that patch, and how it broke ia32. Andrew said he (Andrew) had written it himself, and that he didn't quite know how it broke ia32. He said, "I spent a couple of hours debugging the darn thing, then gave up and used binary search to find the offending patch." Zwane Mwaikambo found a way to trigger the bug using a particular compilation configuration, and Anton guessed that this might actually be his (Anton's) own fault after all.

Nick Piggin said that neither this kernel nor the previous one would boot on his NUMAQ maching. Zwane Mwaikambo confirmed seeing this problem, as did Mark Haverkamp, who added that for him, "The problem went away when I backed out the highmem-equals-user-friendliness.patch" . Nick confirmed that this fix worked for him as well, and Andrew also said, "Thanks for working that out. James Morris reports that the same patch causes initrd-with-highmem failures. Having enough bugs to care for, I guess I'll drop it."

13. CodingStyle Documentation Update

12 Feb 2004 - 17 Feb 2004 (44 posts) Archive Link: "PATCH, RFC: 2.6 Documentation/Codingstyle"

People: Michael FrankGiuliano PochiniAndrew MortonDavid WeinehallAndries Brouwer

Michael Frank posted an update to the CodingStyle document, which describes the proper appearance and structure that developers should use when adding code to the kernel. Among the changes, there was one allowing 'dont' and 'cant' in kernel comments. Tim Bird and others objected that this made kernel developers appear illiterate, but there was no real discussion on the issue. However, in the next iteration of the document, among other changes Michael took out the part allowing 'dont' and 'cant', and replaced it with, "Kernel developers like to be seen as literate. Do mind the spelling of kernel messages to make a good impression. Do not use crippled words like "dont" and use "do not" or "don't" instead." There was no argument.

Another portion of the document stated that 80 character line-lengths was a hard limit and should not be violated. Giuliano Pochini said of this, "I think this requirement is a bit silly IMHO. How many of us do usually code in a 80x25 terminal screen nowadays?" But Andrew Morton replied:

"I think the 90x25 requirement is silly"

"I think the 100x25 requirement is silly"

And so it goes. You get into an xterm arms race wherein everyone has to make their terminal as wide as the widest guy so anyone can get any work done.

Yes, 80 cols sucks and the world would be a better place had CodingStyle mandated 96 columns five years ago. But it didn't happen.

David Weinehall, Andries Brouwer and others also remarked that they did still use 80-column screen sizes.

Michael posted a couple more iterations of the document, and eventually conversation petered out peacefully.

14. udev 017 Released

12 Feb 2004 (2 posts) Archive Link: "[ANNOUNCE] udev 017 release"

Topics: FS: devfs, FS: sysfs, Hot-Plugging, Klibc, Version Control

People: Greg KHChris Friesen

Greg KH said:

I've released the 017 version of udev. It can be found at: (

rpms built against Red Hat FC1 are available at: (
with the source rpm at: (

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it: (

For any udev vs devfs questions anyone might have, please see: (

Major changes from the 015 version:

In all, there is nothing major in this release, but any current users of udev will want this version for all of the bugfixes if for nothing else.

Thanks a lot to Chris Friesen and Kay Sievers for cleaning up the udevd and udevsend communication path and code so much. I really appreciate it.

Thanks also to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:

Daily snapshots of udev from the BitKeeper tree can be found at:
If anyone ever wants a tarball of the current bk tree, just email me.

15. New kernbench Benchmark To measure CPU Throughput

12 Feb 2004 - 13 Feb 2004 (2 posts) Archive Link: "[ANNOUNCE] kernbench-0.20"

Topics: SMP

People: Con KolivasCliff WhiteMartin J. Bligh

Con Kolivas announced

Martin J. Bligh has for some time been producing results of a benchmark he devised called "kernbench" which is designed to measure cpu throughput, with emphasis on SMP systems.

I set out to make this benchmark a portable and easy to use script for anyone with adequate hardware to perform kernbench, after some feedback from MJB. All the SMP work currently underway inspired this. So here is the first public release:

What it does:

It runs the venerable kernel compile a number of different ways: It cleans and primes a kernel tree with a make defconfig. Then it reads all the kernel source to cache it in ram. Then it will perform a number of different kernel compiles after a warmup run compile the same as the one it is about to test. Then it times the following runs 5 times:

half load: make -j (NR_CPUS/2)
optimal load: make -j (NR_CPUS*4)
maximum load: make -j

Optionally it can also perform a single threaded make, the number of jobs for optimal can be defined, the number of runs can be defined, and any of the default runs can be disabled.

Then it will print out an average of each of the loads with some useful statistics. A sample from an IBM X440 8x1.5Ghz P4HT on linux-2.6.3-rc2 follows:

Average Single Threaded Run:
Elapsed Time 1069.65
User Time 965.894
System Time 117.856
Percent CPU 101
Context Switches 6223.2
Sleeps 23056.4
Average Half Load Run:
Elapsed Time 120.808
User Time 802.428
System Time 92.072
Percent CPU 740
Context Switches 10613.6
Sleeps 26667
Average Optimum Load Run:
Elapsed Time 81.59
User Time 1007.89
System Time 112.36
Percent CPU 1372.6
Context Switches 63006.2
Sleeps 40406
Average Maximum Load Run:
Elapsed Time 82.944
User Time 1012.33
System Time 122.424
Percent CPU 1367.6
Context Switches 44822.2
Sleeps 22161

A few points:

Do not try to run the maximum load on a machine with less than 2Gb ram, as swap thrashing is likely, so the benchmark will not be a cpu throughput one but a vm benchmark (of course you may want to do this too).

It is best run on a non-journalled filesystem to minimise the effects of the journal write-out; although this is probably not greatly important.

If run on a 4x box, the half load will be make -j2. The problem with compiling a kernel at make -j2 is that usually only one job spawns so the results may not be very useful.

Cliff if you want to wrap this into an OSDL benchmark, it may be worthwhile profiling each group of runs together and using the -s option by default as a separate "kernbench-long" to include the single threaded runs.

Thanks, Martin for the idea and feedback. Thanks osdl for the hardware for development, and others for code help.

Cliff White replied, "Thanks! We'll get it into STP asap."

16. UML Update 2.6.3-rc2-1

13 Feb 2004 (1 post) Archive Link: "uml-patch-2.6.3-rc2-1"

Topics: User-Mode Linux, Version Control

People: Jeff Dike

Jeff Dike said:

This patch updates UML to 2.6.3-rc2. This breaks with my usual practice of ignoring test patches. However, when I updated my UML tree, I had forgotten that my stock Linus tree was up to 2.6.3-rc2. I took this as a sign from a higher power that this was Meant To Be.

As well as catching up, there are some bug fixes and cleanups -
modules should now work
worked around a process start time bug
fixed a bug which caused ps to divide by zero

The 2.6.3-rc2-1 UML patch is available at

BK users can pull my 2.5 repository from

For the other UML mirrors and other downloads, see

Other links of interest:

The UML project home page :
The UML Community site :

17. fbdev Patches Too Big And Buggy For Acceptance; Patch Submission Policy

14 Feb 2004 - 16 Feb 2004 (12 posts) Archive Link: "[PATCH] back out fbdev sysfs support"

Topics: FS: sysfs, Framebuffer, Version Control

People: Christoph HellwigLinus TorvaldsAlexander Viro

Christoph Hellwig said:

this patch backs out James' sysfs support for fbdev again. It introduces a big, race for every driver not converted to framebuffer_{alloc,release} (that is every driver but Ben's new radeonfb).

I've left in framebuffer_{alloc,release} as stubs so drivers can be converted to it gradually and once all drivers are done it can be enabled again.

James, what about pushing the 2GB worth of fbdev driver fixes in your tree to Linus so people actually get working fb support again instead of adding new holes? A maintainers job can't be to apply patches to his personal CVS repository and sitting on them forever

Linus Torvalds replied:


That's just how I work: if somebody maintains his own tree and builds up a lot of patches, that's _his_ problem. I'm not going to replace things totally unless there is some really fundamental reason I would have to. And quite frankly, the most common "fundamental reason" is that the maintainer has not done his job.

I want controlled patches that do one thing at a time. Not a 2GB untested dump.

He went on:

These things need to be done in a timely fashion, incrementally, one thing at a time. Anything else does not work.

And btw, for anybody who is impacted by this: you are encouraged to help. If you have a machine that works with some out-of-tree code but does _not_ work with the in-tree code, send a patch that fixes JUST THAT BUG.

Because if James can't trickle them in, somebody else will have to. That's what happened with the new radeon driver.

Alexander Viro offered to help split the patches up into small, clean chunks. There was a small flurry of activity, and the thread petered out.

18. Linux 2.6.3-rc3 Released

14 Feb 2004 - 17 Feb 2004 (34 posts) Archive Link: "Linux 2.6.3-rc3"

Topics: Kernel Release Announcement, Power Management: ACPI

People: Linus Torvalds

Linus Torvalds announced 2.6.3-rc3, saying:

More merges, although most of them are architecture updates. IA64, ppc32/64, SuperH and ARM.

But also some cpufreq, watchdog and ACPI updates.

19. PlatinumFB Driver Updated

15 Feb 2004 (2 posts) Archive Link: "[PATCH] Update platinumfb driver"

Topics: Framebuffer

People: Benjamin Herrenschmidt

Benjamin Herrenschmidt said:

This patch updates the PowerMac-only platinumfb driver to use the new mac-io device infrastructure. It also switch allocation to the new framebuffer_alloc/release and fix a couple of bugs.

I finally found the old hardware to really test it so please apply :)

20. Linux 2.6.3-rc3-mm1 Released

16 Feb 2004 - 17 Feb 2004 (10 posts) Archive Link: "2.6.3-rc3-mm1"

Topics: Hot-Plugging, Kernel Release Announcement

People: Andrew MortonBill Davidsen

Andrew Morton announced 2.6.3-rc3-mm1, saying:

Regarding why the x86 CPU-type selection patches were dropped, Bill Davidsen asked, "Was there a problem with this? Seems like a good start to allow cleaning up some "but I don't have that CPU" things which embedded and tiny systems really would like to eliminate." Andrew replied, "I think it was a good change, and was appropriate to 2.5.x. But for 2.6.x the benefit didn't seem to justify the depth of the change." Bill asked if 2.7 would be an appropriate place to pick it up again, but this question went unanswered.

21. Linux 2.4.25-rc3 Released

16 Feb 2004 (1 post) Archive Link: "Linux 2.4.25-rc3"

People: Marcelo Tosatti

Marcelo Tosatti announced 2.4.25-rc3, saying:

Here goes the third 2.4.25 release candidate.

This release includes a few important net fixes, amongst others.

22. KDB 4.3 Released For Linux 2.6.3-rc3

16 Feb 2004 (1 post) Archive Link: "Announce: kdb v4.3 is available for kernel 2.6.3-rc3"

People: Keith OwensJim Houston

Keith Owens announced:

With many thanks to Jim Houston and Xavier Bru.

Current versions are :

Warning: the 2.6 versions of kdb have had minimal testing. In particular they have not been tested with CONFIG_PREEMPT.

23. Linux 2.6.3-rc4 Released

16 Feb 2004 - 18 Feb 2004 (27 posts) Archive Link: "Linux 2.6.3-rc4"

Topics: Disks: IDE, Kernel Release Announcement

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.3-rc4, saying:

I'm planning on doing the final 2.6.3 tomorrow, so please test this final -rc.

Most notably, this should support ppc/ppc64 out-of-the-box, complete with G5 support (64-bit). Special thanks to BenH who made sure the new radeonfb driver works on a wide variety of hardware (a number of the fixes here relative to -rc3 was making sure the driver works on regular x86 laptops).

Apart from the radeon updates, there's some IDE oops fixes (and cleanups), and a SELinux update.

And yes, document the fact that sparc is no longer f*cked up (both atomics and irq save/restore now work the way they always did everywhere else).

24. KDB 4.3 Released For Linux 2.6.3-rc4

16 Feb 2004 (1 post) Archive Link: "Announce: kdb v4.3 is available for kernel 2.6.3-rc4"

People: Keith Owens

Keith Owens announced:

Current versions are :


The arch specific i386 and ia64 patches have not changed between rc3 and rc4. Use the arch rc3 patches with rc4-common-1.

Warning: the 2.6 versions of kdb have had minimal testing. In particular they have not been tested with CONFIG_PREEMPT.

25. Some Progress On KGDB

17 Feb 2004 - 18 Feb 2004 (10 posts) Archive Link: "[PATCH][0/6] A different KGDB stub"

Topics: Networking, Version Control

People: Tom RiniPavel MachekAmit S. Kale

Tom Rini said:

The following is my next attempt at a different KGDB stub for your tree (and then hopefully into This is against 2.6.3-rc4 + bk-netdev-rc3 (from your tree), and nothing else. This has been tested on PPC32 (KGDB=y/n) and i386 (KGDB=y and allmodconfig) and not at all on x86_64 (no time to build a toolchain yet). Since the last time, I've done the following:

Thre are 6 different patches:

core.patch: All of the non-arch specific bits, that aren't drivers.
8250.patch: The i/o driver for KGDB, via a standard PC uart.
kgdboe.patch: The i/o driver for KGDB, via netpoll.
i386.patch: The i386-specific code, tested.
ppc32.patch: The ppc32-specific code, tested.
x86_64.patch: The x86_64-specific bits, untested.

One last note. For some reason, kgdboe isn't working for me right now. But it doesn't look like it's something specific to the kgdboe driver (Dropping in the -mm one and changing names to match still shows it, and the serial driver is solid) so I'm not sure if it's anything other than my bad luck today. So if nothing else, if someone else could give this a shot and let me know if it works for them...

Andrew asked if everyone agreed on this patch, and Pavel Machek replied, "It is based on Amit's version, so I think answer is "yes". I certainly like this one." But Amit S. Kale said:

I don't agree. I did a few more cleanups after Andi expressed concerns over globals kgdb_memerr and debugger_memerr_expected.

I liked Pavel's approach. Let's first get a minimal kgdb stub into mainline kernel. Even this much is going to involve some effort. We can merge other features later.

Let's create a cvs tree at for kgdb components to be pushed int mainline kernel. This split is to keep current kgdb unaffected. People who are already using it won't be affected.

May I suggest we breakup this task into following tasklets. I have expanded item 1 because Pavel has something that's already close. The rest of the items can be discussed in detail later. These need not be done in this order except for first 2 whose sequence is fixed.

  1. A minimal kgdb stub


    kgdbstub.c full.
    No changes to module.c
    No changes for CONFIG_KGDB_THREAD
    No changes to calling convention of do_IRQ (Needs to be done)
    CONFIG_KGDB_CONSOLE removed i386.patch
    No changes for CONFIG_KGDB_THREAD
    No manipulation of kernel stack before entry into do_IRQ
    No non-source level CFI directives.

  2. Minimal x86_64.patch
  3. Patch to sync ppc kgdb with arch independent stub
  4. Patch to sync other architecture kgdbs with arch independent stub on help from maintainers of those architectures.
  5. KGDB_CONSOLE patch

    This is a must for embedded boards that have only one serial port

  6. gdb automatic module loading

    This may or may not be a separate config option. This patch will include x86_64 support required to enable threads.

  8. i386 thread support
  9. Ethernet interface based on netconsole
  10. ... Any other features

Tom, Pavel and Andrew had various technical comments, and they started hashing out the details.

26. Linux 2.4.25 Released

18 Feb 2004 (1 post) Archive Link: "linux-2.4.25 released"

People: Marcelo Tosatti

Marcelo Tosatti announced:


- 2.4.25-rc4 was released as 2.4.25 with no changes.

27. ftape No Longer A Removable Module

18 Feb 2004 (1 post) Archive Link: "[PATCH] mark ftape un-removable"

People: Christoph Hellwig

Christoph Hellwig said:

I've just grepped over the tree for reamining MOD_INC_USE_COUNT users, and ftape is a really horrible one, it relies on MOD_{INC,DEV}_USE_COUNT in the most horrible places + it's own bookkepping and the <= 2.4 may unload hooks. And although I don't have the hardware I can guarantee it doesn't work as expected.

So let's just remove the module_exit handler and mark it unremovable, if someone wants to fix up ftape later it's fine with me, but it's a really scary driver..

28. Local Root Exploit Found In 2.4 And 2.6; Upgrade Recommended

18 Feb 2004 (9 posts) Archive Link: "New do_mremap vulnerabitily."

People: Raphael RigoUlrich KeilLinus TorvaldsChris Friesen

Raphael Rigo said:

Since it seems nobody posted it yet (at least I hope so) :

It is a local root exploit.

Ulrich Keil replied:

There was also a Proof-of-concept exploit released:

Linus Torvalds said, "Fixed in 2.6.3 and 2.4.25 (and, I think, vendor kernels), please upgrade if you allow local shell access to untrusted users." Chris Friesen pointed out:

There is still a call to do_munmap() that does not check the return code, called from move_vma(), which in turn is called in do_mremap().

Can that call ever fail and cause Bad Things to happen?

Linus replied, "Yes it can fail, and no, bad things can't happen. We could return the error code to user space, but on the other hand, by the time the munmap fails we would already have done 90% of the mremap(), so it doesn't much help user space to know that the old area still has a vma, but no pages associated with it."

29. Netlink-Based Notifications For SELinux Kernel Events

18 Feb 2004 (7 posts) Archive Link: "[SELINUX] Event notifications via Netlink"

People: James MorrisDavid S. Miller

James Morris said:

This patch against 2.6.3 implements Netlink based notifications for SELinux kernel events. This will allow SELinux userspace components to maintain synchronization with kernel state.

For example, a userspace AVC (Access Vector Cache, the component that makes access control decisions) is being implemented for use by Security Enhanced X and SE-DBUS. These applications will request access control decisions from the usersapce AVC, which will relay and cache decisions from the kernel AVC.

When the security policy is reloaded or the enforcing mode is changed in the kernel, the userspace AVC can be notified and take appropriate action (e.g. flush cache).

After some technical discussion and fixes, David S. Miller accepted the patch.

30. KDB 4.3 Released For Linux 2.4.25

18 Feb 2004 (1 post) Archive Link: "Announce: kdb v4.3 is available for kernel 2.4.25"

People: Keith Owens

Keith Owens said:

KDB (Linux Kernel Debugger) has been updated.

Current versions are :


The ia64 patch has changed slightly since kdb-v4.3-2.4.25-rc1, due to more clean ups in the base arch/ia64/kernel/mca.c file. Apart from that, the only changes are to the target kernel name in the change logs.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.