Kernel Traffic #330 For 3 Oct 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1467 posts in 9MB. See the Full Statistics.

There were 577 different contributors. 219 posted more than once. The average length of each message was 102 lines.

The top posters of the week were: The top subjects of the week were:
48 posts in 207KB by andrew morton
34 posts in 192KB by al viro
26 posts in 122KB by blaisorblade
25 posts in 252KB by jesper juhl
24 posts in 123KB by rafael j. wysocki
49 posts in 275KB for "[announce] ktimers subsystem"
27 posts in 229KB for "2.6.14-rc2-mm1"
26 posts in 111KB for "[patch 2/2] suspend: cleanup calling of power off methods."
25 posts in 109KB for "[patch 0/3] netfilter : 3 patches to boost ip_tables performance"
22 posts in 96KB for "resource limits"

These stats generated by mboxstats version 2.8

1. Support For Au1x00 AMD SoC UARTs Through The 8250 Serial Driver

19 Sep 2005 - 22 Sep 2005 (11 posts) Archive Link: "[PATCH] Au1x00 8250 uart support."

Topics: Modems

People: Pantelis AntoniouRussell KingChristoph Hellwig

Pantelis Antoniou said:

The following patch enables the use of the Au1x00 AMD SoC UARTs through the standard 8250 serial driver.

The Au1x00 UARTs are weird in the following two ways:

1) The registers are not present at the normal offsets, so a mapping function is used to transform them.

b) Modem status signals are not supported on all the members of the Au1x00 family, so the modem status change interrupts must not be enabled, or we die in an irq storm.

In order to not affect any standard 8250 parts, the code in question is #ifdef'ed on CONFIG_SERIAL_8250_AU1X00. If you deem the readability of the code is more important you may removed them, without any effect on the functionality.

I've also considered abstracting the register mapping to a couple of extra fields on plat_serial8250_port, but wasn't sure how that would go.

Christoph Hellwig and Russell King offered some technical suggestions, and Pantelis modified his patch to accomodate their ideas; but there was no real discussion.

2. uclinux Ported To Blackfin CPU

20 Sep 2005 - 27 Sep 2005 (8 posts) Archive Link: "ADI Blackfin porting for kernel-2.6.13"

People: Luke YangDeepak SaxenaJesper Juhl

Luke Yang from Analog Devices said, "We ported uclinux to our Blackfin cpu. Now we updated our architecture code for kernel-2.6.13. I will send out a patch to this list." He also asked, "I know kernel-2.6.14 is coming. Will the linux kernel accept our patch for 2.6.13?" Deepak Saxena replied, "Nope. 2.6.13 is now closed to new features as is 2.6.14 (unless it is a really sper special case that Linus feels is important enough to slip in). At this point the best thing to do is to post your patches for review, make the changes that are asked, and be ready to post a patch vs 2.6.14 within the first week after it is released so that it might be be picked up for 2.6.15." Luke barrelled ahead with his patch, and Jesper Juhl offered a number of technical suggestions and style guidelines.

3. The Andrew Load

20 Sep 2005 - 26 Sep 2005 (28 posts) Archive Link: "[PATCH 1/2] reboot: Comment and factor the main reboot functions"


People: Linus TorvaldsAndrew MortonEric W. BiedermanAlexander NybergPavel Machek

Eric W. Biederman submitted some reboot fixes to Linus Torvalds, and Pavel Machek suggested that the proper procedure would be to send them to Andrew Morton first, for inclusion in the -mm tree. Linus said:

One issue is that I actually worry that Andrew will at some point be where I was a couple of years ago - overworked and stressed out by just tons and tons of patches.

Yes, he's written/modified tons of patch-tracking tools, and the git merging hopefully avoids some of the pressures, but it still worries me. If Andrew burns out, we'll all suffer hugely.

I'm wondering what we can do to offset those kinds of issues. I _do_ like having -mm as a staging area and catching some problems there, so going through andrew is wonderful in that sense, but it has downsides.


Andrew remarked, "Patches are very low overhead, really. It's patches which don't work which take lots of time - a single dud patch can take hours and can make me think rude thoughts about its originator." He added:

I'm doin OK.

