[01:12] <RAOF> apw: Dunno if you're still here, but 3.13 improves things in some ways.
[01:13] <RAOF> apw: In that pairing the touchpad doesn't cause a kernel panic. However, it doesn't cause a kernel panic because bluetooth fails to work entirely.
[09:58] <cking> smb, https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey
[10:00] <apw> RAOF, oh what a gay day
[10:05] <apw> cking, hey that looks familiar, i can tell i was involved in at least one of those scripts just from the idioms used
[10:06] <cking> yup
[10:09] <smb> apw, Yeah I remembered this one yesterday (well looked it up again) while on the discussion about making usb-creator usable
[10:09] <smb> I think it has some draback when it comes to server images as they use Debian installer and not casper
[10:10] <apw> smb, may so indeed, probabally assumes it can mount itself to get the .debs or something
[10:11] <smb> Some parts are in grub2 but probably needed some intelligencce finding the iso as well and casper was better or so
[10:11] <smb> Really hard to remember now
[10:12] <apw> yeah
[10:12] <apw> and that
[10:36]  * apw whines about tearing under X on saucy
[10:37] <apw> vertical tearing
[10:44] <brendand> hi - i've noticed that on my system, the value in scaling_max_frequency is lower than the highest value in scaling_available_frequencies
[10:45] <brendand> what impact (if any) would that have on system performance?
[10:49] <infinity> brendand: It would limit your max frequency, obviously.  But this is also a bit odd.  What are the values?
[10:49] <apw> i would expect the max frequency to define how fast your machine might be allowed to go
[10:50] <apw> i would hope that info came from the bios and thus it is to blame
[10:50] <apw> cking, ^^ thoughts ?
[10:50]  * infinity notes that his has grown a new and bogus top-end...
[10:50] <infinity> (base)adconrad@cthulhu:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
[10:50] <infinity> 2801000 2800000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 
[10:50] <infinity> THANK GOD FOR THAT EXTRA 1MHz.
[10:50] <brendand> max: 1520400
[10:51] <cking> infinity, i think that's a placeholder for the turboboost
[10:51] <brendand> available: 2534000 2533000 1600000 800000
[10:51] <brendand> am i really restricted to 1.5Ghz?
[10:52] <cking> brendand, file a bug, I'll collect some data and poke at it
[10:52] <apw> i see brendand has that same 1mhz bump 
[10:52] <brendand> kernel bug?
[10:53] <infinity> cking: Oh, did someone finally add turbo capability to ondemand?
[10:53] <smb> apw, Think as cking said that this is turbo mode
[10:53] <cking> it is turbomode, I see that on my range of boxen
[10:54] <cking> brendand, what does fwts cpufreq tell you?
[10:54]  * infinity was under the impression you had to use Intel's awful governor to get turboboost, but maybe they felt pity on those of us who like to not run crap code.
[10:54] <apw> oh yeah i was sure turbo was what i was, i was just idly noting his supported that
[10:54] <brendand> cking, a lot of warnings
[10:55] <brendand> Medium failures: 4
[10:55] <brendand>  cpufreq: Supposedly higher frequency   1.65 GHz is slower (78023 bogo loops) than frequency   1.65 GHz (78059 bogo loops) on CPU 0.
[10:55] <brendand>  cpufreq: Supposedly higher frequency   2.58 GHz is slower (78002 bogo loops) than frequency   2.58 GHz (78023 bogo loops) on CPU 0.
[10:55] <brendand>  cpufreq: Supposedly higher frequency   2.58 GHz is slower (77670 bogo loops) than frequency   2.58 GHz (77823 bogo loops) on CPU 1.
[10:55] <brendand>  cpufreq: Firmware not implementing hardware coordination cleanly. Firmware using SW_ANY instead?.
[10:56] <brendand> cking, and those failures
[10:56] <cking> that's helpful, can you file a bug, and report what fwts says, also include the output acpidump too, then I can figure what's going on
[10:57] <cking> and run that test when the machine is fully idle too
[10:57] <amitk> cking: brendand: it would be useful to check the machine temperature as well
[10:57] <brendand> amitk, hot :P
[10:57] <amitk> (to see if it is a thermal constraint)
[10:58] <cking> that's the problem then
[10:59] <smb> or even something fiddling around with max_frequency from userspace
[11:02] <brendand> cking, max_freq is being lowered because the system is hot?
[11:03] <cking> brendand, to stop the silicon melting away CPU freq throttling is kicked in
[11:03] <cking> (passive cooling)
[11:04] <cking> as well as the fan (active cooling)
[11:04] <cking> brendand, I'll work in the cpufreq test to explicitly detect this so we can figure this out easily 
[11:07] <brendand> cking, right now it's only running at 50% and it's still at the same value
[11:07] <brendand> cking, is there any way to tell for sure it's due to overheating?
[11:08] <cking> cat /sys/class/thermal/thermal_zone*/temp  perhaps
[11:10] <cking> dmesg may contain some info about throttling (well it used to, not checked it recently)
[11:11] <amitk> brendand: and cat trip_point_?_temp in the same directory
[11:12] <cking> good idea ;-)
[11:15] <brendand> cking, amitk - i think it shouldn't be : http://paste.ubuntu.com/6447619/
[11:15] <brendand> cking, amitk - all the temps are lower than any of the trip points
[11:18] <cking> brendand, what is cat /sys/bus/cpu/devices/cpu*/cpufreq/cpuinfo_max_freq
[11:19] <brendand> cking, same as in max_freq: 2534000
[11:19] <brendand> cking, for both cores
[11:20] <cking> brendand, and /sys/bus/cpu/devices/cpu0/cpufreq/bios_limit?
[11:22] <brendand> cking, same
[11:23] <amitk> is this running the intel pstate driver?
[11:30] <brendand> amitk, how can i check that?
[12:02] <infinity> brendand: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[12:03] <brendand> infinity, oh ok - i didn't realise those were the same. no it's just ondemand
[16:33] <ppisati> robher: didn't we disable cpufreq because of instabilities on ecx-1000? was it fixed? upstream code or firmware fix?
[16:34] <robher> ppisati: that was cpuidle. cpufreq was colliding with the omap cpufreq driver, but that should be fixed
[16:35] <ppisati> robher: ah right
[16:57] <ppisati> robher: actually i don't see any sign of us trying to turn it on and then off 
[16:57] <ppisati> robher: i see it's on for raring, when highbank had its own kernel
[16:59] <robher> ppisati: maybe it got turned off in saucy inadvertently.
[17:00] <robher> perhaps some kconfig changes caused new defaults to get picked up?
[17:01] <ppisati> robher: actually i saw i commit from March 2013 when it was turned off cause it paniced omap, so when we collapsed all flavours in a single image kernel, that was off
[18:38] <jtaylor> concerning transparent huge pages, they are enabled but always be default
[18:39] <jtaylor>  /sys/kernel/mm/transparent_hugepage/enabled is set to madvise
[18:39] <jtaylor> found bug 743688
[18:39] <ubot2> Launchpad bug 743688 in linux (Ubuntu) "Transparent HugePages not enabled in 11.04 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/743688
[18:41] <apw> so if we are going to do anythihng with that it sounds liek another measure and evaluate job
[18:44] <jtaylor> concerning comment #12 according to lwn they are swappable (via splitting), and the performance regression might be fixed in 3.11, at least I think saw a commit that fixed one recently
[18:44] <apw> ogasawara, perhaps a WI to measure it, what do you think
[18:45] <ogasawara> apw: +1, was just writing it down
[18:45] <ogasawara> I should actually throw it in the whiteboard before I lose this piece of paper
[18:45] <apw> sounds good to me
[18:46] <jtaylor> commit 348944504362417205107e63cfe4821aa87ec1bb
[18:46] <apw> jtaylor, is that something (the default) which can be modified via either sysctl or via the kernle command line do you know
[18:47] <jtaylor> yes I always do so
[18:47] <apw> ok, so thats something
[18:47] <rtg> apw, whats the story on 'scsi: hyper-v storsvc switch up to SPC-3' in Trusty ? Its not even in linux-next.
[18:48] <rtg> og, only suggested by James
[18:48] <rtg> oh*
[18:48] <apw> rtg, yeah they are meant to be fixing that (i think by returning spc-3) in the hypervisor
[18:48] <apw> but till they do, ...  we need something
[18:48] <apw> i'll poke the lemming to find out
[18:50] <rtg> ogasawara, 3.13-rc1: 78 no-up patches, 30 SAUCE patches that should get reviewed for upstreaming.
[18:52] <ogasawara> rtg: ack
[18:57] <apw> rtg, ogasawara, i have just pushed a dependancy change for the kernel, this moves us from binutils-dev to libiberty-dev, this is a request from foundations.  this will trigger an MIR for that when we get there, but we're not uploading overly soon i assume
[18:58] <rtg> apw, on unstable ?
[18:58] <apw> unstable only indeed
[18:59] <rtg> apw, maybe you should push again. I may have clobbered it.
[18:59] <rtg> obsessively rebasing.....
[19:00] <rtg> sorry
[19:04] <apw> rtg, done, np
[19:04] <rtg> apw, thanks
[19:30] <ppisati> robher: how can i tell if i'm using your cpufreq driver?
[19:30] <ppisati> ubuntu@c09:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
[19:30] <ppisati> generic_cpu0
[19:33] <robher> ppisati: hummm, good question. I think other than looking at the kernel log, you can't.
[19:39] <ppisati> robher: you don't do any particular output in your driver, plus i've this:
[19:39] <ppisati> [    1.364119] cpufreq_cpu0: failed to get cpu0 regulator: -19
[22:29] <bjf> kees, you plan on verifying bug 1183616? (please)
[22:29] <ubot2> Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged] https://launchpad.net/bugs/1183616
[22:36] <robher> ppisati: actually, the cpu0 driver doesn't get instantiated unless the highbank driver succeeds. So if you see cpu0 driver being used, it is working. 
[23:14]  * rtg -> EOD
[23:22] <kees> bjf: I thought it was not cool for the fix-author to also do the verification? I asked around trying to find someone that could test on real hardware but I'm not sure how far they got.
[23:36] <infinity> kees: It's perfectly cool for the author to verify, if you actually verify instead of saying "yeah, I submitted it, therefor it's fixed lolz".
[23:38] <RAOF> Looks like we need to socialise that again.
[23:58] <bjf> kees, that rule doesn't apply to kernel bugs :-)