/srv/irclogs.ubuntu.com/2012/11/09/#ubuntu-kernel.txt

=== emma is now known as em
bizhanMonahi03:23
bizhanMonaHi how could I force Linux to re-enumerate the PCIe bus? thx03:24
the_voice_Hi04:59
the_voice_I followed the tutorial here on how to update the Ubuntu http://wiki.freeswitch.org/wiki/Amazon_EC2 here04: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 heavily09:00
=== henrix_ is now known as henrix
=== edu-afk is now known as edamato
=== henrix is now known as henrix_
rainmanhow 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
amitkrainman: 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
rainmanamitk: let's say the processor allows scaling on the core level, so OSPM(operating system power management) code does individually scale cores?11:28
amitkrainman: yes11:29
amitkrainman: look at affected_cpus and related_cpus in the cpufreq framework code11:30
rainmanamitk: I am on it, thank you very much for the lead11:30
rainmanamitk: do you have experience on ACPI and power management by the way?11:31
amitkx86 hides a lot of this behind acpi bios calls, ARM deals with the details in kernel code11:31
rainmanwow that's a good point11:31
amitkrainman: a bit..11:31
rainmanso that means arm gives a lot of playability since it does the stuff in kernel code11:31
amitkrainman: 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 arch11:33
rainmanamitk: 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
hertonapw, 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 future12:27
rtgherton, I periodically update it, and have no plans to remove. it could be used as a ''reference for some repos12:30
apwherton, 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 reference12:30
rtg--reference (I mean)12:30
* smb would believe that if that is gone then zinc is gone12:30
hertonrtg, ack, yes I want to use it as reference, instead of cloning everything from master linus, will do thanks12:30
hertonapw ^12:30
apwyep12:31
rtgherton, have you thought about making 3.5 stable just a branch in ubuntu-quantal ?12:32
rtginstead of creating yet another repository ?12:33
hertonrtg, 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 know12:34
rtgherton, then just create a 3.5.y branch in the linux repo12:34
hertonyes, that's my plan12:34
hertonrtg, ah, you mean directly in the linux repo, instead of cloning another? I could do that as well12:35
rtgherton, yes12:35
smbherton, The only reason I could see for a seperate tree would be people often getting confused by branches...12:37
smbBut then, they changed to that in upstream, too. Just with one linux-stable...12:37
hertonsmb, 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 separated12:38
hertonrtg, 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
rtgherton, s'fine with me12:40
rtgapw, it took me all freaking day yesterday to get armel to build properly, then slangasek announces armel is dead.12:46
apwrtg, man you kid me ... really13:01
apwso we are dopping armel in R ?13:01
apwherton, sounds better than what we have for the others13:02
rtgapw, https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html13:03
apwwell i guess thats good ...13:04
rtgapw, I finally have an armhf system built up 'cause the qemu-armhf gizmo on tangerine just kept faulting13:06
apwyeah it does that ... pos13:06
apwrtg, are we expecting powerpc uploads from BenC soon do you know ?  dropping them has put us in all sorts of britany pain13:11
BenCapw: I'll be uploading today or today13:12
apwBenC, great13:12
BenC*tonight13:14
rtgapw, why is britany complaining ? that kind of ties powerpc to the distro kernel build. wtf ?13:14
apwrtg, it is complaining because our src stops making them, so migrating our package would leave us with no ppc builds at all13:14
apwso it gets all whiney.  i believe once bens package is in, they will migrate as a pair this time13:15
apwand once thats done they will be unlinked from each other13:15
* rtg grumbles13:15
apwrtg, britany has a point, you are orphaning whole swathes of the archive13:16
apwit doesn't know ben is sorting that out, till he uploads13:16
rtgapw, 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
apwrtg, arse, those are a royal pain, in what bit ?13:17
apw(if you know)13:17
rtgapw, thats the hard part.13:17
apwrtg, fyi i am working on raring-meta, we have some other deps issues due to the temp disablement of the linux-tools on arm13:18
apwwhich is also stopping migration13:18
* henrix -> lunch13:18
rtgbritany doesn't seem very flexible13:18
apwrtg, her job is to stop you breaking the archive.  by dropping linux-tools a couple of package exploded13:22
apwshe knows what she is doing 13:22
rtgapw, if I figure out the armhf tools build problem, can we just ignore armel ? (though they are likely the same).13:25
apwrtg, ahh while i remember, we are missing a couple of tags for ubuntu-raring (the last two uploads) and one of the meta ones too13:25
rtgapw, I just fixed the Ubuntu-3.7.0-0.5 tag13:25
apwrtg, probabally, i'll find out when armel is getting zapped13:25
apwrtg, i think we are also missing .413:26
rtgapw, I never uploaded the others so I didn't bother tagging. those commits are also linear and easy to reproduce13:26
apwthough i suspect it is linear from .513:26
apwack13:26
* rtg will bbiab13:27
rtgcking, are you OK with me bouncing gomeisa ?14:04
rtgI'm trying to remove a chroot and can't get all of the mount point released. damn schroot anyways.14:05
ckingyep14:05
rtgcking, done14:06
BenCapw: When I get a chance I'll write up a test case for you15:16
BenCGotta get this package out the door first...15:16
apwBenC, 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 already15:21
BenCapw: Use the old enforce (before my commit) against my set of powerpc configs (with e500 and e500mc)15:22
BenCThat NVRAM check fails on e500 and e500mc, but it shouldn't15:23
apwBenC, ta15:23
BenCAnd 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 configs15:23
apw(flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \15:24
apw value CONFIG_NVRAM m | \15:24
apw !exists CONFIG_NVRAM15:24
ubot2apw: I am only a bot, please don't think I'm intelligent :)15:24
apwBenC, like that ... but you have it =y on powerpc-e500 and powerpc-e500mc and thats not valid under that form15:25
apwso it correctly fails on those two15:25
apwBenC, or perhaps not ... /me pokes15:26
apwBenC, no i am right15:28
apwCONFIGS/powerpc-config.flavour.powerpc-e500:CONFIG_NVRAM=y15:28
apwCONFIGS/powerpc-config.flavour.powerpc-e500mc:CONFIG_NVRAM=y15:28
apwCONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_NVRAM=y15:28
apwthose three have NVRAM set, so for the rule to be right it has to expect Y for those three15:28
apw(flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \15:29
apwand that only allows it to be powerpc and powerpc-smp, so they will fail15:29
apw(flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \15:30
apwdamn that paste15:30
BenCapw: I tried add "| value CONFIG_NVRAM y" and it still failed15:33
apwBenC, will try that even though it doesn't represent what you want15:35
BenCapw: I don't want to force NVRAM=y on e500/e500mc15:36
BenCIt's fine if it's one, don't care otherwise15:36
BenC*on15:36
BenCapw: What I want is for it to be forced on powepc-smp, and not care for anything else15:37
BenCBut 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 expected15:38
BenCpowerpc15:38
BenCSo if the NVRAM rule works as expected, then the ADT rule isn't :)15:39
apwBenC, nope, cause that _is_ only Y on powerpc-smp, and that rules says Y for that and _must_not_exist_ on all the others15:39
apwso the rule matches reality, not necessarily what you care about15:39
BenCit exists on e500/e500mc right?15:39
apwnope15:39
apwapw@dm:~/git2/ubuntu-raring$ grep CONFIG_THERM_ADT746X CONFIGS/*15:40
apwCONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_THERM_ADT746X=y15:40
BenCHmm…then I wasn't paying close enough attention15: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_NVRAM15:41
ubot2apw: I am only a bot, please don't think I'm intelligent :)15:41
apwso i think that encodes what you are saying15:41
BenCso the second line just basically ignores e500/e500mc?15:41
apwyeah it says this rule is "happy" if we are on one of those flavours, without checking anything related to the option15:42
apwits just a logical or15:42
apwi'll test that on master, and if it works splat it in15:42
BenCOk, thanks15:43
BenCapw: 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 flavour15:43
BenCHence my concern about multiple flavours15:43
apwBenC, the commented out debug is just plain wrong, i prints $a[1] each time, instread of $possible15:45
apwbut its commented out indeed15:45
BenCerr, meant uncomment so you see what it is15:45
BenCI didn't see it only prints the [1] in the array15:46
BenCThat alleviates some of my concern then :)15:46
apwyeah i clearly fixed the debug in the arch one, and not the flavours one15:46
apwmust have not had to debug flavours recently15:46
apwBenC, ok i've fixed the debugging for next time15:56
BenCGracias15: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 along16:59
=== rtg is now known as rtg-afk
* smb -> EOW17:24
=== rtg-afk is now known as rtg
* henrix -> EOD17:59
slangasekrtg: urk, you were losing time fighting with armel?  Well, on the bright side... you don't have to do that again :P18:22
rtgslangasek, urk, indeed :018:23
rtg:)18:23
rtgslangasek, the next kernel upload won't contain _any_ armel support. Is brittany gonna be able to deal with that ?18:25
slangasekyep18:25
rtgslangasek, I understand moving powerpc support kind of made it complain18:26
slangasekwell, once removed we have to make sure we clean up behind it and aren't leaving uninstallable packages in the archive18:27
slangasekbut that's what britney's supposed to do18:27
rtghopefully BenC's upload will get everything sorted18:27
BenCI'm in the final stages of proofing the packages18:28
=== rsalveti_ is now known as rsalveti
* apw calls it a day18:42
=== edamato is now known as edamato-afk
=== yofel_ is now known as yofel
BenCinfinity: Will I need to do a MIR for linux-ppc?19:41
infinityBenC: No, it's just a source split producing things that were already in main.19:43
BenCinfinity: Ok, upload is in progress…can I pester you for processing when it's done?19:43
infinityBenC: 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. :P19:44
infinityBenC: 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
BenCinfinity: There's some patches from Freescale, but they are all available from Freescale's public linux.git and are in the process of upstreaming19:45
* rtg -> EOD19:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!