Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #207 For 2 Mar 2003

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1847 posts in 10294K.

There were 444 different contributors. 227 posted more than once. 178 posted last week too.

The top posters of the week were:

1. Linux 2.5.62 Released

17 Feb 2003 - 27 Feb 2003 (94 posts) Archive Link: "Linux v2.5.62"

Topics: Kernel Build System, SMP, Version Control

People: Linus TorvaldsChris Wedgwood

Linus Torvalds announced 2.5.62:

Hmm.. Mostly lots of small updates, although the merge with Andrew included the RCU dcache patches from IBM that he has carried along for a while (ie fairly fundamnetal, but also very well tested).

ARM, PPC, PPC64, alpha, kbuild.

Oh, and as a sign that 2.6.x really _is_ approaching, people have started sending me spelling fixes. Kernel coders are apparently all atrocious spellers, and for some reason the spelling police always comes out of the woodwork when stable releases get closer.

Chris Wedgwood reported that all kernels after 2.5.59, and possibly earlier, would spontaneously reboot under heavy loads. The 2.5.59-mjb4 seemed pretty stable to him though. Linus asked, "It would be interesting to hear exactly when the trouble started. And if plain 2.5.59 does it (which is unclear from your description), but 59-mjb4 doesn't, then that's an interesting data point." Chris clarified that 2.5.59 did have the problem, and 2.5.59-mjb4 did not. However, a bit later on, he said:

After much testing, which is still in progress it would seem that *maybe* mjb4 does have the problem too, although it's much harder to hit. Please note that this is a single data point where for other kernels I have two or more occurrences of spontaneous reboots.

I've been checking older kernels... it would seem the problem first occurs in 2.5.53 (that is 2.5.53 through 2.5.62-bk all reboot for me). 2.5.51 doesn't appear to and thus far neither does 2.5.52.

I say thus far, because the problem usually appears after about 15 minutes of compiling, but it sometimes takes a little longer. I'm running 2.5.52 now and after 45 minutes it's still going.

As to what difference it might be between '52 and '53 I have no idea. I had a quick look and the changes there are considerable.

I've tried different compiles, with and without preempt, and and without IO-APIC and trimming down the kernel...

He posted in reply to himself shortly thereafter, to say that 2.5.52 did show the behavior after all. He said, "I'm back to 2.5.51 and I'll beat it hard and see what happens. I guess until I (or someone else who sees this) can get some concrete data points you'll have to ignore this." Linus had a suggestion for how to track down the bug. He said, "if it was getting hard to trigger with 2.5.52 too, things might be getting hairier and hairier.. If it becomes hard enough to trigger as to be practically nondeterministic, a better approach might be to just go back to -mjb4, and even if it is still there in -mjb4 try to see which part of the patch seems to be making it more stable. That might give us more clues, and it's a much smaller problem set than going arbitrarily far back in the 2.5.x series." He added in reply to himself:

Btw, this is particularly true if it takes you potentially hours to test something like 2.5.51 for stability, but you can reboot 2.5.59 at will in ten minutes.

In that case, you can test several vrsions of "2.5.59 + partial -mjb patches" much more quickly than you can walk backwards in 2.5.x, and try to pinpoint the "this part of -mjb makes it much less likely to reboot".

Also, with the -mjb patch there are some new configuration options. For example, CONFIG_100HZ on -mjb has very different behaviour than a plain 2.5.59 kernel that defaults to 1kHz timer clock, and maybe the reason -mjb seems more stable is that you may have selected a configuration option that made -mjb act differently.

