Kernel Traffic #241 by Zack Brown

                        Kernel Traffic #241 For 16 Nov 

                                 By Zack Brown

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Mailing List Stats For This Week
  * Threads Covered

    1. 4 Nov  - 7 Nov    (21     QLogic qla2xxx Driver Update Released For 2.6
                         posts)
    2. 7 Nov  - 9 Nov    (2      CramFS Maintainership
                         posts)
    3. 7 Nov             (1      Driver Model Regression Test For OSDL's
                         post)   Scalable Test Platform Released
    4. 7 Nov  - 9 Nov    (15     New Driver For Ethernet Interface Of NVidia's
                         posts)  nForce Chipset
    5. 10 Nov  - 12 Nov  (15     Linux 2.4.23-rc1 Released
                         posts)
    6. 11 Nov            (1      kdb 4.3 Released For Kernel 2.4.23-rc1
                         post)

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:

  * 43 posts in 269K by Jens Axboe
  * 26 posts in 76K by Linus Torvalds
  * 25 posts in 85K by Andrew Morton
  * 18 posts in 57K by Greg KH
  * 16 posts in 56K by Nick Piggin
  * Full Stats

 

1. QLogic qla2xxx Driver Update Released For 2.6
4 Nov  - 7 Nov  (21 posts) Subject: "[ANNOUNCE] QLogic qla2xxx driver update
available (v8.00.00b6)."
Topics: Clustering, Ioctls
People: Andrew Vasquez, Christoph Hellwig, Mike Anderson, Jens Axboe, Arjan 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:

    http://sourceforge.net/projects/linux-qla2xxx/

    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  - 9 Nov  (2 posts) Subject: "CRAMFS"
Topics: FS: ramfs
People: Bradley Bozarth, H. Peter Anvin, Daniel 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  (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.

    http://www.osdl.org/lab_activities/kernel_testing/stp/

    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  - 9 Nov  (15 posts) Subject: "[PATCH 2.4] forcedeth"
Topics: Networking
People: Carl-Daniel Hailfinger, Jeff Garzik, Manfred Spraul, Christoph Hellwig
, Krzysztof 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 [email protected] and Manfred will
    scoop them up.

    You also can download the patches for Linux 2.4.x and 2.6.x from http://
    www.hailfinger.org/carldani/linux/patches/forcedeth/

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  - 12 Nov  (15 posts) Subject: "Linux 2.4.23-rc1"
People: Marcelo Tosatti, Willy 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  (1 post) Subject: "Announce: kdb v4.3 is available for kernel
2.4.23-rc1"
People: Keith Owens

Keith Owens announced:

    ftp://oss.sgi.com/projects/kdb/download/v4.3/

    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 hosted by the generous folks at Tux.Org. All pages on this
 site are copyright their original authors, and distributed under the terms of
                 the GNU General Public License, version 2.0.