Kernel Traffic #331 For 10 Oct 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2477 posts in 14MB. See the Full Statistics.

There were 769 different contributors. 303 posted more than once. The average length of each message was 97 lines.

The top posters of the week were: The top subjects of the week were:
57 posts in 258KB by jeff garzik
52 posts in 288KB by luben tuikov
48 posts in 208KB by linus torvalds
43 posts in 263KB by andrew morton
43 posts in 182KB by paul jackson
138 posts in 586KB for "i request inclusion of reiser4 in the mainline kernel"
130 posts in 667KB for "i request inclusion of sas transport layer and aic-94xx into"
59 posts in 289KB for "2.6.13-mm2"
43 posts in 276KB for "2.6.14-rc1-git-now still dying in mm/slab - this time line 1849"
42 posts in 175KB for "freebox possible gpl violation"

These stats generated by mboxstats version 2.8

1. Linux 2.6.13-mm2 Released; Some Suspend/Resume Issues

8 Sep 2005 - 30 Sep 2005 (83 posts) Archive Link: "2.6.13-mm2"

Topics: Digital Video Broadcasting, FS: CIFS, Framebuffer, Kernel Release Announcement, PCI, Power Management: ACPI, USB

People: Andrew MortonHugh DickinsRafael J. WysockiDaniel RitzLinus Torvalds

Andrew Morton announced Linux 2.6.13-mm2, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/

(kernel.org propagation is slow. There's a temp copy at http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-mm2.bz2)

Andrew tends to get a lot of response to these patches, typically minor reports of compilation problems on a particular architecture or for particular hardware drivers. This time was no exception. Various folks reported problems, and Rafael J. Wysocki requested that a Yenta patch be taken back into the -mm tree, that had earlier been taken out. He complained that his system would not resume from suspend without it. Andrew was amenable to this, and couldn't quite remember why the patch had been dropped in the first place. But Hugh Dickins replied, "I remember well. My laptop does not APM resume from RAM with it. I've just rechecked and that's still the case. I did try various patches from Rafael to help him work it out, but it remained a puzzle." Rafael summarized:

the observations are sort of interesting (just for the record):

  1. The problem is due to interrupt sharing. The IRQ is shared between yenta and 3c59x.
  2. Without the yenta driver the box resumes.
  3. Without the 3c59x driver the box resumes.
  4. If yenta is woken up _before_ 3c59x, the box resumes.
  5. If yenta is woken up _after_ 3c59x, the box hangs. Unfortunately, this is the default, because of the PCI device numbers.

Daniel Ritz hurled himself at this problem, requesting system data from Rafael, and scouring the archives and the bugs database for former discussion and similar problems. He put up a patch, saying, "we get interrupt storms from usb which then hurt when yenta has it's handler installed but usb has not. usb/hcd-pci.c frees the irq on suspend...so it may be enough not to do that (survives suspend-to-ram and suspend-to-disk here. yes, restore too :)" Rafael replied:

I've tried and it apparently works provided that _none_ of the IRQ-sharing devices drops the IRQ on suspend.

I think that's the whole point: Either all of the devices should drop/request IRQs on suspend/resume, or none of them should do this. IMHO we need to chose one of these options and call it "the right way" or there always will be problems with this.

Close by, Linus Torvalds said, "Trivial decision: if not freeing the irq fixes the problem, then please send a tested patch that does just that. It's what we used to do anyway." Elsewhere, as other folks considered various possibilities, he added:

The right thing is to not free and re-aquire the damn interrupt in the first place. It was a MISTAKE. We undid the ACPI braindamage that made it be required a month ago, because sane people REALIZED it was a mistake.

It's not just "random luck" that not releasing the interrupt over suspend fixes the problem. The problem is _due_ to drivers releasing the interrupt in the first place.

IT DOESN'T MATTER what we do before the suspend, because we don't control the wakeup sequence. If the BIOS wakeup enables the devices again, the fact that we disabled them on suspend makes zero difference.

And yes, we can always "fix" things by selecting the right order to re-aquire the interrupts, but the thing is, the "right order" will be machine-dependent and in general depend on the phase of the moon and BIOS version, and ACPI quirks.

The _only_ sane thing to do is to not drop the interrupts in the first place. So that if you start getting interrupts before you expect them, you can still handle them.

2. ReiserFS Alienates Contributors

16 Sep 2005 - 4 Oct 2005 (140 posts) Archive Link: "I request inclusion of reiser4 in the mainline kernel"

Topics: FS: ReiserFS

People: Hans ReiserChristoph Hellwig

Hans Reiser requested that Reiser4 be included in the 2.6 tree, and he tried to thank folks for their feedback and suggestions, but ultimately the strain was too much for him, and he couldn't resist needling the developers with statements like, "Most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code." So the discussion went nowhere. After some heated discussion, at one point Christoph Hellwig said:

Thanks a lot for the groundless attacks, but I'm done.

I'll stop helping you to review stuff because it's just totally pointless, you ignore most of the review anyway and start personal attacks.

Please find someone else to review your code for inclusion, that can stand beeing attacked everytime they write an email. Before you should probably fix up various bits I wrote up and especialy make sure to get rid of all duplication of generic I/O code or explain in detail why you need it and fix your own implementations.

Andrew collected Christoph's objections, and added them to the Reiser4 ChangeLog entry in his -mm tree, so they would not be forgotten.

3. Patch Submission Policy Documentation

26 Sep 2005 - 4 Oct 2005 (34 posts) Archive Link: "[PATCH 0/3] CPUMETER (Re: [PATCH 0/5] SUBCPUSETS: a resource"

People: Linus TorvaldsPaul Jackson

In the course of discussion, Linus Torvalds accepted a patch, saying:

Just a non-technical note: the sign-offs makes me suspect the patch (or an earlier version of it) may have been written by Kurosawa-san. However, it wasn't clear, so I didn't make that change, and so it now ends up being in git with Paul as the author.

If that was wrong, please for the future keep authorship intact by having a "From: A U Thor <[email protected]>" at the head of the description, which will make authorship clear and allow the tools to pick that up.

Paul Jackson replied:

You guessed right. Your non-technical note was applicable.

Andrew - why doesn't your "The perfect patch" mention this? http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

Linus - would you like a patch to Documentation/SubmittingPatches that mentions this?

Hmmm ... I don't even see the "Acked-by" in these patch guides either. Probably I should include that in SubmittingPatches as well.

Too bad that first line doesn't start "Author:" instead of "From:". Oh well - I see Andrew already suggested that, and you declined. (You should'a listened to him ;).

