Meeting Minutes

IRC Log of the meeting.

Agenda

2010-06-15 Meeting Agenda

Release Metrics

Bugs

 
  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)

Launchpad report of bugs with patches.
Breakdown of bugs with patches

 
 

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

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 Regression Stats

Incoming Bugs:

  Version Count
  Maverick 23 (+8)
  Lucid 950 (+4)

Current regression stats:

  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.”

Open Discussion or Questions:

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