Patch volume isn't a problem wrt the simple mechanics of handling them. The problem we have at present is lack of patch reviewing bandwidth. I'll be tightening things up in that area. Relatively few developers seem to have the stomach to do a line-by-line through large patches, and it would be nice to refocus people a bit on that. Christoph's work is hugely appreciated, thanks.

Famous last words, but the actual patch volume _has_ to drop off one day. In fact there doesn't seem to much happening out there wrt 2.6.15.

Bugs are a big problem - it takes 4 hours minimum to get a -mm out the door and a single bug can cause it to slip to the next day in which case I have to start again. A couple of times it has taken over two days just to get together a tree which boots on four architectures and compiles on seven.

I'm spending more and more time on bugs now. We have hundreds of bugs which people have taken the time to report, which the relevant developers know about and NOTHING IS HAPPENING. "I can't reproduce it" is not an adequate reason when there are nice testers out there who are available to work through the diagnosis process. We have hundreds of machines out there which we are known to have broken and developers just need to reapportion some of their time to getting these things fixed.

The -mm tree does prevent a large amount of crap from hitting mainline - I'd guess the bug leakthrough rate is ~10%, although that 90% tends to be the easy stuff - often compile errors. I'd like to release -mm's more often and I'd like -mm to have less of a wild-and-crappy reputation. Both of these would happen if originators were to test ther stuff more carefully.

At one point in the discussion, Eric remarked, "It is especially challenging for people like me who typically work on parts of the kernel without a maintainer. So there frequently isn't an intermediate I can submit my patches to." And Andrew said:

Yup. And MAINTAINERS has quite a few omissions. I generally know who should be poked and if there's nobody obvious I have 26000 patches to grep through to find out who might know a bit about that code. Low-level x86 is a bit of a problem really because it has many cooks and no obvious chef.

Individual maintainers have differing response times, differing attentiveness and differing patchloss ratios.

There's also confusion once I've cc'ed a maintainer on a patch over whether I'll be sending it to Linus or whether I want them to.

If a maintainer has a tree in -mm then I'll autodrop the patch if they merge it, so there's no confusion there.

If the maintainer says "thanks, merged" and I don't have their tree in -mm then I'll tend to hang onto the patch indefinitely until it finally hits -linus. Or I'll eventually forget and merge it up anyway ;)

If the maintainer just acks the patch I'll send it in to Linus.

If the maintainer nacks the patch I'll either drop it or I'll mark it not-for-merging and hang onto it anwyay, as a reminder that we have some bug which needs fixing.

If the maintainer has a tree in -mm and doesn't merge the patch I'll hang onto it and periodically resend to the maintainer until some definite response comes back.

Close by, Alexander Nyberg also remarked, "Morever is severely underworked (acpi being a noteable exception) and Andrew has stepped in alot there too. Alot of bugs reported on the mailing list are only followed up by Andrew. I think he really should receive much more help than he currently does." Andrew replied:

Yes, kernel bugmeister is a completely separate function from patchmonkeying. It is something which a separate person can and should do.

My current thinking is that I'll develop the processes, find out what works and then look to hand it off to some other sucker. I wouldn't claim that this is going very well at present, perhaps because I'm just not putting enough time into the bugmeistering to be able to demonstrate what works and what does not.

I wouldn't say that bugmeister is a fulltime job, but it'll be a lot-of-time job. It needs someone who isn't shy and who has a good understanding of the kernel code-wise, of the processes (hah) and of the people.

The ability to maintain an overall view of where we're at, which bugs are serious and which aren't. The ability to succinctly communicate that overview to everyone else. Able to tell Linus "you can't release a kernel until bugs A, B and C are fixed". The skills and gut-feel to know when a patch is some once-off which can be ignored unless it reoccurs, etc. It's one of those things which can consume as much effort as one is able to put into it.

Kernel development is more professional than we like to pretend nowadays, and developers will react well to someone who is doing this for us. It's pretty boring tho.

4. Linux 2.6.14-rc2-mm1 Released

19 Sep 2005 - 28 Sep 2005 (42 posts) Archive Link: "2.6.14-rc2-mm1"

Topics: Kernel Release Announcement

People: Andrew MortonLuben Tuikov