Linus replied:

The "From:" rule has been implicit in my tools for a _loong_ time, and switching to "Author:" would just break the tools for no actual technical gain. Not just the tools, either, since Andrew isn't the only one who follows that From: rule - it would break "people".

So you'd have to make the tools accept _both_ "From:" and "Author:", and I personally prefer an _unambiguously_ slightly misnamed thing over some "either X or Y" where X is slightly misnamed but accepted because it's the one more commonly used.

It's like the unix "creat()" system call. Sure, it would make more sense to add the "e", but it wouldn't actually really _help_ anybody.

As to documenting the "From:" thing - yes, we probably should. It's quite commonly used.

4. Thermal Control And cpufreq Support For iMac G5

29 Sep 2005 - 30 Sep 2005 (6 posts) Archive Link: "iMac G5: experimental thermal & cpufreq support"

Topics: FS: sysfs, I2C

People: Benjamin HerrenschmidtGeoff LevandDean Hamstead

Benjamin Herrenschmidt said:

I now have some experimental thermal control and cpufreq support for iMac G5. I have not _yet_ implemented support for the SMU based single CPU desktops (PowerMac9,1), those will have to wait a little bit more (not too much hopefully, but I need potential testers to contact me as I lack hardware access). At this point, it should work on PowerMac8,1 (iMacG5 rev A) and PowerMac8,2 (iMacG5 rev B).

WARNING: This is really a 'first shot'. There is no overtemp detection, so be careful. The driver doesn't yet have a sysfs interface for you to read the temperature, but I left it with verbose debugging enabled in the kernel log so you can see what's going on with the 2 control loops (the System one which ticks every 5 seconds and the CPU one which ticks every second). Please tell me if it appears to behave properly. On my iMac G5 rev A, the target temperature for the CPU is set by the firmware at 78 degree C with a max at about 83 degree. If I put load on the CPU, the CPU appears to properly ramp up slowly to 82 then go down and stabilize at 78 while the driver slowly ramps the fans up.

