Kernel Traffic #184 For 15 Sep 2002

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.

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...

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!

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.

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
and
(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).

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...

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.

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

• BeFS updates (Will Dyson)
• Fix prototype mismatch in tc/tc.c (Silvio Cesare)
• SunRPC oops fix (Chuck Lever)
• Fix SunRPC TCP handling for write_space (Chuck Lever)
• Update ver_linux reporting further (Steven Cole)
• Cpufreq updates (Dominik Brodowski)
• Update pegasus.h license header (Petko Manolov)
• USB lcd driver (Adams IT)
• Update bluetooth drivers (Greg Kroah-Hartmann, Masoodur Rahman)
• USB serial update (Greg Kroah Hartmann)
• Workaround for some usb keyboards (Itai Nahshon)
• Minolta DImage4 entry for unusual_devices (Petr Konecny)
• OHCI completion of unlinked urbs fix (David Brownell)
• Tighten AC97 modem detect rules (me)
• Report AC97 codecs by their PNP ID (me)
• Further sis memory checks (Zwane Mwaikambo)
• Add new opcodes to the hdreg.h IDE table (Andre Hedrick)
• Update cris and x86_64 ide.h files (Andre Hedrick)
• Fix includes in freecom.c (Andre Hedrick)
• Winbond IDE requires PCI (Andre Hedrick)
• icside cleanup (Andre Hedrick)
• Report ide unregister failures (Andre Hedrick)
• Clean up legacy hd driver to use outb (Andre Hedrick)
• Ditto for ide-cs (Andre Hedrick)
• ns87415 needed to call its own ide_dma_end (Andre Hedrick)
• Make via_base unsigned long not uint (Andre Hedrick)
• Update ide-ppc (probably broken until some other changes go in) (Bartlomiej Zolnierkiewicz Andre Hedrick)
• Fix bugs in the ide-cd -> ide-scsi pass over (Andre Hedrick)
• Kill GET_ERR macro in ide-disk (Andre Hedrick)
• IDE dma hack fix for etrax - needs to be generalised (Andre Hedrick)
• Update as yet unused ide-lib code (Andre Hedrick)
• Fix types in ide_probe reporting (Roman Zippel)
• Add disable/enable irq probe handling (Roman Zippel)
• Fix non PCI IDE build problems (me)
• Merge Matrox G450 updates (Petr Vandrovec)
• Re-enable DRM for GMX2000 (it doesnt work yet) (me)

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/report.sh results/log > results/report
sh pgms/index.sh 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

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
2.4.19: http://khack.osdl.org/stp/3877/results/report
2.5.33: http://khack.osdl.org/stp/4928/results/report

Another compare...why does pre5 appear a little worse than pre4 ?
2.4.20-pre5: http://khack.osdl.org/stp/4836/results/report
2.4.20-pre4: http://khack.osdl.org/stp/4581/results/report

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

At http://www.xs4all.nl/~zippel/lc/lkc-0.4.tar.gz 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:

• correct dependencies for the config files are now generated, "make oldconfig" isn't needed anymore in many cases (you should try it before making any comments about it).
• config rulebase is with some small (known) exceptions the same in the old and new syntax, even comments are now preserved.
• menuconfig is working again. Except of xconfig the user interface is almost as before, anything you could do before, you still can do.
• it's much faster in the common case.
• clean separation between frontends and backend.

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:

choice
  prompt "Adaptec AIC7xxx support"
  optional
  depends SCSI

config SCSI_AIC7XXX
  tristate "New driver"
  help
  ...

config AIC7XXX_CMDS_PER_DEVICE
  int "Maximum number of TCQ commands per device"
  depends SCSI_AIC7XXX
  default "253"
  help
  ...

config AIC7XXX_RESET_DELAY_MS
  int "Initial bus reset delay in milli-seconds"
  depends SCSI_AIC7XXX
  default "15000"
  help
  ...

config AIC7XXX_BUILD_FIRMWARE
  boolean "Build Adapter Firmware with Kernel Build"
  depends SCSI_AIC7XXX

config SCSI_AIC7XXX_OLD
  tristate "Old driver"
  help
  ...

config AIC7XXX_OLD_TCQ_ON_BY_DEFAULT
  boolean "Enable Tagged Command Queueing (TCQ) by default"
  depends SCSI_AIC7XXX_OLD
  help
  ...