Regardless, it would be very interesting to hear what the -mjb split-down results would be. Even if the answer might be "at 1kHz timer it is unstable, at 100Hz it is stable" (and if that were to be it, then you'd have to walk backwards to 2.5.24 to find the old 2.5.x kernel that had a slow tick rate).

Chris reported that 2.5.51 also showed the spontaneous reboot, although it took almost an hour to induce. At this point Linus said, "Ok, I wrote up this doublefault task-gate handler which has gotten some very very minimal testing, and which is probably totally buggered on SMP machines etc, but which has caught at least one double-fault on one of my test-machines (which I forced to double-fault by making %esp contain an invalid value in kernel mode)." He thought it might give Chris some useful debugging information just before the crash.

A bunch of people posted tons of debugging output, and it seemed as though a lot of headway was made toward finding various problems in the kernel, but Chris' spontaneous reboots remained elusive.

2. Configuration Option For All SCSI Low-Level Drivers

18 Feb 2003 - 19 Feb 2003 (9 posts) Archive Link: "[PATCH 2.5.62]: 2/3: Make SCSI low-level drivers also a seperate, complete selectable submenu"

Topics: Disks: SCSI

People: Bill DavidsenChristoph HellwigMarc-Christian Petersen

Marc-Christian Petersen posted a patch to make all SCSI low-level drivers a separate configuration submenu, so they could all be disabled at once. Christoph Hellwig said people could already choose to disable CONFIG_SCSI, but Bill Davidsen replied, "Isn't that going to disable all of SCSI? I think the intention may be to drop hardware drivers and just use ide-scsi, although I might be misreading the original intent. There are a fair number of tape/CD/DVD devices out there which you might run SCSI. I many cases will run SCSI or not at all."

3. Configuration Option For All Ethernet 1000Mbit NICs

18 Feb 2003 - 19 Feb 2003 (4 posts) Archive Link: "[PATCH 2.5.62]: 1/3: Make Ethernet 1000Mbit also a seperate, complete selectable submenu"

Topics: Networking

People: Jeff GarzikMarc-Christian Petersen

Marc-Christian Petersen posted a patch to make Ethernet 1000Mbit support a separate configuration submenu, so all 1000 Mbit NICs could be disabled at once. Jeff Garzik said he'd apply the patch, though he said he'd prefer a different name. Marc-Christian had used "NET_ETHERNETGBIT", and Jeff suggested "NET_GIGE" or something short like that.

4. Kernel Panics In Morse Code

18 Feb 2003 - 19 Feb 2003 (6 posts) Archive Link: "[PATCH] morse code panics for 2.5.62"

People: Tomas SzepeVojtech Pavlik

Tomas Szepe posted support for displaying kernel panics in morse code, for 2.5.62; he said:

5. Kernel Errata List

18 Feb 2003 - 21 Feb 2003 (3 posts) Archive Link: "[ANNOUNCE] 2.5 kernel errata list"

Topics: Bug Tracking

People: Paul LarsonRik van Riel

Paul Larson announced:

Based on a suggestion and several people saying they would find it useful, I'm keeping a kernel errata page on the Linux Test Project website at

I'll try to maintain a list of known fixes for blocking problems with the most recent kernel on this page. By "blocking", I mean anything severe enough to keep you from testing the kernel (can't compile, panic on boot, catches your hair on fire, etc). This is _not_ a replacement for the bug tracking system. I won't put anything here that doesn't have a fix or a workaround. So if you're looking for an exhaustive list of problems for a given kernel, look at bugme, but if all you want is a list of known fixes to get you up and running quickly, the errata list should give you a quick and easy answer.

If you have any suggestions to make this more useful or if you see anything I've missed, please let me know.

Rik van Riel asked how this was different from the Bugzilla database already in place, and Paul explained, "The bugzilla database tracks problems, whether they are fixed or not. The errata list aims to be a quick (hopefully short) list of known fixes to problems. Bugzilla also tracks all types of problems where the errata list will usually only contain fixes to major, blocking problems. Basically I'm trying to keep a list that will help people quickly find the diffs against releases that will help them get up and running enough to test with."

6. Accessing BitKeeper Without BitKeeper

19 Feb 2003 (1 post) Archive Link: "accessing bitkeeper without bitkeeper"

Topics: Version Control

People: Pavel Machek

Pavel Machek announced:

With attached patch to CSSC (, and

rsync -zav --delete linux-2.5

you can download local copy of whole linux-2.5 repository, and you can access it, too.

There was no reply.

7. Documentation For The Kernel Bug Database

19 Feb 2003 (1 post) Archive Link: "[ANNOUNCE] Kernel Bug Database documentation on-line"

People: John Bradford

John Bradford announced:

I've put some extensive documentation for the latest version of my Kernel Bug Database online at:

The latest version of the Kernel Bug Database is at the usual location:

Main new features since version 2.0:

I've written the code for automatic testing of patches to see whether they will apply to various kernel versions, but it will not be enabled until the machine that hosts is replaced with a faster one with more disk space :-).

8. IPMI Driver Version 18 Released

19 Feb 2003 (1 post) Archive Link: "IPMI driver version 18 release"

People: Corey Minyard

Corey Minyard announced:

I found a few stupid bugs in the IPMI driver dealing with certain error cases, and this also contains the documentation updates that I have not sent to Linus enough times to be included yet :-).