The algorithm itself is extracted from darwin. However, it's a rather complex modified version of the PID algorithm, and thus it could use some review to make sure I got everything right.

The thermal control is also part of a new infrastructure I have written called "windfarm" that splits the whole thing into several modules (though I have only tested with everything built in at this point). Ultimately, it should be possible to port the existing Desktop G5 and Xserver thermal driver to the new infrastructure provided that the appropriate sensor & control modules are written. The old thermal driver uses pretty much the same 2 kind of PID control loops as provided by the windfarm_pid helper.

I would encourage people doing thermal control on other machines (laptops, etc...) to also use the new infrastructure.

Ok, now the patches. You need to appy them in proper order. First of all, it all is on top of current -git as of yesterday. I won't guarantee they will apply on anything more ancient.

First, you need a fix that is currently pending in -mm (and should be in 2.6.14 before it's final) :

http://gate.crashing.org/~benh/ppc64-smu-fix.diff

Then, you can apply the patch that adds cpufreq support for the iMac G5 (and possibly the SMU based desktop, though not tested)

http://gate.crashing.org/~benh/ppc64-fx-freq-scaling.diff

Then apply those 2 patches in that order:

http://gate.crashing.org/~benh/ppc64-smu-partitions.diff

http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff

That's it. Now enable:

CONFIG_WINDFARM_SMU

and

CONFIG_I2C_PMAC_SMU

If you are using modules, you may have to manually load the whole bunch, especially the i2c SMU one which isn't requested (yet).

Geoff Levand asked, "As we are already in the digital domain, I would think it would be more savvy to use a digital controller than try to simulate an analog controller... Why don't you abstract the control algorithm such that you can plug in others as they are developed." Benjamin replied:

Because I don't know much about those control algorithms, and all the calibration data provided by the firmware is in the form of factors for these algorithms, I wouldn't know how to "unmangle" them to use with different ones.

Actually, the control algorithms (PID and modified PID) are in a "helper", so it's fairly easy for the platform module to use whatever it wants, feel free to submit other algorithms :) But for Apple machines, I'd rather use what I have calibration data for, unless you can produce something that works without any...

Dean Hamstead said:

Although i dont have an imac g5, i think that in general ben is on the right track. its better to have something in place than nothing.

not putting down the feedback, but im not sure just how much fiddling people will really want, and its not a huge audience. which brings me back to the point of just getting something in place and then people can change it as IMO linux kernel code is more likely to be fiddled with (and better 'documentation' - whatever that is) than darwin code.

go ben, keep working hard. and keep chasing the mpeg decoder in the ati cards of apple ibook and friends!

5. git Guide Updated

29 Sep 2005 - 4 Oct 2005 (39 posts) Archive Link: "[howto] Kernel hacker's guide to git, updated"

People: Jeff GarzikDave JonesAnton AltaparmakovLinus TorvaldsJunio C. Hamano

Jeff Garzik said:

Just updated my KHGtG to include the latest goodies available in git-core, the Linux kernel standard SCM tool:

http://linux.yyz.us/git-howto.html

Several changes in git-core have made working with git a lot easier, so be sure to re-familiarize yourself with the development process.

Comments, corrections, and notes of omission welcome. This document mainly reflects my typical day-to-day git activities, and may not be very applicable outside of kernel work.

Dave Jones replied:

You wrote..

$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ rsync -a --verbose --stats --progress \
  rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
  .git/

Could be just..

$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ git pull

Likewise, in the next section, git pull doesn't need an argument if pulling from the repo it cloned.

Anton Altaparmakov pointed out that those two sets of commands were "not actually the same. "git pull" for example will not download Linus' tags whilst the rsync would get everything." Dave replied, "Ah. I didn't know this. Thanks. Hmm, it'd be nice to have a shorthand 'not have to type the url, pull everything'. Something like 'git pull all'." Linus Torvalds posted a patch, saying, "Something like this? Except it's called "git fetch --all", and it's obviously totally untested." Unfortunately the discussion skewed off here, because he had upgraded to a new version of Pine that by default would mess up whitespace in patches. Linus reconfigured his Pine, but the subthread clogged up and died out.

Elsewhere, Jeff updated his guide again, taking into account all the comments he'd received. Junio C. Hamano, the official git maintainer, responded to the part of the guide that said, "Once the 'git fetch --tags' changes make it into the official repository (are they there already?), I'll remove all the remaining direct references to running rsync." Junio replied to this:

Sounds like a thinly veiled threat and/or very effective prodding ;-).

