Ubuntu Kernel Team Meeting Minutes - 06/15/2010
Brad Figg
brad.figg at canonical.com
Wed Jun 16 00:15:14 BST 2010
= Meeting Minutes =
[[http://irclogs.ubuntu.com/2010/06/15/%23ubuntu-meeting.txt|IRC Log of the meeting.]]
<<BR>>
[[http://voices.canonical.com/kernelteam/|Kernel Team Blog.]]
== Agenda ==
[[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 15 Jun, 2010|20100615 Meeting Agenda]]
=== Release Metrics ===
==== Bugs ====
||<-3 tablestyle="width: 100%;")> ||
||<:> ||<:> '''Alpha 2 Milestoned Bugs (29 (up 24))''' ||<:> '''Release Targeted Bugs (83 across all packages (up 33))''' ||
||linux ||<:> 10 ||<:> 17 ||
==== Milestoned Features ====
* 13 blueprints (Includes HWE Blueprints)
==== Bugs with Patches Attached:117 (down 5 from last week) ====
* https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
* Breakdown by status:
http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/
=== Blueprint: kernel-maverick-apparmor ===
Slow progress - updated compatibility code, need to do testing and send out pull request when done
=== Blueprint: kernel-maverick-firewire-stack ===
Nothing to report
=== Blueprint: kernel-maverick-misc ===
The debian commonisation is progressing well, both Karmic and Lucid branch sets have been converted over. There is some resistance to applying these changes to Karmic currently as they are very hard to review and seen as perhaps outside the SRU process;
discussions are ongoing but we may have to abandon doing this for Karmic. We have also mothballed a no longer used branch in Karmic, the netbook branch.
'''Question:''' "Does this lift a hold on lucid patches against mvl-dove?"
'''Answer:''' Yes, it appears to and we think the Marvell, lucid patches are in the tree and awaiting upload."
=== Blueprint: kernel-maverick-new-kernel-on-lts ===
The LTS backport kernel and meta packages at http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu are up to 2.6.35-3.4 (tracking the latest maverick kernel release). All appears well. In fact, its much better then the previous 2.6.35-rc2 based release which had
some memory corrupter bugs.
=== Blueprint: kernel-maverick-pv-ops-ec2-kernel ===
pv-on-HVM drivers don't help us out :(
Karmic pv-ops kernel on EC2 is more flaky than it was in the Karmic cycle (only successfully booted in 1 of 4 availability zones).
Lucid pv-ops is boot in 2 of 4 availability zones on last test.
Maverick wasn't booting at all under 2.6.35.2, have tried it with the latest config changes made pulled forward from Lucid and haven't tried .3 yet.
Current plan is revert to full Xen topic branch, and get other work items done and return to pv-ops kernel in a few weeks.
'''Question:''' "Wasn't there a middle option? The drivers only?"
'''Answer:''' "The drivers are the pv-ops-HVM."
=== Blueprint: kernel-maverick-tracing-support ===
Patch sent upstream for perf probe under review. I've packaged trace-cmd and kernelshark, sent three patches upstream for them (2 trace-cmd, 1 kernel). Will work on getting them into Maverick.
=== Blueprint: kernel-maverick-ubuntu-delta-review ===
I pushed 3 of our sauce patches upstream which just removed some
duplicate device id's. I've also dropped 2 more sauce patches which
added MODULE_ALIAS for the Dell WMI module and the other which sent
events on data interface as well as master interface for the hostap
driver.
=== Blueprint: kernel-maverick-union-mounts ===
Waiting on testing from Foundations from updated kernels. Need to get the tools updated for this and uploaded to the same PPA, hoping to have those tommorrow.
(tgardner) ogasawara, you got some pushback on one of those removals. what came of that?
(ogasawara) tgardner: hrm, I didn't see any reply.
(ogasawara) tgardner: I'll have to look into it
(tgardner) ogasawara, the one with duplicate IDs
(ogasawara) tgardner: I'm not subscribed to the upstream list so I wonder if I wasn't CC'd on the reply?
(tgardner) ogasawara, likely
(apw) google is your friend
=== Blueprint: kernel-maverick-bug-handling ===
* Conversation with the Forums people has begun, they are talking internally to gather some thoughts on our proposal concerning the discussion between us to improve the quality of the information on the forums. They will be gettting back with me late
this week or next week and we will go from there.
* I have tested the SHA1 gathering script several times now. It will likely not be as useful as i thought due to the fact that the janitor puts a comment containing the SHA1 of the fix that solves an issue in bugs that potentially have multiple tasks,
thus giving us false positives. I am working to define the problem before I see if we can modify the script to react to those comments appropriately.
* I sent out the initial e-mail to get an idea of the interest level for a Kernel Triager Summit. Based on the response, I will begin the further planning items needed to make this a reality.
=== Blueprint: kernel-maverick-upstart ===
Waiting on testing from Foundation from updates kernels. Expecting preliminary feedback on Wednesday.
=== Blueprint: kernel-maverick-bios-test-automation ===
* Added the following functionality to the firmware test suite:
* Battery Test: Exercise CPU to drain quicker
* Kernel Version checking
* Include Blank Test Template
* Re-organise klog scanning, added more intelligence
* Logging: Add line numbering, test failure levels, summary of failures, improved automatic text formatting
* Add --no-s3 --no-s4 options to ignore suspend/hibernate tests
* Check for redundant _OSI(Linux)
* HPET sanity check vendor ID
* Syntax check SSDT tables
* Virtualisation extention checks
* Add in MCFG test
* General bug fixing and code tidying
=== Status: Maverick ===
We've rebased to 2.6.35-rc3 which should be available as of
linux-2.6.35-3.4. '''Please test'''.
Alpha 2 is Thurs July 1 (ie ~2weeks from today) so make sure you're on
track with any work items that need doing as we're currently above the
trend line in our Alpha 2 burn down chart:
Also keep in mind that if you have any patches which you want to land
in the Alpha2 kernel, they need to be sent to the kernel-team ml and
have garnered the appropriate Ack's '''before''' Fri Jun 25. I'll send an
email reminder this Friday.
=== Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others ===
* Dapper: 2.6.15-55.84 (security)
* Hardy: 2.6.24-28.70 (security)
2.6.24-28.71 (waiting for approval)
* Jaunty: 2.6.28-19.61 (security)
* Karmic: 2.6.31-22.60 (security)
2.6.31-22.61 (waiting for approval)
- mvl-dove 2.6.31-214.28 (security)
2.6.31-214.29 (waiting for approval)
- fsl-imx51 2.6.31-112.28 (security)
2.6.31-112.29 (waiting for approval)
- ec2 2.6.31-307.15 (security)
2.6.31-307.16 (waiting for approval)
* Lucid: 2.6.32-22.36 (security)
2.6.32-23.37 (proposed)[4] 8/39 verifications done (+ 8)
- LBM 2.6.32-23.37 (proposed)[1] 1/ 3 verifications done (+ 1)
- mvl-dove 2.6.32-205.18 (security)
2.6.32-206.19 (waiting for approval)
- fsl-imx51 2.6.31-608.14 (security)
2.6.31-608.15 (waiting for approval)
- ti-omap 2.6.33-501.7 (security)
2.6.33-502.8 (waiting for approval)
- qcm-msm 2.6.31-802.4 (security)
2.6.31-802.5 (waiting for approval)
- ec2 2.6.32-306.11 (security)
2.6.32-307.12 (waiting for approval)
As we found out today there is resistance on the current changes in Karmic
which only affect the build infrastructure. This needs to be resolved
before the uploads will be accepted into proposed.
=== Incoming Bugs and Regressions ===
==== Incoming Bugs: ====
||<-2 tablestyle="width: 35%;")> ||
||<:> '''Version''' ||<:> '''Count''' ||
||Maverick ||<:>23 (+8) ||
||Lucid ||<:>950 (+4) ||
==== Current regression stats: ====
||<-5 tablestyle="width: 100%;")> ||
||<:> '''Version''' ||<:> '''Potential''' ||<:> '''Update''' ||<:> '''Release''' ||<:> '''Proposed''' ||
|| maverick ||<:> 8 (+1) ||<:> ||<:> ||<:> ||
|| lucid ||<:> 223 (-11;) ||<:> 30 (+5) ||<:> 136 (+8) ||<:> 1 ||
|| karmic ||<:> ||<:> 6 (-3) ||<:> 48 (-2) ||<:> 1 ||
|| jaunty ||<:> ||<:> 4 (-1) ||<:> 19 (-1) ||<:> ||
|| hardy ||<:> ||<:> 1 ||<:> 2 (-1) ||<:> ||
=== Incoming Bugs: Bug day report ===
I neglected to announce the Bug Day scheduled for today last week due to travel for the SELF conference. That Bug Day will be held next week. The next bug day will be next Tuesday. We will be focusing on working Confirmed bugs and getting them to either
Incomplete, by way of testing or information requests, or Triaged based on the completeness of the bug. My goal is to work through all of the Confirmed bugs to get them in the correct state and work
but the best method for them based on conversation with Andy last week. I am happy with the progress of the Team bug day so far. I'd like to hold this again this week. I am open to continuing the two half days on Friday and Monday again if there is no
objection.
'''Question:''' "Are you all still finding the half day Kernel team days on friday and monday useful?"
'''Answer:''' "Though not everyone has been able to participate as much as they'd like, they do like the split and we'll continue to see if the idea gets traction."
=== [TOPIC] Open Discussion or Questions: Anyone have anything? ===
|| (ogasawara) || https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-gpu-freeze-reports ||
|| (ogasawara) || There are 3 Alpha2 work items assigned to the canonical-kernel-team in ||
|| (ogasawara) || that blueprint. ||
|| (ogasawara) || sconklin, could I persuade you to own those 3 work items? It looked like ||
|| (ogasawara) || you and apw attended this UDS session but apw seems to have enough ||
|| (ogasawara) || Alpha2 work items on his plate. ||
|| (sconklin) || looking ||
|| (ogasawara) || while you're looking, the other item was https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-uefi-support ||
|| (ogasawara) || This also has an Alpha2 work item assigned to canonical-kernel-team, ||
|| (ogasawara) || "Investigate situation with Intel graphics drivers on EFI". ||
|| (ogasawara) || cking or tgardner, did either of you attend this UDS session? Can I get ||
|| (ogasawara) || one of you to own this work item? ||
|| (sconklin) || ogasawara: sure, I can take those ||
|| (cking) || ogasawara, nope, it clashed with something else I had to attend ||
|| (ogasawara) || sconklin: thanks, much appreciated. ||
|| (tgardner) || ogasawara, I volunteer cking as he's already involved with EFI ||
|| (sconklin) || I'll edit the blueprint now || ||
|| (ogasawara) || cking: thanks ||
|| (phunge0) || https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092 ||
|| (ubottu) || Launchpad bug 585092 in linux (Ubuntu) "tmpfs umount slowdown" [Medium,Triaged] ||
|| (phunge0) || Could I get some feedback on prospects for this bug in lucid? Upstream devs think they have a real fix to the problem (2nd try), it's been posted to lkml but won't be merged until 2.6.35-rc4 at earliest (when Linus gets back from
vacation). I'm wondering if backporting it would be considered feasible. If not I'm hoping the workaround could be revisited, it has serious performance downsides. ||
|| (phunge0) || Please let me know if there's someone specific I should be talking to. ||
|| (tgardner) || phunge0, is this so critical that you can't wait 2 weeks for it to show up in due course? ||
|| (smb) || I believe last time they had a fix they reverted it due to hangs in xfs ||
|| (bjf) || phunge0, it looks like we are waiting to see what upstream wants to do about it ||
|| (smb) || But it was one of the things I wanted to investigate ||
|| (phunge0) || ok ||
|| (apw) || phunge0, do we have a poninter to the outstanding conversation on that ||
|| (phunge0) || it's not critical, but my firm was hoping to migrate to lucid with the SRU ||
|| (phunge0) || http://lkml.org/lkml/2010/6/10/259 ||
|| (apw) || to the 'new' fix? make it easier for us to track when it hits maverick so we can test ||
|| (phunge0) || and this blocks us ||
|| (apw) || phunge0, thanks ||
|| (apw) || phunge0, us ? ||
|| (phunge0) || this is the patchset http://lkml.org/lkml/2010/6/10/175 ||
|| (phunge0) || my firm, sorry ||
|| (tgardner) || phunge0, it remains to be seen if Jens fix is gonna do the trick ||
|| (apw) || phunge0, thats like 13 patches! ||
|| (tgardner) || apw, maybe we can get it via stable :) ||
|| (apw) || tgardner, fingers crossed :) ||
|| (phunge0) || yeah, this is linus indicating that it might be acceptable for 2.6.35 ||
|| (smb) || We might but that will certainly take time ||
|| (apw) || cirtainly we should help test it in 35 ||
|| (phunge0) || http://lkml.org/lkml/2010/6/10/285 ||
|| (phunge0) || but he pushed back ||
|| (manjo) || can we get some feed back on the firewire stack switch? I think its a matter of blacklisting old modules and whitelisting new ones ||
|| (manjo) || blacklist ohci1394 sbp2 eth1394 dv1394 raw1394 video1394 and whitelist firewire-ohci firewire-sbp2 firewire-core firewire-net in /etc/modprobe.d/blacklist-firewire.conf. As far as I can see this is the only real change that needs to
happen to make this switch. ||
|| (manjo) || I emailed ubuntu-devel and ubuntu-kernel ||
|| (manjo) || and I don't have any response yet ||
|| (manjo) || ie switch from old firewire stack to new stack ||
|| (apw) || so i'd recommend you ask on #ubuntu-devel about this as well ||
|| (tgardner) || manjo, did your email include a patch? ||
|| (apw) || there are some old hands there who can probabally help guide us as to the next step ||
|| (manjo) || tgardner, no, I thought we talked about this a while back and ||
|| (manjo) || foundations need to make that change ? ||
|| (tgardner) || manjo, we can do it as well. we have before ||
|| (manjo) || I am happy to send a patch ||
|| (manjo) || tgardner, to ubuntu-kernel ? ||
|| (apw) || manjo, do we have the alternate userspace stack available ? ||
|| (tgardner) || I want some test results too. ||
|| (apw) || (i thought there was one if you switched?) ||
|| (manjo) || yep we have both moduels built as of now ||
|| (tgardner) || manjo, yep, ubuntu-kernel list ||
|| (apw) || manjo, i meant the userspace integration, does it work with both ? ||
|| (apw) || s/both/either ||
|| (tgardner) || apw, thats what I meant by test results ||
|| (manjo) || apw, there was a bug for which the switch was tested ||
|| (manjo) || but I can send a patch with test info ||
|| (tgardner) || manjo, just put the results in the bug ||
|| (apw) || sounds good then ... ||
|| (JFo) || I think we need a gneral CFT on the new stack then ||
|| (manjo) || tgardner, will do ||
|| (tgardner) || JFo, good idea ||
|| (manjo) || bjf, can you action me ||
|| (manjo) || so that I have this info for the next meeting ||
|| (manjo) || for/before ||
|| (JFo) || bjf, action me as well for the sending of the CFT ||
|| (bjf) || [ACTION] manjo to send a patch with test info ||
|| (JFo) || manjo, I'll send it once you let me know it is built and where the test kernel is. ||
|| (bjf) || [ACTION] jfo to put out a CFT on new firewire stack ||
|| (JFo) || thanks bjf ||
|| (kamal) || Regarding bug 553498 ||
|| (ubottu) || Launchpad bug 553498 in linux (Ubuntu Lucid) "Intel Core i3/i5/i7 hang on resume from suspend (SCI_EN)" [High,Fix committed] https://launchpad.net/bugs/553498 ||
|| (kamal) || We have this marked as Fix Committed for Lucid, but the fix in Lucid (my original patch) only helps Dell Studio 155x machines, so isn't really sufficient. ||
|| (kamal) || I would like to get M. Garrett's better version of the fix ("Unconditionally set SCI_EN", as it exists now in Maverick) pulled into Lucid so we can fix this for all i3/i5/i7 machines.||
|| (kamal) || What is the procedure? ||
|| (apw) || kamal, propose it as an SRU patch in the normal way ||
|| (apw) || send it to the kernel-team list etc ||
|| (tgardner) || that one seems like a good stable update patch ||
|| (kamal) || ok, will do -- can I change the bug state from "Fix Committed" back to "In Progress" or something also? ||
|| (smb) || Would there be chance that GregKH accepts it into stable upstream? ||
|| (tgardner) || smb reads my mind ||
|| (apw) || cirtainly worth asking ... ||
|| (bjf) || kamal, you can also open a new bug just for the purposes of SRU, point back at the other bug ||
|| (smb) || kamal, as bjf suggest ||
|| (kamal) || bjf, ok I'll open a whole new bug for this -- should I ask GregKH about this directly? ||
|| (smb) || Sounds strange that the bug only closes dell but is named generically ||
|| (kamal) || the bug was originally titled "Dell Studio ..." but I changed it after realizing that it affected all (?) i3/i5/i7 machines ||
|| (apw) || kamal, yeah we should get the title of the dell only bug fixed to be dell only and make the new one generic ||
|| (smb) || kamal, I wonder whether I have not written some notes how to do ||
|| (smb) || kamal, let me dig and get back to you ||
|| (kamal) || apw: ok, that makes sense re: the bug titling. ||
|| (kamal) || smb: I'll wait for your notes. ||
|| (kamal) || thanks folks ||
--
Brad Figg brad.figg at canonical.com http://www.canonical.com
More information about the Ubuntu-news-team
mailing list