Ubuntu Kernel Team: Kernel Team Meeting Minutes – December 13, 2011

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20111213 Meeting Agenda

ARM Status

P/omap4: a new kernel (3.2.0-1402.2) based off 3.2 (Ubuntu-3.2.0-3.9) has been released, while a new TI BSP + 3.2-rc5 is in the pipe.
SRU kernels: nothing to report.

Release Metrics and Incoming Bugs

Just adding link this week, instead of posting all data.

http://people.canonical.com/~kernel/reports/kt-meeting.txt

Milestone Targeted Work Items

If your name is in the above table, please review your Alpha-2 work items. Note that Alpha-2 is Thurs Feb 2.

Blueprint: hardware-p-kernel-power-management

Power Management:

• Re-run power.d readahead and journal-commit tests on non-idle
  user application scenerios.
• Measure mouse power consumption, different rates + devices:

http://zinc.canonical.com/~cking/power-benchmarking/mouse-movement

http://zinc.canonical.com/~cking/power-benchmarking/powertop-good-bad-recommendations

http://zinc.canonical.com/~cking/power-benchmarking/backlight-non-linearity

http://zinc.canonical.com/~cking/power-benchmarking/pm-utils-results

https://wiki.ubuntu.com/Kernel/PowerManagementPMUtils

Status: Precise Development Kernel

We have uploaded the 3.2.0-4.10 Ubuntu kernel which is based on latest upstream v3.2-rc5 kernel. Additionally, after yesterday’s Tech Board discussion around the i386 non-pae flavor, it was decided to continue carrying this flavor for 12.04 and then drop it in 12.10. The installer will also be switched to default to the pae flavor for i386.

Important Upcoming Dates:

• Thurs Feb 2 – Alpha 2 (~7 weeks)

Status: CVE’s

CVE-2010-4251 CVE-2010-4805 CVE-2011-1082 CVE-2011-1083: epoll DOS — fix incomplete, referred back to Security for review
CVE-2011-1747: agp ioctl memory DOS — no upstream fix as yet
CVE-2011-3347: be2net non-member vlan DOS — cannot identify upstream fix
CVE-2011-3638: ext4 extent split — upstream fix identified, pending application
CVE-2011-4112: pktgen bridge panic — redhat is withdrawing the CVE
CVE-2011-4131: nfs4 ACL oops — fix is still iterating upstream, pending
CVE-2011-4347: kvm kvm_vm_ioctl_assign_device crashes — no upsteam fix as yet

=== CVE Metrics ===

Currently open CVEs for each supported branch:

We only have one open CVE with an upstream fix currently. The remainder await fixes from upstream.

(bah, will drop the CVE- prefix for future updates.) ..

Status: Stable, Security, and Bugfix Kernel Updates – Oneiric/Natty/Maverick/Lucid/Hardy

Many of the kernels in -proposed were quickly verified and went into
regression testing early. This week is mostly about finishing up the
stragglers. A new Oneiric has been prep’d and uploaded. We’ll just have
to see if we can get it verified and regression tested before the
dead week of Christmas.

Here is the status for the main kernels, until today (13/12):

• Hardy – 2.6.24-30.97

• On holiday

• Regression testing in progress.

• On holiday

• Regression testing in progress.

• Prep’d and trying to reach -proposed

Current opened tracking bugs details:

Hardware Certification – Testing Pools

hi
let me do this gradually As part of the SRU workflow the hardware certification team tests the -proposed kernel on as many certified systems as possible. As the number of certified systems for each release has grown, getting full coverage has become more and more difficult. To allow us to reduce the number of systems tested we have devised a system of ‘testing pools’. This takes advantage of a system which stores details of the certified hardware including it constituent components to provide as broad a component coverage as possible.

Initially the system ensured that at least one instance of each piece of hardware (as identified by PCI Id’s) was present in the testing pool. This turned out not to fulfill the goal of the system since we still ended up with needing almost all the systems we had to provide full coverage (e.g. 165 systems certified for Natty gave a testing pool of 158)

We made a first effort at reducing the size of the pools by considering only components of particular categories to be ‘important’. A list of these was sent to the kernel-team mailing list.

https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AphFraZYTghddElqTHl3NmZsWXVDYkMxcE5zX3EtR0E&hl=en_US#gid=0

These give us testing pools of ~50 systems. However we are not happy yet with the coverage. We need feedback on which components need to be added in. The criteria used should be: how likely is it that a bug could occur in just a subset of the components of this category? A good example is the category ‘Display Controller/VGA Compatible Controller’ which we do cover already. We know for a fact that bugs will be specific to particular makes of graphics card. Same for CPUs (‘Processor’ category)

We really need feedback on this
…

brendand, This will all be documented in the meeting minutes. It would be good if you could also follow up with an email to the kernel-team mailing list.

Open Discussion or Questions? Raise your hand to be recognized

brendand: Do you have a revised list which has all the possible components you want us to review to consider adding back in? Also, what # are you looking for to satify coverage? ogasawara – if you can access that link then all the ones marked ‘x’ are not considered at the moment

we have no fixed number to reach

brendand, what is the max number of machines that you can cover ?

tgardner – it seems to be about 90, realistically speaking. something like that.
ack

i would prefer for now to take each component category on it’s own merits’ rather than considering how many extra systems it adds. we (the hwcert team) can worry about managing that

i had a question to pose, as a bit of a thought experiment

Could a bug affect only a subset of device of the category ‘Bridge/PCI bridge’?

brendand, likely, but its more likely to be BIOS specific
if there is more than one different piece of h/w in any category it is possible to get different results from each however, we have way fewer problems with PCI bridges.

apw – yes, definitely *possible*.
actually the point of that question was to illustrate the line of thinking that needs to be taken to evaluate this list of component categories between tgardner and apw that’s the kind of critique of the list i’m looking for
thanks
Any Open Discussion comments?

one last thing. i’m not sure is that link public. anyone who can’t get access please let me know and i’ll sort something out

If no other comments, then going once

brendand: how do you want feedback, maybe a “feedback” column, and we’ll add X’s to categories we think should be added back?

ogasawara – i’m arranging for everyone to have edit rights and i’ll add a feedback column

brendand: let us know when it’s ready for editing. I’m sure a few of us can just a quick pass off and tick the ones we want.
brendand, any other comments?

yeah, if any of the categories don’t make sense to you, contact me about it
i’ll send the link to the kernel-team list

brendand, dot dot then ?

Any other open discussions or questions?