It is not there yet only because I simply have not got around to it, but it will happen before 0.99.8.

I suspect the version Linus posted has a funny interaction with 'git-pull'; 'git pull --tags' by mistake, or intentionally to file a bug report to annoy me ;-), would create an Octopus out of those tags, if I am not mistaken.

Linus replied:

Hey, even more impressive is "git pull --all", which will happily try to create an octopus of every single ref available at the other end.

Now, I think that octopus merges in _general_ are likely to be driver error, and that it might make sense to have a separate flag to enable them in the first place. That would solve the confusion..

So then you could do

git pull --all --octopus xyzzy

if you _really_ meant to do that.

Junio replied:

True.

However, I think --all is a mistake even if you use it without merging in 'git fetch', so I am not planning to do refs/heads/ side, at least not yet. Even if you prevent an Octopus, what would you do then? If you choose to merge one of them, which one? Not merging any that is not explicitly specified on the command line, seems to me the most sensible and safe option.

The rule for 'pull' to decide which refs to merge is:

  1. if command line has explicit refspecs (--tags and --heads do not count), they are all merged.
  2. if command line has no explicit refspecs (--tags and --heads do not count), the default one found from either remotes or branches file is merged.

Notice that I am forbidding remotes file to say "by default I always merge these three heads from there to make an Octopus" by the above rule (branches file cannot even name more than one head so this is not an issue). Since everybody seems to agree that Octopus is not something that is done mechanically and routinely anyway (I do make many Octopus merges, but they happen across my local topic branches. Topics merged change day-by-day, and even the set of topics alive at the time changes everyday. IOW, it is not something I would want to do with the same sets of heads every time by describing them in the remotes file.), I think this is a sensible way to guard against accidental Octopus.

We could consider fetching all heads, by minimally renaming remote master to origin and getting everything else under the same name, but I'd really want to keep the local namespace for branches isolated from each other. Many kernel.org public repositories seem to have 'test' and 'release' branches and if you are a maintainer of such a tree, and if you are interested in another maintainer's tree, and if that other maintainer has the 'test' and 'release' branches, --heads (or --tags) overwriting your 'test' with his 'test' is obviously not what you want.

Possibly, something like this could be arranged later:

* git fetch --heads=$ns $remote "[email protected]"

In addition to the usual refspecs (the rest of the command line arguments), fetch all remote heads and store remote refs/heads/$a under local refs/heads/$ns/$a for all $a. If $ns is empty, remote "master" is renamed "origin".

* git fetch --heads $remote "[email protected]"

shorthand for empty $ns

6. Linux 2.6.14-rc2-mm2 Released

29 Sep 2005 - 4 Oct 2005 (43 posts) Archive Link: "2.6.14-rc2-mm2"

Topics: Kernel Release Announcement

People: Andrew Morton

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

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm2/

(temp copy at http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.14-rc2-mm2.gz)

7. Stable Series Patch Review Begins Towards 2.6.13.3

29 Sep 2005 - 5 Oct 2005 (22 posts) Archive Link: "[PATCH 00/10] -stable review"

Topics: Bug Tracking, Networking, PCI

People: Chris WrightHugh DickinsDavid S. MillerStephen HemmingerIngo MolnarMarc LehmannIvan KokshayskyLinus TorvaldsIon BadulescuJulian AnastasovRoland McGrathAndi KleenJeff DikeAndrew MortonAlexander Nyberg

Chris Wright said:

This is the start of the stable review cycle for the 2.6.13.3 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Sun Oct 2, 02:00 UTC. Anything received after that time, might be too late.

He posted a set of patches with the following changelog entries:

Two additional patches received some comment. The first had this changelog entry:

As I do periodically, I checked to see how far out of sync compat_do_execve() has gotten from do_execve(). And as usual there was some missing stuff in the former. Perhaps we need some tighter consolidation of these two routines to make this less likely to happen in the future.

Anyways, on the success path of compat_do_execve() we forget to call acct_update_integrals() and update_mem_hiwater(), as is done in do_execve().

Signed-off-by: "David S. Miller" <[email protected]>
Signed-off-by: Chris Wright <[email protected]>

