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

Kernel Traffic #163 For 21 Apr 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1133 posts in 4984K.

There were 397 different contributors. 178 posted more than once. 148 posted last week too.

The top posters of the week were:

1. Non-BitKeeper Patches Preferred For Development

5 Apr 2002 - 13 Apr 2002 (13 posts) Archive Link: "ReiserFS Bug Fixes 3 of 6 (Please apply all 6)"

Topics: Development Policy, FS, Version Control

People: Linus TorvaldsLarry McVoyHans Reiser

Hans Reiser posted a BitKeeper-generated patch, and Linus Torvalds replied:

Please don't use bk patches, they have turned out to be pretty much unusable.

Either make a (controlled) bk tree available for pulling, or just use old-fashioned patches.

Larry McVoy agreed that BitKeeper patches wouldn't work under some common circumstances, and recommended Linus' solution as well. He described:

BK won't let you accept a patch unless the receiving repository has the parent of the patch. In other words, this won't work:

bk clone bk://
<make some changes>
bk commit (or bk citool) # creates changeset 1.800
<make some changes>
bk commit (or bk citool) # creates changeset 1.801
# Now you want to send the second patch to Linus so you do a:
bk send -r+ - | mail

That will fail when Linus tries to accept the patch, because he doesn't have your 1.800.

2. Status Of HP ScanJet 2200c Support

15 Apr 2002 (2 posts) Archive Link: "HP scanjet 2200c support"

Topics: Printers

People: Eric Weigle

Pablo Alcaraz asked if the HP ScanJet 2200c was supported under Linux, and Eric Weigle pointed him to and

3. Some Preemption Discussion

15 Apr 2002 (3 posts) Archive Link: "[PATCH] 2.5: don't miss a preemption"

Topics: Real-Time, SMP

People: Robert LoveHugh Dickins

Robert Love posted a patch and explained:

Current kernel preemption code opens a small window between the check for need_resched in schedule and the setting of preempt_count to zero in preempt_schedule. While this window is generally short (a few cycles) the resulting period of non-preemptibility could be as long as the next timer tick - much longer, in fact, if a lock is obtained in the interim.

This patch checks for need_resched in preempt_schedule after setting preempt_count back to zero, before returning. The overhead is negligible and it is crucial to never miss a preemption opportunity.

Out of curiosity, Hugh Dickins asked why it was so important never to miss a preemption opportunity. Robert replied:

Two main reasons:

  1. In 2.5, we have a kernel preemption model that makes the fully preemptible, subject to SMP locking constraints and a few other rules. Without this patch, we break this model and do not allow preemption when it is in fact legal.
  2. Like I said, it may be awhile before we can preempt again. If we take a lock after return from schedule but before the next interrupt, it can be many tens (or hundreds) of milliseconds before we release the lock and subsequently preempt. If need_resched was set in response to an important real-time application, the wait can be detrimental. Servicing apps as soon as they become runnable is the point of preempt-kernel, anyhow.

It is not crucial in the sense we break anything; merely that we are working toward providing very efficient response and dispatch to interactive and real-time applications and we _must_ respond to them as soon as possible.

End of thread.

4. Best Compiler To Use For TriCore Linux Port

16 Apr 2002 (2 posts) Archive Link: "Kernel 2.4.x and gcc version"

Topics: Compiler, Porting Linux

People: Yannis MitsosAlan Cox

Yannis Mitsos asked:

I am a member of a small team which is trying to port Linux to Infineon's TriCore processor. The gcc version that is available for the aforementioned processor is 2.8.1. On the other hand the aforementioned processor does not embed a MMU, so we are using the uClinux patch with the 2.4.x kernel.

I am wondering if with the 2.8.1 version we will be able to obtain a reliable 2.4.x kernel. According to the /Documentation/Changes file the gcc 2.95.3 is required...

Between the gcc version 2.8.1 and the 2.95.3 some extra flags and options have been added, but are all these requisite for ALL the processors ???

Alan Cox replied, "On the whole probably not." But he added, "gcc 2.95.3 is the one that is minimal for the x86 processor core. How it behaves with other platforms is going to vary. Many of the problems with the older compiler where with register allocation, which is a very big x86 problem but much less of an issue on other compilers." End of thread.

5. Status Of ServeRAID Maintainership And Code

16 Apr 2002 (11 posts) Archive Link: "[PATCH] fix ips driver compile problems"

Topics: Development Philosophy, Disk Arrays: RAID, Disks: SCSI

People: Dave HansenAlan CoxLinus Torvalds

Dave Hansen posted a patch that had been floating around internally at IBM for some time. He said, "it applies to 2.5.8 and the ServeRAID driver works just fine with it applied. Without it, the driver fails to compile." In a later post he added:

I have no official connection to the writing of this driver. It's a big company :) I'm most interested in this because I have an old ServeRAID card at home.

I know that none of the real authors is actively working on fixing this.

Can this be accepted as a band-aid until the maintainers decide to maintain a 2.5 driver, or are we pushing authors to rewrite drivers which don't use the new DMA scheme?

Alan Cox said, "Its not a band aid, its a bug. It happens to work by freak chance on x86. Its much better it stays visibly broken until its fixed." But close by, Linus Torvalds said:

Quite frankly, since after several months of being broken, nobody has stepped up to actually fix it, I am most definitely going to accept the band-aid solutions to SCSI drivers that will thus only work on x86.

