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.
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.
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.
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 netdev@oss.sgi.com 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.
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.
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.