| === 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 | ||
| 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:50 |
| janimo | this is in the context of a cgroups bug that seems to be worked aorund if we chose the flatmem path | 08:51 |
| === fmasi is now known as fmasi_afk | ||
| === bipul is now known as Kevin-Mitinik | ||
| === Kevin-Mitinik is now known as bipul | ||
| 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:21 |
| === fmasi_afk is now known as fmasi | ||
| janimo | apw, thanks. | 09:24 |
| apw | janimo, then again i would be suspicious as to how flatmem could fix anything in cgroups by anything other than luck | 09:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| apw | janimo, maybe but i don't see it happening for these throw away devies | 09:31 |
| janimo | apw, not officially from google, for sure | 09:32 |
| 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 | 09:34 |
| 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:28 |
| tseliot | apw: excellent, I'll run some tests and fix what doesn't work | 10:29 |
| 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:40 |
| tseliot | apw: ah, even better | 10:41 |
| apw | though it looks to be FTBFS'ing ...arg | 10:41 |
| * apw respins ... bah | 10:46 | |
| tseliot | apw: it FTBFS, at least on i386 | 11:44 |
| tseliot | something wrong in the configuration perhaps? | 11:44 |
| tseliot | apw: shall I use this one instead? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc5-saucy/ | 11:47 |
| apw | tseliot, ok i am all confused, there is -rc4 in the PPA already, and -rc5 is building | 11:48 |
| tseliot | apw: if I try to dist-upgrade it gets 3.9.0-4 instead of 3.10 | 11:50 |
| apw | tseliot, right, ... there is no meta in there for it | 11:56 |
| apw | manual install for the moment | 11:57 |
| tseliot | apw: oh, right | 12:59 |
| === pgraner` is now known as pgraner | ||
| * rtg_ reboots gomeisa | 13:15 | |
| * rtg_ reboots tangerine | 13:26 | |
| infinity | smb: Your linux-ec2 tracking bug might want some verification-testing love. | 13:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| smb | infinity, Ah ok. Ta | 13:51 |
| rtg_ | apw, smoke testing 3.10-rc5. have you gotten any feedback on dkms compatibility ? | 13:53 |
| infinity | smb: Right then. Bug progressed. | 13:53 |
| 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:54 |
| apw | rtg_, oh and note i brown-paper-bagged the changelog for the updateconfigs entry ... sigh | 13:56 |
| apw | it really is -rc5 | 13:56 |
| rtg_ | apw, I assumed ... | 13:59 |
| * apw probabally should have stayed in bed | 14:01 | |
| 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:04 |
| apw | rtg_, yeah i recon that is reasonable | 14:05 |
| infinity | apw: We could take a vote to make it not Monday. | 14:10 |
| infinity | apw: Or maybe strike until Tuesday. | 14:11 |
| smb | infinity, In which case Tuesday became alternate Monday and we had to go on strike again... | 14:12 |
| * smb likes that thought | 14:13 | |
| === bdmurray_ is now known as bdmurray | ||
| 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:57 |
| 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:58 |
| xnox | infinity: am I missing something about reasoning to default to $MODULES=most in initramfs? | 14:59 |
| apw | xnox, yep and my quick look at the boot speed tests showed it was better again today | 15:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:07 |
| apw | xnox, the disk is either encrypted or it is not | 15:08 |
| 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:09 |
| 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 | 15:11 |
| * apw prepares to reboot to save his fans | 16:27 | |
| infinity | apw: 1188647? | 16:38 |
| 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:39 |
| * 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:40 |
| infinity | apw: Can do. Want me to test both conditions to make sure it does what it says on the tin? | 16:41 |
| apw | infinity, would be helpful indeed if you could | 16:42 |
| infinity | apw: Alrighty. I'll follow up to the bug in a bit. | 16:43 |
| apw | ta | 16:44 |
| infinity | apw: Updated. | 17:14 |
| infinity | apw: TL;DR: It's all good. | 17:14 |
| * rtg_ -> lunch | 17:41 | |
| * xnox looks at bootcharts and it returned back to normal on 20130606.1, yet the fix was uploaded on 20130607 ........ | 17:44 | |
| SonikkuAmerica | I assume linux-3.9 is on its way soon? | 17:46 |
| SonikkuAmerica | (For Raring) | 17:46 |
| === yofel_ is now known as yofel | ||
| infinity | SonikkuAmerica: No, raring is 3.8 | 17:51 |
| infinity | SonikkuAmerica: We don't do new upstream versions in stable releases. | 17:52 |
| 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:53 |
| SonikkuAmerica | infinity: Ah. Now that's a good idea. :) Thanks! | 17:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| SonikkuAmerica | Well I gotta go, thx for the info! Bye! | 17:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:06 |
| === lifeless_ is now known as lifeless | ||
| 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. | 18:07 |
| === fmasi is now known as fmasi_afk | ||
| === davmor2_ is now known as davmor2 | ||
| === jpds is now known as Guest72281 | ||
| 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:23 |
| infinity | rtg_: Pandas suck. | 20:24 |
| rtg_ | infinity, can I restart, or increment version and reupload ? | 20:25 |
| infinity | rtg_: Retrying the build. | 20:25 |
| * rtg_ -> EOD | 20:31 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!