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.
Milestone Targeted Work Items
|apw||hardware-p-kernel-boot||1 work item|
|hardware-p-kernel-config-review||4 work items|
|hardware-p-kernel-delta-review||4 work items|
|foundations-p-ipv6||1 work item|
|cking||hardware-p-kernel-delta-review||1 work item|
|jsalisbury||other-p-bug-workflows||1 work item|
|ogasawara||hardware-p-kernel-version-and-flavors||1 work item|
|hardware-p-kernel-config-review||21 work items|
|tgardner||hardware-p-kernel-version-and-flavors||1 work item|
|hardware-p-kernel-delta-review||1 work item|
Re-run power.d readahead and journal-commit tests on non-idle
user application scenerios.
Measure mouse power consumption, different rates + devices:
Complete PowerTop good/bad results:
Measure backlight levels power traits:
- More extensive 32 vs 64 bit power comparisons (in progress)
- Compare UEFI vs BIOS firmware (in progress)
Complete pm-utils measurements:
Crowd-sourcing pm-utils extra tweaks, CALL FOR TESTING:
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)
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:
|linux Hardy||10 (-1)|
|linux Lucid||7 (-1)|
|linux Maverick||7 (-1)|
|linux Natty||7 (-1)|
|linux-ec2 Lucid||7 (-1)|
|linux-fsl-imx51 Lucid||7 (-1)|
|linux-mvl-dove Lucid||7 (-1)|
|linux-mvl-dove Maverick||7 (-1)|
|linux-ti-omap4 Maverick||7 (-1)|
|linux-ti-omap4 Natty||7 (-1)|
|linux-lts-backport-maverick Lucid||7 (-1)|
|linux-lts-backport-natty Lucid||7 (-1)|
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
Lucid – 2.6.32-36.79
- Regression testing in progress.
Maverick – 2.6.35-31.63
- On holiday
Natty – 2.6.38-13.53
- Regression testing in progress.
Oneiric – 3.0.0-14.23
Prep’d and trying to reach -proposed
Current opened tracking bugs details:
- Prep’d and trying to reach -proposed
For SRUs, SRU report is a good source of information:
Future stable cadence cycles:
Hardware Certification – Testing Pools
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.
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.
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
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?