Kernel Traffic #241 For 16 Nov 2003

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1044 posts in 5197K.

There were 396 different contributors. 175 posted more than once. 160 posted last week too.

The top posters of the week were:


1. QLogic qla2xxx Driver Update Released For 2.6
4 Nov 2003 - 7 Nov 2003 (21 posts) Subject: "[ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b6)."
Topics: Clustering, Ioctls
People: Andrew VasquezChristoph HellwigMike AndersonJens AxboeArjan van de Ven

Andrew Vasquez announced:

A new version of the 8.x series driver for Linux 2.6.x kernels has been uploaded to SourceForge:

Changes from previous release (8.00.00b5) include:

  • Intelligent RSCN handling.
  • Slab cache allocations for driver SRBs.
  • Support larger numbers of targets.
  • Initial rework of debug logging facilities.

Review the revision notes for further details of the changes in 8.00.00b6.

Beginning with this beta, distributions of the driver will only be in the source-type tarball format. It's not worth the extra effort of building a separate drop-in kernel tarball, given the varying release periods of the driver. Similar drop-in-kernel-tarball results can be had by:

        driver source in /tmp/qla8_b6

        # cd <kernel source>
        # patch -p1 < /tmp/qla8_b6/add_to_kernel.diff
        # mkdir drivers/scsi/qla2xxx
        # cp /tmp/qla8_b6/* drivers/scsi/qla2xxx
        # make ...

Failover functionality is present in this distribution, at this time I do not foresee a policy change regarding its presence in the 8.x series driver. The next beta release of 8.x will be failover-feature resync'd with our latest 6.x beta (6.07.xx).

Christoph Hellwig remarked, "your ioctl API gets worse and worse. You don't expect this huge dungpile of ioctls all marked _BAD to be merged, do you? Also having different ioctl values for different plattforms is not an option for Linux." Andrew acknowledged the problem, and said he really didn't think the ioctl code would be merged. But he explained, "Software (SMS 3.0) has been built on top of the this IOCTL interface. We painfully discovered this problem when we began to look at other non-x86 platforms (ppc64)." Regarding having different ioctl values for different architectures, Andrew added, "The better (right) fix would be to push this interface change onto the caller of the IOCTLs where they can manage the differences there, and the driver could once and for all shed itself of this nagging problem. That is the consensus here. The _BAD conversion was only done so the driver would compile." Arjan van de Ven felt that most or all of the ioctl mess could just be removed, in favor of using APIs already defined elsewhere throughout the kernel. But Andrew didn't see how this could be done with existing APIs. His ioctls, he said, did considerably more than the generic functions defined elsewhere; and there was no more discussion on that point.

Elsewhere, Mike Anderson asked Andrew, "Can you give more information on why clustering was turned off starting in b5?" Andrew explained:

This change was part of a relatively large performance-patch that was originally against the 6.x series driver. There were two main reasons for disabling clustering support:

  • Given the ability of the ISP to efficiently DMA to and from a significant number of data segment descriptors (via command/continuation type IOCBs), there were some questions regarding the benefits that clustering provided given the overhead incurred by the mid-layer attempting merge the requests.
  • Given the ISPs inability to handle data segments that cross 32-bit page boundaries, and the overhead in defensive logic within the driver to prevent these cases (compare the 6.x code to the 8.x code and you will see what I mean), by disabling clustering we guarantee that a single SG element never crosses a 4GB boundary.

Now, in 2.6 there are some significant changes. For one, with the block layer rewrite and the ability to limit segment boundaries of a block queue request with the blk_queue_segment_boundary() call, a LLDD need not concern itself with any defensive fast-path logic to handle the 4GB cross.

So, we're left with the benefits of the overhead of this merge process done by the block layer. I'm certainly receptive to the notion of reexamining the use of clustering given some solid data points showing an (significant -- this is subjective) increase in performance and/or a resounding 'yeah, enable it!' from those in the block-layer 'know.'

Jens Axboe came in here, saying that while Andrew's first bullet-point was true, the second was not: Jens explained that Linux would never allow crossing a 4GB boundary, and so there was no need to guard against it. Jens' conclusion was that although there may be little benefit to clustering in this case, "In 2.6 clustering comes for free, so it would be silly not to enable it." Andrew accepted the correction, and said he'd reenable clustering for the next driver version. They chatted some more on peripheral details, and the thread petered out.


2. CramFS Maintainership
7 Nov 2003 - 9 Nov 2003 (2 posts) Subject: "CRAMFS"
Topics: FS: ramfs
People: Bradley BozarthH. Peter AnvinDaniel Quinlan

