kernel weekly news – 30.10.2010

Posted: October 27, 2010 in kernel

Hello folks and get ready for this special Halloween issue of the weekly kernel news!

-From the git pull req department comes Matthew Garrett with platform drivers update targetted
at 2.6.37 (x86), Martin Schwidefsky has some fresh s390 updates for .37, Boaz Harrosh – exofs – 2.6.37
(merge window), Tony Lindgren – omap – .37, Kevin Hilman – davinci – .37 and Robert Richter with oprofile updates for 2.6.37 .

-Trond Myklebust updated the NFS client tree (mainline) in a pull request, Guenter Roeck also has his updates for
the hwmon tree and Michal Simek has announced changes to the microblaze (arch/microblaze) tree.

-Other tree updates are :
-tegra – Colin Cross (I will not specify the targetted kernel version, since, given the time period, the version is
2.6.37. I will specify if that is not the case.)
-blackfin – Mike Frysinger
-omap-dss2 – Tomi Valkeinen
-AT91 – Nicolas Ferre
-i7core/nehalem EDAC fixes – Mauro Carvalho Chehab – 2.6.36-rc1
-battery – Anton Vorontsov
-wireless – John W. Linville :
“Here are some fixes intended for 2.6.37. Highlights are some carl9170
fixes, a fix/cleanup for the earlier wl1251 move, various ath9k fixes,
a mac80211 fix relating to IBSS station expiry and a cfg80211 fix
related to processing country IEs. One of the ath9k patches looks big,
but it is just changing a table of register initialization values in
order to correct a number of issues. The associated changelogs are
reasonably descriptive of the issues involved.

Also included is a patch from Tejun as part of his work to remove
flush_scheduled_work(). I noticed you already included a similar
patch from Tejun, so I figured this was acceptable as well.

Please let me know if there are problems!”
-arch/tile – Chris Metcalf
-sound – Takashi Iwai – 2.6.37.rc1:
“The biggest changes are the update of ASoC core API, in addition to
lots of fixes/updates in ASoC drivers. The summary regarding ASoC

– Overhaul of the core APIs for registration of all kinds of devices,
reducing the level of direct coupling between machine drivers and their
CODEC and CPU drivers allowing ASoC machines to have multiple CODEC
devices and multiple instances of the same CODEC device within a system.
– New CODEC drivers for 88PM860x CODEC, MAX98088, WL1273, WM8962, WM8804,
and WM8985.
– New CPU drivers for EP93xx AC’97 controllers, MPC85xx SSI ports,
and SH HDMI controllers.
– Machine support for Freescale P1022 DS, Marvell Tavor and Saarb, and
Simplemachines Sim.One.

For HD-audio, the former individual HDMI parsers for ATI, Intel and
Nvidia are now unified to a single parser. Also, the BIOS pin parser
was improved so that it can assign multiple input-pins for the same
task (e.g. mic-in).

Another new stuff is the aloop driver. It’s a simple PCM loopback
driver for PCM data pass-through. This has been in external
alsa-driver tree for long time, and now it’s revised and merged to

Other than that, many driver updates including oxygen, USB-audio, and
the removal of BKL in OSS code, (and yet-again-new ISA driver :),
etc are found.”
-xen PV on HVM – Stefano Stabellini:
“Please pull from the following branch:

git:// for-linus

it contains both series rebased on Konrad’s xen-pcifront series [3]
(they depend on it, unfortunately I cannot produce a working series
without it) on Linux 2.6.36 rc8; my two patch series start after git
commit 67ba37293e938208795d6a3562201bdb0cf43393.

The first patch series introduces some performance improvements for Xen
PV on HVM guests: interacting with the emulated APIC is slow because it
causes traps in the hypervisor while receiving Xen events using the
vector callback mechanism allow us to skip all that. For this reason we
remap interrupts and MSIs into Xen pirqs so that from that point on we
can receive them as Xen events instead.

The second patch series implements the basic support needed to boot
Linux as initial domain on Xen: the target is not to add full featured
dom0 support in the kernel but to be able to boot Linux on Xen on

