[08:50] <janimo> apw, hi, do you know if switching an ARM build (nexus 4) from sparsemem to flatmem model could introduce bugs ?
[08:50] <janimo> I am not sure whether there's just performance differences between the memory models or correctness can be affected
[08:51] <janimo> this is in the context of a cgroups bug that seems to be worked aorund if we chose the flatmem path
[09:21] <apw> janimo, it shouldn't make a difference in theory, but as always YMMV
[09:21] <apw> as in theory this is a single memory device, so in sparsemem is a 'flatmem' degenerate case, in theory
[09:24] <janimo> apw, thanks.
[09:25] <apw> janimo, then again i would be suspicious as to how flatmem could fix anything in cgroups by anything other than luck
[09:26] <janimo> apw, there are two separate codepaths for memcg (initialization at least) for these two configs
[09:26] <janimo> the sparsemem one skips initializing two of the five blocks of the nexus 4
[09:26] <janimo> so when there's an acces to any of them there's a fault
[09:26] <apw> so can we not just fix it
[09:27] <janimo> apw, I sent my findings to the3 cgroups ml and got no answer, and then to ubuntu-kernel
[09:27] <janimo> and a few minutes ago to arm-kernel
[09:27] <janimo> I am not sure I ahve a fix, or what it would look like
[09:27] <apw> this of course is the problem of basing ones security model on a feature in the kernel which is only just being finished in 3.10/11 and then using 3.1/4 kernels on your devices
[09:27] <apw> it is always going to hurt
[09:28] <janimo> the code looks the same in newer  kernels IIRC
[09:28] <janimo> option names got changed and other fixes done. But cannot be sure as there's no new kernel to test on the nexus 4
[09:28] <apw> nor will there ever be i am sure
[09:28] <janimo> and most other arm boards do not have such unusual phsyisical memory layout
[09:29] <apw> how unusual is it, as if it is very sparse there will be costs to switching in terms of size of th e cmap
[09:29] <janimo> apw, right that is the drawback I saw, maybe around 1M overhead
[09:29] <janimo> but that is not a correctness issue so expected
[09:29] <janimo> apw, there are 5 blocks IIRC
[09:30] <janimo> discontiguous I mean
[09:30] <janimo> apw, I keep hoping that once there;s a tegra multiARM kernel and tegra3 upstreamed, forward porting older android kernels may not be that hard
[09:30] <janimo> but I may be missing something big
[09:31] <apw> janimo, maybe but i don't see it happening for these throw away devies
[09:32] <janimo> apw, not officially from google, for sure
[09:34] <apw> the devices will be on the scrap heap before it is easy
[09:34] <apw> lets hope the next generation are on something less pants
[10:28] <apw> tseliot, yo ... we have a working 3.10 kernel so we can start dkms testing against it: https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+packages in the saucy pocket
[10:29] <tseliot> apw: excellent, I'll run some tests and fix what doesn't work
[10:40] <apw> tseliot, excellent thanks
[10:40] <apw> tseliot, wahts in there now is -rc3, there is a -rc4 in the queue to build as well
[10:41] <tseliot> apw: ah, even better
[10:41] <apw> though it looks to be FTBFS'ing ...arg
[10:46]  * apw respins ... bah
[11:44] <tseliot> apw: it FTBFS, at least on i386
[11:44] <tseliot> something wrong in the configuration perhaps?
[11:47] <tseliot> apw: shall I use this one instead? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc5-saucy/
[11:48] <apw> tseliot, ok i am all confused, there is -rc4 in the PPA already, and -rc5 is building
[11:50] <tseliot> apw: if I try to dist-upgrade it gets 3.9.0-4 instead of 3.10
[11:56] <apw> tseliot, right, ... there is no meta in there for it
[11:57] <apw> manual install for the moment
[12:59] <tseliot> apw: oh, right
[13:15]  * rtg_ reboots gomeisa
[13:26]  * rtg_ reboots tangerine
[13:45] <infinity> smb: Your linux-ec2 tracking bug might want some verification-testing love.
[13:46] <infinity> smb: (Which could be an opportune time to offer a trade in the form of bugging me about your sponsorship URL again, wherever that went)
[13:46] <smb> infinity, Hm yeah maybe though thats done by qa isn't it?
[13:46] <infinity> smb: No, v-testing is done by you / the kernel team.
[13:46] <infinity> smb: Not the same as regression testing.
[13:47] <infinity> smb: Basically just amounts to making sure everything on http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html has a checkmark next to it, making sure that checkmark is accurate for your flavour, and setting the task done.  Ish.
[13:47] <infinity> Well, rather, s/evetything has a checkmark/nothing has an exclamation point/
[13:47] <smb> Hm, I am a bit surprised by that, which means I never had that before, so let me check up on that.
[13:47] <infinity> Since tracking and security bugs are unique snowflakes.
[13:48] <smb> infinity, For the other thing I am just typing something on #ubuntu-devel... :-P
[13:48] <infinity> smb: Probably someone (like me) has just been setting your v-done tasks done in the past because ec2 was a straight debase and had no flavor-specific bugs listed.
[13:49] <infinity> smb: Oh, I guess it has none this time either, all those ones are for the master kernel.  They're just kinda ec2-related.
[13:49] <infinity> smb: So, there may be nothing to do there but twiddle the task anyway.
[13:50] <smb> infinity, Yeah, let me make sure. I think there was nothing specific and I may even have booted the thing on my systems
[13:50] <infinity> smb: There was nothing specific, I'm going to twiddle that task for you anyway.
[13:50] <infinity> smb: Which will then move on to regression-testing and such.
[13:51] <smb> infinity, Ah ok. Ta
[13:53] <rtg_> apw, smoke testing 3.10-rc5. have you gotten any feedback on dkms compatibility ?
[13:53] <infinity> smb: Right then.  Bug progressed.
[13:54] <apw> rtg_, i have uploaded the rebase and tseliot is on the case
[13:54] <apw> (to pre-proposed)
[13:54] <rtg_> apw, ok, will do a bit more HW testing. 
[13:54] <tseliot> right
[13:56] <apw> rtg_, oh and note i brown-paper-bagged the changelog for the updateconfigs entry ... sigh
[13:56] <apw> it really is -rc5
[13:59] <rtg_> apw, I assumed ...
[14:01]  * apw probabally should have stayed in bed
[14:04] <smb> apw, Isn't that a given on any Monday?
[14:04] <apw> you are very astute
[14:04] <rtg_> apw, thought I'd upload mako with CONFIG_BT_HCISMD=y while I sort out perf (which is proving to be a bit of a PITA)
[14:05] <apw> rtg_, yeah i recon that is reasonable
[14:10] <infinity> apw: We could take a vote to make it not Monday.
[14:11] <infinity> apw: Or maybe strike until Tuesday.
[14:12] <smb> infinity, In which case Tuesday became alternate Monday and we had to go on strike again... 
[14:13]  * smb likes that thought
[14:57] <xnox> apw: i fixed cryptsetup's initramfs hook here not to add itself into initramfs if there are no encrypted root or resume devices. But that only makes a different if one has MODULES=dep, because otherwise "a basic subset of modules" is added anyway which are quite large.
[14:58] <xnox> Why do we have "most" instead of "dep" by default?
[14:58] <xnox> the images I guess should be built with "most" but the installed systems could be using "dep"
[14:59] <xnox> infinity: am I missing something about reasoning to default to $MODULES=most in initramfs?
[15:00] <apw> xnox, yep and my quick look at the boot speed tests showed it was better again today
[15:01] <apw> though i have yet to see it appear in the official graphs which are days behind
[15:01] <infinity> xnox: Because 'dep' hasn't always been historically guaranteed to be correct, but 'most' works for pretty much everyone.
[15:01] <apw> xnox, the current reasoning is that the initramfs is 'disk independant' so we can move the disk from machine to machine and it will still work
[15:01]  * xnox also is waiting for the new bootcharts.
[15:01] <infinity> xnox: Oh, and what Andy said, 'most' makes initrds portable between machines.
[15:02] <apw> now pitti and i had some discussions about what we do put on there, i think we could justify ripping out a goodly chunk more of the stuff in there, and still be disk portable
[15:02] <infinity> xnox: I'm not sure what you mean by "that only makes a difference if..." though.  Surely, not adding cryptsetup also avoids adding plymouth, and solves the general complaint?
[15:03] <infinity> (Though, I've been arguing for a while that we should just have plymouth by default in the inirtd, if only we could speed it up a tad)
[15:03] <infinity> Having two very different boot paths for plymouth is hard to debug.
[15:03] <xnox> actually it looks like plymouth is in by default =/
[15:03] <xnox> as I don't have cryptsetup in my current initramfs, yet plymouth is still there.
[15:04] <infinity> That should only be true if you have a FRAMEBUFFER=y setup.
[15:04] <infinity> Unless something changed again recently...
[15:04] <xnox> infinity: hm. ok let me check.
[15:07] <xnox> apw: the question is should we include "cryptsetup" in the definition of portable between machines initramfs. Cause at the moment - installing a cryptsetup package and not using any encrypted filesystems results in most crypto modules in the initramfs, yet those are actually only required to boot encrypted root fs.
[15:07] <xnox> imho - encrypted machines are "speciality" rather than "common/portable"
[15:08] <apw> xnox, the disk is either encrypted or it is not
[15:09] <apw> xnox, if _that_ disk is ecrypted (root disk) then the initrd for it needs to include them to be portable, if it is not then it does not
[15:09] <apw> xnox, we are not trying to make it 'dd from one disk to another' portable i don't think
[15:11] <xnox> apw: I agree. In that case, I'd like to propose to not include cryptsetup & modules in the initramfs if root disk is not encrypted. Regardless of MODULES=dep/most. For the case of "I want to generate initramfs on this machine, to transfer/boot that one" i'll add an option to include cryptsetup things unconditionally.
[15:11] <apw> xnox, yes please
[16:27]  * apw prepares to reboot to save his fans
[16:38] <infinity> apw: 1188647?
[16:39] <apw> bug #1188647
[16:39] <ubot2`> Launchpad bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,In progress] https://launchpad.net/bugs/1188647
[16:39] <infinity> apw: As in, is that why you're rebooting to save your fans?
[16:39] <infinity> (cause my fans were on 24/7 before I twiddled that)
[16:39] <apw> heh no i have a much crappier machine than that, did i give you your test kernel
[16:39] <infinity> apw: Nope, you gave me no test kernel.
[16:40]  * cking reboots
[16:40] <apw> infinity, this should just have the enable off by default and an =enable to turn it back on: http://people.canonical.com/~apw/lp1188647-saucy/
[16:40] <apw> infinity, if you could test that and let me know
[16:41] <infinity> apw: Can do.  Want me to test both conditions to make sure it does what it says on the tin?
[16:42] <apw> infinity, would be helpful indeed if you could
[16:43] <infinity> apw: Alrighty.  I'll follow up to the bug in a bit.
[16:44] <apw> ta
[17:14] <infinity> apw: Updated.
[17:14] <infinity> apw: TL;DR: It's all good.
[17:41]  * rtg_ -> lunch
[17:44]  * xnox looks at bootcharts and it returned back to normal on 20130606.1, yet the fix was uploaded on 20130607 ........
[17:46] <SonikkuAmerica> I assume linux-3.9 is on its way soon?
[17:46] <SonikkuAmerica> (For Raring)
[17:51] <infinity> SonikkuAmerica: No, raring is 3.8
[17:52] <infinity> SonikkuAmerica: We don't do new upstream versions in stable releases.
[17:53] <SonikkuAmerica> infinity: Oh. That stinks, 'cuz they just announced 3.8 is EOL. I guess we won't need it for that long anyway, given it's only supported till January
[17:53] <infinity> SonikkuAmerica: We're supporting 3.8 until raring goes EOL.
[17:54] <SonikkuAmerica> infinity: Ah. Now that's a good idea. :) Thanks!
[17:55] <bjf> SonikkuAmerica, we are supporting the raring kernel until 14.04.01 (which is around Aug. of 2014)
[17:55] <SonikkuAmerica> bjf: Ummm... you mentioned a date in April. :)
[17:56] <SonikkuAmerica> bjf: August 2014 is 14.08
[17:56] <infinity> SonikkuAmerica: He means the 14.04.1 point release, which will be after 14.10 releases.
[17:56] <bjf> SonikkuAmerica, 14.04 is april, 14.04.1 is Aug.
[17:56] <SonikkuAmerica> infinity: OK. Makes even more sense.
[17:57] <infinity> (Not that we'll be supporting raring itself that long, so this doesn't really matter for you)
[17:57] <infinity> It just matters if you're using our upstream tree, or precise with the lts-raring kernel.
[17:58] <infinity> bjf: Wait, why would we be supporting lts-raring until .04.1?
[17:58] <SonikkuAmerica> (I interpreted that as a date 2014.04.01... :P) Right. By that time I'll be well into 14.04
[17:58] <infinity> bjf: Surely, it's lts-saucy we need to support until then.
[17:59] <SonikkuAmerica> Well I gotta go, thx for the info! Bye!
[18:00] <bjf> infinity, we support all precise lts-hwe kernels until the first point release of 14.04
[18:00] <infinity> bjf: Oh, that's going to be... Fun.
[18:01] <bjf> infinity, why, it's just a few months difference
[18:01] <infinity> bjf: But it's no longer a backport once the parent releases go EOL.  I guess that's not a big deal.
[18:02] <bjf> infinity, it comes out of the same git repo
[18:02] <infinity> Yeah.
[18:02] <bjf> infinity, you just won't accept new uploads to raring
[18:03] <infinity> We lose some of the benefit of moving to a 9-month support cycle if you have to support all the interim kernels until LTS+1.1 anyway.
[18:03] <bjf> this really only affects the kernel and possibly x stack
[18:06] <infinity> Yeah.  I just wish we'd gone with a "stable series" and "hwe series" instead of "hwe series x 3 (or 4?)"
[18:06] <infinity> It spreads things a bit thin as far as end-user configurations and troubleshooting sanity.
[18:07] <infinity> Will we bit doing an lts-t kernel for P, so people who installed with, say, lts-r because 3.2 didn't support their hardware aren't suddenly left unsupported in their supposedly 5-year LTS?
[18:07] <infinity> s/we bit/we be/
[18:07] <bjf> infinity, yes
[18:07] <infinity> Kay, at least that bit makes sense.
[20:23] <rtg_> infinity, still about ? Can you tell me what happened here ? https://launchpad.net/ubuntu/+source/linux-maguro/3.0.0-2.3/+build/4659648
[20:24] <infinity> rtg_: Pandas suck.
[20:25] <rtg_> infinity, can I restart, or increment version and reupload ?
[20:25] <infinity> rtg_: Retrying the build.
[20:31]  * rtg_ -> EOD