The 2.5 version is attached. The 2.4 version is at:

9. FUSE (Filesystem In Userspace) 1.0 Released

20 Feb 2003 (1 post) Archive Link: "[ANNOUNCE] Filesystem in Userspace (FUSE) 1.0 stable release"

People: Miklos Szeredi

Miklos Szeredi announced:

FUSE lets you write your very own filesystem, as an ordinary program. It has a simple yet comprehensive interface, and provides an easy way to create a virtual filesystem for just about any application.

Example applications include: automatic CD changer fs, remote filesystems for handhelds, filesystem view for databases, etc...

FUSE currently works on all 2.4.x kernels (up to 2.4.20 and possibly later). Installation is simple, no kernel patching or recompilation is needed. Documentation for the interface and example programs are provided in the package.

You can download the latest version from:

10. /proc Reorganization And Speedup

20 Feb 2003 - 24 Feb 2003 (28 posts) Archive Link: "[patch] procfs/procps threading performance speedup, 2.5.62"

Topics: Big O Notation, FS: procfs, Version Control

People: Ingo MolnarLinus TorvaldsOliver XymoronAlexander Viro

Ingo Molnar announced:

Lots of people have requested that threads should show up in /proc again, to be able to look at per-thread CPU usage, activity, and generally, to ease the debugging of threaded apps.

the main problem with threads in /proc is that there's a big slowdown when using lots of threads. Here are some runtime numbers in seconds, under 2.5.62, on a 525MHz PIII box:

   # of threads (*):  1000    2000    4000    8000    16000
   ps                 0.77    1.52    3.13    6.44    13.81
   ps -axm            0.93    1.85    3.78    7.73    18.37
   top -d 0 -n 0      0.75    1.53    3.23    7.60    22.12

[ (*): the system is completely idle, all threads are sleeping. Overhead is combined system and userspace overhead measured via 'time'.]

ie. the overhead is really massive, eg. with 16K threads running, procps is basically unusable for any administration or debugging work. And there are users that want 50K or more threads. So clearly, this state of procfs and procps is unacceptable - who would use 'top' to check a system's state if a single screen-refresh takes 22 seconds?!

in the above timings, only 'ps -axm' is actually displaying every thread, all other commands produce only a few lines of output. The reason of the overhead is two-fold:

1) there's significant kernel overhead in reading large /proc directories, the overhead of many readdir()'s is O(N^2). The main overhead is in get_pid_list(), which has to loop over an increasing number of threads to find the next intended batch of PIDs.

to fix this overhead i've introduced a 'lookup cursor' cookie, which is cached in filp->private_data, across readdir() [getdents64()] calls. If the cursor matches then we skip all the overhead of skipping threads. If the cursor is not available then we fall back to the old-style skipping algorithm.

2) procps is forced to parse every thread in /proc to build up accurate 'process CPU usage' counters. The parsing and accessing of every /proc/PID/stat file is necessary because CPU statistics are scattered across all threads.

the fix for this is two-fold. First, it must be possible for procps to separate 'threads' from 'processes' without having to go into 16 thousand directories. I solved this by prefixing 'threads' (ie. non-group-leader threads) with a dot ('.') character in the /proc listing:

 $ ls -a /proc
 .      16994   .17078  412  7          execdomains  locks       stat
 ..     16995   .17079  460  8          filesystems  meminfo     swaps
 1      17031   .17080  469  9          fs           misc        sys
 16864  17033   .17081  5    92         ide          mounts      sysvipc
 16866  17034   .17082  515  buddyinfo  interrupts   mtrr        tty
 16867  17072   17113   516  bus        iomem        net         uptime
 16946  .17073  2       517  cmdline    ioports      partitions  version
 16948  .17074  3       518  cpuinfo    irq          profile     vmstat
 16949  .17075  390     519  devices    kcore        scsi
 16989  .17076  4       520  dma        kmsg         self
 16992  .17077  400     6    driver     loadavg      slabinfo

the .17073 ... .17082 entries belong to the thread-group 17072.

