=== emma is now known as em | ||
bizhanMona | hi | 03:23 |
---|---|---|
bizhanMona | Hi how could I force Linux to re-enumerate the PCIe bus? thx | 03:24 |
the_voice_ | Hi | 04:59 |
the_voice_ | I followed the tutorial here on how to update the Ubuntu http://wiki.freeswitch.org/wiki/Amazon_EC2 here | 04:59 |
the_voice_ | however when I go /boot/ | 05:00 |
the_voice_ | I don't see a newer version of vmlinuz-* | 05:00 |
=== smb` is now known as smb | ||
* apw yawns heavily | 09:00 | |
=== henrix_ is now known as henrix | ||
=== edu-afk is now known as edamato | ||
=== henrix is now known as henrix_ | ||
rainman | how do most recent linux kernels alternate the frequencies of processor and/or cores in order to save power? do they do it on the core level or the processor level? anybody has an idea? | 11:25 |
amitk | rainman: it depends on the processor (HW). The software can do either. It really depends on whether the cores can be scaled independently or not. | 11:27 |
rainman | amitk: let's say the processor allows scaling on the core level, so OSPM(operating system power management) code does individually scale cores? | 11:28 |
amitk | rainman: yes | 11:29 |
amitk | rainman: look at affected_cpus and related_cpus in the cpufreq framework code | 11:30 |
rainman | amitk: I am on it, thank you very much for the lead | 11:30 |
rainman | amitk: do you have experience on ACPI and power management by the way? | 11:31 |
amitk | x86 hides a lot of this behind acpi bios calls, ARM deals with the details in kernel code | 11:31 |
rainman | wow that's a good point | 11:31 |
amitk | rainman: a bit.. | 11:31 |
rainman | so that means arm gives a lot of playability since it does the stuff in kernel code | 11:31 |
amitk | rainman: but current ARM-based SoCs can only do processor-level scaling (architecture limitation). I think Qualcomm, Marvell and Nvidia can do core level since they only have to be compatible and can play around with the arch | 11:33 |
rainman | amitk: can I humbly request a contact detail of you to ask lots of questions if you do not mind of course, I am doing a research in optimizing power on multi-core systems. | 11:42 |
herton | apw, do you know if am I safe cloning from linux repo on zinc under ubuntu/, for the 3.5 stable stuff? I just don't want to use it if it can be modified or be gone etc. in the future | 12:27 |
rtg | herton, I periodically update it, and have no plans to remove. it could be used as a ''reference for some repos | 12:30 |
apw | herton, thats the repo with the u* tags in it right? if so then that is a slowly following linus branch and will never rewind; ie. it is safe to reference | 12:30 |
rtg | --reference (I mean) | 12:30 |
* smb would believe that if that is gone then zinc is gone | 12:30 | |
herton | rtg, ack, yes I want to use it as reference, instead of cloning everything from master linus, will do thanks | 12:30 |
herton | apw ^ | 12:30 |
apw | yep | 12:31 |
rtg | herton, have you thought about making 3.5 stable just a branch in ubuntu-quantal ? | 12:32 |
rtg | instead of creating yet another repository ? | 12:33 |
herton | rtg, I could do, but then it ties more to our kernel may be, I think just using a master linus branch and putting 3.5 in a branch would be better, don't know | 12:34 |
rtg | herton, then just create a 3.5.y branch in the linux repo | 12:34 |
herton | yes, that's my plan | 12:34 |
herton | rtg, ah, you mean directly in the linux repo, instead of cloning another? I could do that as well | 12:35 |
rtg | herton, yes | 12:35 |
smb | herton, The only reason I could see for a seperate tree would be people often getting confused by branches... | 12:37 |
smb | But then, they changed to that in upstream, too. Just with one linux-stable... | 12:37 |
herton | smb, yes, I think using existing linux is fine. But if we plan to maintain other versions in the future, may be we should have also a linux-stable separated | 12:38 |
herton | rtg, ok, so I'll create 3 branches there, 1 for the main 3.5, one for the -queue (I don't want to have a separate repo for the queue), and one for review (to announce review of the patches, alternative to who doesn't want to download the patches for review from the mailing list) | 12:39 |
rtg | herton, s'fine with me | 12:40 |
rtg | apw, it took me all freaking day yesterday to get armel to build properly, then slangasek announces armel is dead. | 12:46 |
apw | rtg, man you kid me ... really | 13:01 |
apw | so we are dopping armel in R ? | 13:01 |
apw | herton, sounds better than what we have for the others | 13:02 |
rtg | apw, https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html | 13:03 |
apw | well i guess thats good ... | 13:04 |
rtg | apw, I finally have an armhf system built up 'cause the qemu-armhf gizmo on tangerine just kept faulting | 13:06 |
apw | yeah it does that ... pos | 13:06 |
apw | rtg, are we expecting powerpc uploads from BenC soon do you know ? dropping them has put us in all sorts of britany pain | 13:11 |
BenC | apw: I'll be uploading today or today | 13:12 |
apw | BenC, great | 13:12 |
BenC | *tonight | 13:14 |
rtg | apw, why is britany complaining ? that kind of ties powerpc to the distro kernel build. wtf ? | 13:14 |
apw | rtg, it is complaining because our src stops making them, so migrating our package would leave us with no ppc builds at all | 13:14 |
apw | so it gets all whiney. i believe once bens package is in, they will migrate as a pair this time | 13:15 |
apw | and once thats done they will be unlinked from each other | 13:15 |
* rtg grumbles | 13:15 | |
apw | rtg, britany has a point, you are orphaning whole swathes of the archive | 13:16 |
apw | it doesn't know ben is sorting that out, till he uploads | 13:16 |
rtg | apw, we've still got a periodic parallel build failure that I'm gonna go after today. Its bitten me several times in the last couple of days. | 13:16 |
apw | rtg, arse, those are a royal pain, in what bit ? | 13:17 |
apw | (if you know) | 13:17 |
rtg | apw, thats the hard part. | 13:17 |
apw | rtg, fyi i am working on raring-meta, we have some other deps issues due to the temp disablement of the linux-tools on arm | 13:18 |
apw | which is also stopping migration | 13:18 |
* henrix -> lunch | 13:18 | |
rtg | britany doesn't seem very flexible | 13:18 |
apw | rtg, her job is to stop you breaking the archive. by dropping linux-tools a couple of package exploded | 13:22 |
apw | she knows what she is doing | 13:22 |
rtg | apw, if I figure out the armhf tools build problem, can we just ignore armel ? (though they are likely the same). | 13:25 |
apw | rtg, ahh while i remember, we are missing a couple of tags for ubuntu-raring (the last two uploads) and one of the meta ones too | 13:25 |
rtg | apw, I just fixed the Ubuntu-3.7.0-0.5 tag | 13:25 |
apw | rtg, probabally, i'll find out when armel is getting zapped | 13:25 |
apw | rtg, i think we are also missing .4 | 13:26 |
rtg | apw, I never uploaded the others so I didn't bother tagging. those commits are also linear and easy to reproduce | 13:26 |
apw | though i suspect it is linear from .5 | 13:26 |
apw | ack | 13:26 |
* rtg will bbiab | 13:27 | |
rtg | cking, are you OK with me bouncing gomeisa ? | 14:04 |
rtg | I'm trying to remove a chroot and can't get all of the mount point released. damn schroot anyways. | 14:05 |
cking | yep | 14:05 |
rtg | cking, done | 14:06 |
BenC | apw: When I get a chance I'll write up a test case for you | 15:16 |
BenC | Gotta get this package out the door first... | 15:16 |
apw | BenC, if you can just show me the form i can debug it, as all the forms i'd expect you to have used test right and have tests already | 15:21 |
BenC | apw: Use the old enforce (before my commit) against my set of powerpc configs (with e500 and e500mc) | 15:22 |
BenC | That NVRAM check fails on e500 and e500mc, but it shouldn't | 15:23 |
apw | BenC, ta | 15:23 |
BenC | And the ADT check before it succeeds even though the check is the exact same syntax against the exact same flavours and the exact same value in the configs | 15:23 |
apw | (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \ | 15:24 |
apw | value CONFIG_NVRAM m | \ | 15:24 |
apw | !exists CONFIG_NVRAM | 15:24 |
ubot2 | apw: I am only a bot, please don't think I'm intelligent :) | 15:24 |
apw | BenC, like that ... but you have it =y on powerpc-e500 and powerpc-e500mc and thats not valid under that form | 15:25 |
apw | so it correctly fails on those two | 15:25 |
apw | BenC, or perhaps not ... /me pokes | 15:26 |
apw | BenC, no i am right | 15:28 |
apw | CONFIGS/powerpc-config.flavour.powerpc-e500:CONFIG_NVRAM=y | 15:28 |
apw | CONFIGS/powerpc-config.flavour.powerpc-e500mc:CONFIG_NVRAM=y | 15:28 |
apw | CONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_NVRAM=y | 15:28 |
apw | those three have NVRAM set, so for the rule to be right it has to expect Y for those three | 15:28 |
apw | (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \ | 15:29 |
apw | and that only allows it to be powerpc and powerpc-smp, so they will fail | 15:29 |
apw | (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \ | 15:30 |
apw | damn that paste | 15:30 |
BenC | apw: I tried add "| value CONFIG_NVRAM y" and it still failed | 15:33 |
apw | BenC, will try that even though it doesn't represent what you want | 15:35 |
BenC | apw: I don't want to force NVRAM=y on e500/e500mc | 15:36 |
BenC | It's fine if it's one, don't care otherwise | 15:36 |
BenC | *on | 15:36 |
BenC | apw: What I want is for it to be forced on powepc-smp, and not care for anything else | 15:37 |
BenC | But the error only arose when it listed power and powerpc-smp as flavours, and the exact same situation existed for the ADT rule and it worked as expected | 15:38 |
BenC | powerpc | 15:38 |
BenC | So if the NVRAM rule works as expected, then the ADT rule isn't :) | 15:39 |
apw | BenC, nope, cause that _is_ only Y on powerpc-smp, and that rules says Y for that and _must_not_exist_ on all the others | 15:39 |
apw | so the rule matches reality, not necessarily what you care about | 15:39 |
BenC | it exists on e500/e500mc right? | 15:39 |
apw | nope | 15:39 |
apw | apw@dm:~/git2/ubuntu-raring$ grep CONFIG_THERM_ADT746X CONFIGS/* | 15:40 |
apw | CONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_THERM_ADT746X=y | 15:40 |
BenC | Hmm…then I wasn't paying close enough attention | 15:40 |
apw | (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \ | 15:41 |
apw | (flavour powerpc-e500 powerpc-e500mc) | \ | 15:41 |
apw | value CONFIG_NVRAM m | \ | 15:41 |
apw | !exists CONFIG_NVRAM | 15:41 |
ubot2 | apw: I am only a bot, please don't think I'm intelligent :) | 15:41 |
apw | so i think that encodes what you are saying | 15:41 |
BenC | so the second line just basically ignores e500/e500mc? | 15:41 |
apw | yeah it says this rule is "happy" if we are on one of those flavours, without checking anything related to the option | 15:42 |
apw | its just a logical or | 15:42 |
apw | i'll test that on master, and if it works splat it in | 15:42 |
BenC | Ok, thanks | 15:43 |
BenC | apw: I suggest you comment out the debug in the loop for possibles for the flavour predicate though…in my testing, it only showed the first flavour | 15:43 |
BenC | Hence my concern about multiple flavours | 15:43 |
apw | BenC, the commented out debug is just plain wrong, i prints $a[1] each time, instread of $possible | 15:45 |
apw | but its commented out indeed | 15:45 |
BenC | err, meant uncomment so you see what it is | 15:45 |
BenC | I didn't see it only prints the [1] in the array | 15:46 |
BenC | That alleviates some of my concern then :) | 15:46 |
apw | yeah i clearly fixed the debug in the arch one, and not the flavours one | 15:46 |
apw | must have not had to debug flavours recently | 15:46 |
apw | BenC, ok i've fixed the debugging for next time | 15:56 |
BenC | Gracias | 15:56 |
=== brendand_ is now known as brendand | ||
* rtg takes a break to shovel some of the 16" of snow received overnight while the armhf build slowly crawls along | 16:59 | |
=== rtg is now known as rtg-afk | ||
* smb -> EOW | 17:24 | |
=== rtg-afk is now known as rtg | ||
* henrix -> EOD | 17:59 | |
slangasek | rtg: urk, you were losing time fighting with armel? Well, on the bright side... you don't have to do that again :P | 18:22 |
rtg | slangasek, urk, indeed :0 | 18:23 |
rtg | :) | 18:23 |
rtg | slangasek, the next kernel upload won't contain _any_ armel support. Is brittany gonna be able to deal with that ? | 18:25 |
slangasek | yep | 18:25 |
rtg | slangasek, I understand moving powerpc support kind of made it complain | 18:26 |
slangasek | well, once removed we have to make sure we clean up behind it and aren't leaving uninstallable packages in the archive | 18:27 |
slangasek | but that's what britney's supposed to do | 18:27 |
rtg | hopefully BenC's upload will get everything sorted | 18:27 |
BenC | I'm in the final stages of proofing the packages | 18:28 |
=== rsalveti_ is now known as rsalveti | ||
* apw calls it a day | 18:42 | |
=== edamato is now known as edamato-afk | ||
=== yofel_ is now known as yofel | ||
BenC | infinity: Will I need to do a MIR for linux-ppc? | 19:41 |
infinity | BenC: No, it's just a source split producing things that were already in main. | 19:43 |
BenC | infinity: Ok, upload is in progress…can I pester you for processing when it's done? | 19:43 |
infinity | BenC: If you've already added your bits to it, it might need a quick audit to make sure your patches are all license-compliant as part of the NEW process, but here's hoping you've been doing that sanely, with an eye to upstreaming. :P | 19:44 |
infinity | BenC: I'm ubufluish, and considering wandering back to bed, but poke me and I'll get to it this weekend with a community hat on. | 19:45 |
BenC | infinity: There's some patches from Freescale, but they are all available from Freescale's public linux.git and are in the process of upstreaming | 19:45 |
* rtg -> EOD | 19:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!