Kernel Traffic #184 For 15 Sep 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1739 posts in 8824K.

There were 421 different contributors. 219 posted more than once. 166 posted last week too.

The top posters of the week were:

1. e1000 Driver With TCP Segmentation Offloading

2 Sep 2002 - 7 Sep 2002 (39 posts) Subject: "TCP Segmentation Offloading (TSO)"

Topics: Networking

People: Scott FeldmanDavid S. Miller

Scott Feldman remarked, "TCP Segmentation Offloading (TSO) is enabled[1] in 2.5.33, along with an enabled e1000 driver. Other capable devices can be enabled ala e1000; the driver interface (NETIF_F_TSO) is very simple." And David S. Miller replied, "I would like to praise Intel for working so closely with us on this. They gave us immediately, in one email, all the information we needed to implement and test e1000 support for TSO under Linux. With some other companies, doing this is like pulling teeth."

2. Dealing With Filesystem Fragmentation

3 Sep 2002 - 6 Sep 2002 (7 posts) Subject: "ext3 throughput woes on certain (possibly heavily fragmented) files"

Topics: FS: ReiserFS, FS: XFS, FS: ext2, FS: ext3

People: Stephen C. TweedieNikita DanilovHans ReiserAaron Lehmann

Aaron Lehmann noticed that under ext3, catting the contents of some large files could take much longer than others. He speculated that this was due to file fragmentation; and Stephen C. Tweedie replied, "Yep, both ext2 and ext3 can get badly fragmented by files which are closed, reopened and appended to frequently like that." He added, "There are some ideas from recent FFS changes. One thing they now do is to defragment things automatically as a file grows by effectively deleting and then reallocating the last 16 blocks of the file. Fragmentation will still occur, but less so, if we do that." Nikita Danilov suggested, "Another possible solution is to try to "defer" allocation. For example, in reiser4 (and XFS, I believe) extents are allocated on the transaction commit and as a result, if file was created by several writes, it will still be allocated as one extent." Stephen said that ext2 already did this, and added, "The problem with mail files, though, is that they tend to grow quite slowly, so the writes span very many transactions and we don't have that opportunity for coalescing the writes. Actively defragmenting on writes is an alternative in that case." And Hans Reiser said:

The FFS approach has an advantage for the case where the file grows too slowly for allocation to be delayed.

I think I prefer that we implement a repacker for reiser4 though, as that, combined with delayed allocation, will be a balanced and thorough solution.

Aaron asked:

How does current ReiserFS fare against extreme fragmentation? What about XFS? Without trying to risk a flamewar, what Linux filesystems are the most preventive of fragmentation?

The filesystem could make a huge difference on a machine like a mail server...

Hans replied, "Sometimes it is best to confess that one does not have the expertise appropriate for answering a question. Someone on our mailing list studied it carefully though. Perhaps they can comment." But there was no reply.

3. Patch Submission: Keeping Fixes Separate From New Code

3 Sep 2002 - 10 Sep 2002 (30 posts) Subject: "One more bio for for floppy users in 2.5.33.."

People: Linus TorvaldsJens AxboeSuparna Bhattacharya

Linus Torvalds posted a patch and said:

I found another major bio-related bug that definitely explains why the floppy driver generated corruption - any partial request completion would be totally messed up by the BIO layer (not the floppy driver).

Any other block device driver that did partial request completion might also be impacted.

I'm still looking at the floppy driver itself - some of the request completion code is so messed up as to be unreadable, and some of that may actually be due to trying to work around the bio problem (unsuccessfully, I may add). So this may not actually fix things for you yet, simply because the floppy driver itself still does some strange things.

Jens, oops. We should not update the counts by how much was left uncompleted, but by how much we successfully completed!

Jens Axboe replied:

Yeah oops, the most embarassing thing is that Bart and I have both found this but independently months ago but it seems it got lost at my end (or your end, but lets not point fingers :-) :-(

Patch is ofcourse correct. I'm not sure other drivers have been hit (of the used ones), since they would have to use old style completions and do less than current_nr_sectors in one-go.

Suparna Bhattacharya said that she'd also fixed it in the bio traversal patches she'd sent in awhile ago. "guess it went unnoticedm," she said. Linus replied:

Well, I've never seen a "this should go in" about it.

Also, it was apparently mixed up with the "bio splitup" stuff, which was discussed at least with Jens, and I feel strongly that we shouldn't split, we should build up. Jens was working on exactly that.

In other words, I absolutely hate the fact that a major bug-fix was
(a) not marked as such and sent to me
(b) mixed up with experimental work for other drivers

Even now (assuming I hadn't fixed it on my own), I would have preferred to get that fix separately, as it would have impacted the floppy driver, for example (the fix broke the floppy driver even more than it was before, because the floppy driver was stupidly trying to work around the original bug by hand).

Imagine what a horror it is to figure out why a large experimental patch breaks an existing driver? My first reaction would have been to just throw the large new patch away, since it obviously broke the floppy even more. Instead, if I had been passed the bug-fix only, and the floppy had broken worse that it was originally, it would have been absolutely _obvious_ where the problem was.

In short: please please PLEASE keep fixes to existing code separate from new stuff. It makes everything easier, and I have absolutely no problems with applying "obvious fixes" even if they might break something else.

In contrast, the new stuff I really don't know if it should go in at all, considering that it's trivial (and CPU-efficient) to build up legal bio request on the fly and _not_ depend on splitting them later (or at least making splitting a special thing only used by things like MD and other such indirection layers).

4. Finding The Right Compiler

3 Sep 2002 - 10 Sep 2002 (32 posts) Subject: "[PATCH] Important per-cpu fix."

People: Rusty RussellDavid S. MillerLinus Torvalds

Rusty Russell posted a short patch and explained:

Frankly, I'm amazed the kernel worked for long without this.

Every linker script thinks the section is called .data.percpu. Without this patch, every CPU ends up sharing the same "per-cpu" variable.

This might explain the wierd per-cpu problem reports from Andrew and Dave, and also that nagging feeling that I'm an idiot...

David S. Miller reported, "without the explicit initializers the per-cpu stuff still ends up in the BSS with egcs-2.9X, even with your fix applied." Rusty replied, "OK. I really hate working around wierd toolchain bugs (I use 2.95.4 here and it's fine), and adding an initializer to the macro is ugly. If you're not going to upgrade your compiler, will you accept a gcc patch to fix this? If so, where can I get the source to your exact version?" David said he was using gcc 2.92.11, and added, "Oh, "I'm" willing to upgrade "my" compiler, it's my users that are the problem. If you impose 3.1 or whatever, I get less people testing on sparc64 as a result." Linus Torvalds said:

Well, I don't think you have to go to 3.1.x.

gcc-2.96 at least seems to do all right. Apparently 2.95 does too. It's only the truly ancient compilers that don't work.

But David came back with, "Yes I do, anything after our standard sparc64 (ie. egcs-2.92.11) compiler up until 3.1.x is seriously unusable for kernel builds."

5. Linux 2.4.20-pre5-ac2 Released

4 Sep 2002 - 5 Sep 2002 (3 posts) Subject: "Linux 2.4.20-pre5-ac2"

Topics: Assembly, Disks: IDE, FS: BeFS, Kernel Release Announcement, Modems, Networking, PCI, USB

People: Alan CoxSteven ColePetr VandrovecWill DysonRoman ZippelChuck LeverAndre HedrickBartlomiej ZolnierkiewiczDominik BrodowskiItai NahshonDavid BrownellZwane Mwaikambo

Alan Cox announced 2.4.20-pre5-ac2 and said:

Merging the smaller bits of the IDE changes first along with the patch backlog. This isnt going to fix anyones IDE bugs, but by merging this way its easier to check it doesn't introduce any new ones. This patch is mostly about clearing the decks ready for further work.

Linux 2.4.20-pre5-ac2

6. BYTE Unix Benchmarks Comparing 2.4 And 2.5

4 Sep 2002 - 10 Sep 2002 (64 posts) Subject: "BYTE Unix Benchmarks Version 3.6"

People: Paolo CiarrocchiCliff WhiteBert Hubert

Paolo Ciarrocchi reported:

I've just ran the BYTE Unix Benchmarks Version 3.6 on the 2.4.19 and on the 2.5.33 kernel. Here it goes the results:

BYTE UNIX Benchmarks (Version 3.11)
  System -- Linux localhost.localdomain 2.4.19 #10 Fri Aug 23 20:53:06 BST 2002
i686 unknown
  Start Benchmark Run: Wed Sep  4 22:11:32 BST 2002
   1 interactive users.
Dhrystone 2 without register variables   1499020.6 lps   (10 secs, 6 samples)
Dhrystone 2 using register variables     1501168.4 lps   (10 secs, 6 samples)
Arithmetic Test (type = arithoh)         3598100.4 lps   (10 secs, 6 samples)
Arithmetic Test (type = register)        201521.0 lps   (10 secs, 6 samples)
Arithmetic Test (type = short)           190245.9 lps   (10 secs, 6 samples)
Arithmetic Test (type = int)             201904.5 lps   (10 secs, 6 samples)
Arithmetic Test (type = long)            201906.4 lps   (10 secs, 6 samples)
Arithmetic Test (type = float)           210562.7 lps   (10 secs, 6 samples)
Arithmetic Test (type = double)          210385.9 lps   (10 secs, 6 samples)
System Call Overhead Test                407402.6 lps   (10 secs, 6 samples)
Pipe Throughput Test                     476268.6 lps   (10 secs, 6 samples)
Pipe-based Context Switching Test        218969.9 lps   (10 secs, 6 samples)
Process Creation Test                      9078.6 lps   (10 secs, 6 samples)
Execl Throughput Test                       998.0 lps   (9 secs, 6 samples)
File Read  (10 seconds)                  1571652.0 KBps  (10 secs, 6 samples)
File Write (10 seconds)                  109237.0 KBps  (10 secs, 6 samples)
File Copy  (10 seconds)                   24329.0 KBps  (10 secs, 6 samples)
File Read  (30 seconds)                  1562505.0 KBps  (30 secs, 6 samples)
File Write (30 seconds)                  113152.0 KBps  (30 secs, 6 samples)
File Copy  (30 seconds)                   14334.0 KBps  (30 secs, 6 samples)
C Compiler Test                             470.9 lpm   (60 secs, 3 samples)
Shell scripts (1 concurrent)                980.4 lpm   (60 secs, 3 samples)
Shell scripts (2 concurrent)                544.1 lpm   (60 secs, 3 samples)
Shell scripts (4 concurrent)                287.0 lpm   (60 secs, 3 samples)
Shell scripts (8 concurrent)                147.0 lpm   (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places          42311.6 lpm   (60 secs, 6 samples)
Recursion Test--Tower of Hanoi            18915.4 lps   (10 secs, 6 samples)

                     INDEX VALUES
TEST                                        BASELINE     RESULT      INDEX  

Arithmetic Test (type = double)               2541.7   210385.9       82.8
Dhrystone 2 without register variables       22366.3  1499020.6       67.0
Execl Throughput Test                           16.5      998.0       60.5
File Copy  (30 seconds)                        179.0    14334.0       80.1
Pipe-based Context Switching Test             1318.5   218969.9      166.1
Shell scripts (8 concurrent)                     4.0      147.0       36.8
     SUM of  6 items                                                 493.2
     AVERAGE                                                          82.2

sh pgms/ results/log > results/report
sh pgms/ pgms/index.base results/log >> results/report
cat results/report

  BYTE UNIX Benchmarks (Version 3.11)
  System -- Linux localhost.localdomain 2.5.33 #32 Tue Sep 3 22:18:19 BST 2002
i686 unknown
  Start Benchmark Run: Wed Sep  4 20:46:31 BST 2002
   1 interactive users.
Dhrystone 2 without register variables   1488327.9 lps   (10 secs, 6 samples)
Dhrystone 2 using register variables     1488265.3 lps   (10 secs, 6 samples)
Arithmetic Test (type = arithoh)         3435944.6 lps   (10 secs, 6 samples)
Arithmetic Test (type = register)        197870.4 lps   (10 secs, 6 samples)
Arithmetic Test (type = short)           145140.8 lps   (10 secs, 6 samples)
Arithmetic Test (type = int)             104440.5 lps   (10 secs, 6 samples)
Arithmetic Test (type = long)            177757.4 lps   (10 secs, 6 samples)
Arithmetic Test (type = float)           208476.4 lps   (10 secs, 6 samples)
Arithmetic Test (type = double)          208443.3 lps   (10 secs, 6 samples)
System Call Overhead Test                397276.7 lps   (10 secs, 6 samples)
Pipe Throughput Test                     434561.9 lps   (10 secs, 6 samples)
Pipe-based Context Switching Test        148653.5 lps   (10 secs, 6 samples)
Process Creation Test                      5422.1 lps   (10 secs, 6 samples)
Execl Throughput Test                       771.6 lps   (10 secs, 6 samples)
File Read  (10 seconds)                  1553289.0 KBps  (10 secs, 6 samples)
File Write (10 seconds)                  132002.0 KBps  (10 secs, 6 samples)
File Copy  (10 seconds)                   17994.0 KBps  (10 secs, 6 samples)
File Read  (30 seconds)                  1540682.0 KBps  (30 secs, 6 samples)
File Write (30 seconds)                  137781.0 KBps  (30 secs, 6 samples)
File Copy  (30 seconds)                   11460.0 KBps  (30 secs, 6 samples)
C Compiler Test                             450.9 lpm   (60 secs, 3 samples)
Shell scripts (1 concurrent)                876.7 lpm   (60 secs, 3 samples)
Shell scripts (2 concurrent)                480.3 lpm   (60 secs, 3 samples)
Shell scripts (4 concurrent)                251.0 lpm   (60 secs, 3 samples)
Shell scripts (8 concurrent)                126.0 lpm   (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places          33530.4 lpm   (60 secs, 6 samples)
Recursion Test--Tower of Hanoi            18514.3 lps   (10 secs, 6 samples)

                     INDEX VALUES
TEST                                        BASELINE     RESULT      INDEX

Arithmetic Test (type = double)               2541.7   208443.3       82.0
Dhrystone 2 without register variables       22366.3  1488327.9       66.5
Execl Throughput Test                           16.5      771.6       46.8
File Copy  (30 seconds)                        179.0    11460.0       64.0
Pipe-based Context Switching Test             1318.5   148653.5      112.7
Shell scripts (8 concurrent)                     4.0      126.0       31.5
     SUM of  6 items                                                 403.6
     AVERAGE                                                          67.3

Cliff White replied:

Always useful to compare. I think the data from STP show something simular. I've pulled some reports, rather than send a huge email, here are the URL's (btw STP runs v4.0.1 UNIXbench)

runs made on 2-CPU platform

Another compare...why does pre5 appear a little worse than pre4 ?

Bert Hubert also said:

Side-by-side with some marked changes highlighted:
                                        2.4.19           2.5.33
Dhrystone 2 without register variable   1499020.6 lps    1488327.9 lps
Dhrystone 2 using register variables    1501168.4 lps    1488265.3 lps
Arithmetic Test (type = arithoh)        3598100.4 lps    3435944.6 lps
Arithmetic Test (type = register)        201521.0 lps     197870.4 lps
Arithmetic Test (type = short)           190245.9 lps     145140.8 lps
Arithmetic Test (type = int)             201904.5 lps     104440.5 lps
Arithmetic Test (type = long)            201906.4 lps     177757.4 lps
Arithmetic Test (type = float)           210562.7 lps     208476.4 lps
Arithmetic Test (type = double)          210385.9 lps     208443.3 lps
System Call Overhead Test                407402.6 lps     397276.7 lps
Pipe Throughput Test                    476268.6 lps     434561.9 lps
Pipe-based Context Switching Test       218969.9 lps     148653.5 lps
Process Creation Test                     9078.6 lps       5422.1 lps
Execl Throughput Test                       998.0 lps        771.6 lps
File Read  (10 seconds)                 1571652.0 KBps   1553289.0 KBps   
File Write (10 seconds)                  109237.0 KBps    132002.0 KBps
File Copy  (10 seconds)                  24329.0 KBps     17994.0 KBps
File Read  (30 seconds)                 1562505.0 KBps   1540682.0 KBps
File Write (30 seconds)                  113152.0 KBps    137781.0 KBps
File Copy  (30 seconds)                   14334.0 KBps     11460.0 KBps
C Compiler Test                             470.9 lpm        450.9 lpm
Shell scripts (1 concurrent)                980.4 lpm        876.7 lpm
Shell scripts (2 concurrent)                544.1 lpm        480.3 lpm
Shell scripts (4 concurrent)                287.0 lpm        251.0 lpm
Shell scripts (8 concurrent)                147.0 lpm        126.0 lpm
Dc: sqrt(2) to 99 decimal places         42311.6 lpm      33530.4 lpm
Recursion Test--Tower of Hanoi            18915.4 lps      18514.3 lps

                      INDEX VALUES           2.4.19     2.5
 TEST                                        INDEX      INDEX

 Arithmetic Test (type = double)              82.8       82.0
 Dhrystone 2 without register variables       67.0       66.5
 Execl Throughput Test                        60.5       46.8
 File Copy  (30 seconds)                      80.1       64.0
 Pipe-based Context Switching Test           166.1      112.7
 Shell scripts (8 concurrent)                 36.8       31.5
                                         =========  =========
      SUM of  6 items                        493.2      403.6
      AVERAGE                                 82.2       67.3

7. Kernel conf 0.4 Released

4 Sep 2002 - 5 Sep 2002 (3 posts) Subject: "linux kernel conf 0.4"

Topics: Configuration, Disks: SCSI

People: Roman Zippel


Roman Zippel announced:

At you can find the latest version of my config system. It slowly is becoming completely usable, so it's time for a new release. A lot has changed since the last official release, so here only some highlights:

Installation is very simple with "make install KERNELSRC=<..>", where KERNELSRC points to a 2.5.33 kernel tree. "make uninstall KERNELSRC=<..>" will deinstall everything. I think the new system is ready for wider testing, so any feedback is very much appreciated. Most important is probably the new syntax, until it it's integrated I can easily change the converter to generate whatever syntax. I still have to update the documentation, but the syntax should be easily understandable even without it. For the lazy guys out there, here is an (already advanced) example:

  prompt "Adaptec AIC7xxx support"
  depends SCSI

  tristate "New driver"

  int "Maximum number of TCQ commands per device"
  depends SCSI_AIC7XXX
  default "253"

  int "Initial bus reset delay in milli-seconds"
  depends SCSI_AIC7XXX
  default "15000"

  boolean "Build Adapter Firmware with Kernel Build"
  depends SCSI_AIC7XXX

  tristate "Old driver"

  boolean "Enable Tagged Command Queueing (TCQ) by default"
  depends SCSI_AIC7XXX_OLD

  int "Maximum number of TCQ commands per device"
  depends SCSI_AIC7XXX_OLD
  default "8"

  boolean "Collect statistics to report in /proc"
  depends SCSI_AIC7XXX_OLD


This new syntax basically fixes the recursive dependencies in the old syntax:

if [ "$CONFIG_SCSI_AIC7XXX_OLD" != "y" ]; then
   dep_tristate 'Adaptec AIC7xxx support' CONFIG_SCSI_AIC7XXX
   if [ "$CONFIG_SCSI_AIC7XXX" != "n" ]; then
if [ "$CONFIG_SCSI_AIC7XXX" != "y" ]; then
   dep_tristate 'Old Adaptec AIC7xxx support' CONFIG_SCSI_AIC7XXX_OLD
   if [ "$CONFIG_SCSI_AIC7XXX_OLD" != "n" ]; then

The most important thing here is that you now always see that there is a choice between two drivers. For example in menuconfig you had to know that you have to disable one option to see the other option or if you have an old .config, which doesn't contain CONFIG_SCSI_AIC7XXX_OLD, but has CONFIG_SCSI_AIC7XXX set to 'y', "make oldconfig" won't tell you about the new option.

Anyway, back to the new syntax. One thing I'm not yet completely sure about is indention, as it might help to make above more easily readable. The parser automatically recognizes the suboptions (by analyzing the dependencies) and the frontends present them accordingly (how exactly you should try yourself :) ). The problem here are the help texts, they should be easily editable, but on the other hand the parser has to find where it ends (and possibly reformat it a bit). Right now the help text simply ends at the first line that doesn't start with a white-space. So I'm toying with various ideas to make the suboption more easily recognizable, e.g. they could also be put within an "if FOO" ... "endif" block.

Something else above example demonstrates is the default value, first, bool and tristate symbols can have default values as well and second, something like this is possible:

config FOO
  bool 'bar' if BAR
  default y

The default value has two meanings here, first it's used as default value for the prompt and if the prompt isn't visible, FOO is set to it. This is quite useful for some of the advanced config options.

That's it for now, so have fun and complain _now_, not when it's too late. :)

8. libaio Developer Confusion

4 Sep 2002 - 5 Sep 2002 (2 posts) Subject: "libaio 0.3.90 -- test release for sync up"

Topics: Backward Compatibility

People: Benjamin LaHaiseShailabh Nagar

Benjamin LaHaise said, "Well, Andrea seems to be trying to fork libaio, but he never sent any patches to me, so I don't know what his complaint with me as maintainer is. I hope he finds it in his heart to submit *patches* for any changes he's making. Anyways, here's a test release going in the direction I've meant to for libaio-0.4.0 -- 0.3.15 is a compatible release for folks running Red Hat Advanced Server and does not break source/binary compatibility. 0.4.0 on the other hand breaks source compatibility to match the changes made for 2.5, but should still provide backwards compatible symbols. I've also tossed the beginnings of man pages in man/ for people to hack on (Alan, Bert you guys need to synch up with each other on list). ChangeLog bits are below, the test cases have not been updated for the new API, nor has it been tested in any way mean or form. I'll try to get a 0.3.91 out before I leave tomorrow afternoon, but if not it will wait until Tuesday." Shailabh Nagar asked when folks could expect to see some more core aio code in 2.5, but there was no reply.

9. Searching For The autofs Maintainer

5 Sep 2002 (2 posts) Subject: "Automount oops - who to report to?"

Topics: FS: autofs

People: H. Peter AnvinAxel Siebenwirth

Ian Chard had some problems with autofs, but couldn't find out who the maintainer was. Axel Siebenwirth wasn't sure but suspected it was H. Peter Anvin. There was no reply.

10. Linux 2.4.20-pre5-ac3 Released

5 Sep 2002 (14 posts) Subject: "Linux 2.4.20-pre5-ac3"

Topics: Disks: IDE, FS: ReiserFS, FS: procfs, I2C

People: Alan CoxSteven Cole

Alan Cox announced:

Next batch of backlog stuff, and one small Promise IDE fix. The backlog is now basically clear.

Since master.kernel is currently being unhappy this patch can be found on I'll upload it to at some point later on.

Linux 2.4.20-pre5-ac3

11. IDE Developer Organization

5 Sep 2002 (2 posts) Subject: "IDE cleanup (against 2.5.33) -- who takes these?"

Topics: Disks: IDE

People: Pavel MachekAlan Cox

Pavel Machek posted an IDE patch and asked, "Who takes cleanup patches against 2.5.33? Alan is it you or should it go directly to Linus?" Alan Cox replied, "Via Andre please, and small cleanups like that can wait while we get the big stuff done."

12. Block Preallocation For ReiserFS

6 Sep 2002 (1 post) Subject: "[BK] ReiserFS PATCH resend (preallocation the default)"

Topics: FS: ReiserFS, SMP, Version Control

People: Hans Reiser

Hans Reiser posted a patch and announced, "This changeset enables preallocation of blocks on reiserfs filesystems by default. Without this, SMP boxes seems to have speed problems on some workloads. You can get it from bk://"

13. Linux 2.4.20-pre5-ac4 Released

6 Sep 2002 - 9 Sep 2002 (18 posts) Subject: "Linux 2.4.20-pre5-ac4"

Topics: Big Memory Support, Disks: IDE, Kernel Release Announcement, Networking, PCI, USB

People: Alan CoxJens AxboeAdrian BunkSteven ColeOliver NeukumAndre HedrickBartlomiej Zolnierkiewicz

Alan Cox announced 2.4.20-pre5-ac4:


Since still seems down I've put this on

Linux 2.4.20-pre5-ac4

14. iowait Statistics Added To /proc/stat In 2.5

6 Sep 2002 (2 posts) Subject: "[PATCH] iowait stats for 2.5.33"

People: Rik van RielAndrew Morton

Rik van Riel posted a patch and said:

the following patch, against 2.5.33-mm4, implements iowait statistics in /proc/stat. This can be used to determine how much of your machine's idle time is truly idle and how much time it should have been doing something but was waiting on (disk) IO instead.

Please add this to your patch queue or let me know if you want any changes to it.

Andrew Morton replied:

trivial: I'd be inclined to use:

void iowait_schedule()

less trivial: there are times when an io wait is deliberate: in the context of balance_dirty_pages(), and (newly) in the context of page reclaim when current->backing_dev_info is non-zero.

Given that this is a deliberate throttling sleep, perhaps it should not be included in the accounting? That way we only account for the accidental, undesirable sleeps, and reads and such.

15. New devlabel Program To Allow Consistent Device Access

6 Sep 2002 - 7 Sep 2002 (2 posts) Subject: "[ANNOUNCE] devlabel: consistent device access through symlinking"

Topics: Disks: IDE, Disks: SCSI, Hot-Plugging, USB

People: Gary LerhauptDaniel Egger

Update: After KT publication, Gary gave me a URL for the devlabel project ( .

Gary Lerhaupt said:

Attached is a program I have been working on to allow for consistent access to storage devices. It works by creating symlinks to actual storage device names. When coupled with the UUID of the disk in question, the symlink can consistently point to the right data even if the device name changes. Devices can thus be referenced by their symlink only and this symlink is user-definable.

Moreover, I've incorporated it into the current hotplug system (I did my testing on Red Hat 7.3/Advanced Server 2.1). You should, for example, be able to plug your flashcard reader into your USB slot, add a symlink to it and then use this symlink as its reference. Remove the cardreader from USB and the symlink should disappear. Re-insert and the symlink will come back. This should also work for PCMCIA devices as well as IEEE1394 (firewire). While patches are included with this RPM, the eventual idea would be to get the code added directly into hotplug.

The UUIDs gathered vary dependent on the device in question. For SCSI (this includes USB/firewire) it will attempt to search for IDS in the following order: Page83 type 3, Page83 type 2, Page83 type 1, Page 80, Page83 type 0, Manufacturer/Model Name. For IDE, it only looks in /proc/ide/hd#/identify (words 10-19, the serial number). In both cases it will always try to append the manufacturer/model data so that in the event that your device does not return any UUID (eg. megaraid) you will at least be able to use this as an ID. However, if more than one device on your system returns the same ID, neither will be usable with devlabel. It is also worth noting that USB/Firewire stuffs return the UUID of the reader and not of the storage contained within. This is not such a bad thing if you think about it, but you should probably label your symlink accordingly (eg. /dev/flashreader instead of /dev/flashdisk1).

Also included with the RPM is an rc.sysinit patch to run devlabel on boot. I am not quite sure I have placed this correctly and this is important if you wish to use your symlinks within /etc/fstab. Want to make sure that the symlink is correct before fstab gets ahold of it. I may also consider writing additional code to comment out references in fstab in the event that the symlink has been deleted because the UUID can no longer be determined/found (maybe a "restart safefstab" parameter or something).

Daniel Egger replied, "Except that for source RPMs sucking big time the stuff is REALLY cool! I could also see benefits for other devices like HID where the current ordering is done after a first come - first serve approach where the minor device numbers follow the order the devices appear on the bus which is quite easy to mess up and never consistent; Applying your scheme to and-class devices also would allow to link whatever device to a fixed device node which could solve many problems as far as I can see."

16. IPMI Driver Direction

6 Sep 2002 - 9 Sep 2002 (5 posts) Subject: "[patch] Version 2 of the Linux IPMI driver"

Topics: FS: devfs, I2C, Ioctls

People: Corey MinyardMatthew WilcoxGreg KH

Corey Minyard announced:

I've cleaned a few things up and fixed some minor bugs. The only big change is renaming the "unused" address to the "system interface" address (which makes a heck of a lot more sense). I'm working on userland tools that will tie in to this and to LAN/ICMB stuff, and there I saw the need for the name. I still haven't tested interrupt-driven operation, but that's really a rather minor concern since almost no boards support it and the driver will work without it.

You can get the patch on my web page at, relative to 2.5.33 or 2.4.19. The patch is fairly self-contained, so it should be easy to port to other kernel versions.

The lanana guy is not available for a while, so I'm not getting a device number in the near future, but I think it's ready for the 2.5 release. Does this need more time, or is it ready for inclusion?

Matthew Wilcox replied:

I don't think you should be using a device number at all. ioctl is Evil (TM) and it's perfectly possible to write an IPMI driver which uses neither an ioctl nor a chaacter device. Voila:

yes, it was stupid to call it BMC instead of IPMI. i was handed a pile of junk that'd been half-heartedly ported from windows. however, the principle is sound, you don't need ioctl, nor a character device.

This made no sense to Corey. He said:

You access a device as a filesystem? That's bizarre. It's a device, and they call them "devices" in the kernel for a reason. Why would you want to do this? Especially with devfs, the whole device numbering problem goes away. You could easily make it a misc device.

Plus, your patch misses a lot of places where IPMI is going. Many cards have multiple IPMI interfaces (I have one that has three). In multi-card systems, IPMI is used for transport for a lot of configuration and control information between cards that may be going to different applications both inside the kernel and in userland, so a straight BMC interface is not going to get you there. You really need a message handler in the kernel. You could do a message handler in userland, but then it makes implementing watchdog timers and I2C interfaces kernel interfaces over IPMI much more difficult, and it's a message router hooked directly to a device and it makes some sense to put it in the kernel.

I toyed with the idea of making it a network interface, since you have addressing that is separate from messaging. However, it probably wasn't worth the work for that.

And it wasn't stupid to call your "driver" BMC. That's exactly what it is. It's not IPMI, it's a KCS BMC interface (hooked in as a filesystem).

Matthew said he knew his own patch had limitations, but he felt Corey's implementation was wrong. He explained, "The point is to get away from using character devices where we don't need them (and we really don't need them in most places). Plus, there's no dependency on devfs with this approach." And Greg KH also added, "devfs did not make the device numbering problem go away at all, you still need to have a registered major/minor number with Lanana to use devfs. Yes, you can ask for a dynamic misc number, but that is very difficult to support."

17. UML 2.5.33 Released

6 Sep 2002 (1 post) Subject: "UML 2.5.33"

Topics: Networking, User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

UML has been updated to 2.5.33 and UML 2.4.19-2.

Other changes include
Fixed a couple of jail mode crashes
Fixed a crash caused by not properly copying the fpstate pointer during a signal delivery
Fixed a stupid typo in uaccess.h.
Ethernet devices now are guaranteed to end up with the same names that were specified on the command line

The patch is available at

For the other UML mirrors and other downloads, see

Other links of interest:

The UML project home page :
The UML Community site :

18. e2compress Version 0.4.43 For Kernel 2.4 Released

8 Sep 2002 (1 post) Subject: "WEB site for e2compress patch on 2.4 kernel."

Topics: Compression, FS: ext2

People: Denis Richard

Denis Richard announced:

A new WEB site for the e2compress patch on the 2.4 kernel is available at .

The last version of the patch to download, is 0.4.43 for the 2.4.17 linux kernel.

The fixed bugs are :

Feel free to contact me if you have some problems.

19. Zerocopy NFS For 2.5.33

8 Sep 2002 - 9 Sep 2002 (6 posts) Subject: "[PATCH] zerocopy NFS for 2.5.33"

Topics: FS: NFS, Networking

People: Hirokazu TakahashiDavid S. Miller

Hirokazu Takahashi announced:

I updated the patches for zerocopy NFS. You can apply them against linux-2.5.33 and zerocopy NFS over UDP/TCP works very fine.

    This patch enables HW-checksum against outgoing packets including UDP frames.
    This patch makes sendfile systemcall over UDP work. It also supports UDP_CORK interface which is very similar to TCP_CORK. And you can call sendmsg/senfile with MSG_MORE flags over UDP sockets too.

    Using TSO code is commented out at this moment as TSO for UDP isn't implemented yet. I'm waiting for it so that we would remove "#ifdef NotYet" to send jumbo UDP frames without any fragmentation and any checksumming. Then I hope we will get great performance.

    This patch fixes the problem of x86 csum_partilal() routines which can't handle odd addressed buffers.
    This patch makes RPC be able to send some pieces of data and pages without any copies.
    This patch makes NFSD pass pages in pagecache to RPC layer directly when NFS clinets request file-read.
    nfsd_readdir can also send pages without copy.
    This patch makes per-cpu UDP sockets so that NFSD can send UDP frames on each prosessor simultaneously. Without the patch we can send only one UDP frame at the time as a UDP socket have to be locked during sending some pages to serialize them.
    If you don't want to use sendfile over UDP yet, you can apply it instead of 1) and 2) .

To the second paragraph of item 2, David S. Miller replied:

Actually, device interface for what could be used is there, see NETIF_F_FRAGLIST. No devices set this and IP never makes use of it yet though :-)

Acenic and Tigon3 will be able to do this, probably e1000 has this feature as well.

But it does not work how you imagine. One passes already fragmented list of packets to card, and it can checksum the packet if you tell it which descriptor is first of fragmented frame and which is last.

It does not do the fragmentation of UDP frames for you, only checksumming of UDP portion. No card does what you mention.

20. Taking Entropy From Video

9 Sep 2002 (1 post) Subject: "kernel & entropy: introducing video-entropyd"

Topics: Random Number Generation

People: Folkert van Heusden

Folkert van Heusden announced:

Copy & paste from its webpage ( ):


For security reasons (when doing network traffic or generating secure keys for example) one wants as much entropy-data in the kernel random-driver as possible. The random-driver takes partially care for this itself. But in situations in where there's a lot of demand for entropy-data, it might not be able to gather enough entropy-data by itself.

That's where this program is for: adding entropy-data to the kernel-driver. It does that by fetching 2 images from a video4linux-device (with a random delay in between), calculating the difference between those two and then calculating the number of information-bits in that data. After that, the data with the number-of-entropy-bits is submitted to the kernel-random-driver.

After that, the program exits. That is because I am assuming you also want to use your video4linux-device for other things. So run this program every minute (or so) from crontab.

I tested this program with a Philips webcam. (

You also might want to take a look at audio-entropyd:

21. LMbench 2.0 Benchmarks For Kernel 2.5.34

9 Sep 2002 (2 posts) Subject: "LMbench2.0 results 2.5.34"

Topics: Networking, Real-Time, Virtual Memory

People: Paolo Ciarrocchi

Paolo Ciarrocchi reported:

I'm back with the result of LMbenche2.0 against 2.5.34. Same config of 2.5.33.

2.5.33 is preemption ON
2.5.33x is preemption OFF
2.5.34 is preemtpion ON

Hardware is a HP Omnibook 6000, 256 MiB of Ram, PIII@800. Hope it is intersting for you.

cd results && make summary percent 2>/dev/null | more
make[1]: Entering directory `/usr/src/LMbench/results'

                 L M B E N C H  2 . 0   S U M M A R Y

Basic system parameters
Host                 OS Description              Mhz

--------- ------------- ----------------------- ----
frodo      Linux 2.4.18       i686-pc-linux-gnu  797
frodo      Linux 2.4.19       i686-pc-linux-gnu  797
frodo      Linux 2.5.33       i686-pc-linux-gnu  797
frodo     Linux 2.5.33x       i686-pc-linux-gnu  797
frodo      Linux 2.5.34       i686-pc-linux-gnu  797

Processor, Processes - times in microseconds - smaller is better
Host                 OS  Mhz null null      open selct sig  sig  fork exec sh
                             call  I/O stat clos TCP   inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
frodo      Linux 2.4.18  797 0.40 0.56 3.18 3.97       1.00 3.18 115. 1231 13.K
frodo      Linux 2.4.19  797 0.40 0.56 3.07 3.88       1.00 3.19 129. 1113 13.K
frodo      Linux 2.5.33  797 0.40 0.61 3.78 4.76       1.02 3.37 201. 1458 13.K
frodo     Linux 2.5.33x  797 0.40 0.60 3.51 4.38       1.02 3.27 159. 1430 13.K
frodo      Linux 2.5.34  797 0.38 0.59 3.60 4.53       1.02 3.39 182. 1573 13.K

Context switching - times in microseconds - smaller is better
Host                 OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                        ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
frodo      Linux 2.4.18 0.990 4.4200   13.8 6.2700  309.8    58.6   310.5
frodo      Linux 2.4.19 0.900 4.2900   15.3 5.9100  309.6    57.7   309.9
frodo      Linux 2.5.33 1.620 5.2800   15.3 9.3500  312.7    54.9   312.7
frodo     Linux 2.5.33x 1.040 4.3200   17.8 7.6200  312.5    49.9   312.5
frodo      Linux 2.5.34 1.520 5.2800   21.8 9.0800  312.2    39.0   311.9

*Local* Communication latencies in microseconds - smaller is better
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
frodo      Linux 2.4.18 0.990 4.437 8.66
frodo      Linux 2.4.19 0.900 4.561 7.76
frodo      Linux 2.5.33 1.620 6.497 9.11
frodo     Linux 2.5.33x 1.040 4.888 8.70
frodo      Linux 2.5.34 1.520 7.142 8.51

File & VM system latencies in microseconds - smaller is better
Host                 OS   0K File      10K File      Mmap    Prot    Page
                        Create Delete Create Delete  Latency Fault   Fault
--------- ------------- ------ ------ ------ ------  ------- -----   -----
frodo      Linux 2.4.18   68.9   16.0  185.8   31.6    425.0 0.789 2.00000
frodo      Linux 2.4.19   68.9   14.9  186.5   29.8    416.0 0.798 2.00000
frodo      Linux 2.5.33   77.8   19.1  211.6   38.3    774.0 0.832 3.00000
frodo     Linux 2.5.33x   77.2   18.8  206.7   37.0    769.0 0.823 3.00000
frodo      Linux 2.5.34   77.3   18.3  208.6   37.6    762.0 0.848 3.00000

*Local* Communication bandwidths in MB/s - bigger is better
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
frodo      Linux 2.4.18 810. 650.       181.7  203.7  101.5  101.4 203. 195.3
frodo      Linux 2.4.19 808. 680.       187.2  203.8  101.5  101.4 203. 190.1
frodo      Linux 2.5.33 571. 636.       185.6  202.5  100.5  100.4 202. 190.3
frodo     Linux 2.5.33x 768. 710.       185.4  202.5  100.5  100.4 202. 189.5
frodo      Linux 2.5.34 560. 670.       185.6  202.5  100.5  100.4 202. 190.5

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------  ---- ----- ------    --------    -------
frodo      Linux 2.4.18   797 3.767 8.7890  158.9
frodo      Linux 2.4.19   797 3.767 8.7980  158.9
frodo      Linux 2.5.33   797 3.798 8.8660  160.1
frodo     Linux 2.5.33x   797 3.796   45.5  160.2
frodo      Linux 2.5.34   797 3.796 8.8760  160.2
make[1]: Leaving directory `/usr/src/LMbench/results'

22. The Correct Use Of BUG()

9 Sep 2002 - 10 Sep 2002 (37 posts) Subject: "[BK PATCH] USB changes for 2.5.34"

Topics: Debugging, FS, SMP, USB, Virtual Memory

People: Linus TorvaldsAlan CoxDavid BrownellGreg KH

Greg KH posted a USB patch that included a BUG() call, and Linus Torvalds took exception to that. Linus said, "that BUG() thing is _way_ out of line, and has killed a few of my machines several times for no good reason. It actively hurts debuggability, because the machine is totally dead after it, and the whole and ONLY point of BUG() messages is to help debugging and make it clear that we can't handle something." [...] "Rule of thumb: BUG() is only good for something that never happens and that we really have no other option for (ie state is so corrupt that continuing is deadly)." Greg said he'd fix it, and Linus replied, "I've just excluded it, with a comment to never _ever_ kill the machine unless there is a major reason for it." Alan Cox remarked, "I'd have thought you may well want the reverse. If the user didnt pick the kernel debugging, don't die on software check option you want to blow up. If they are debugging or its < 2.6.0-rc1 you want it to show the stack and keep going." Linus replied, "If it isn't fatal, there is no excuse for blowing up. EVER. That's _especially_ true for some random user who didn't ask for, and can't handle debugging. If it's useful information that the developer believes he wants, it shouldn't be conditional at all." He added:

You definitely want to keep going regardless. A BUG() that takes out the machine is just not useful, because users who aren't ready to debug it can't even make any reports except "it stops" (which this one did if you were under X - the machine was just _dead_).

Basically, with the amount of locking we have, a BUG() or a blow-up just about anywhere is lethal. Most sequences (especially in drivers, but inside filesystems etc too) tend to hold spinlocks etc that just makes it a bad idea to BUG() out unless you really really have to, since the machine is not likely to survive and be able to write good reports to disk etc at pretty much any point.

(It used to be that you could take a fault just about anywhere except for in interrupt handlers, and Linux would try its damndest to clean up and continue as if nothing had happened. Those days are sadly gone, and trapping and depending on killing the process seldom works well any more).

On the whole, it's a lot better to just print out a message (and call traces are often very useful) and continue. That's not always possible, of course, and a lot of BUG() and BUG_ON() cases are perfectly valid simply because sometimes there isn't anything you can do except kill the machine and try to inform the user.

I think the historical kernel behaviour ("trap and kill and continue" historically worked so fine for _both_ major bugs and for "random sanity test" cases) has caused us to be a bit lazy about this sometimes.

Elsewhere, he added:

The fact is, BUG() is almost always the wrong thing to do. And it's almost _guaranteed_ to be the wrong thing to do in a driver, since a driver won't know what locks the rest of the kernel is holding, _and_ since it's almost always possible for a driver to try to return an error code instead.

In short:

Either you want debugging (in which case BUG() is the wrong thing to do), or you don't want debugging (in which case BUG() is the wrong thing to do). You can choose either, but in neither case is BUG() acceptable.

BUG() is fine for _fundamental_ problems, where you don't have any other choice, and where the machine really is effectively dead anyway. If the VM notices that it's lists are corrupt, that's a BUG() thing. We don't have much choice. If the scheduler notices that it's running on another CPU than it thought it was running on, that's a BUG() thing.

Now, the kernel problem may be that BUG() is a bit too easy to use, and the alternatives are not. We should fix that. But we shouldn't fix it by using BUG() in places where it definitely doesn't belong.

But he replied to himself:

There are probably good exceptions to this rule, like any rule.

For example, if the request queue (or some other fundamental internal data structure) is found to be corrupted, I couldn't really fault a driver for BUG()'ing out on it. It's not as if the driver could sanely even do an end_request() in that case.

But even broken hardware is not a reason for a BUG(). For example, if the driver notices that some part of the controller is hung hard (ie provable hardware problem), the last thing it should do is to bring the system down. It should fail the IO, and maybe turn itself off, but let the system continue otherwise.

One of the best things I ever did from a debuggability standpoint was to almost never use panic() in the base kernel, and make various kernel page faults etc just try to kill the offender and go on.

Sometimes that "try to continue" approach ends up being nasty too (the problem repeats and you end up with a dead machine that scrolls infinite bug reports off the screen, making them really hard to catch), but on the whole it tends to make things much easier to debug ("oops, I just lost my floppy drive, let's save the messages on the harddisk and reboot").

David Brownell summed up Linus' approach by saying, "Or in even shorter sound bite format: "Just say no to BUG()s."" But Linus replied:

Well, the thing is, BUG() _is_ sometimes useful. It's a dense and very convenient way to say that something catastrophic happened.

And actually, outside of drivers and filesystems you can often know (or control) the number of locks the surrounding code is holding, and then a BUG() may not be as lethal. At which point the normal "oops and kill the process" action is clearly fine - the machine is still perfectly usable.

(In fact, on UP a BUG() tends to be quite usable just about anywhere except in an interrupt handler: there may be some local locks like directory semaphores etc that are held and not released, but _most_ of the time the machine is quite usable. SMP really does make things harder to debug even quite apart from the races it introduces. Sad.)

23. Support For ALi 5451 Gameport

9 Sep 2002 - 10 Sep 2002 (3 posts) Subject: "[PATCH] 2.4.20-pre5-ac4: Add support for ALi 5451 gameport"

Topics: PCI, Sound

People: Pascal SchmidtVojtech PavlikAlan Cox

Pascal Schmidt posted a patch and announced:

This patch adds support for the gameport found on ALi 5451 chips to drivers/sound/trident.c and drivers/char/joystick/pcigame.c. The ALi 5451 gameport works just like a Trident 4DWave gameport, so the patch just adds the ALi device id in the relevant places.

Patch against 2.4.20-pre5-ac4 since that has the necessary code to use trident and pcigame at the same time.

Tested and found working on a Soyo K7ADA motherboard (ALi Magik1 chipset).

Vojtech Pavlik replied, "Very nice. I think this is for Alan. For normal 2.4, as you said, the pcigame.c code isn't much useful, because doesn't cooperate well with the trident.c code. For 2.5, pcigame code is embedded into trident.c to make things simpler." And Alan Cox said, "I fixed that in 2.4 by making pcigame look for devices if the sound card isnt compiled in for them, otherwise provide pcigame_attach and pcigame_release functions that drivers can use to attach pci mmio joystick interfaces to their hardware. Works very nicely and saves embedded one completely in the other."

24. Updated Preemptible Kernel

9 Sep 2002 (1 post) Subject: "[patch] 2.4: updated preemptable kernel"

Topics: Real-Time

People: Robert Love

Robert Love announced:

Updated fully preemptive kernel patches are available at:


and your favorite mirrors.

These releases contain some of the recent fixes from 2.5. Note new design features of kernel preemption will most likely not be back-ported from 2.5; just fixes to the existing infrastructure.

The above patches include fixes for the "preempting with interrupts disabled" bug as well as some other misc. issues. Note they are not per se in sync with 2.5 or each other yet...

25. Linux Test Project 20020910 Released

10 Sep 2002 (1 post) Subject: "[ANNOUNCE] ltp-20020910 released"

Topics: Bug Tracking, FS: JFS, FS: NFS, Version Control

People: Robert WilliamsonMatthew WilcoxPaul LarsonAndrea ArcangeliJeff MartinAndreas JaegerRandy Hron

Robert Williamson announced:

The Linux Test Project test suite LTP-20020910.tgz has been released. Visit our website ( <> ) to download the latest version of the testsuite, and for information on test results on pre-releases, release candidates & stable releases of the kernel. There is also a list of test cases that are expected to fail, please find the list at <>

The highlights of this release are:

We encourage the community to post results, patches, or new tests on our mailing list, and to use the CVS bug tracking facility to report problems that you might encounter. More details available at our web-site.

Change Log
- Fix path in                          ( Paul Larson )  
- runtest/syscalls:
        a.Removed the {} from the environment    ( Robbie Williamson )
        b.Comment out stime01, since it sets     ( David Barrera )
          the system time forward and could
          cause problems with several other
          tests if it's running at the same
          time (-x nn)
- Renamed the fsx-linux test on nfs to           ( Robbie Williamson )
- fsxtest: Added code to handle JFS.             ( Robbie Williamson )
- ld01: Made the diff case insensative for       ( Robbie Williamson )
  cross-platform compatibility.
- Removed obsolete test, "ulimit", from          ( Robbie Williamson)
  automatic build and install.
- Moved the 'chown' commands to "install"        ( Robbie Williamson )
  section in 'Makefile' of fchmod tests
- Applied patches for s390                       ( Susanne Wintenberger )
- Applied patches for IA64                       ( Jacky Malcles )
- Applied patch for adding some missing includes ( Andreas Jaeger )
  to remove warnings about missing prototypes
- Applied x86-64 patch for ldd01                 ( Andreas Jaeger )
- Fix for ar01 hang when filesystem is full      ( Paul Larson )
- Make ltp run with uClibc                       ( Steven J. Hill )
- Fix compiler warnings in various tests         ( Xiao Feng Shi )
- Clean up many of the mktemp warnings           ( Paul Larson )
  And use mkstemp in tst_tmpdir()
- Applied pan/logfile/tools patches.             ( William J. Huie )
- Use regular instead of mandatory locks in      ( Matthew Wilcox )
  fcntl09, fcntl10, fcntl11 to fix with NFS
- Fix pids in fcntl11, fcntl19, fcntl20, fcntl21 ( Paul Larson )
  to be pid_t instead of short for 2.5 compat
- Add command line options to to  ( Randy Hron,
  allow setting of various pan options and         Paul Larson,
  changing the temp directory                      Nate Straz )
- Added automation script documentation          ( Jeff Martin )
  to /doc directory.
- Patched nanosleep02.c to correctly test the    ( Andrea Arcangeli )
  functionality and avoid false positives.

26. Kernel conf 0.5 Released

10 Sep 2002 - 11 Sep 2002 (5 posts) Subject: "linux kernel conf 0.5"

Topics: Kernel Build System

People: Roman Zippel

Roman Zippel announced:

At you can find the latest version of the new config system. Besides various small bug fixes, it includes the following changes:

With the exception of the X interface I'm not planning any big visible changes anymore, so slowly I'd like to know any reason, why this config system shouldn't go into 2.5.x. The old arguments against cml2 don't really work anymore, so you have to come up with something new. :-) The only argument I know of is that various people on kbuild mailing list are afraid, that Linus wouldn't accept such a big change. I think hardly anyone cares how the config backend is implemented, so the only really visible change is the new config format, but here only the format is new, the information is still the same (if anyone cares about the subtle differences, I can explain them separately). Making a clear cut now is really the easiest solution. Changing parsers and syntax separately would be more painful, as we risks constants subtle behaviour changes and bugs during this period, by doing a single switch we can quickly get over it.

Otherwise the little feedback I got was mostly positive, so if anything thinks the old config system is in any way better, I'd really like to know about it now (and if anyone wants to keep the old system, (s)he just volunteered to fix all the subtle differences between the three different parsers). So unless I hear objections rather soon, it's up to Linus.

27. 2.5 Status Report For September 11

10 Sep 2002 (1 post) Subject: "[STATUS 2.5] September 11, 2002"

Topics: Networking

People: Guillaume Boissiere

Guillaume Boissiere announced the 2.5 status report for September 11 ( and said, "Here is this week's 2.5 update. Of note, discontigmem support and TCP segmentation offload have been merged since last week."

28. 2.5 Problem Status Report

10 Sep 2002 - 11 Sep 2002 (29 posts) Subject: "2.5 Problem Status Report"

Topics: Disks: IDE, FS: JFS, FS: ext2, Forward Port, PCI, Version Control

People: Thomas Molina

Thomas Molina announced the 2.5 problem status report:

The most current version of this status report can be found at:

     * Several  people  have  requested  the  discussion be linked to LKML
archives. With this version I've switched from
       locally edited discussion threads to archived links.
     * Great  progress has been made in forward porting IDE driver code
from 2.4 to 2.5. Several people have tried 2.5.33
       without disaster. Updates continue to be added to the -ac kernels
and the 2.5 bitkeeper kernels.
     * Floppy  support  appears to have been fixed in 2.5.33-bitkeeper. It
has been tested, and the corruption previously
       seen has not been duplicated.
     * Support for __FUNCTION__ pasting is being phased out of gcc. This
has broken compiling in numerous places. Defines
       of the form:
       #define func_enter() sx_dprintk (SX_DEBUG_FLOW, "sx: enter "    
__FUNCTION__ "\n")
       need to be changed to the form:
       #define func_enter() sx_dprintk (SX_DEBUG_FLOW, "sx: enter %s\n", 

              2.5 Kernel Problem Reports as of 10 Sep
   Problem Title                Status                Discussion
   JFS oops                     open                  06 Sep 2002
   qlogicisp oops               no further discussion 2.5.33
   2.5.32 reboot oops           no further discussion 2.5.33  
   ext2 umount oops             no further discussion 2.5.33
   DEBUG_SLAB oops              no further discussion 2.5.33
   2.5.32-mm1 problems          no further discussion 2.5.33
   soft suspend problem         no further discussion 2.5.33   
   PCI and/or starfire.c broken no further discussion 2.5.33
   __write_lock_failed() oops   no further discussion 2.5.33
   invalidate_inode_pages       open                  10 Sep 2002
   Problem running on Athlons   open                  06 Sep 2002
   dequeue_signal panic                               08 Sep 2002
                                closed                09 Sep 2002
   mouse/keyboard flakiness     open                  09 Sep 2002
   process hang in do_IRQ       open                  09 Sep 2002
   do_syslog lockup             open                  09 Sep 2002
   BUG at kernel/sched.c        open                  10 Sep 2002

29. Timpanogas Sells Intellectual Property To Canopy Group

11 Sep 2002 (1 post) Subject: "[ANNOUNCE] Timpanogas Research Group IP Assigned to Canopy Group"

People: Jeff V. Merkey

Jeff V. Merkey said:

Please be advised that all TRG Intellectual Property has been sold for an undisclosed amount to the Canopy Group in Lindon, Utah.

Any inquiries regarding future or pending projects regarding any issues with any Linux projects or source code maintained by TRG for Linux should be directed to These requests will be forwarded to the appropriate party.

NWFS and all other Linux projects have been assigned as of this date to the Canopy Group. Please direct any future inquiries to the address specified above.

I will continue to work on approved Linux projects in my new capacity at Network Associates. I can be reached at If your questions are regarding any TRG specific code, please send these inquiries to the address specified above.







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.