The key here is for procps to be able to parse threads without having to call into the kernel 16K times. The dot-approach also has the added benefit of 'hiding' threads in the default 'ls /proc' listing.

the other change needed was the ability to read comulative CPU usage statistics from the thread group leader. I've introduced 4 new fields in /proc/PID/stat for that purpose, the kernel keeps those uptodate across fork/exit and in the timer interrupt - it's very low-overhead.

the attached patch, against 2.5.62-BK, implements these kernel features.

Alex Larsson has modified procps for these new kernel capabilities, the new procps package (or the patch against upstream procps) can be downloaded from:

here are the performance measurements (with stock procps+procfs numbers in paranthesis)

   # of threads:       1000     2000     4000      8000      16000
   ps                  0.02     0.03     0.03      0.03       0.04
                      (0.77)   (1.52)   (3.13)    (6.44)    (13.81)

   ps -axm             0.89     1.72     3.40      6.87      15.57
                      (0.93)   (1.85)   (3.78)    (7.73)    (18.37)

   top -d 0 -n 0       0.11     0.12     0.12      0.13       0.16
                      (0.75)   (1.53)   (3.23)    (7.60)    (22.12)

eg. with 16K threads running in the background, a single 'top' screen-refresh got more than 130 times faster. A simple 'ps' got more than 340 times faster ... Even the 'ps -axm' (which displays all threads) command got faster, due to the pid-cursor. But even with just 1000 threads running a simple 'ps' is 30 times faster, and top refresh is 6 times faster.

another advantage of this approach is that old procps is fully compatible with the new kernel, and new procps is fully compatible with old kernels. Plus everything is still encoded in the ASCII namespace, no binary interfaces are used.

the patch works just fine on my boxes. (the patch is also included in the threading backport, in the rawhide 2.4 kernel, and has been in use for a couple of weeks already.)

Linus Torvalds replied:

Well, part of the problem (I think) is that you added all the threads to the same main directory.

Putting a "." in front of the name doesn't fix the /proc level directory scalability issues, it only means that you can avoid some of the user- level scalability ones.

So to offset that bad design, you then add other cruft, like the lookup cursor and the "." marker. Which is not a bad idea in itself, but I claim that if you'd made the directory structure saner you wouldn't have needed it in the first place.

It would just be _so_ much nicer if the threads would show up as subdirectories ie /proc/<tgid>/<tid>/xxx. More scalable, more readable, and just generally more sane.

Other folks had similar suggestions, but Ingo replied that Alexander Viro had said that the /proc/<tgid>/<tid>/xxx solution could not be done sanely, and was fraught with security problems. Linus said it was no different than the current situation, except the information would show up in a different place. And Oliver Xymoron remarked, "Well perhaps that was just Al's way of saying the current stuff is broken too."

There was a bit more discussion, but folks were unable to agree on the proper way to go about things.

11. Status Of 8x AGP Support

20 Feb 2003 (3 posts) Archive Link: "8x AGP under linux?"

Topics: PCI

People: Casey LancourDave JonesMatthew E Tolentino

Casey Lancour asked, "Does anyone know the status to 8x agp support under linux? I am using the Granite bay 7205 chipset and I cant get my geforce4 card to use agpgart or nvidia's agp support, it seems to be defaulting to pci mode (not even using 4x agp)." Dave Jones replied, "For 2.4, there is a patch for that chipset (that didnt get merged to mainline). 2.5 has it supported out-of-the-box, but likely breaks with your binary nvidia driver." Matthew E added, "Casey, I can send you the 2.4 patch for the E7205/E7505 chipsets that I posted a while back that also incorporates AGP 3.0 support if you are interested. However as Dave mentioned, I did have quite a bit of trouble with the Nvidia 8x binary only driver, so ymmv...."

12. Consolidating Multiple ioctl Handler Code

20 Feb 2003 - 24 Feb 2003 (13 posts) Archive Link: "ioctl32 consolidation"

Topics: Feature Freeze, Ioctls, Version Control

People: Pavel MachekJeff GarzikArnd BergmannMartin SchwidefskyStephen RothwellDavid S. MillerAndi Kleen

Pavel Machek posted a patch and said:

Currently, 32-bit emulation in kernel has *5* copies, and its >1000 lines each. Plus, locking of all but x86-64 architectures is broken (I'm told by andi ;-).

So, here's patch that starts sharing sys32_ioctl() [as a first step], which should rmove locking problems.

I've done the work for x86-64 and sparc64; if it looks good I'll attempt to do other architectures. [Unless maintainers prefer to do it themselves: I don't have easy access to 64-bit machines besides hammer.]

Jeff Garzik replied:

Yes :/ Consolidating all these copies into a single layer has been a "project to be" for quite some time.

I do not know if it is too late in 2.5.x to begin this work, however. We _are_ in a feature freeze... I suppose it is up to the consensus of arch maintainers, because it [obviously] does not affect ia32.

Pavel replied that Andi Kleen had asked him to do the work; and Pavel asked David S. Miller and other architecture maintainers what they thought about it. David said he was totally fine with it. Arnd Bergmann also replied:

For s390, I'd love to see progress in the consolidation. Feel free to submit changes for arch/s390x/kernel/ioctl32.c directly, like Stephen Rothwell does for the syscall32 consolidation. Of course, Martin has the last word here, but I'm rather sure he agress with me in this.

If you want access to an s390x system, you can probably get access to one at or install the hercules emulator. I try to keep working kernel tree at, but the 32 bit emulation has been broken for most of 2.5.

Note that for any ioctls that pass pointers, you will need special massaging for the high order bit of the user space pointer, because s390 only has 31 bit pointers, not 32 bit.

Martin Schwidefsky added, "Everything that moves out of arch/s390x/kernel/ioctl32.c has my blessing. I am currently working on the 31 bit emulation. It almost works again and I will include the changes in the next patch set."

13. Status Of SpeedTouch USB Modem Driver

20 Feb 2003 - 21 Feb 2003 (3 posts) Archive Link: "Alcatel SpeedTouch USB Modem"

Topics: Modems, SMP, USB

People: Duncan SandsSteve Parker

Steve Parker noticed that the driver for the Alcatel SpeedTouch USB Modem was now included in the 2.5 kernel. This surprised him, because there had always been a lot of problems with the kernel driver as opposed to the user-space version. He'd been using the user-space version for over a year with no problems; and asked what the status was on the kernel driver.

Duncan Sands replied, saying he was the maintainer. Regarding the historical troubles, Duncan said:

These problems are being resolved. Most of them have already been resolved. The cvs version for 2.4, which you can find at

is quite stable. In theory it can still crash (due to various micro races), but in practice it does not. In any case, these micro races will be fixed soon. The 2.5 version, which is essentially identical to 2.4 cvs, doesn't work very well in the current 2.5 kernel. I don't know why. I am working on it.

I have nothing against the user space version, which I used for many moons. The kernel version is certainly much lighter weight - less CPU, less memory. Whether this matters for you depends on your machine/needs. My machine is slow, and I need all the CPU time I can get!

He added:

The main disadvantages of the kernel mode driver were:

  1. unstable, and very unstable on SMP/preempt boxes
  2. required running the closed source speedmgmt program
  3. required compiling your own kernel

The driver is in 2.5, and is heading for inclusion in 2.4, so I expect that in the future most distributions will ship with the speedtch module compiled. Thus (3) is going away.

The cvs version of the user space driver contains a patch for modem_run which enables it to be used with the kernel driver in place of speedmgmt (use the -k flag). Thus (2) has already gone away.

As I mentioned, (1) is (almost) dealt with.

Steve replied, "Thanks for that, Duncan. Lightweight and stable certainly sounds good; I look forward to the project being ready."

14. Some Users Unhappy With Kernel Code Written Under NDA

20 Feb 2003 - 21 Feb 2003 (23 posts) Archive Link: "Linux kernel rant"

Topics: BSD: FreeBSD, BSD: OpenBSD, Disks: IDE, Disks: SCSI

People: James BuchananJeff GarzikRik van RielTomas Szepe

James Buchanan complained:

I am just wondering if anyone thinks the same way. I am thinking about going to BSD for good because of these things.

Linux is starting to include code written under non-disclosure agreements and other nasties, and for me this kills the magic of Linux. Doesn't stop anyone from reading the code, but it's the principle that counts.

I don't know. I feel Linux has lost the plot. It's supposed to be getting bigger and better (well, at least bigger -- to borrow words from Andy Tanenbaum. He was referring to the onslaught of "improvements" to Minix being submitted, but now this applies to Linux as well.)

True, there are lots of nice improvements and binary only drivers cannot use ksysms, so I've read somewhere. (True? Nice.) But NDAs? Come on, where do you get off on that?

Jeff Garzik pointed out that this situation had been going on for ages, and that FreeBSD also had drivers written under NDA. He said, "It's the way of the hardware world. If you don't get an NDA, you don't get open source support." Tomas Szepe also said BSD developers had to sign NDAs, but James replied, "Theo De Raadt refuses to sign them." Jeff replied:

OpenBSD contains drivers _obviously_ written under NDA, just like every other free BSD. Theo probably imported these drivers from FreeBSD, I would guess.

I pay attention to net drivers in all the BSD OS's, so if you know net drivers and their vendors, these things are obvious ;-)

Rik van Riel pointed out that Theo De Raadt didn't have the same hardware support, precisely because he refused to sign the NDAs. He quipped, "Of course, you're free to run openbsd on any machine that supports it. I'm sure you'll be able to put one together from various supported pieces of hardware."

Elsewhere, James said he didn't use any drivers written under NDA, and Rik and Tomas pointed out that it was virtually impossible to find IDE or modern SCSI drivers to satisfy that condition. Close by, Jeff asked James to post the list of kernel drivers he used, so he and others could point out the portions written under NDA.

15. Kernel 2.5.62-mm3 Released

23 Feb 2003 - 26 Feb 2003 (18 posts) Subject: "2.5.62-mm3"

Topics: FS: sysfs, Virtual Memory

People: Andrew MortonDave McCracken

Andrew Morton announced:

16. NTFS 2.1.1a For 2.4 Released

24 Feb 2003 (3 posts) Archive Link: "[ANN] NTFS 2.1.1a for kernel 2.4.20 released"

Topics: FS: NTFS, Version Control

People: Anton Altaparmakov

Anton Altaparmakov announced:

NTFS 2.1.1a is now released for kernel 2.4.20. This fixes both the reported hangs and improves the handling of compressed files so that the warning message people keep reporting is now gone. (Note the hangs were specific to the 2.4.x kernel ntfs versions. 2.5.x kernel ntfs versions are not affected.)

Download the patch from:

Or get from our BK repository (which is at the current BK linux-2.4 version, i.e. 2.4.21-pre4-bk):


17. Possible Violation Of GPL

24 Feb 2003 (1 post) Archive Link: "[ANNOUNCE] interesting new vendor kernels on"

Topics: FS: NFS, Virtual Memory

People: Christoph Hellwig

Christoph Hellwig announced:

I'd like to annouce that there are two new interesting vendor kernels available on the kernelnewbies vendor kernels page ( Both unfortunately don't use the traditional organization of multiple pathes agains ta base kernel release but were tarballs that I had to diff against known kernel release.

In detail they are:

  1. The NEC kernel for their IA64 machines.

    Interestng here are their VM changes and a NFS extension for shared storage called GFS (it's different from Sistina's filesystem of the same name)

  2. The kernel from TimeSys 3.1 demo release

    This one is really interesting, it features a completly new scheduler architectured around hooks to their propritary real time kernel and heavyweight mutexes (e.g. with priority inheritance) that replace Linux spinlocks. These architecture probably violates the GPL, but I'd like to hear some more opinions on people who actually read the code before bothering TimeSys about this issue.

18. Free Driver Petition

24 Feb 2003 (1 post) Archive Link: "Free Drivers Petition"

People: Harry Lepper

Harry Lepper suggested, "Please sign up the Free Drivers Petition at <>."

19. Mailing List Statistics

24 Feb 2003 - 25 Feb 2003 (11 posts) Archive Link: "statistics for this mailinglist"

Topics: FS: procfs, SMP, Version Control

People: Folkert van HeusdenJ.W. SchultzLarry McVoyMartin J. BlighDavid S. MillerIngo MolnarMaciej SoltysiakChris WedgwoodLinus TorvaldsAlan CoxAndrea ArcangeliOsamu TomitaJeff GarzikWilliam Lee Irwin IIIAndrew MortonZwane Mwaikambo

Folkert van Heusden posted some statistics for the linux-kernel mailing list:

Overall statistics
First message was written at: 2003/02/18 13:09:03
Last message was written at: 2003/02/19 23:54:45
Total number of messages: 1595
Total size: 8704KB
Total number of writers: 369
Number of people who wrote >1 message: 196
Total number of lines: 141544
Average lines per message: 88
Total header length (lines): 76324
Average header length (lines): 47
The header is on average 53.92% of the message (lines).
The header is 46.05% bytes in size of the total.
Average number of bits information per byte: 0.7501
Total number of unique user-agents: 142
Total number of unique organisations: 44
Total number of unique top-level domains: 51

Low   : 0.00%
Normal: 1.38%
High  : 0.00%
(the rest is unspecified)

Top writers
   | # msgs|av size| total|time| e-mail address
  1]     76|   4785| 355KB|0854| Alan Cox <>
  2]     59|   5692| 328KB|1428| "Martin J. Bligh" <>
  3]     57|   3410| 189KB|1124| "David S. Miller" <>
  4]     53|  16844| 871KB|1937| Osamu Tomita <>
  5]     42|   5531| 226KB|1133| William Lee Irwin III <>
  6]     42|   5055| 207KB|1415| Andrew Morton <>
  7]     35|   4743| 162KB|1334| Linus Torvalds <>
  8]     32|   3391| 105KB|1441| Jeff Garzik <>
  9]     28|   5374| 146KB|1437| Andrea Arcangeli <>
 10]     26|   3938|  99KB|1540| Ingo Molnar <>

