Kernel Traffic #133 For 17�Sep�2001

By Zack Brown

linux-kernel FAQ ( | subscribe to linux-kernel ( | linux-kernel Archives ( | ( | LxR Kernel Source Browser ( | All Kernels ( | Kernel Ports ( | Kernel Docs ( | Gary's Encyclopedia: Linux Kernel ( | #kernelnewbies (

Table Of Contents


This issue of Kernel Traffic is dedicated to the people who died in the World Trade Center buildings, the Pentagon, and the four hijacked planes.

I don't know anyone, in the US and abroad, who was not overwhelmingly affected by the attack. My roommate knew someone on one of the planes. My mother was in Manhattan at the time, half a mile away from the World Trade Center, and watched them from her window as they fell. I've heard dozens of stories over the past week, of people who knew people who by chance were spared, or who's fate is still not known.

Unfortunately, in the absense of a known or accessible enemy, many Americans are blaming Arab people in general, and street-violence against them has already increased. It's important, when confronted with violence against ourselves, that we not sink to the level of our attackers. Just as innocent people were struck at random on Tuesday, so now many Americans are striking innocent people at random today. Don't these Americans tend to legitimize that form of combat by engaging in it themselves?

Likewise, I feel it is important for the United States government to recognize and affirm the self-imposed limitations that give it much of its value as a government. If it decides to set aside a regard for human rights in its quest to stop these sorts of attacks, then the laws and precedents set in the coming weeks and months will remain in place for a long time to come, and will be very difficult to overturn later. And by discarding human rights even in part, will America not then be legitimizing other countries that do the same?

These are difficult days, requiring thought, introspection, and study. Hopefully America and the world will rise to the occassion.

Mailing List Stats For This Week

We looked at 1412 posts in 5692K.

There were 459 different contributors. 201 posted more than once. 154 posted last week too.

The top posters of the week were:

1. Status Of Real-Time Linux

6�Sep�2001�-�9�Sep�2001 (19 posts) Subject: "[PATCH] (Updated) Preemptible Kernel"

Topics: Real-Time, SMP, Small Systems

People: Robert Love,�Phillip Susi,�Daniel Phillips,�Christoph Lameter,�Chris Ricker,�Stephen Frost

Robert Love announced:

Available at (about 29K):

for kernel 2.4.10-pre4 and 2.4.9-ac9, respectively.

Changes since previous post:

Changes since original patch:

This patch allows a new config setting, CONFIG_PREEMPT (set in `Processor Type and Features') that enables a fully preemptible kernel. Preemption is controled via SMP lock points. Control of execution is yielded to higher processes even if the currently running process is in kernel space.

This should increase response and decrease latency, and is a highly recommended patch for real-time, audio, and embedded systems. However, it is recommended for anyone. I use it on my everyday workstation.

An interesting new article on a preemptible kernel in linux is available at:

Phillip Susi asked, "am I correct in assuming that this only allows preemption during code that is called from user space? For instance, it would be bad to preempt an ISR or BH, right? Actually... what happens if say, the kernel called from user space is holding a lock, and gets preempted?" Daniel Phillips replied, "The thread will eventually get rescheduled and release the lock."

Elsewhere, under the Subject: Linux Preemptive patch success 2.4.10-pre4 + lots of other patches () , Christoph Lameter reported success with the patch under 2.4.10-pre4, and said he wished it would get into the kernel soon. He added, "Given the minimal nature of the patch I would suggest that it become part of 2.4.10 or 11" But Robert replied:

Are you kidding? We will be lucky to see this in during 2.5.

Its a pretty big change. It makes the Linux kernel preemptible. This is a fairly big move, one I don't think any of the major Unices have done. The only reason the patch is not _huge_ is because the Linux kernel is already setup for concurrency of this nature -- it does SMP.

I suggest you read

and my previous threads on this issue, for more informaiton.

Daniel Phillips said it could always be made into a config option, and added, "The other Unices are at least evenly split, or mostly preemptible. Typically, a more complex strategy is used where spinlocks can sleep after a few spins. This patch is very conservative in that regard, it basically just uses the structure we already have, SMP spinlocks."

Elsewhere, Robert asked which UNICES were preemptible, since he'd been under the impression Irix was the only one. Chris Ricker replied, "Solaris is, and has been since good ol' Solaris 2.0. So's AIX and even more obscure things like DG/UX. I'd think all SysVR4 derivatives have to be, by virtue of the SysV schedular (threads have priorities from 0 to 159; system threads run from 60 to 99, so the schedular must be able to preempt system threads for the real-time threads from 100 to 159)."

Elsewhere, under the Subject: Trouble with update Preemptive patch for 2.4.9-ac9 () , Jordan Breeding reported an oops with an SMP kernel 2.4.9-ac9, and Robert replied, "I will take a look at this, but note that currently the patch is experimental with SMP enabled." Stephen Frost volunteered to be an SMP guinea-pig for the patch, and Robert said:

I would certainly take you up on that offer. I honestly don't think the patch is ready for SMP, yet -- but we have to start somewhere.

apply the patch and set CONFIG_SMP and CONFIG_PREEMPT to 'y' and let it run. Any errors, OOPS, etc, pass them this way.

Unfortunately, if the patch fails, its going to fall hard. If the preemption is imperfect during SMP, certainly you will hardlock.

It might help to enable CONFIG_DEBUG_SPINLOCKS and CONFIG_DEBUG_BUGVERBOSE -- these are present in the -ac tree. The NMI watchdog might prove useful, too.

But honestly, just telling me it locks on boot is useful, so whatever you can manage.

2. Toshiba IDE DMA Docs Available

7�Sep�2001 (6 posts) Subject: "Toshiba IDE DMA support"

Topics: Disks: IDE

People: Alex Deucher,�Andre Hedrick

Alex Deucher announced, "I just received the documention for the IDE conrollers in may older Toshiba notebooks. These controllers are capable of DMA, but at the moment do not have it implemented. I know nothing about programming IDE drivers, so if anyone is interested in developing these drivers shoot me an email and I can send you the docs and help with testing (I have several notebooks to test on). I'd like to get into it myself, but just don't have the time." Andre Hedrick replied, "Sure send the docs over!"

3. Status Of ext3

7�Sep�2001�-�12�Sep�2001 (8 posts) Subject: "ext3-2.4-0.9.9"

Topics: FS: ext2, FS: ext3, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced his latest ext3 patch:

Patches against 2.4.10-pre4 and 2.4.9-ac9 are at

It's a fairly large change. The most significant parts are

There have been two reports of a possible interaction problem with vfat where a readdir on the vfat mountpoint returns ENOTDIR when ext3 is present in the kernel. This has proved elusive and in fact has been observed on systems where ext3 was never used. It is probably a vfat bug.

At the above website there is also a patch from Ted Ts'o which will provide significant speedups for accessing large directories. Ted's equivalent patch for ext2 has already been incorporated into the official kernel(s). If possible, please test Ted's patch on top of ext3 0.9.9.

4. Binary-Only Lucent Drivers

9�Sep�2001�-�10�Sep�2001 (5 posts) Subject: "Problem with i810 chipset"

Topics: Modems

People: Steve Kieu,�Alan Cox,�Horst von Brand

Steve Kieu reported a system lockup when exiting X, if an Internet connection was active. He listed among his system components, "Lucent software modem using lt-modem driver version 5-99b" . Alan Cox replied, "Please report problems with binary only drivers to the driver vendor, it could be any kind of incompatibility and as we have no source only they can help you." Horst von Brand suggested checking out the latest driver, somewhere on Steve tried it and it worked.

5. Developers Respond To Question About Binary-Only Code

10�Sep�2001 (8 posts) Subject: "Developing code for ia64"

Topics: Binary-Only Modules

People: Shmulik Hen,�Arjan van de Ven,�David Woodhouse,�Alan Cox,�Rik van Riel

Shmulik Hen of Intel asked, "When developing kernel drivers (module) for ia64, is it necessary to do it on an ia64 machine? Our product contains a pre-compiled core object (IP protection :-\ ) and a set of wrapper source files, so for dual platform support the tar ball has to contain both an ia32 and ia64 versions of the executable. Is there any way to get an ia64 compiler (and libs) installed on an ia32 machine and use it to get ia64 compatible binaries?" Arjan van de Ven replied, "I would seriously recommend to intel to consider NOT doing this. Binary only modules are generally frowned upon and there is (almost) never a good reason for doing them." David Woodhouse also replied to Shmulik, "This list is for people interested in Linux, which is Free Software. If you are not working on Free Software, then your message is off-topic, and offensive to many. You should not expect to get any assistance here. Please go away." Alan Cox also replied to Shmulik, "Our operating system contains a GPL license (IP protection ...) that makes the whole issue questionable. Remember the GPL forbids linking of non GPL code." He added, "If you are doing proprietary software please take it off this list. Perhaps you should get a paid support contract for the compiler." Rik van Riel also replied to Shmulik, "Your email address has been saved, bug reporters about any intel binary only driver will be told to ask you."

At some point, Shmulik said, "I would like to take back my question regarding this closed source development. It is indeed not the community role to support non GPL development and I'm sorry for bothering you. The product I was referring to is not a hardware device driver (which are all open source)."

End Of Thread. Although the code in question was not a kernel module, the reaction it received shows the general attitude of linux-kernel to binary-only modules.

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.