Kernel Traffic #331 For 10 Oct 2005

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)

• Added Andi's x86_64 tree, as separate patches
• Added a driver for TI acx1xx cardbus wireless NICs
• Large revamp of pcmcia suspend handling
• Largeish v4l and DVB updates
• Significant parport rework
• Many tty drivers still won't compile
• Lots of framebuffer driver updates
• There are still many patches here for 2.6.14. We're doing pretty well with merging up the subsystem trees. ia64 and CIFS are still pending. x86_64 and several of Greg's trees (especially USB) aren't merged yet.

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.

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.

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.

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.

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 <author@mailbox.com>" at the head of the description, which will make authorship clear and allow the tools to pick that up.

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 ;).

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.

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

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

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!

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.

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.

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.

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.

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 "$@"

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 "$@"

shorthand for empty $ns

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)

• A bunch of memory management updates
• The big pcmcia changes have been temporarily dropped
• Multiple obscure tty drivers still won't compile
• Lots of post-2.6.14-rc2-mm1 patches have been cheerfully tossed out again due to various bugs, which felt nice.
• I am offline until October 9. Please send critical 2.6.14 fixes direct to Linus.

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 stable@kernel.org 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.

• In some cases, especially on modern laptops with a lot of PCI and cardbus bridges, we're unable to assign correct secondary/subordinate bus numbers to all cardbus bridges due to BIOS limitations unless we are using "pci=assign-busses" boot option. So some cardbus controllers may not have attached subordinate pci_bus structure, and yenta driver must cope with it - just ignore such cardbus bridges.

  For example, see https://bugzilla.novell.com/show_bug.cgi?id=113778

  Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
  Signed-off-by: Linus Torvalds <torvalds@osdl.org>
  Signed-off-by: Chris Wright <chrisw@osdl.org>

• It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable and can trigger due to the test itself being racy.

  de_thread() does
          while (atomic_read(&sig->count) > count) {
          }
          .....
          .....
          BUG_ON(!thread_group_empty(current));
  
  but release_task does
          write_lock_irq(&tasklist_lock)
          __exit_signal
                  (this is where atomic_dec(&sig->count) is run)
          __exit_sighand
          __unhash_process
                  takes write lock on tasklist_lock
                  remove itself out of PIDTYPE_TGID list
          write_unlock_irq(&tasklist_lock)

  so there's a clear (although small) window between the atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the thread.

  And actually there is no need for all threads to have exited at this point, so we simply kill the BUG_ON.

  Big thanks to Marc Lehmann who provided the test-case.

  Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)

  Signed-off-by: Alexander Nyberg <alexn@telia.com>
  Cc: Roland McGrath <roland@redhat.com>
  Cc: Andrew Morton <akpm@osdl.org>
  Cc: Ingo Molnar <mingo@elte.hu>
  Acked-by: Andi Kleen <ak@suse.de>
  Signed-off-by: Linus Torvalds <torvalds@osdl.org>
  Signed-off-by: Chris Wright <chrisw@osdl.org>
  

• per-socket multicast filters were not being applied to all sockets in the case of an exact-match bound address, due to an over-exuberant "return" in the look-up code. Fix below. IPv4 does not have this problem.

  Thanks to Hoerdt Mickael for reporting the bug.

  Signed-off-by: David L Stevens <dlstevens@us.ibm.com> Signed-off-by: Chris Wright <chrisw@osdl.org>

• ip_vs_ftp when loaded can create NAT connections with unknown client port for passive FTP. For such expectations we lookup with cport=0 on incoming packet but it matches the format of the persistence templates causing packets to other persistent virtual servers to be forwarded to real server without creating connection. Later the reply packets are treated as foreign and not SNAT-ed.

  If the IPVS box serves both FTP and other services (eg. HTTP) for the time we wait for first packet for the FTP data connections with unknown client port (there can be many), other HTTP connections that have nothing common to the FTP conn break, i.e. HTTP client sends SYN to the virtual IP but the SYN+ACK is not NAT-ed properly in IPVS box and the client box returns RST to real server IP. I.e. the result can be 10% broken HTTP traffic if 10% of the time there are passive FTP connections in connecting state. It hurts only IPVS connections.

  This patch changes the connection lookup for packets from clients:

  • introduce IP_VS_CONN_F_TEMPLATE connection flag to mark the connection as template
  • create new connection lookup function just for templates - ip_vs_ct_in_get
  • make sure ip_vs_conn_in_get hits only connections with IP_VS_CONN_F_NO_CPORT flag set when s_port is 0. By this way we avoid returning template when looking for cport=0 (ftp)

  Signed-off-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Chris Wright <chrisw@osdl.org>

• We were leaking pmd pages when 3_LEVEL_PGTABLES was enabled. This fixes that, has been well tested and is included in mainline tree. Please include in -stable as well.

  Signed-off-by: Jeff Dike <jdike@addtoit.com>
  Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
  Signed-off-by: Chris Wright <chrisw@osdl.org>

• Here is the patch (fuzz removed) for 2.6.13.2 that fixes OOPs when using bonding with skge.

  Skge driver was bringing link up/down when changing mac address. This doesn't work in the bonding environment, and is more effort than needed.

  Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=5271 Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
  Sigend-off-by: Chris Wright <chrisw@osdl.org>

• Patch from Joel Sing to fix the default congestion control algorithm for incoming connections. If a new congestion control handler is added (via module), it should become the default for new connections. Instead, the incoming connections use reno. The cause is incorrect initialisation causes the tcp_init_congestion_control() function to return after the initial if test fails.

  Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
  Acked-by: "David S. Miller" <davem@davemloft.net>
  Signed-off-by: Chris Wright <chrisw@osdl.org>

• Handle better the case where the sender sends full sized frames initially, then moves to a mode where it trickles out small amounts of data at a time.

  This known problem is even mentioned in the comments above tcp_grow_window() in tcp_input.c, specifically:

  ..
   * The scheme does not work when sender sends good segments opening
   * window and then starts to feed us spagetti. But it should work
   * in common situations. Otherwise, we have to rely on queue collapsing.
  ..

  When the sender gives full sized frames, the "struct sk_buff" overhead from each packet is small. So we'll advertize a larger window. If the sender moves to a mode where small segments are sent, this ratio becomes tilted to the other extreme and we start overrunning the socket buffer space.

  tcp_clamp_window() tries to address this, but it's clamping of tp->window_clamp is a wee bit too aggressive for this particular case.

  Fix confirmed by Ion Badulescu.

  Signed-off-by: "David S. Miller" <davem@davemloft.net>
  Signed-off-by: Chris Wright <chrisw@osdl.org>

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" <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>

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 <mk@linux-ipv6.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>

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.

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

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.