[07:55] <kraut> moin
[13:25] <BenC> Good morning everyone
[13:25] <cking> Morning BenC
[13:42] <amitk_> BenC: any reason we might _not_ upload a new kernel today?
[13:43] <BenC> amitk_: none that I know of
[13:43] <soren> When do you intend to freeze?
[13:44] <rtg> amitk_: gotta finish fixing this DMI IO_DELAY patch for xen before uploading.
[13:44] <tjaalton> BenC: is the abi going to change? I've got some packaging fixes for lrm pending
[13:45] <rtg> tjaalton: the ABI is -13
[13:45] <tjaalton> rtg: right, but there won't be a -14 ?-)
[13:45] <BenC> tjaalton: we will need a new lrm uploaded
[13:45] <rtg> tjaalton: sorry, misunderstood. No, the ABI should remain at 13
[13:46] <amitk_> rtg: no worries. I was just asking to make sure I don't have to do a separate upload for mobile.
[13:46] <tjaalton> BenC: yeah, that's why I'm asking :)
[14:03] <rtg> zul: you around?
[14:03] <zul> rtg: perhaps yes :)
[14:04] <rtg> zul: I'm adding some definitions to include/asm-x86/mach-xen/asm/io_32.h and io_64.h. Whats the best way to do that? Its for the IO_DELAY patch.
[14:05] <zul> create a patch for it and add it to the list
[14:05] <zul> or you could send it to me and I could do it for you
[14:06] <rtg> zul: ok, gimme a bit to get it prepared.
[14:06] <zul> sure
[14:06] <zul> just ping me when you are ready
[14:09] <rtg> zul: I committed to the main Hardy repo. I think xen is the only flavour that does not build. It fails early on with kernel/sysctl.c
[14:10] <zul> hmm..ok
[14:10] <zul> grrr..
[14:27] <rtg> tjaalton: if you are going to upload lrm, how about updating madwifi to 0.9.4 first?
[14:44] <tjaalton> rtg: sure
[14:45] <rtg> tjaalton: thanks
[14:46] <tjaalton> that'll probably fix bug 182489 too
[14:46] <ubotu> Launchpad bug 182489 in linux-restricted-modules-2.6.24 "Atheros wireless (AR5006EG) not working on ASUS Eee PC" [High,Confirmed] https://launchpad.net/bugs/182489
[14:48] <rtg> tjaalton: I couldn't tell if the update enables some of the newer Atheros chipsets. 
[14:49] <tjaalton> oh right
[15:40] <BenC> I think to fix the cpufreq loss on cpu1 for suspend/resume, I may just pull 2.6.25 for the next upload
[15:40] <BenC> probably will be an ABI change
[15:41] <cking> BenC>
[15:41] <cking> ?
[15:41] <rtg> cking: he's kidding.
[15:41] <BenC> you hope :)
[15:41] <cking> Opps: typos galore
[15:41] <cking> BenC: 2.6.25 may also fix some of the scheduling interrupts issues.
[15:42] <cking> BenC: April fool'd me?
[15:43]  * BenC 1, cking 0
[15:43] <cking> ...well done. 
[15:43] <cking> ...I am v. gullible.
[15:44] <BenC> hehe
[15:45] <BenC> don't feel bad, I fooled my kids into thinking the school's power was out, and they could stay home today
[15:45] <rtg> BenC: oh, how cruel!
[15:45] <smb> BenC: cruel was word I was missing .:)
[15:50] <soren> Hm.. I'm considering syncing our virtio stuff with what's currently in 2.6.25. The trouble is that there's no way to merge cleanly with linus, because what we have now came from a different VCS, got changed, and was then imported into linus's tree, so what we have does not correspond to anything that was ever in another git tree. How would you handle this?
[15:50] <soren> (please ignore the question of "why" for now)
[15:51] <BenC> soren: one big patch with a thorough list of changes in the commit log
[15:51] <soren> I'm considering reverting all teh commits that brought us to where we are now and then cherry-picking from linus, but that looks butt ugly in the logs
[15:51] <soren> BenC: Oh, really?
[15:51] <soren> Hm..
[15:52] <soren> Ok, that actually sounds somewhat manageable.
[15:52] <BenC> post-hardy, we'll basically ditch all of those commits
[15:52] <soren> Sure.
[15:52] <soren> The changes aren't really very big, but the amount of commits rewinding and the fast-forwarding again made it look *huge*.
[15:52] <BenC> See, we're a reasonable bunch :)
[15:53] <soren> Sometimes, perhaps :)
[15:53] <soren> I'd like a few days to test it.. When was the freeze again?
[15:54] <BenC> Hmm, we are actually planning an upload this evening...and the chances of another upload before release is very slim
[15:54] <BenC> but not impossible
[15:55] <rtg> zul: how is the IO_DELAY patch coming for xen?
[15:55] <zul> need to compile test it
[15:55] <soren> BenC: So you all go on holiday starting tomorrow? :)
[15:55] <rtg> zul: I have compile engines if you can give me the patch
[15:56] <zul> sure gimme a sec...ill put it up somewhere
[15:56] <rtg> soren: we're gone until after UDS :)
[15:57] <zul> rtg: http://people.ubuntu.com/~chucks/0003-xen-io-delay-fix.patch
[15:57] <rtg> zul: cool
[15:57] <zul> rtg: hopefully that will fix it
[15:58] <BenC> If not, maybe just add a 0000-revert-iodelay.patch for xen
[15:59] <BenC> rtg: is -rt or -openvz experiencing problems with iodelay?
[15:59] <BenC> I'd do the revert for them instantly if so
[15:59] <rtg> BenC: nope
[15:59] <BenC> ok
[15:59] <rtg> xen fails because of the way they generate asm includes.
[15:59] <BenC> gotcha
[16:01] <rtg> BenC: or rather, include/asm/mach-xen/asm includes. Its kind of weird.
[16:01] <zul> yeah that totally sucks...redhat is getting dom0 to work with paravirt-ops
[16:50] <tjaalton> rtg: madwifi-0.9.4 builds fine
[16:51] <rtg> tjaalton: cool. we should have an upload later today that fixes the sparc/powerpc/hppa FTBSs.
[16:52] <tjaalton> rtg: ok, I don't have any further changes, the one that was assigned turned out to be invalid
[16:52] <tjaalton> of course there'll be new nvidia/fglrx tomorrow..
[16:53] <rtg> tjaalton: isn't that the way it always is :)
[16:54] <tjaalton> rtg: yep, a pleasure to work with :) (making new tarballs, blech)
[17:04] <abogani> rtg: Sorry for Xen break!
[17:04] <BenC> Hey ppl
[17:04] <rtg> abogani: np. zul fixed it right up.
[17:04] <BenC> Running a little late on starting the meeting...
[17:05] <smb> BenC: Hi
[17:05] <cking> BenC: hiya
[17:05] <amitk_> here
[17:05] <BenC> Basically we are jumping right into this list: https://edge.launchpad.net/ubuntu/+milestone/ubuntu-8.04
[17:05] <BenC> s/edge\.// for the non-beta-launchpad folks
[17:06] <BenC> Bug #188226 is the first one
[17:06] <ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,In progress] https://launchpad.net/bugs/188226
[17:06] <BenC> Any comments on that? I'm sort of on the fence with it
[17:07] <BenC> I'm open to enabling this for certain flavours too, as opposed to all flavours
[17:08] <rtg> I thought the server folks would have som e interest in this.
[17:08] <BenC> default in kernel Kconfig is USER_SCHED
[17:08] <rtg> does CGROUPS _require_ a user space app to configure?
[17:09] <BenC> No, you can configure it with echo if you want
[17:09] <BenC> but the udev/userspace stuff makes it easier to automate
[17:09] <rtg> these guys say you can simulate USER_SCHED usgin CGROUPS.
[17:10] <BenC> Are the tools in universe?
[17:10] <BenC> right, but that's a bit much to do right before RC, I think
[17:10] <rtg> agreed.
[17:10] <rtg> I'm not sure that 'High' is the appropriate priority.
[17:11] <BenC> Maybe this should be in server flavours, and re-evaluate at UDS
[17:11] <rtg> that is what I proposedto soren awhile ago.
[17:11] <cking> The scheduler cannot be all things to all men all the time
[17:12] <BenC> agreed
[17:12] <BenC> soren: server flavours == -server in i386/amd64, and all of sparc/hppa/ia64
[17:12] <BenC> s/soren/so/
[17:12] <rtg> right.
[17:12] <rtg> since I'm doing test build, I can take care of it.
[17:13] <BenC> Great, thanks...please update the bug report with the decision too
[17:13] <rtg> just doing so...
[17:13] <BenC> Bug #200057
[17:13] <ubotu> Launchpad bug 200057 in linux "HP / Compaq laptops crash with port 0x80 delay write" [High,In progress] https://launchpad.net/bugs/200057
[17:14] <BenC> Tim, that's assigned to you...that's fixed with iodelay, right?
[17:14] <rtg> yep - fix committed.,
[17:14] <rtg> i have positive feedback that it solves a problem.
[17:14] <BenC> Excellent
[17:14] <BenC> Bug #187671
[17:14] <ubotu> Launchpad bug 187671 in linux "sdhci module hangs Everex StepNote 2053T" [Medium,Triaged] https://launchpad.net/bugs/187671
[17:15] <rtg> hopefully it won't introduce regressions.
[17:15] <BenC> smb: That one's assigned to you...what's the status?
[17:15] <smb> This is still being debugged on kernel bugzilla
[17:16] <smb> There isn't something definitive, yet. Looks like certin inb operations lock up when done in series
[17:16] <smb> but not always the same. Strange timing issue
[17:16] <BenC> wonder if it's hardware
[17:16] <rtg> smb: will the DMI IO_DELAY patch help?
[17:17] <smb> I am not sure, there is a chence
[17:17] <mjg59> rtg: I doubt it - unless it's doing inb_p, it doesn't cover that codepath
[17:17] <rtg> mjg59: that was kind of what I was wondering.
[17:18] <smb> no, not that i know of only normal inb, inw...
[17:18] <smb> but I check against that
[17:19] <smb> Using readb, readl, readw...
[17:20] <BenC> smb: Unless you can come up with something definitive by the end of the week, we may have to just mark it -later
[17:21] <BenC> And that's the last open bug on the list
[17:21] <smb> BenC: ok
[17:21] <smb> There is bug 134660
[17:21] <ubotu> Launchpad bug 134660 in linux-ubuntu-modules-2.6.24 "Ralink rt2400 / rt2500 / rt2570 / rt61 / rt73 do not work out of the box in Gutsy/Hardy" [High,Confirmed] https://launchpad.net/bugs/134660
[17:21] <BenC> it's not milestoned for ubuntu-8.04
[17:21] <smb> I am currently building a test kernel we could try
[17:21] <BenC> if it needs to be looked at, please make sure it is milestoned
[17:21] <smb> BenC: Its on the milestone list
[17:22]  * BenC missed it
[17:22] <BenC> I see it now
[17:23] <BenC> smb: Ok, just to recap what we discussed earlier, if testing shows that 2.6.25 rt2x00 code works for the reporter, we'll get it in
[17:23] <smb> BenC: Right
[17:24] <smb> If it doesn't I would mark it as -later 
[17:24] <BenC> please make sure the bug is updated with that info so folks know what our intentions are
[17:24] <smb> ok
[17:24] <BenC> thanks
[17:24] <BenC> Anything we missed, or that needs to be added to the milestone list?
[17:25] <BenC> rtg: later I want to review the dell patches I have to make sure we aren't missing anything
[17:26] <BenC> Alright, that's the end of the meeting then
[17:26] <BenC> Thanks everyone
[17:26] <rtg> BenC: ok. Mario complained about some missing ones yesterday, but I think I got 'em since.
[18:11] <keescook> hola.  any general eta on l-u-m for -13?
[18:12] <rtg> keescook: uploading a kernel tonight. lum/lrm/lbm too follow.
[18:13] <rtg> I could do them earlier, but the last kernel upload FTBS on all but x86/x86_64
[18:13] <keescook> rtg: sweet, okay.  I was testing -13 for my kvm and aa fixes, and noticed my sound was gone.  :P
[18:13] <keescook> oh
[18:13] <keescook> haha
[19:56] <rtg> drat. setting CONFIG_CGROUPS is gonna cause an ABI bump.