Wednesday, February 11, 2009

Jaunty Kernel Bits

It has been a long few weeks, with that said I'll try and recap some of the more interesting things that have been going on with Ubuntu, specifically the kernel happenings in the Jaunty Jackalope release.

The Platform Team met in Berlin for the Jaunty Platform Sprint for the week of 2-6 Feb. This was an incredible event with the vast majority of the Canonical Engineering teams. We had both cross team and individual sub-team tracks. The kernel track covered all of the release roadmap items and administrative topics.

I'll talk about some of the roadmap items and the most interesting highlights...

Kernel Version

The Jaunty Kernel version will be 2.6.28. We considered 2.6.29, it was not selected however due to all of the major changes. The primary reasons were due to the large number new features that are scheduled to land in it. Regression of functionality is a large concern and there would be a good chance of that happening given when estimated date that Linus will declare it baked. Unfortunately it just doesn't line up with the Jaunty release cycle. On the bright side... for Jaunty+1 we will have time to shake out any issues and are looking towards 2.6.30 or .31

Suspend & Resume

We are making the suspend & resume one of our top priorities for this cycle. We ran a suspend and resume workshop with every notebook at the sprint.

Surprisingly we had a small number of failures. Most of them were on resume with NVidia video. We did not test the priority divers only the free ones. Out of 65 machines tested (various models) there were 12 failures.

We will be issuing a Call For Testing at the Beta release, however for those of you that want to play along at home early you can visit the Suspend/Resume wiki here: and some more of the background material is here:

Some other notable suspend and resume news for Jaunty...
  • There is a new testing script to test (and stress test) suspend resume.
  • Suspend/Resume script will also be integrated into checkbox (aka System->Administration->System Testing) for ease of testing.
  • If a suspend/resume cycle fails it is detected by apport and the user will have the option of filing a bug
Vanilla Kernel Builds

Starting with Alpha 5 we will have available .deb packaged pure upstream vanilla kernels available.

The primary intent for doing this is to allow our community to test kernels without the Ubuntu "sauce", that is things that we add to the kernel to support the Ubuntu distribution. The goal is to help get wider testing of the upstream kernel source by leveraging interesting Ubuntu Community members.

In addition to Jaunty we are doing this for Hardy, Intrepid and the current active kernel development branch. The planned update schedule for each of these is:
  • Hardy, Intrepid - Upon a stable upstream point release i.e.
  • Jaunty - Every RC until release final is declared. Then it will fall into the same cycle as Hardy & Intrepid
  • Current active devel branch - Currently 2.6.29 updated on every RC release
The plan is to have them available in the Ubuntu-Kernel-Team PPA, until them you can find them at:

There is a lot more and I'll talk more about them later. As usual I'm on a plane back from Europe and my battery is beginning to run low, so thats prob about enough for this post.



Jef Spaleta said...

The vanilla kernel offering is great.

Just to be clear, is the workflow for bugs associated with the vanilla kernel going to be different than the ubuntu kernels?

You should think about requiring the kerneloops facility be installed and enabled to forward oops to when with the vanilla kernel when people choose to test it.


Pete & Amber said...


The bug flow will be handled by Ubutnu triggers & the kernel team. Bugs will be reported into launchpad with a tag verified and then opened upstream with the bz linked to the LP bug.

You sort of beat me to the kernel oops posting tomorrow. We have enabled it in our production kernels in Jaunty forward. I'll take it up with the kernel team about doing it in the vanilla kernels as well. Sounds like and excellent idea! Thanks.

Jef Spaleta said...

I give Canonical a lot of heat, so thanks for taking my suggestion seriously. Making a vanilla kernel available as a testing alternative is a really good idea.. and I think its going to pay off for everyone as a model for better upstream interaction, especially if this helps you drive issues forward to the upstream kernel developers more quickly.

Try to keep metrics on the benefits of making a vanilla kernel available. I'd like to be able to look back at what you are doing with it and be able to stand up a strong case for other distributions to do the same thing..if its something the upstream kernel developers find helpful.

Since your indulging me, exposing metrics concerning vanilla versus distribution kernel bug reporting on similar hardware might be interesting.

Even if upstream developers ultimately don't find the alternative vanilla kernel helpful, I'm going to give you high marks for trying to interact with the upstream kernel development in a more direct way by making the vanilla kernel available.


Pete & Amber said...

Thanks Jef, we will publish the stats and it will be fully transparent. Thanks for taking notice, as Manger of the Kernel Team I'm committed to making sure that we are being a good community citizens.

Anonymous said...

How is the suspend failure detection implemented? I'm asking because the current failure detection in gnome-power-manager seems to have some problems (like, so maybe you will have the same problems with the script, or otherwise g-p-m could be changed to use your failure detection.

Anonymous said...


This all sounds very interesting, does this mean eventually ie Hardy the kernel will be updateable to 2.6.27 via the repositories or just from PPA in the long term?



Pete & Amber said...


The suspend/resume detection *only* works when running the suspend/resume test. It does not work to detect routine suspend/resume failures. That would still be handled by g--p-m

Pete & Amber said...


The vanilla kernels are only designed to work or the corresponding kernel release. You could in theory put 2.6.27 on Hardy but I would not expect it to work due to the userspace changes needed.

Also I need point out these kernels are *not* supported for production use. They are made available for testers and troubleshooting only.

Anonymous said...

Unknown said...

What I would love to see is improved performance after resuming from suspend to disk.

Ubuntu is eye wateringly slow paging stuff back in from the swap file. Using vmstat I can see data coming back from swap at about 4 megabytes per second. I usually run "swapoff -a ; swapon -a" which runs at about 10 megs a second. The resume image is read at 70 megs a second so this is very subpar performance.

This normally results in Firefox being frozen until enough of it has been swapped back in.

(And before anyone says use suspend to ram, I used to but the BIOS on my motherboard hangs about one out of every ten resumes and I have to reset.)

Pete & Amber said...


Interesting we are seeing about a 4 sec resume time. If you file a bug with your metrics I'll have someone take a look. Just subscribe me to the bug or let me know the bug number.

Anonymous said...

Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!