Andrew Morton announced Linux 2.6.14-rc2-mm1, saying:

5. I2C Subsystem Maintainership

22 Sep 2005 (36 posts) Archive Link: "[patch 00/18] USB and PCI Fixes for 2.6.14-rc2"

Topics: I2C, PCI, USB

People: Greg KHJean Delvare

Greg KH posted a number of patches for USB and PCI in the 2.6 tree. Among them was one to "Remove my name from the I2C maintainer, Jean is more than capable of handling it all now." The patch listed Jean Delvare as the I2C subsystem maintainer.

6. Linux 2.4.32-rc1 Released

22 Sep 2005 (1 post) Archive Link: "Linux 2.4.32-rc1"

Topics: Compression, FS: NFS, Ioctls, Networking

People: Marcelo TosattiAndrea ArcangeliChuck EbbertPatrick McHardyJean Delvare

Marcelo Tosatti announced Linux 2.4.32-rc1, saying, "Here goes the first -rc of v2.4.32, containing a set of small corrections here and there, most of them being fixes backported from v2.6." He also listed a summary of changes between this and the previous releases:

Andrey J. Melnikoff:
Remove isofs useless unsigned " < 0" comparison

nfs client: handle long symlinks properly

Chuck Ebbert:
i386: fix incorrect FP signal delivery

Dave Johnson:
[IPV4]: Fix negative timer loop with lots of ipv4 peers.

Gustavo Zacarias:
[SPARC64]: Use vmalloc() in do_netfilter_replace()

Hasso Tepper:
[IPV6]: Route events reported with wrong netlink PID and seq number

CAN-2005-0204: AMD64, allows local users to write to privileged IO ports via OUTS instruction
isofs driver ignore parameters

Jean Delvare:
update lm_sensors mailing list address

Kirill Korotaev:
Lost sockfd_put() in routing_ioctl()
lost fput in 32bit ioctl on x86-64

Kiyoshi Ueda:
IA64: page_not_present fault in region 5 is normal

M.Baris Demiray:
Update PPPoE's configuration documentation

Marcelo Tosatti:
NFS: dprintk on -ENAMETOOLONG error handling
Update VERSION to 2.4.32-rc1
Andrea Arcangeli: avoid size_buffers_type overflow
Revert unnecessary arch/ppc64/boot/zlib.c
Revert unnecessary zlib_inflate/inftress.c fix

cciss 2.4.60

Patrick McHardy:
[NETFILTER]: Handle NAT module load race

7. Cogito 0.15.1 Released With Important Bug Fix

23 Sep 2005 (1 post) Archive Link: "[ANNOUNCE] Cogito-0.15.1 (important bugfix)"

Topics: BSD

People: Petr Baudis

Petr Baudis announced Cogito 0.15.1, saying:

I'm announcing the release of 0.15.1 of Cogito, the human-friendly UI for Linus' GIT. You can find it at

when mirroring will go through another short period of actually working. ;-)

I'm cc'ing the Linux Kernel mailing list since this release contains a bugfix for an ugly potential data loss bug, which actually probably covers nearly all Cogito users (it was introduced in cogito-0.11.2). If you had some local uncommitted changes and merge new stuff (either using cg-update or cg-merge), in some cases it would silently trash your local changes. It was caused by a bogus git-checkout-cache invocation pointed out by Linus.

Other interesting stuff:

8. I2C Maintainership Announcement

28 Sep 2005 (1 post) Archive Link: "Change of I2C kernel subsystem maintainer"


People: Greg KHJean Delvare

Greg KH had posted a patch earlier to alter the MAINTAINERS file, but now he followed it up with:

If people hadn't noticed anymore, I've passed on the full I2C subsystem maintainership to Jean Delvare <[email protected]>. He and I had been "sharing" it for the past months, but now he's more than capable of handling the whole thing, and I know it is in good hands now.

So, for any I2C driver questions or patches, please feel free to let him know, don't send them to me anymore, please :)

I'll still be paying attention to the I2C core work, especially where it touches the driver core interfaces, and have some pending work to clean up in that area. I'll also remain the conduit for sending I2C and hwmon stuff on to Andrew for the -mm tree, and Linus for the mainline tree, so nothing will change there.







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.