=== smb` is now known as smb === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [08:50] apw, hi, do you know if switching an ARM build (nexus 4) from sparsemem to flatmem model could introduce bugs ? [08:50] I am not sure whether there's just performance differences between the memory models or correctness can be affected [08:51] this is in the context of a cgroups bug that seems to be worked aorund if we chose the flatmem path === fmasi is now known as fmasi_afk === bipul is now known as Kevin-Mitinik === Kevin-Mitinik is now known as bipul [09:21] janimo, it shouldn't make a difference in theory, but as always YMMV [09:21] as in theory this is a single memory device, so in sparsemem is a 'flatmem' degenerate case, in theory === fmasi_afk is now known as fmasi [09:24] apw, thanks. [09:25] janimo, then again i would be suspicious as to how flatmem could fix anything in cgroups by anything other than luck [09:26] apw, there are two separate codepaths for memcg (initialization at least) for these two configs [09:26] the sparsemem one skips initializing two of the five blocks of the nexus 4 [09:26] so when there's an acces to any of them there's a fault [09:26] so can we not just fix it [09:27] apw, I sent my findings to the3 cgroups ml and got no answer, and then to ubuntu-kernel [09:27] and a few minutes ago to arm-kernel [09:27] I am not sure I ahve a fix, or what it would look like [09:27] 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] it is always going to hurt [09:28] the code looks the same in newer kernels IIRC [09:28] 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] nor will there ever be i am sure [09:28] and most other arm boards do not have such unusual phsyisical memory layout [09:29] 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] apw, right that is the drawback I saw, maybe around 1M overhead [09:29] but that is not a correctness issue so expected [09:29] apw, there are 5 blocks IIRC [09:30] discontiguous I mean [09:30] 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] but I may be missing something big [09:31] janimo, maybe but i don't see it happening for these throw away devies [09:32] apw, not officially from google, for sure [09:34] the devices will be on the scrap heap before it is easy [09:34] lets hope the next generation are on something less pants [10:28] 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] apw: excellent, I'll run some tests and fix what doesn't work [10:40] tseliot, excellent thanks [10:40] tseliot, wahts in there now is -rc3, there is a -rc4 in the queue to build as well [10:41] apw: ah, even better [10:41] though it looks to be FTBFS'ing ...arg [10:46] * apw respins ... bah [11:44] apw: it FTBFS, at least on i386 [11:44] something wrong in the configuration perhaps? [11:47] apw: shall I use this one instead? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc5-saucy/ [11:48] tseliot, ok i am all confused, there is -rc4 in the PPA already, and -rc5 is building [11:50] apw: if I try to dist-upgrade it gets 3.9.0-4 instead of 3.10 [11:56] tseliot, right, ... there is no meta in there for it [11:57] manual install for the moment [12:59] apw: oh, right === pgraner` is now known as pgraner [13:15] * rtg_ reboots gomeisa [13:26] * rtg_ reboots tangerine [13:45] smb: Your linux-ec2 tracking bug might want some verification-testing love. [13:46] 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] infinity, Hm yeah maybe though thats done by qa isn't it? [13:46] smb: No, v-testing is done by you / the kernel team. [13:46] smb: Not the same as regression testing. [13:47] 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] Well, rather, s/evetything has a checkmark/nothing has an exclamation point/ [13:47] Hm, I am a bit surprised by that, which means I never had that before, so let me check up on that. [13:47] Since tracking and security bugs are unique snowflakes. [13:48] infinity, For the other thing I am just typing something on #ubuntu-devel... :-P [13:48] 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] 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] smb: So, there may be nothing to do there but twiddle the task anyway. [13:50] 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] smb: There was nothing specific, I'm going to twiddle that task for you anyway. [13:50] smb: Which will then move on to regression-testing and such. [13:51] infinity, Ah ok. Ta [13:53] apw, smoke testing 3.10-rc5. have you gotten any feedback on dkms compatibility ? [13:53] smb: Right then. Bug progressed. [13:54] rtg_, i have uploaded the rebase and tseliot is on the case [13:54] (to pre-proposed) [13:54] apw, ok, will do a bit more HW testing. [13:54] right [13:56] rtg_, oh and note i brown-paper-bagged the changelog for the updateconfigs entry ... sigh [13:56] it really is -rc5 [13:59] apw, I assumed ... [14:01] * apw probabally should have stayed in bed [14:04] apw, Isn't that a given on any Monday? [14:04] you are very astute [14:04] 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] rtg_, yeah i recon that is reasonable [14:10] apw: We could take a vote to make it not Monday. [14:11] apw: Or maybe strike until Tuesday. [14:12] infinity, In which case Tuesday became alternate Monday and we had to go on strike again... [14:13] * smb likes that thought === bdmurray_ is now known as bdmurray [14:57] 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] Why do we have "most" instead of "dep" by default? [14:58] the images I guess should be built with "most" but the installed systems could be using "dep" [14:59] infinity: am I missing something about reasoning to default to $MODULES=most in initramfs? [15:00] xnox, yep and my quick look at the boot speed tests showed it was better again today [15:01] though i have yet to see it appear in the official graphs which are days behind [15:01] xnox: Because 'dep' hasn't always been historically guaranteed to be correct, but 'most' works for pretty much everyone. [15:01] 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] xnox: Oh, and what Andy said, 'most' makes initrds portable between machines. [15:02] 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] 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] (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] Having two very different boot paths for plymouth is hard to debug. [15:03] actually it looks like plymouth is in by default =/ [15:03] as I don't have cryptsetup in my current initramfs, yet plymouth is still there. [15:04] That should only be true if you have a FRAMEBUFFER=y setup. [15:04] Unless something changed again recently... [15:04] infinity: hm. ok let me check. [15:07] 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] imho - encrypted machines are "speciality" rather than "common/portable" [15:08] xnox, the disk is either encrypted or it is not [15:09] 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] xnox, we are not trying to make it 'dd from one disk to another' portable i don't think [15:11] 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] xnox, yes please [16:27] * apw prepares to reboot to save his fans [16:38] apw: 1188647? [16:39] bug #1188647 [16:39] Launchpad bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,In progress] https://launchpad.net/bugs/1188647 [16:39] apw: As in, is that why you're rebooting to save your fans? [16:39] (cause my fans were on 24/7 before I twiddled that) [16:39] heh no i have a much crappier machine than that, did i give you your test kernel [16:39] apw: Nope, you gave me no test kernel. [16:40] * cking reboots [16:40] 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] infinity, if you could test that and let me know [16:41] apw: Can do. Want me to test both conditions to make sure it does what it says on the tin? [16:42] infinity, would be helpful indeed if you could [16:43] apw: Alrighty. I'll follow up to the bug in a bit. [16:44] ta [17:14] apw: Updated. [17:14] 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] I assume linux-3.9 is on its way soon? [17:46] (For Raring) === yofel_ is now known as yofel [17:51] SonikkuAmerica: No, raring is 3.8 [17:52] SonikkuAmerica: We don't do new upstream versions in stable releases. [17:53] 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] SonikkuAmerica: We're supporting 3.8 until raring goes EOL. [17:54] infinity: Ah. Now that's a good idea. :) Thanks! [17:55] SonikkuAmerica, we are supporting the raring kernel until 14.04.01 (which is around Aug. of 2014) [17:55] bjf: Ummm... you mentioned a date in April. :) [17:56] bjf: August 2014 is 14.08 [17:56] SonikkuAmerica: He means the 14.04.1 point release, which will be after 14.10 releases. [17:56] SonikkuAmerica, 14.04 is april, 14.04.1 is Aug. [17:56] infinity: OK. Makes even more sense. [17:57] (Not that we'll be supporting raring itself that long, so this doesn't really matter for you) [17:57] It just matters if you're using our upstream tree, or precise with the lts-raring kernel. [17:58] bjf: Wait, why would we be supporting lts-raring until .04.1? [17:58] (I interpreted that as a date 2014.04.01... :P) Right. By that time I'll be well into 14.04 [17:58] bjf: Surely, it's lts-saucy we need to support until then. [17:59] Well I gotta go, thx for the info! Bye! [18:00] infinity, we support all precise lts-hwe kernels until the first point release of 14.04 [18:00] bjf: Oh, that's going to be... Fun. [18:01] infinity, why, it's just a few months difference [18:01] bjf: But it's no longer a backport once the parent releases go EOL. I guess that's not a big deal. [18:02] infinity, it comes out of the same git repo [18:02] Yeah. [18:02] infinity, you just won't accept new uploads to raring [18:03] 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] this really only affects the kernel and possibly x stack [18:06] Yeah. I just wish we'd gone with a "stable series" and "hwe series" instead of "hwe series x 3 (or 4?)" [18:06] It spreads things a bit thin as far as end-user configurations and troubleshooting sanity. === lifeless_ is now known as lifeless [18:07] 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] s/we bit/we be/ [18:07] infinity, yes [18:07] Kay, at least that bit makes sense. === fmasi is now known as fmasi_afk === davmor2_ is now known as davmor2 === jpds is now known as Guest72281 [20:23] 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] rtg_: Pandas suck. [20:25] infinity, can I restart, or increment version and reupload ? [20:25] rtg_: Retrying the build. [20:31] * rtg_ -> EOD