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