Hugh Dickins remarked, "The patch is good, but for -stable? Spelling corrections next?" Chris replied, "Heh, I think you've got a good point. This one doesn't have any real nasty side-effects that I can see. David do you have objections to dropping this one from -stable?" David S. Miller said, "No objections, you can drop it."

The other patch to be discussed had this changelog entry:

I think we should cache the per-socket route(dst_entry) only when the IPv6 UDP socket is connect(2)'ed. (which is same as IPv4 UDP send behavior)

Signed-off-by: Mitsuru KANDA <[email protected]>
Signed-off-by: Chris Wright <[email protected]>

Chuck Wolber felt this really wasn't a necessary bug fix, and so didn't belong in the -stable patch set. But David replied, "Without this unconnected ipv6 UDP sockets end up using the wrong route or IPSEC path." Mitsuru Kanda, the author of the patch, said he would work on updating the patch. Chris replied, "BTW, we dropped this one, since it had possible leak in it. I'll let you and DaveM decide when the updated one is ready for -stable." David said this would be fine.

8. Linux 2.6.14-rc3 Released

30 Sep 2005 (1 post) Archive Link: "Linux v2.6.14-rc3"

Topics: Kernel Release Announcement

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.14-rc3, saying:

Ok, this may or may not be the last -rc before 2.6.14, but the point is that we're getting closer.

The diffstat (not included here) tells the story: most of the changes are just a couple of lines, with a few outliers: a new "cassini" network driver, the mpt sas driver, some ip-conntrac work, and net/llc cleanups. Oh, and sparc updates and some ppc tlb and smu work.

9. Linux 2.6.13.3 Released

3 Oct 2005 - 5 Oct 2005 (7 posts) Archive Link: "Linux 2.6.13.3"

Topics: Networking

People: Chris WrightStephen HemmingerChris Wright:Ivan KokshayskyJulian AnastasovAlexey KuznetsovDavid StevensAlexander Nyberg

Chris Wright announced Linux 2.6.13.3, saying:

We (the -stable team) are announcing the release of the 2.6.13.3 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.13.2 and 2.6.13.3, as it is small enough to do so.

The updated 2.6.13.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.13.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/ (http://www.kernel.org/git/)

Alexander Nyberg:
Fix fs/exec.c:788 (de_thread()) BUG_ON

Alexey Kuznetsov:
Don't over-clamp window in tcp_clamp_window()

Chris Wright:
Linux 2.6.13.3

David Stevens:
fix IPv6 per-socket multicast filtering in exact-match case

Ivan Kokshaysky:
yenta oops fix

Julian Anastasov:
ipvs: ip_vs_ftp breaks connections using persistence

Paolo 'Blaisorblade' Giarrusso:
uml - Fix x86_64 page leak

Stephen Hemminger:
skge: set mac address oops with bonding
tcp: set default congestion control correctly for incoming connections

10. Documenting That ksymoops Should No Longer Be Used

5 Oct 2005 - 7 Oct 2005 (7 posts) Archive Link: "[PATCH] Documentation: ksymoops should no longer be used to decode Oops messages"

People: Jesper JuhlAlexey DobriyanRandy Dunlap

Jesper Juhl posted a patch to "Document the fact that ksymoops should no longer be used to decode Oops messages." Alexey Dobriyan replied, "If it's considered harmful, better remove all references to ksymoops. 2.4 users will happily grab their copy of this file from 2.4 tree." Jesper said, "I opted to keep the entry but make an explicit note that ksymoops should not be used for 2.6 kernels to make it clear. There are still people who use ksymoops on 2.6 Oops messages, so I thought it would make sense to keep the entry but make it clear that you should /not/ do that." But he said either way would be fine, and posted another patch to remove the ksymoops entry instead. He remarked, "I'll leave it up to the powers that be to sprinkle holy penguin pee on the preferred version."

Elsewhere, Kalin Kozhuharov asked what was the preferred method to decode oopses on 2.6; and Randy Dunlap replied:

You should just enable CONFIG_KALLSYMS so that the kernel can report (decode) the symbols with the oops message.

Yes, ksymoops will still work, but it should only be used if the kernel was not configured with CONFIG_KALLSYMS, and some people say that the kernel oops + symbols are better than the ksymoops output. I haven't compared them so can't say.

 

 

 

 

 

 

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 kernel.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.