Top subjects
   | # msgs|av size| total|time| subject
  1]    150|   4476| 655KB|1255| Minutes from Feb 21 LSE Call
  2]     34|   4474| 148KB|1339| doublefault debugging (was Re: Linux v2.5.62 --- spontaneous
  3]     28|   4249| 116KB|1154| [patch] procfs/procps threading performance speedup, 2.5.62
  4]     23|   3795|  85KB|0840| Longstanding networking / SMP issue? (duplextest)
  5]     23|   3507|  78KB|1609| Linux kernel rant
  6]     21|  10297| 211KB|1216| AGP backport from 2.5 to 2.4.21-pre4
  7]     21|   3944|  80KB|1026| Linux v2.5.62
  8]     19|   4189|  77KB|0925| [PATCH] add new DMA_ADDR_T_SIZE define
  9]     17|   4824|  80KB|1129| [RFC] Is an alternative module interface needed/possible?
 10]     16|   4265|  66KB|1355| RFC3168, section - ECN and retransmit of SYN

Top receivers
   | # msgs|av size| total|time| e-mail address
  1]    424|   6563|2717KB|1428|
  2]    149|   7420|1079KB|1409| Linus Torvalds <>
  3]     58|   6021| 341KB|1316| Andrew Morton <>
  4]     48|   8122| 380KB|1334| "David S. Miller" <>
  5]     47|   5845| 268KB|1509| "Martin J. Bligh" <>
  6]     36|   5781| 203KB|1359| Jeff Garzik <>
  7]     29|   8334| 236KB|1052| Alan Cox <>
  8]     26|   4200| 106KB|1042|
  9]     23|   4752| 106KB|1134| Larry McVoy <>
 10]     22|   5346| 114KB|0959| Ingo Molnar <>