config AIC7XXX_OLD_CMDS_PER_DEVICE
  int "Maximum number of TCQ commands per device"
  depends SCSI_AIC7XXX_OLD
  default "8"
  help
  ...

config AIC7XXX_OLD_PROC_STATS
  boolean "Collect statistics to report in /proc"
  depends SCSI_AIC7XXX_OLD
  help
  ...

endchoice

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
$CONFIG_SCSI
   if [ "$CONFIG_SCSI_AIC7XXX" != "n" ]; then
      ...
   fi
fi
if [ "$CONFIG_SCSI_AIC7XXX" != "y" ]; then
   dep_tristate 'Old Adaptec AIC7xxx support' CONFIG_SCSI_AIC7XXX_OLD
$CONFIG_SCSI
   if [ "$CONFIG_SCSI_AIC7XXX_OLD" != "n" ]; then
      ...
   fi
fi

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. :)

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 ftp://ftp2.linux.org.uk/pub/linux/people/alan/patches. I'll upload it to kernel.org at some point later on.

Linux 2.4.20-pre5-ac3

• Fix procfs handling for zoran driver (Silvio Cesare)
• ZR36067 doesn't support bitmask clipping so error such a request. (Silvio Cesare)
• LBA48 on older promise IDE fix (Mike Isely)
• Report jfs tools version in ver_linux (Steven Cole)
• HP XP arrays can need largelun (Steve Mickeler)
• Allow maestro3 gpio amp control setup by nd for odd machines (Panasonic CF-72) (Michael Olson)
• Add autodetect to the CF-72 maestro3 funny (me)
• Fix overlarge read in vicam usb (Silvio Cesare)
• Length limit S/390 cio proc write files (Silvio Cesare)
• Length limit S/390 chandev proc write files (Silvio Cesare)
• Length limut S/390 dasd statistics write (Silvio Cesare)
• Two fixes to 3270 driver for S/390 (Silvio Cesare, me)
• Fix buffer limits in tubfs for S/390 | Really this code wants redoing to loop rather than do shorter read/writes on full buffers. but thats not trivial (Silvio Cesare)
• Use define values not magic constants on S/390 netiucv buffer checks (Silvio Cesare)
• Correct a vmalloc corner case (Dave Miller)
• Fix hisax oops with out of range card type (Alan Hourihane)
• Update Documentation/Changes for reiserfs (Neils Jensen)
• Fix incorrect type in i2c-core (Silvio Cesare)
• Fix length limits in i2c-dev (Silvio Cesare)
• Fix incorrect type in amdtp (Silvio Cesare)
• Update Buslogic maintiners entry 8(
• Don't register a gameport at I/O zero if none s configured on es1370, es1371, (me)
• Handle unprintable ac97 codec names (STAC) (me)
• Restructure pcigame and trident audio not to fall over each other (me)

**
** WARNING: THIS IS THE NEXT BIG IDE UPDATE. ITS BOUND
** TO BREAK SOMETHING. DONT USE THIS ON DATA YOU CARE ABOUT
**

Since kernel.org still seems down I've put this on ftp://ftp2.linux.org.uk/pub/linux/people/alan/

Linux 2.4.20-pre5-ac4

• Fix error path bug in pci resource code (Keith)
• Fix p4-clockmod compile error (Adrian Bunk)
• Align packets nicely on kaweth USB ethernet (Oliver Neukum)
• Further Changes file fix (Steven Cole)
• TCP timestamp handling fix (Dave Miller)
• Compile warning fixes (Niels Jensen)
• Next batch of IDE header updates (Andre Hedrick)
• IDE scsi update | Needs some highio cleanup yet (Andre Hedrick)
• IDE DMA updates (Andre Hedrick)
• Update the IDE PCI driver layer (Andre Hedrick)
• Fix pdc202xx further braindamage (me)
• Further icside fixes (Bartlomiej Zolnierkiewicz)
• Fix ide-lib atapi DMA check (Bartlomiej Zolnierkiewicz)
• CMD64x rev 5/7 UDMA check fix (Bartlomiej Zolnierkiewicz)
• Add blk_fs_request helper (Jens Axboe)
• IDE highmem fixes (scsi needs doing I suspect) (Jens Axboe)
• Longer PIO timeout for taskfile write (Andre Hedrick)
• Fix promise cable detect (Andre Hedrick)
• Split promise into old and new drivers (me)

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.

trivial: I'd be inclined to use:

void iowait_schedule()
{
        atomic_inc(...);
        schedule();
        atomic_dec(...);
}  

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.

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).

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 http://home.attbi.com/~minyard, 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?

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:

http://ftp.linux.org.uk/pub/linux/willy/patches/bmc.diff

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.

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).

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
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.33-1.bz2

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

A new WEB site for the e2compress patch on the 2.4 kernel is available at http://www.alizt.com .

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

The fixed bugs are :

• Deadlock correction between compressing cluster and sync of pages.
• Management of MAPPED and DIRTY buffer flags.
• Test of block numbers in compression.
• Test if page is dirty to allocate buffer when compressing.
• When decompressing cluster use the size of the cluster and not the size of the file, because it can be called from vmtruncate (the size of the file has already changed).
• Management of working area lock.
• When (de)compressing file containing holes, the data must be moved and not only the block number.
• New function ext2_decompress_pages() to allocate blocks for a cluster already read (block decompressed). It is now called in ext2_decompress_cluster() and not only in ext2_file_write().

Feel free to contact me if you have some problems.

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.

1. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va10-hwchecksum-2.5.33.patch
   This patch enables HW-checksum against outgoing packets including UDP frames.

2. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va11-udpsendfile-2.5.33.patch
   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.

3. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va-csumpartial-fix-2.5.33.patch
   This patch fixes the problem of x86 csum_partilal() routines which can't handle odd addressed buffers.
4. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va01-zerocopy-rpc-2.5.33.patch
   This patch makes RPC be able to send some pieces of data and pages without any copies.
5. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va02-zerocopy-nfsdread-2.5.33.patch
   This patch makes NFSD pass pages in pagecache to RPC layer directly when NFS clinets request file-read.
6. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va03-zerocopy-nfsdreaddir-2.5.33.patch
   nfsd_readdir can also send pages without copy.
7. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va04-zerocopy-shadowsock-2.5.33.patch
   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.
8. ftp://ftp.valinux.co.jp/pub/people/taka/tune/2.5.33/va05-zerocopy-tempsendto-2.5.33.patch
   If you don't want to use sendfile over UDP yet, you can apply it instead of 1) and 2) .

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.

Copy & paste from its webpage ( http://www.vanheusden.com/ved/ ):

video-entropyd

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.

http://www.vanheusden.com/ved/

You also might want to take a look at audio-entropyd: http://www.mindrot.org/audio-entropyd.html

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'

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.

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.

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").

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.)

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).

Updated fully preemptive kernel patches are available at:

2.4.19: http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-2.patch
2.4.20-pre5: http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.20-pre5-1.patch
2.4.20-pre5-ac4: http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.20-pre5-ac4-1.patch

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...

The Linux Test Project test suite LTP-20020910.tgz has been released. Visit our website ( <http://ltp.sourceforge.net> ) 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 <http://ltp.sourceforge.net/expected-errors.php>

The highlights of this release are:

• New "utils" section created and added to the CVS tree. This repository will hold various utilities, including kernel coverage analysis tools and STAX execution scripts.
• LTP website has been modified to contain detailed information about kernel code coverage, including details on lcov (LTP's GCOV extension) and documentation on how to use lcov for generating coverage information.
• New test driver created that runs over the STAf eXecution (STAX) service of the Software Test Automation Framework (STAF) <http://staf.sourceforge.net>. The driver is available to download from the "Utilities" category of the Files section, as well as the "utils" section of the CVS tree.
• Documentation on configuration and use of the new STAX LTP driver, with screenshots, posted on LTP website.

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 runpan.sh                          ( Paul Larson )  
- runtest/syscalls:
        a.Removed the {} from the environment    ( Robbie Williamson )
          variables
        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 )
  "nfsx-linux"
- 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 runalltests.sh 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.

At http://www.xs4all.nl/~zippel/lc/lkc-0.5.tar.gz you can find the latest version of the new config system. Besides various small bug fixes, it includes the following changes:

• Improved mouse interface of qconf
• qconf isn't build if QT isn't available
• "if" ... "endif" block added
• update to 2.5.35

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.

The most current version of this status report can be found at: http://members.cox.net/tmolina/kernprobs/status.html

   Notes:
     * 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", 
__FUNCTION__)

              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

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 info@timpanogas.org. 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 jmerkey@nai.com. If your questions are regarding any TRG specific code, please send these inquiries to the timpanogas.org address specified above.