Kernel Traffic #145 For 10 Dec 2001

By Zack Brown

Table Of Contents


The search engine is back. Kir Kolyshkin and Alexander F Avdonkin have graciously set up an aspseek engine to provide searching capabilities for this site. Aspseek ( is a company that releases its search engine under the GPL. They have promised that the only banner ads on the search pages will be for their own company, which seems fitting.

Many thanks to Kir and Alexander for doing all the hard work. Thanks, folks!

Mailing List Stats For This Week

We looked at 1707 posts in 7339K.

There were 589 different contributors. 274 posted more than once. 242 posted last week too.

The top posters of the week were:


1. Using XFS With Kernel Pre-Emption
26 Nov 2001 - 1 Dec 2001 (5 posts) Archive Link: "Mixing Patches: pre-emptive + xfs"
Topics: FS: XFS
People: Robert LoveAnuradha RatnaweeraKeith Owens

Jeremy Elgar asked if there were any problems with using the pre-emptive patches alongside the XFS patches. Bill Dunn thought Jeremy might have to do a little massaging to get the patches to play nice together, which he found to be common with multiply-patched kernels. But Michael Dunsky and Anuradha Ratnaweera reported that they'd been running kernels with those patches for some time, with no problems, and Robert Love added for good measure, "The only problem reported was a compile error, which Keith Owens merged a fix for. If you do have problems, report them and perhaps we can help."


2. Brief Discussion Of Why Marcelo Is 2.4 Maintainer
27 Nov 2001 - 1 Dec 2001 (8 posts) Archive Link: "PATCH: 2 small patches against 2.4.15-pre6 (sym2 + email change) (fwd)"
People: Gerard RoudierMike FedykMarcelo TosattiAlan CoxChristophe Barbe

In the course of asking a different question, Gerard Roudier asked Marcelo Tosatti, "By the way, I missed the postings that made you the maintainer of 2.4 kernel neither saw any comments from Alan about. I am sure that you will do the best you can and will do a very good work, but I feel a bit frustrated not to know the reasons of this decision. If you can point me to the corresponding articles, I will be very interested in." Christophe Barbe pointed Gerard to an Advogato entry ( from Alan Cox, but Gerard replied that this satisfied him, but Mike Fedyk said, "This doesn't really show *why* he was chosen. Marcello hasn't gotten much press in the past." He added, "Yes, it does look like a big change from the outside. Even for LKML readers ;)"

Elsewhere, Marcelo also replied to Gerard's initial question, pointing to the Advogato entry and saying, "Well, basically, it seems Alan got tired of maintenance... :)"


3. Renovating The Block Layer In 2.5
27 Nov 2001 - 1 Dec 2001 (34 posts) Archive Link: "2.5.1-pre2 does not compile"
Topics: Disks: IDE, Disks: SCSI
People: Linus TorvaldsChristoph HellwigPaul MackerrasMartin DaleckiAndreas DilgerDaniel PhillipsRobert Love

Someone encountered some compiler errors while trying to test 2.5.1-pre2, and Linus Torvalds replied:


The next-generation block-layer support is starting to be merged into the 2.5.x tree, and that breaks old drivers that haven't been updated to the new locking.

In particular, there used to be _one_ lock for the whole IO system ("io_request_lock"), and these days it's a per-block-queue lock.

In many cases the fix is as simple as just replacing the "io_request_lock" with "host->host_lock", but sometimes this is complicated by the need to pass the right data structures down far enough..

Many drivers have been converted (ie IDE, symbios, aic7xxx etc), but many more have not (especially older SCSI drivers, in your case it's the classic aha1542).

It will probably take some time until most drivers have been converted. Tested patches are more than welcome.

Christoph Hellwig suggested that, as long as they were breaking SCSI, he'd be happy to submit a patch "to remove the old-style (2.0) scsi error handling completly, forcing drivers still using it to be fixed? Early 2.5 looks like a good time for that to me.." Robert Love also supported this idea, and Linus said, "I agree, that sounds like a good thing, and as I consider the block layer to be one of the major pushes for 2.5.x it makes perfect sense." Christoph posted the patch, and he, Andreas Dilger, and Martin Dalecki had a brief technical discussion about it.

Paul Mackerras also replied to Linus, asking, "Is there a description of the new block layer and its interface to block device drivers somewhere? That would be helpful, since Ben Herrenschmidt and I are going to have to convert several powermac-specific drivers." Daniel Phillips gave a link to, and Linus confirmed that this was the doc to go by. Various folks discussed the ideas in that doc.


4. New Framebuffer API For Kernel 2.5
28 Nov 2001 - 30 Nov 2001 (6 posts) Archive Link: "[PATCH] Hooks for new fbdev api"
Topics: Framebuffer
People: James SimmonsGeert UytterhoevenPetr Vandrovec

James Simmons posted a patch against 2.5.0 and announced happily:

This is my first public release of the new api of the framebuffer layer. The basic goal is to remove all the excess duplicate code and to place all the console related code into fbcon.c. The second goal to allow the framebuffer layer to exist without the console system. On embedded devices that lack a keyboard it makes no sense plus it takes up valiable space to have the VT system compiled in. The 3rd and finally goal is to allow fbdev driver writing to be easy and yet flexiable.

This patch shows 3 basic things I like to change.

  • Universal cursor api. This allows the fbcon layer to not be required hooks to program the cursor for every type of card avaliable. This allows a seperation of fbdev and fbcon.
  • Move from framebuffer base to more accel engine base. This allows the complete removal of console code from the low level framebuffer drivers and we get ride of those god forsaken fbcon-cfb* files. So we end up with a huge code reducution and this encourages the driver write to write much faster fbdev drivers. Note these our the basic accels needed for the fbcon layer. They are not used by userland in anyway. It also means you have only 3 basic functions to deal with instead of the 7 of struct display_switch.
  • Removal of duplicate code. Examples are the fb_cmap functions which are basically the same in every driver. So you will be seeing soon a fbgen2 that will have the same code that is duplicated over and over again in each driver.

Geert Uytterhoeven and Petr Vandrovec had some technical comments, and they all went back and forth briefly about it.


5. Cleaning the BKL Out Of 2.5
28 Nov 2001 - 1 Dec 2001 (26 posts) Archive Link: "[PATCH] remove BKL from drivers' release functions"
People: David Hansen

David Hansen posted a patch to remove the big kernel lock (BKL) from a bunch of places in drivers in the 2.5 tree. He explained, "Many of these patches simply remove the BKL from the file. This causes no harm because the BKL was not really protecting anything, anyway. Other patches try to actually fix the locking. Some do this by making use of atomic operations with the atomic_* functions, or the (test|set)_bit functions. Most of these patches replace uses of normal integers which were used to keep open counts in the drivers. In other some cases, a spinlock was added when the atomic operations could not guarantee proper serialization by themselves. And, in very few cases, the existing locking was extended to protect more things. These cases are very uncommon because locking is very uncommon in most of these drivers." Various folks discussed this, with the general concensus being that getting rid of the BKL was always good.


6. Kernel 2.4.17-pre2 Released
30 Nov 2001 (2 posts) Archive Link: "Linux 2.4.17-pre2"
Topics: BSD, FS: ReiserFS, FS: ext2, Power Management: ACPI, USB
People: Marcelo TosattiPete ZaitcevDavid HindsJean TourrilhesGreg KHBen CollinsPatrick MochelPaul MackerrasDavid S. MillerNikita DanilovAlan CoxDouglas GilbertRussell KingDave McCrackenChristoph HellwigRobert LoveAndrew Morton

Marcelo Tosatti announced 2.4.17-pre2. He included the changelog:

Lots of driver changes this time...

Also, I want to know if people feel any difference on interactivity under heavy IO workloads.


  • Remove userland header from bonding driver (David S. Miller)
  • Create a SLAB for page tables on i386 (Christoph Hellwig)
  • Unregister devices at shaper unload time (David S. Miller)
  • Remove several unused variables from various places in the kernel (David S. Miller)
  • Fix slab code to not blindly trust cc_data(): it may be not valid on some platforms (David S. Miller)
  • Fix RTC driver bug (David S. Miller)
  • SPARC 32/64 update (David S. Miller)
  • W9966 V4L driver update (Jakob Jemi)
  • ad1848 driver fixes (Alan Cox/Daniel T. Cobra)
  • PCMCIA update (David Hinds)
  • Fix PCMCIA problem with multiple PCI busses (Paul Mackerras)
  • Correctly free per-process signal struct (Dave McCracken)
  • IA64 PAL/signal headers cleanup (Nathan Myers)
  • ymfpci driver cleanup (Pete Zaitcev)
  • Change NLS "licenses" to be "GPL/BSD" instead only BSD. (Robert Love)
  • Fix serial module use count (Russell King)
  • Update sg to 3.1.22 (Douglas Gilbert)
  • ieee1394 update (Ben Collins)
  • ReiserFS fixes (Nikita Danilov)
  • Update ACPI documentantion (Patrick Mochel)
  • Smarter atime update (Andrew Morton)
  • Correctly mark ext2 sb as dirty and sync it (Andrew Morton)
  • IrDA update (Jean Tourrilhes)
  • Count locked buffers at balance_dirty_state(): Helps interactivity under heavy IO workloads (Andrew Morton)
  • USB update (Greg KH)
  • ide-scsi locking fix (Christoph Hellwig)

Patrick Dijkkamp pointed out that Marcelo had forgotten to update the version number again, as he had last week.


7. Identifying Good Kernel Releases
30 Nov 2001 - 2 Dec 2001 (13 posts) Archive Link: "Please tag tested releases of the 2.4.x kernel"
People: Willy TarreauIan StirlingMike Fedyk

Justin Wells asked if there were some way to tag kernels on, so users could tell which releases were better than others. Mike Fedyk suggested that Justin volunteer to keep track of how good each kernel was, but Willy Tarreau said:

well, at least there's a very simple way to get valuable information : install a voting system on a web site ( so that people who go there to get a new kernel can also tell which kernel they're using, the approximative uptime they have, if they encountered problems, if they had to patch it to gain stability, and eventually what they do with it (io/net/desktop/all).

A further step could be to qualify recensed patches on the net in the same manner. There *are* ways to get very stable kernels even now, for a given application. Not everyone has the same needs of course, but it could help even the maintainers by giving them a more global feedback about which patches could most likely be included with low risk.

I think that if even one tenth of the LKML subscribers rank their kernels at least once a week, we'll quickly see some stable and unusable kernels.

Mike really liked that idea, and Ian Stirling put in, "I've proposed in the past a more extensive version of this. make register or similar. Which you run, and it grabs a snapshot of system setup, optionally with comments, and sends it in to a registry. You can then do make comment and report issues. These would vary from "it crashes", to "my hard drive died/is dying" So we get information on systems, and some idea on which are reliable or not."


8. Incremental Prepatches Now Available
1 Dec 2001 - 3 Dec 2001 (9 posts) Archive Link: "Incremental prepatches"
People: H. Peter AnvinMatt DomschAnders Peter Fugmann

H. Peter Anvin announced:

I have created a robot on which makes incremental prepatches available. It looks for standard-named prepatches in the /pub/linux/kernel/v*.*/testing directories, and creates incrementals in the corresponding /pub/linux/kernel/v*.*/testing/incr directory.

For example:

hera 86 % cd /pub/linux/kernel/v2.5/testing/incr/
hera 87 % ls -l *.gz
-rw-rw-r--    1 kdist    kernel     177158 Nov 27 10:17
-rw-rw-r--    1 kdist    kernel     102202 Nov 28 15:35
-rw-rw-r--    1 kdist    kernel      52955 Nov 29 15:29
-rw-rw-r--    1 kdist    kernel      53616 Nov 30 17:04

The naming and function of the patches should be obvious.

.bz2 and .sign files are available too, of course.

Several folks burst into applause, and Matt Domsch asked, "Would you be interested in setting up a kdist-like list to email out the changelog, diffstat, and incremental patch too as a product of the patch generation script? That would increase the usefulness of comments like "Alan - much merging" in the changelogs. Also, a script to update a web page ala would make patch browsing really easy. I volunteer to help if you like." There was no reply to this, but elsewhere, Anders Peter Fugmann suggested to H. Peter, "Could you (when you have the time) extend the system to include a patch between the last pre version and a final version?" H. Peter replied that he'd intended to do this but had forgotten. He whipped up the feature and added it, and Anders replied, "Thats about as perfect as it gets."


9. Migrating From OSS To ALSA
3 Dec 2001 - 5 Dec 2001 (18 posts) Archive Link: "OSS driver cleanups."
Topics: Sound: ALSA, Sound: OSS
People: Alan CoxJeff GarzikZwane Mwaikambo

Zwane Mwaikambo had some cleanup patches for OSS. He knew that OSS would soon be replaced by ALSA, and asked if it was worth the trouble to continue his OSS work. Alan Cox replied, "Well if you've done the work why not - people will be running 2.4 for a long time. The PM changes may also be relevant to ALSA anyway."

At one point John Gluck asked if ALSA would make it into 2.4; and Jeff Garzik said, "IMHO ALSA should -never- go into 2.4. It's fine as a patch but 2.5 is the time for big merges, and since it's already available for 2.4 outside the kernel there shouldn't be any need for backporting."


10. Problems With The linux-kernel Mailing List
3 Dec 2001 - 4 Dec 2001 (3 posts) Archive Link: "Is lkml dead?"
Topics: Spam
People: Ragnar Hojland EspinosaMatti Aarnio

Hans-Christian Armingeon asked if the linux-kernel mailing list was dead, and Ragnar Hojland Espinosa confirmed that it "Seems that its hickuping a bit.." And Matti Aarnio explained:

I would say "that is an understatement"...

For several good reasons there has been an attempt at renumbering vger into an alternate address space. That project, however, did yield massive amounts of DNS lookups failing in a way which did yield "NO ERROR" status, but also no data at all.

Moving vger back to old address failed partially too, and it took serious gymnastics to sort things out again.

The situation motivating for such drastic operation of renumbering is that some systems consider it right and proper to reject email just because DNS lookup does timeout somehow on them (no attempt of yielding 400-series error codes).

Some people (a LOT of people) seem to think that it is right and proper to analyze the parameter value given to the EHLO/HELO greeting verb. ISP's know that they just can't do that, world is full broken MUAs (for some reason, usually at M$ systems) which are trying to submit email via ISP hubs.. Spam-spewers usually do get that part correctly.

Some people seem to think that it is proper to even imagine of analyzing that the SMTP client's IP address has working DNS reverser entry. (Combine that with a failure to handle timeouts..)


11. Improved Spinlock Debugging For UP Systems
3 Dec 2001 - 5 Dec 2001 (17 posts) Archive Link: "[PATCH] improve spinlock debugging"
Topics: SMP
People: Manfred Spraul

Manfred Spraul announced:

CONFIG_DEBUG_SPINLOCK only adds spinlock tests for SMP builds. The attached patch adds runtime checks for uniprocessor builds.

Tested on i386/UP, but it should work on all platforms. It contains runtime checks for:

  • missing initialization
  • recursive lock
  • double unlock
  • incorrect use of spin_is_locked() or spin_trylock() [both function do not work as expected on uniprocessor builds] The next step are checks for spinlock ordering mismatches.

Which other runtime checks are possible? Tests for correct _irq usage are not possible, several drivers use disable_irq().

There was a bit of a technical discussion following.


12. 2.4 Maintenance
5 Dec 2001 - 6 Dec 2001 (8 posts) Archive Link: "Linux 2.4.17-pre3"
People: Marcelo TosattiAlex BuellDavid S. Miller

Marcelo Tosatti announced 2.4.17-pre3, and said, "People with Pentium Pro, please test if the workaround is really working correctly..." Alex Buell asked, "Where are the sparc fixes? There are some fixes that's been queued since 2.4.16 that really needs to go in!" Marcelo asked Alex to send the patches to him, and David S. Miller replied, "I sent you them twice already, once I merge up to 2.4.17-pre4 I'll resend them to you."







We Hope You Enjoy Kernel Traffic

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.