I have just added a last minute fix at end to solve a vcpu
initialization problem for pv guests (they would see only a single vcpu
even though they are given more than one [4]).”
-acpi – Len Brown (merge window)
-infiniband – Roland Dreier
-xen – Jeremy Fitzhardinge
-vfs – Al Viro
-hwpoison – Andi Kleen
-perf – Ingo Molnar
-nfsd – J. Bruce Fields
-mn10300 – David Howells
-v4l/dvb – Mauro Carvalho Chehab – 2.6.37-rc1
-viafb – Florian Tobias Schandinat
-async_tx – Dan Williams
-networking – David Miller
-linux-fs – Jan Kara – ext3 and quota fixes
-drm – Dave Airlie
-mmc – Chris Ball
-9p – Eric Van Hensbergen (merge window)
-PCI – Jesse Barnes
-staging – Greg KH (for -rc)
-x86/platform – Thomas Gleixner
-hwmon – Jean Delvare
-ext4 – Theodore Ts’o
-watchdog – Wim Van Sebroeck (for -rc1)
-md – Neil Brown
-vfs – Al Viro

-Linus sent a mail to the list titled “Reminder : short merge window”. I will reproduce it in its entirety below :
“So this is just a reminder – I’m trying to make sure that everybody is
aware of the fact that in my 2.6.36 announcement, I was talking about
trying to do a short merge window. Why? So that I could release -rc1
by the time the kernel summit started, despite the release of 2.6.36
being delayed.

And so far, in the five days since the 2.6.36 release, we’ve merged
5500+ commits. That has turned my “maybe we can do a shorter merge
window” into a “we can definitely do a shorter merge window”. Because
we already have enough changes, and there’s almost a week to go – so I
think we’re well on track for doing that. But I’ll holler here once
more, just to try to make sure that nobody gets any big surprise by
such a shorter-than-usual merge window.

So for anybody out there planning on pushing things to me for this
release and haven’t yet done so (and I know there are subsystems that
haven’t yet, because they’re in linux-next), make sure it happens this
week by Saturday (because Sunday I’m spending on a plane, and I was
tentatively planning on doing the release using the free PDX WiFi).

-Steven Rostedt announced, (obviously) a Perl script that may be used
by developers and testers in kernel test-automation. This is the mail body (well,
a part of it :) :
“You may have heard of the project at This project
is an advanced testing suite to automate tests across several number of
machines. But it may be a bit too complex for the kernel developer that
has a hacked up setup in his basement, and only has a few tests that
need automation.

Thus, if you are like me, and just want something that can automate the

1) run ranconfig several times and make sure it builds and boots

2) Have a bunch of patches you are about to push, and you want to
make sure they build (and don’t cause new warnings), boot and
perhaps run a test script on the test box, for each patch you
are about to push.

3) Bisect a reproducing bug, that either fails the build of the
kernel, booting of the kernel, or can be detected by a script that
is run on the test machine.

Then I have the script for you!

**** ****

(for the script and a sample config file that is highly documented)

I know lots of other developers that have written their own scripts, but
I worked on this to be as simple, generic and flexible as possible, with
as little learning curve as possible.

I’ve just completed This is a perl script that can do
bisects, patch set verification, or just simply test rand configs on
various kernels.

The way it works, is that it reads a generic config file that you set
up. You do not need to know perl or how the script itself works. But
here’s the current requirements to use the test script:

1) You need two machines, where one is the build system and the other is
the test system. It also works with a virtual machine system where the
Guest is the test system and the host is the build system.

2) You need a way to force a reboot of the test system. For bare-metal,
I use a digital loggers power switch box. But virsh works well for
virtual guests too.

3) The user running the test must be able to ssh into the test system
from the build system without a login (ie. using ssh keys). The script
uses scp to copy data onto the system.

4) The test system needs a minimum of two kernels. One to boot to a
reliable kernel (this may be the distro kernel) and this kernel needs to
be loaded by default. The second kernel is the test kernel, which may
or may not even boot.

5) You need a way to reboot into the test kernel for one instance. If
you use grub v1, this is already supplied. Just specify in the config
file the full title name of the test kernel in /boot/grub/menu.lst.

6) You need a way to read the console output of the test box with
something that produces standard output.

That’s about it!”
Since the reactions were more than warm, expect to see the script soon in your local git clone.

-That’s about it for this week, enjoy the weekend and the Halloween parties !

  1. fajriyansah says:

    nice article and good job

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s