Bradley Bozarth asked who currently maintained CramFS. He said, "Daniel Quinlan originally maintained this, now it is orphaned. His endian patch, which implemented the correct behavior according to the docs (which basically listed always do little endian as a todo), was dropped. We have been maintaining this patch on our kernel, but it really should go in - I don't want to spend a ton of time like I did last time to have it dropped again, however - is anyone thinking of maintaining cramfs? What are the chances of the endian fix going in if I submit it again? (if even the former maintainer had no success). I would maintain cramfs if desired - it hasn't really changed in a long time except in regards to higher level fs changes." H. Peter Anvin replied, "I think Al Viro has been doing a rewrite. You may want to check with him."


3. Driver Model Regression Test For OSDL's Scalable Test Platform Released
7 Nov 2003 (1 post) Subject: "[ANNOUNCE] STP Driver Model Regression Test"
People: Leann Ogasawara

Leann Ogasawara announced:

a Driver Model Regression test has been added to OSDL's Scalable Test Platform.

The test is a series of scripts and modules built outside of the kernel to help stress test the driver model. An extensible amount of busses, drivers, classes, class devices, and devices are loaded and unloaded in parallel in an attempt to push the driver model to its limits. The execution time is measured and given as output upon a successful test completion. It is the goal of this test to detect any performance regressions (or improvements) on previous or newly released kernels.


4. New Driver For Ethernet Interface Of NVidia's nForce Chipset
7 Nov 2003 - 9 Nov 2003 (15 posts) Subject: "[PATCH 2.4] forcedeth"
Topics: Networking
People: Carl-Daniel HailfingerJeff GarzikManfred SpraulChristoph HellwigKrzysztof Halasa

Carl-Daniel Hailfinger announced on behalf of himself, Manfred Spraul, and Andrew de Quincey:

Attached is forcedeth: A new driver for the ethernet interface of the NVIDIA nForce chipset, licensed under GPL.

The driver was written without support from NVIDIA, it's the result of a cleanroom development:

Carl-Daniel and Andrew reverse engineered the nvnet driver and wrote a specification, Manfred wrote the driver based on the spec. Since the driver has been available and working for a while now, Carl-Daniel fitted some compat glue to make it compile under 2.4.

This release it intended for developers, it's alpha quality: normal network traffic could work, although slow due to incomplete interrupt handling. It does work on two nForce 2 systems, nForce and nForce 3 are untested.

Try it yourself, but don't complain if something breaks. Note that the driver generates quite a lot of debug output.

Send any reports to linux-kernel or and Manfred will scoop them up.

You also can download the patches for Linux 2.4.x and 2.6.x from

Jeff Garzik was very happy to see this. He said:

Neat! I saw Manfred posted this driver for 2.6.x, as well. I'm glad soembody FINALLY got around to supporting this chipset under Linux.

Anyway, even with an alpha-quality driver, it's a driver that works where otherwise the kernel doesn't. So, after I review the driver, I would prefer to merge it soon rather than later. It gets users going, after all.

Elsewhere, Christoph Hellwig suggested using a name closer to the hardware, such as 'nforce_eth'. Krzysztof Halasa agreed with this, but Jeff said there were trademark issues to consider in this case, and that "I would prefer to avoid the issue completely, rather have to chase down some lawyers and get a definitive answer." Carl-Daniel also said, "We (Manfred, Andrew and I) debated the name for quite a long time and forcedeth, forced and forceeth were the final candidates. forcedeth was not only a descriptive name, but also a clever pun. So it won the compo."


5. Linux 2.4.23-rc1 Released
10 Nov 2003 - 12 Nov 2003 (15 posts) Subject: "Linux 2.4.23-rc1"
People: Marcelo TosattiWilly Tarreau

Marcelo Tosatti announced Linux 2.4.23-rc1 and said, "It contains network driver fixes (b44, tg3, 8139cp), several x86-64 bugfixes, amongst others." Willy Tarreau remarked, "Interestingly, tg3, which had a slight tendency to hang on 2.4.22 when duplex mismatched seems rock solid now. I could even force renegociation and duplex mismatches during heavy loads (pktgen) without even a warning in the logs."


6. kdb 4.3 Released For Kernel 2.4.23-rc1
11 Nov 2003 (1 post) Subject: "Announce: kdb v4.3 is available for kernel 2.4.23-rc1"
People: Keith Owens

Keith Owens announced:

Current versions are kdb-v4.3-2.4.23-rc1-common-1.bz2, kdb-v4.3-2.4.23-rc1-i386-1.bz2. Other platforms will follow as they get updated to 2.4.23-rc1. This is just a maintenance version to sync with kernel 2.4.23-rc1.







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.