"Not acceptable" is when broken drivers means that people can't test the features they _care_ about. Apparently nobody seems to care about the SCSI driver itself..

6. Kernel Source Tree Reorganizations

16 Apr 2002 - 17 Apr 2002 (11 posts) Archive Link: "[PATCH] i386 arch subdivision into machine types for 2.5.8"

Topics: PCI, Power Management: ACPI, SMP, Source Tree, Version Control, VisWS

People: James BottomleyEric W. BiedermanPatrick Mochel

James Bottomley announced some reorganization of the kernel source tree. He said:

This patch tries to split arch/i386 up into machine specific directories (similar to the way arch/arm is done). The idea is to separate out those machines which don't look like standard PCs (particularly from an SMP standpoint). For the current kernel, all it really does is to get the visws stuff into a separate directory (arch/i386/visws). I've also taken some files which aren't going to be used by non-pc SMP machines (mainly related to mpbios and ioapic) and placed them into arch/i386/generic.

The patch goes much further than visws needs, mainly because it now allows me to add my voyager stuff in a separate arch/i386/voyager directory with virtually no disturbance of the main line code. I'm afraid there are also still four VISWS defines in arch/i386/kernel/smpboot.c because it wasn't obvious to me how to get rid of them simply.

The 269k diff file (large because it has a lot of file moves) is at

There's also a bitkeeper repository with all this in at

I haven't done anything about the other half of i386/arch reform which is splitting the PC directory up into bus types, but I believe Patrick Mochel is thinking about this.

Eric W. Biederman replied:

A couple of comments.

And of course you don't look at allowing different firmware implementations, but I'm doing that, so it is covered. :)

Elsewhere, Patrick Mochel summarized his own work:

Not necessarily bus types, but close.

I've done three sets of cleanups in the arch/i386/kernel/ directory:

Each one does similar things to those drivers: moves the support into subdirectories, and splits the monolithic files into platform-specific modules.

Doing this has several advantages:

The main motivation behind this has been the PCI driver, especially with the numerous conflicting changes that I've seen both personally, and with the various ACPI and NUMA changes. I've been wanting to do something like this for about a year. About a month ago, I finally just sat down and did it.

The patches can all be found at

Unfortunately, maintaining these massive changes is time consuming, and conflicting with other goals and timelines. The only one I really care about is the PCI driver. I've had a chance to up-port it to 2.5.8, and should work for most people (though I've only tested it on single and dual x86 boxes w/o ACPI support)

The CPU cleanups are against ~2.5.6, and most likely won't apply to the current tree. Conflicts tend to be obvious, and easily fixable, if anyone is willing to up-port it.

Ditto for the mtrr driver, though it's pretty stale (~1 month old), and likely to have more conflicts.

If there is serious interest, I'll up-port them to the latest kernel and export BK trees.

7. Using BitKeeper And CVS For Framebuffer Development

16 Apr 2002 - 17 Apr 2002 (16 posts) Archive Link: "Fbdev Bitkeeper repository"

Topics: Framebuffer, Version Control

People: M. R. BrownJames SimmonsLarry McVoyRoman Zippel

James Simmons announced that he'd created a BitKeeper repository for the framebuffer layer, and offered to give access to folks who sent him their public-key. M. R. Brown replied, "Please tell us that primary framebuffer/input/console development will continue in the CVS drop-in tree on SourceForge? Bitkeeper is unable to support this (easier, more efficient) style of development." Larry McVoy asked why M. R. thought CVS was easier and more efficient than BitKeeper, and the two of them argued back-and-forth for awhile, with Roman Zippel chiming in eventually that this was off-topic and should be taken to a more relevant mailing list. But at one point, after M. R. and Larry had been going at it for a couple of days, James said, "To answer the question are we going to drop CVS drop in support of the linux console project. No!! The reasons have nothing to do with politics or who is better. The reason for this is some people want to use CVS and don't want to spend the time learning bitkeeper. That is their choose. I don't want to force anyone to do something they don't want. Have both bitkeeper and CVS is a plus in many ways to many people."

8. Trouble Using Preemption On 2.5.8 SMP Systems

17 Apr 2002 (3 posts) Archive Link: "2.5.8: preemption + SMP broken ?"

Topics: Real-Time, SMP

People: Robert LoveDipankar Sarma

Dipankar Sarma reported that his 4 CPU 486 would hang at boot, if SMP and preemption were enabled in the kernel. Robert Love posted a patch, explaining, "all my testing is on SMP. The problem manifested itself in 2.5.8-pre when some changes where made to the migration code. The race is in the migration code - I am not sure it is preempts fault, per se, but the attached patch should fix it. It is pending with Linus for the next release." Dipankar tried it out and reported complete success.

9. Setting Process CPU Affinity

17 Apr 2002 (2 posts) Archive Link: "binding a process to a processor"

Topics: SMP

People: Robert Love

Lee Chin how to make sure a particular process would stay on a particular CPU in an SMP system, and Robert Love replied:

In 2.5, there is the system call sched_setaffinity. It is rather new so your libraries do not support it - see example code and headers at:

For 2.4, there is not yet such an interface. At the above URL, you can find a proc-based and a syscall-based interface for setting and retrieving affinity.

End of thread.







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.