[03:17] <semitones> that would be cool
[03:17] <semitones> too bad he left
[03:26] <kristian-aalborg> greetings
[08:46] <cking> morning
[08:46] <smb> morning (.+)
[09:51]  * cking kills pulseaudio and tries some different tweaks
[09:58] <cking> apw, https://wiki.ubuntu.com/Kernel/PowerManagement
[09:59]  * RAOF should do some more controlled tests, but that seems to drop t420s power consumption ~4W (down to a more respectable 11-12W totally idle)
[10:03] <cking> nice
[10:03] <apw> RAOF, which is your entry in the table ?
[10:03] <RAOF> There isn't one yet.  See point "should do some more controlled tests".
[10:03] <apw> ahh :)
[10:04] <apw> RAOF, its very early hear
[10:04] <apw> here even, bah
[10:04] <RAOF> :P
[10:04] <RAOF> I wonder if that issue applies to this x200s, too.  Although it can't save *that* much power; dropping power consumption 4W here would drop it down to 4W in total, which seems a bit ambitious :)
[10:07] <apw> RAOF, but 1w on there would be mamoth
[10:07] <RAOF> It might get me back up to >10h runtime on the 9cell, yeah.
[10:32]  * cking rummages around for his power meter
[11:24] <Daviey> What is the current state of realtime kernel?
[11:24] <Daviey> (morning btw)
[11:28] <tjaalton> RAOF: which screen brightness setting did you have?
[11:28] <tjaalton> when testing the t420s
[11:29] <Daviey> apw / cking: Do you know the status of -realtime?  https://wiki.ubuntu.com/RealTime , suggests -lowlatency is the focus.. but TBH, i don't understand the difference.
[11:29] <apw> realtime hasn't existed for some time has it ?
[11:30] <apw> Daviey, realtime is presumably the -rt patchset, which lags the main kernel by many releases
[11:30] <apw> Daviey, lowlatency is about using upstream features is differnet configurations to get the best latency response they can
[11:30] <Daviey> apw: so TL;DR suggests we don't have a good story in that area?
[11:35] <apw> TL;DR ?
[11:38] <tjaalton> "too long; didn't read" :)
[11:40] <tjaalton> RAOF: 9,2W here, with rc6 enabled too, though the brightness is ~60%
[11:51] <tjaalton> turning bt off (0,5W), min_power for sata (0,5W) and brightness to minimum drops the estimate to ~7,1W :P
[12:08] <tjaalton> can't get lower than 6,2W
[12:35] <apw> does anyone know if we had a launchpad rollout recently?  i am seeing new delete buttons next to tasks and nominations
[12:36] <Daviey> apw: that was on planet.ubuntu.com as a new feature
[12:36] <apw> oh what does it do
[12:37] <Daviey> apw: if i add a task for FOOBAR project by accident, previously all you could do was mark it invalid. Now you can remove it.
[12:38] <apw> any idea what it means for a nomination, will it remove all precice ones or just the one on the specific task
[12:38] <diwic> no more "the NULL project" I assume :-)
[12:38] <Daviey> apw: http://blog.launchpad.net/bug-tracking/removing-a-project-from-a-shared-bug-report
[12:39] <Daviey> apw: NFI, try it on https://staging.launchpad.net/
[12:44]  * apw is tempted to hit it on production just to see what explodes
[12:45] <Daviey> lol
[12:46] <apw> Daviey, and anyhow as usual anything i click on on staging leads to an oops
[12:47] <apw> Daviey, oh and it doesn't have the code for that rolled out anyhow
[12:47] <Daviey> hah
[13:29] <ogra_> apw, do you remember the conclusions from our hallway hack session about dropping the initrd ? was it "kernel team rolls uuid support into the in-kernel tub 
[13:29] <ogra_> ergh
[13:30] <ogra_> ... into the in-kernel-stub initrd, then "stopwatch boot time diffs on different arches with that change"
[13:30] <ogra_> ?
[13:40] <apw> there is cirtainly a 'comparison of the three no-initrd, small initrd =mod, and fat' to produce
[13:41] <ogra_> right, i'm just thinking about how to turn it into proper WIs
[13:42] <apw> there should citainly be one to say do that comparison, and perhaps one to investigate use of the internal initrd
[13:43] <apw> i suspect maintainance of that is so fraught with complexity its not worth it
[13:43] <ogra_> would it be ok to write "rtg: to provide a kernel with uuid support in the internal initrd for measuring" ?
[13:43] <apw> i'd just put canonical-kernel-team on those and we can figure out who
[13:43] <ogra_> i can do all the measuring items and assign them to me
[13:43] <ogra_> k
[13:45] <ogra_> would we need to make the kernel learn a new cmdline option ? noinitrd will likely also skip the internal one i guess
[13:45] <ogra_> (or wont it ?)
[14:00] <apw> initrd handling is all grub side
[14:00] <apw> bootloader side, we only use one if its passed
[14:07] <ogra_> apw, but how does the kernel know if it should use the in kernel initrd or no initrd ?
[14:26] <apw> it always uses the internal initrd, just mosttimes it is empty
[14:26] <apw> unless there is one passed from outside
[14:28] <ogra_> k
[14:29] <ogra_> thx :)
[14:34]  * apw runs to toolstation, seems one of our switches i about to fall apart and expose live wires !
[15:11]  * smb looks over to apw, wondering whether the curse is spreading now...
[15:12] <apw> heh yeah, i'd not connected that things here were all falling appart cause the were house ones
[15:12] <apw> but clearly smb is to blame
[15:12] <smb> Always a pleasure to pass on the fun. :-P
[15:14] <apw> heh thanks
[15:35] <apw> heh nice, my battery is so flat that gsd is reporting it as not-present
[15:36] <smb> hm, is it present in the acpi stat?
[15:36] <apw> yep and now it has a charge of != 0, its now present in gsb too
[15:37] <smb> maybe a feature... a battery without charge is not really present... :-P
[15:52] <_ruben> i wonder if it'd detect my fully charged battery, which is not within my laptop currently ;)
[15:56] <ppisati> -CONFIG_BOOT_PRINTK_DELAY=y -- why do we have this on?
[15:57] <smb> to allow using the option iirc
[15:57] <smb> it allows setting the delay when y (does not do any delay by default)
[16:00] <ppisati> ah ok
[16:00]  * ppisati is having fun with the omap4 config sync/review
[16:02] <apw> ppisati, sounds riviting
[16:02] <apw> cking, i added a notes column to your sheet
[16:03] <apw> cking, and i am updating and charging a couple of my laptops to test
[16:09] <cking> apw, yeah, good note to add, nice to flag up broken results
[17:14] <apw> cking, this fix does what enable alpm by defualt ?
[17:15] <cking> alpm? ASPM don't you mean?
[17:15] <apw> cking, possibly :)
[17:15] <cking> alpm is sata related
[17:16] <apw> and what is aspm
[17:16] <cking> ASPM is the PCIe power tweaks
[17:16] <smb> Too many STLBs
[17:16] <cking> if ALPM is borked you may lose data
[17:16] <smb> STLAs even
[17:17] <cking> ALPM = Aggressive Link Power management for SATA
[17:17] <apw> cking, anyhow does nothing for my acer :(
[17:17] <smb> cking, Aggressive or Advanced as well?
[17:17] <cking> Aggressively Advanced?!
[17:18] <apw> cking, does your version number appear in version_signature?
[17:18] <smb> apw, As far as I understand the change it would only disable that now if the bios had enabled it and os is granted control
[17:18] <apw> and if not, how did you arrange that exactly
[17:19] <cking> apw, smb was discussing the version signature with me just now, seems like I foobar'd it
[17:19] <smb> apw, look for _OSC in your dmesg
[17:19] <apw> it is very confusing that you managed to elide your +foo ... and makes it hard to know if i am testing the right thing
[17:19] <apw> i see those
[17:20] <cking> apw, I know, I failed, this is what happens when I rush things over saturday :-(
[17:20] <apw> just amazed it is actually possible
[17:20] <smb> apw, I was surprised as well
[17:20] <cking> nothing surprised me
[17:21] <apw> normally one has to work pretty hard to stop it being in there
[17:22] <smb> cking, good point is, do you know whether aspm on/off would yield any message and which?
[17:23] <cking> smb, theoretically yes, but I dunno off the top of my head
[17:25] <smb> On my netbook here _OSC fails, but I don't know whether it would have the bit enabled or not. Well, from the data it does not seem to have
[17:26] <smb> apw, You can check whether your current kernel was compiled on Sat. ;)
[17:26] <cking> smb, what do you mean by _OSC fails?
[17:27] <smb> cking, pci0000:00: Unable to request _OSC control (_OSC support mask: 0x0f)
[17:27] <cking> ah, yes, that that then disables ASPM
[17:28] <smb> cking, Currently. With the patch I would assume it would be left alone if the bios had enabled it
[17:28] <cking> smb, I believe that's the idea behind it
[17:30] <smb> So this was taken, running the Sat. kernel. But power usage seems to be unchanged. Just was wondering whther there would be a piece of msg saying something... Hm, though that would only appear in the unpatched kernel...
[17:30] <jjohansen> smb:  		printk(KERN_INFO"ACPI FADT declares the system doesn't support PCIe ASPM, so disable it\n");
[17:31] <smb> jjohansen, Cool. Thanks. Re-installing the original kernel to cross check
[17:32] <jjohansen> smb: also not this patch won't fix everybody, only some of those with broken bioses
[17:32] <cking> sorry, this is hard to follow at the mo, my kids are demanding my attention
[17:32] <jjohansen> cking: when don't they :)
[17:32] <apw> "do they blend?"
[17:32] <cking> but the gist is that some broken BIOSes caused the old code to put the system into a sub-optimal state
[17:32] <smb> apw is a bit harsh
[17:33] <smb> jjohansen, Right, I just want to make sure data taken is consistent
[17:33] <mjg59> It seems that the expected behaviour is for Linux to *never* touch the ASPM bits unless we get _OSC control
[17:33] <cking> mjg59, where is the microsoft presentation you referred to in the patch?
[17:34] <mjg59> Right now if the firmware sets the "Do not use ASPM" bit  we clear ASPM state
[17:34] <mjg59> Which involves touching the ASPM bits
[17:34] <mjg59> It seems that we shouldn't be doing that
[17:34] <apw> ahh one of those subtle wordings catching us again
[17:34] <mjg59> There is no wording
[17:35] <apw> deep joy
[17:35] <mjg59> Platform expectations here are entirely undocumented
[17:35] <cking> well, it's kind of nebulous isn't it and it's not really mentioned in any specs we've got
[17:35] <mjg59> cking: If you just google for "pci express in depth for windows vista and beyond" you should find it
[17:36] <cking> so theoretically we should see some platforms do well out of this patch, while others no change whatsoever and the likelyhood of worse behaviour is nil isn't it?
[17:36] <cking> ah google my frend
[17:36] <mjg59> In theory
[17:37] <cking> well, so far the minimal crowd sourcing results look that way too
[17:37] <mjg59> The machine that triggered the original patch /seems/ to give full _OSC control
[17:37] <mjg59> Which would mean it still works with this patch
[17:38] <apw> cking, where is my automation *stamp*
[17:39] <cking> apw, what do you mean?
[17:39]  * apw is bored of oding this testing by hand already on 2 machines
[17:39] <cking> apw, lazy git ;-)
[17:40] <smb> apw, You have not written it, yet?
[17:41] <cking> I'm writing some code right now, I've got netfilter process monitoring and the ACPI battery monitoring in, just need to tidy it up.
[17:41] <apw> cking, this machine here, i've plugged the  power back in, and am still getting acpi estimates
[17:41] <apw> that seems unexpected
[17:42] <cking> bad powerflop behaviour perhaps?
[17:42] <apw> most likey
[17:42] <cking> this is why I'm hacking my own code, to ensure it's done right
[17:42] <cking> or more right ;-)
[17:43] <ogra_> whats the superlative of right ?
[17:44] <ogra_> rightest ? :)
[17:44] <cking> not more right for sure
[17:44] <apw> rightingly
[17:44] <cking> even righter
[17:44] <ogra_> so right :)
[17:44] <cking> more rightish
[17:45] <apw> less ridingcrop perhaps
[17:45] <smb> righton
[17:46] <kraut> howdy
[17:46] <kraut> i got a strange issue with the 3.0.x kernel. i wrote a daemon which watches if network devices are available with the kernel mac-table
[17:46] <kraut> after i upgraded to 3.0.x the timeout "gc_stale_time" doesn't as supposed to
[17:47] <kraut> gc_stale_time is set to 60 but it takes much more time until the entry wents from "STALE" to "FAILED".
[17:47] <apw> the entry in which table ?
[17:47] <kraut> could anybody tell me what changed from 2.6 to 3.0?
[17:47] <kraut> apw: arp
[17:47] <kraut> root@exodus:/proc# ip -4 neigh show dev br0 | grep "192.168.1.12 lladdr"
[17:47] <kraut> 192.168.1.12 lladdr 00:23:76:4f:8e:3b STALE
[17:47] <kraut> f.e.
[17:48] <apw> which kernel version is it confirmed working as you expected ?
[17:48] <kraut> wait
[17:49] <kraut> meh, deleted anyone because of diskusage
[17:49] <kraut> the last one from the last ubuntu version
[17:49] <kraut> hmm
[17:49] <kraut> linux-image-2.6.31-21-generic
[17:49] <kraut> this one f.e.
[17:50] <kraut> the entry above is still on "STALE" by the way :/
[17:50] <apw> so since Lucid ?
[17:50] <kraut> yep
[17:50] <apw> no 31 isn't anything
[17:50] <kraut> can't remeber all the "code names" ;)
[17:50] <kraut> with 11.04 everything was fine, with 11.11 not.
[17:50] <kraut> or 11.10 better said
[17:51] <apw> ok so 2.6.38 then
[17:51] <kraut> hmm. can't really tell. from dpkg -l it must be 2.6.31-21?
[17:51] <apw> smb, did we release with .31 in anything?  karmic maybe ?
[17:52] <kraut> ah, i think i purged the old packages so i can't figure out with dpkg -l
[17:52]  * ogra_ doesnt think it is a kernel prob ...
[17:52] <smb> apw, No, except maybe he is on arm
[17:52] <apw> kraut, is this imx51 ?
[17:52] <kraut> ogra_: i'm not really sure weither it's a kernel issue or not
[17:52] <kraut> but as i remember the arp table is a kernel "feature" and i think there is anywhere anyhow an issue :/
[17:53] <ogra_> i can use the command here on my ac100 and get STALE on oneiric with .38 ... if i try it on my x86 laptop under natty with .38 i dont get the STALE
[17:53] <kraut> apw: lmx51?
[17:53] <kraut> x86
[17:53] <kraut> Linux exodus 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux
[17:53]  * ogra_ would suspect the ip command to have changed here, rather than the kernel
[17:53] <apw> ok so if it worked on 11.04 which was natty, then the kernel would have been a 2.6.38 kernel
[17:53] <kraut> and no, it's not an issue with the hostname ;)
[17:53] <apw> and from there to 3.0 there are only 4 commits to arp
[17:54] <apw> none of which sound anything to do with state handling
[17:54] <kraut> from /proc/net/arp:
[17:54] <kraut> 192.168.1.11     0x1         0x2         38:e7:d8:de:bd:5d     *        br0
[17:54] <kraut> and 0x2 is STALE IMHO
[17:55] <kraut> root@exodus:/proc# cat /proc/sys/net/ipv4/neigh/default/gc_
[17:55] <kraut> gc_interval    gc_stale_time  gc_thresh1     gc_thresh2     gc_thresh3     
[17:55] <kraut> is gc_thresh new?
[17:56] <kraut> brb
[17:56] <apw> nope
[17:57]  * ogra_ would suggest looking at the changelog of iproute 
[17:59] <apw> its curtainly true that iproute has changed a lot in oneirc
[18:00] <kraut> i don't think it's an issue with ip-utils because /proc/net/arp shows me the same issue?
[18:00] <ogra_> ogra@horus:~$ zgrep -i ARP /usr/share/doc/iproute/changelog.Debian.gz 
[18:00] <ogra_>           Update ARP header type table
[18:01] <ogra_> well
[18:01] <ogra_> ...
[18:01] <kraut> hmmmm!
[18:03] <apw> cking, this is hopeless, the powertop interval changes randomly depending on how the values change
[18:03] <apw> 10s 15 45 sometimes
[18:04] <cking> apw, now you see why I'm hacking up something more useful
[18:04] <apw> i am more wondering what use any of the results are given this behaviour
[18:07] <cking> apw, they are limited, but will hopefully show up any seriously bad power issues or improvements
[18:07] <cking> hence, that's why I'm getting some proper kit
[18:08] <apw> proper kit is approriate, but something more usefult for 'us' would be good
[18:09] <cking> yep, but once I can calibrate typical ACPI results against real world power usage and make powertop like tool we will be in a better shape, but this is only day #1 of the project so progress is limited so far ;-)
[18:11] <kraut> from /usr/include/linux/neighbour.h the flag 0x2 in /proc/net/arp means REACHABLE so i think it's still a kernel issue
[18:11] <smb> cking, The only "downside" seems to be that external kit can only gather power consumption while plugged into ac, while acpi only gives you the consumption when on battery...
[18:12] <apw> kraut, well we'll need an accurate kernel version where its behaving different to work out where to look
[18:12] <apw> kraut, from what you've told me there doen't look to be any significant changes at all between the two versions
[18:13] <cking> smb, well, I can take these machines apart you know...
[18:14] <smb> cking, You even might succeed in putting them back together. :) I may not succeed on that part. 
[18:14] <apw> cking, nothing i've tested so far sees any benefit
[18:16] <cking> apw, it has been beneficial, now you see why I'm doing this over the next few months and you're not.
[18:17] <apw> cking, oh i know why you are doing it :)  i don't have the patience :)
[18:18] <kraut> apw: that's not so easy because i can't downgrade that way :/
[18:18] <apw> kraut, you should be able to run the older kernel with teh current userspace generally
[18:19] <kraut> if i didn't deleted it, that wouldn't be a problem^^
[18:19] <apw> you can get it back from the launchpad librian
[18:20] <apw> https://launchpad.net/ubuntu/natty/+source/linux
[18:24] <kraut> can't i add that one to my sources.list?
[18:24] <kraut> deb https://launchpad.net/ubuntu/natty/+source/linux oneiric main
[18:25] <apw> that sounds dangerous
[18:25] <apw> oh that, no that isn't an archive
[18:28] <kraut> hmm
[18:28] <hallyn> hoping to test the new power-saving oneiric kernel today, but - I'm curious, does anyone have an idea offhand on whether th elucid kernel would be even still more battery-friendly?
[18:28] <kraut> so should i take this one? https://launchpad.net/ubuntu/natty/+source/linux/2.6.38-13.52/+files/linux_2.6.38.orig.tar.gz
[18:31] <kraut> i think i finish for today. i'm fed up :/
[18:34] <kraut> thanks for helping so far!
[18:48] <cking> apw, so I want to make my power measuring tool skip a reading if it sees processes wakeup/die. do you think that's a sane idea?
[18:49] <cking> s/wakeup/fork or exec or exit/
[18:49] <apw> my experience is more than one after are affected, i wonder if we could just consider restarting
[18:49] <apw> but dropping one or more is not unreasonable perhaps
[18:50] <cking> I've now got a vmstat like output including average + stddev power data
[18:50] <cking> gonna sleep on the this and tinker some more tomorrow
[18:50] <apw> cking, sounds planwise
[18:51] <cking> been reading the power meter manual, it's a nice bit of kit
[18:51] <cking> just hope I don't blow it up
[18:53] <apw> cking, stay away from smb
[18:53] <cking> he's had his fair share of dead H/W
[18:55] <apw> and i realise the switch which just broke and tried to kill me, was one he has been using
[18:55] <apw> just saying
[18:55] <cking> heh
[19:10]  * apw wanders off
[20:42] <smoser> smb, around ?
[23:26] <redzarf> trying to rebuild lucid kernel on amazon ec2, but it's not building the image deb file (only headers, docs, tools)
[23:26] <redzarf> any ideas?
[23:27] <redzarf> kernel version is linux-ec2_2.6.32-319.39
[23:49] <GrueMaster> Anyone know what happened to linux-ti-omap4: 3.0.0-1206.12 ?  I tested it in proposed last week, and it is marked now as fix-released.  The source and meta are on the server, but not the kernel deb.
[23:49] <GrueMaster> For oneiric.