Top CC'ers
   | # msgs|av size| total|time| e-mail address
  1]    752|   5396|3962KB|1242| <>
  2]    115|   4061| 456KB|1334|
  3]     56|   5549| 303KB|1249| Andrew Morton <>
  4]     54|  14239| 750KB|1747| Alan Cox <>
  5]     39|   6608| 251KB|1102| "David S. Miller" <>
  6]     35|   9217| 315KB|1301|
  7]     32|   5170| 161KB|1419| Chris Wedgwood <>
  8]     32|   4268| 133KB|0844| "Martin J. Bligh" <>
  9]     26|   5165| 131KB|1459| Zwane Mwaikambo <>
 10]     24|   8095| 189KB|1313| Jeff Garzik <>

Top of top-level-domain
 1]  com 668
 2]  org 200
 3]   de 118
 4]   uk 117
 5]  net 90
 6]   jp 55
 7]   au 49
 8]   cz 32
 9]   hu 30
10]  edu 27

Top organisations
 1]   81
 2]   42 The Domain of Holomorphy
 3]   11 Working Overloaded Linux Kernel
 4]    8 none
 5]    8 Nuix
 6]    7 USAGI Project
 7]    7 ith Kommunikationstechnik GmbH
 8]    3 Open Source Devlopment Lab
 9]    3 My House
