=== shengyao_afk is now known as shengyao
=== yofel_ is now known as yofel
=== Guest61012 is now known as fmasi_afk
=== cmagina_ is now known as cmagina
=== kentb-out is now known as kentb
=== gfrog_ is now known as gfrog
=== fmasi_afk is now known as fmasi
=== fmasi is now known as Guest1765
=== Guest1765 is now known as fmasi_wfh
[15:28] <Sargun> Why is CONFIG_FUNCTION_TRACER set to y in the standard kernel config?
[15:28] <Sargun> (on AMD64 Raring's kernel config)
[15:35] <smb> Sargun, Because it otherwise would not be possible to enable function tracing on a stock kernel (it is a bool and should be y for i386, too). If that is the answer you are looking for
[15:35] <bjf> Sargun, i believe it is enabled so that ftrace can be used to debug kernel problems
[15:36] <bjf> Sargun, i believe we benchmarked it and found it added little/no overhead if you were not in fact using ftrace
[15:37] <apw> yeah i believe the same
[15:38] <smb> right, according to help 5 NOPs at the entry of each function which should have not much impact
[15:41] <Sargun> Hm
[15:42] <Sargun> This is unfortunate. I really want to enable KMEMCHECK on my kernels, which conflicts with CONFIG_FUNCTION_TRACER (it requires it to be =n).
[15:45] <Sargun> I guess is CONFIG_FUNCTION_TRACER doesn't get used during normal operation, this is fine
[15:46] <apw> Sarvatt, if you are changing your config you can change both anyhow right ?
[15:50] <bjf> Sargun, ^
[15:52] <apw> bah i hate auto complete ... it is meant to pick the person who spoke last, that is working, NOT
[15:56] <Sargun> apw: Yeah, I was just wondering if CONFIG_FUNCTION_TRACER was used for anything other than debugging.
[15:57] <apw> no indeed, just for debug, but ... you dont want to change your system to start using debugging tools when you need them
[16:25] <cking> brendand, i've built a new version of fwts for testing on that ARM box - it's in ppa:colin-king/white
[16:26] <brendand> cking, cool - i'll give it a try
[16:26] <cking> great!
[16:53]  * cking waits with baited breath
[17:22] <cking> brendand_, any results?
[17:24] <brendand_> cking, yeah, passed
[17:24] <brendand_> cking, how did you change the test?
[17:24] <cking> brendand_, cool, I'll send the patches out for review then \o/
[17:25] <cking> brendand_, i re-wrote the support libs last week but forgot to tweak the test according to the new api, so it failed last week, today I fixed the test and it works as expected
=== fmasi_wfh is now known as fmasi_afk
[20:25] <hallyn> rtg: i'm sitting here on my saucy laptop, getting the same kvm modprobe error you were on trusty.  has that been figured out yet?
[21:21] <apw> hallyn, hey which kerle is that
[21:25] <apw> hallyn, is that a home brew
[21:28] <hallyn> no
[21:28] <hallyn> 3.11.0-12-generic #19-Ubuntu
[21:29] <hallyn> (cut-paste is being a b*, refusing to cut at words)
[21:30] <apw> hallyn, i don't think i see that on my machine when it is on 3.11 kernels
[21:31] <rtg> hallyn, hmm, kvm_amd is working for me. You have Intel, right ?
[21:31] <apw> hallyn, can you try the kernle in -proposed -13 ?
[21:31] <apw> hallyn, i have a kvm_intel (the one showing the issue originally) but i believe it works fine on the 3.11 kernles
[21:31] <hallyn> just dget it from the build logs?
[21:32] <hallyn> not the logs of course
[21:32] <hallyn> about time to call eod judging by reading my own comments
[21:34]  * hallyn tries https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/5146181/+files/linux-image-3.11.0-13-generic_3.11.0-13.20_amd64.deb
[21:34] <hallyn> will be awhile
[21:43] <apw> hallyn, i have just booted 3.11-12.19 and 3.12-13.20 and both work fine, 3.12-0 does not
[21:48] <hallyn> apw: (i've installed but not yet rebooted) have you figured out wha'ts up with 3.12-0?
[21:49] <apw> hallyn, nope rtg is on the case, its not h/w specific, seems to be a kvm core issue
[21:50] <hallyn> wowzer
[21:51] <rtg> hallyn, its a debugfs issues, so nothing too critical. I should be able to at least pin it down soon.
[22:02] <hallyn> rtg: oh right, i forgot that showed up in syslog
[22:03] <hallyn> but holy cheeseballs!  somehow kvm got disabled in bios.  
[22:04] <hallyn> <think><think><think>  <lightbulb>   that effing windows 7 install i did to try and update bios.  I bet it disabled it!
[22:07] <rtg> hallyn, bummer dude
[22:07] <apw> hallyn, man ... m$ should really be taken out and ...
[22:18] <hallyn> you must not assume malice on th...  oh wait this isn't debian-devel
[22:18] <hallyn> i dunno, do they want to then charge me to reenable it for me?
[22:25] <rtg> hallyn, the 3.12 kvm issues appears to be genuine. I've instrumented the create debugfs dir path and should have some notions soon.
[23:29] <Malediction> Could anyone tell me why, since the latest release upgrade, I have 64 rcuos/<number> and rcuob/<number> processes on a single core VM? (or better yet, tell me what docs/man I can read to better understand them)
[23:51] <bjf> Malediction, http://lwn.net/Articles/518953/
[23:54] <Malediction> Ah, thank you. :)