10]    3

Top user-agents
 1]  207 Mutt/1.4i
 2]   78 Mutt/1.3.28i
 3]   70 Mutt/
 4]   70 Mutt/1.5.3i
 5]   60 ELM [version 2.5 PL6]
 6]   55 Mulberry/2.2.1 (Linux/x86)
 7]   51 Mutt/1.3.25i
 8]   42 Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
 9]   42 Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
10]   41 Ximian Evolution 1.2.1 (1.2.1-4)

Messages per day
   Sunday   257 ************************************
   Monday   133 *******************
  Tuesday   146 ********************
Wednesday   215 ******************************
 Thursday   300 *****************************************
   Friday   239 *********************************
 Saturday   136 *******************

Messages per Month
Jan     0
Feb  1427 *************************************************
Mar     0
Apr     0
May     0
Jun     0
Jul     0
Aug     0
Sep     0
Oct     0
Nov     0
Dec     0

Messages per day-of-the-month
 1     0
 2     0
 3     0
 4     0
 5     0
 6     0
 7     0
 8     0
 9     0
10     0
11     0
12     0
13     0
14     0
15     0
16     2 *
17     0
18   146 ************************
19   215 ***********************************
20   301 *************************************************
21   239 ***************************************
22   136 **********************
23   255 *****************************************
24   133 **********************
25     0
26     0
27     0
28     0
29     0
30     0
31     0

Messages per hour
 1    45 *******************
 2    17 ********
 3    13 ******
 4    10 *****
 5     4 **
 6    12 ******
 7    21 *********
 8    41 ******************
 9    63 ***************************
10    83 ***********************************
11    72 *******************************
12    83 ***********************************
13    86 *************************************
14    93 ***************************************
15   100 ******************************************
16   101 *******************************************
17    84 ************************************
18   117 **************************************************
19    52 **********************
20    72 *******************************
21    84 ************************************
22    61 **************************
23    63 ***************************

Created with mboxstats; written by

Maciej Soltysiak was surprised that there didn't seem to be any Pine users represented in the statistics. Several folks pointed out that Pine didn't use an "X-Mailer" header or "User-Agent" header to identify itself, but they said it could probably be recognized by the "Message-ID" header.

J.W. Schultz also pointed out:

And it wouldn't hurt to aggregate versions. This is really just a top-6 list.

 1]  476 Mutt (most common versions versions)
 2]   60 ELM [version 2.5 PL6]
 3]   55 Mulberry/2.2.1 (Linux/x86)
 4]   42 Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
 5]   42 Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
 6]   41 Ximian Evolution 1.2.1 (1.2.1-4)

Wonder where "unknown" would land if counted.

Folkert asked:

Problem is: what part is version-information and what is name? For Mutt 1.0, ELM 3.6 it's clear; it's the number part.

But what about:
FlokEdit peanutbutterrelease
FlokEdit RMDrelease

J.W. replied, "I would expect it to take a few regexes but so far $mta =~ s/\W.*$// would do the trick to produce Mutt, ELM, Mulberry, Sylpheed, Mew, Ximian and even FlokEdit."

20. Linux 2.5.63 Released

24 Feb 2003 - 25 Feb 2003 (10 posts) Archive Link: "Linux 2.5.63"

Topics: Version Control

People: Linus TorvaldsJohn Cherry

Linus Torvalds announced 2.5.63:

Hmm.. Nothing really fundamental here - various updates all over (architecture updates, networking, usb, acpi, bluetooth, the usual suspects).

The task structure reference counting seems to have broken alpha, Richard is still chasing that one down.

John Cherry posted:

Compile statistics: 2.5.63

Note that gcc 3.2 was used for all of these statistics.

                               2.5.62               2.5.63
                       --------------------    -----------------
bzImage (defconfig)         18 warnings          15 warnings
                             0 errors             0 errors

bzImage (allmodconfig)      33 warnings          29 warnings
                             9 errors             9 errors

modules (allmodconfig)    2514 warnings        2426 warnings
                           105 errors           128 errors

Compile statistics have been for kernel releases from 2.5.46 to 2.5.63 at:

I am also compiling nightly views of Linus' linux-2.5 bitkeeper tree. Results can be found at:







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.