**** BEGIN LOGGING AT Fri Dec 07 02:59:59 2012 Dec 07 03:00:30 i've started off with the demo image that shipped with my board. I'm hesitant to even do a package upgrade as I'm afraid I may lose support for all the optimized programs Dec 07 03:00:33 on arm, depending on far back you go with the kernel version, you better find a version of gcc built at the same time. ;) Dec 07 03:00:38 i'm not sure how I can check to see what I might lose Dec 07 03:00:51 ah, ok Dec 07 03:00:55 did you rebuild your programs or just apt-get them? Dec 07 03:01:13 well I was using ubuntu at first, and now I'm back playing with arm Dec 07 03:01:16 err angstrom Dec 07 03:01:45 is it a tremendous amount of work to get a video player built under ubuntu that leverages the dsp? Dec 07 03:01:59 that's where I see the biggest difference Dec 07 03:02:16 you can mix/match the kernel's too.. there's some things nice in angstrom's userspace.. but i need dpkg. ;) Dec 07 03:02:26 I saw some demo of synergy on youtube with 6 beagleboards...that looked amazing Dec 07 03:02:58 oh that was mans's project, no dsp their.. Dec 07 03:03:04 all cortex... Dec 07 03:03:11 oh I love ubuntu, I'd must rather work in it...but I think I need the drivers unless I can with get something optimized built Dec 07 03:03:35 how exactly did that work? I haven't really seen a program that does that screen division like that Dec 07 03:03:52 should I just google synergy beagleboard? Dec 07 03:03:56 but for the dsp: instead of working the dsplink guys i followed the tidspbridge guys.. (aka nokia) it works for video.. but yeah, no more changes now.. ;) Dec 07 03:04:21 because of their microsoft deal? Dec 07 03:05:05 here's the wall: http://www.youtube.com/watch?v=9pwUdRKllo0 Dec 07 03:05:46 pretty much, before Microsoft all Nokia phones had omap34/36xx based devices.. now qualcomm.. Dec 07 03:05:47 yeah that's amazing Dec 07 03:06:20 too bad omapfbplay doesn't have sound :) Dec 07 03:07:18 and i think sounds now finally works on the beagle in v3.7-rcX! ;) Dec 07 03:07:29 it was broken for a long time. Dec 07 03:07:59 running under angstrom? Dec 07 03:09:03 when it says "usb networked" does that just refer to the nics that connect via usb, or was there some special program running over usb (not ethernet) Dec 07 03:10:25 is there a version of ubuntu I could drop back to to be on par with the best angstrom, or is there just too much optimization by the angstrom guys to compete? Dec 07 03:10:29 alot of those 'usb networked' device notes go back when we didn't have any real ethernet devices on the original beagle.. Dec 07 03:11:19 just grab the kernel/modules from here: http://downloads.angstrom-distribution.org/demo/beagleboard/ They'll run just fine on ubuntu... Dec 07 03:11:20 so is v3.7-rcX another kernel besides the one you're hosting? Dec 07 03:12:08 so I just need to drop my kernel back to 3.0.17? Dec 07 03:12:14 we are at v3.7-rc8: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary (in this merge the twl4030 (beagle/etc) was rewritten..) Dec 07 03:13:01 that chip does the power management? Dec 07 03:13:04 Well, you could use my legacy v3.2.x branch on github.. 800Mhz works.. Dec 07 03:13:13 audio/usb/etc... Dec 07 03:13:41 it's a very complex multifunction/mult power/etc device.. Dec 07 03:14:14 does torvald's kernel have the myriad of patches in your repo? Dec 07 03:14:29 seems like you've done a great deal of work to get things to where they are Dec 07 03:15:34 We (beagleboard.org community) use torvald kernel as a base.. Most of the patches we have in the repo is stuff heading mainline.. or the last gasp of board based changes, before we have to fianlly convert to device tree.. Dec 07 03:17:17 so is that a good thing? Dec 07 03:18:09 yeah, it keeps it easy to rebase and keep following torvald's tree.. but we give up on backporting to old stuff. ;) Dec 07 03:20:17 I see...so do the angstrom guys do something special to get 1 GHz? Dec 07 03:20:59 here's their patch list for '1 Ghz' : https://github.com/beagleboard/kernel/tree/beagleboard-3.0/patches/pm-wip (both directories) Dec 07 03:21:51 Unless you work for TI and are paid to do it, yeah that massive list of patches to keep track of and push mainline. ;) Dec 07 03:22:29 wow, it takes all that go from 800 to 1 GHz? Dec 07 03:23:43 Correct.. ;) IF you didn't care about the life of the silicon and had heat spreader... well you could just bump the Vcc voltage and enable 1Ghz. .;) Dec 07 03:24:54 so did someone do that once for the angstrom kernel, and it's just too much work to follow the new revs? Dec 07 03:25:37 and one user actually did that in 2.6.36: https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/z3Jsk_nHLNU Dec 07 03:26:14 That was pulled from ti's 3.0.x-psp, they were even posted to the linux-omap mailing list, but after asked for more comments the poster never rebased so they got lost.. Dec 07 03:26:14 moo Dec 07 03:26:31 anyone here doing any nexus7 ubuntuey stuff? Dec 07 03:27:02 so TI will make the board work in their branch at 1 GHz Dec 07 03:27:09 ? Dec 07 03:28:02 that doesn't quite seem as big of a patch as the site you just showed me Dec 07 03:28:20 but I guess that was for 2.6.36 Dec 07 03:29:46 that small patch just over volts the core with no protection. ;) Dec 07 03:30:45 and that's what TI does in their tree? Dec 07 03:31:47 no.. that small patch was from a users.. Dec 07 03:32:39 btw, i have no interest in TI's tree, i know it supports 1Ghz.. and there's a lot of patches to accomplish it.. but it's not mainline.. Dec 07 03:32:54 oh it's really far off? Dec 07 03:33:05 is your goal to get most of the stuff pushed into mainline, is that realistic? Dec 07 03:35:25 why not? ;) btw you should talk to the fedora-arm guys: they will not except even a small patch: it has to be 100% mainline. ;) Dec 07 03:35:47 heh Dec 07 03:36:07 so to get the serial port working for output I had to diable getty in /etc/init, but keep the console line in uEnv.txt Dec 07 03:36:15 i thought from what I read online I had to remove that line fro uEnv.txt Dec 07 03:36:46 You need both places... uEnv.txt just redirects the boot console... /etc/init/serial inits getty.. Dec 07 03:37:04 well it didn't work when I removed it from uEnv.txt Dec 07 03:37:12 but maybe that's because it's also setting up the port correctly for me Dec 07 03:37:16 i.e. 9600, etc.. Dec 07 03:37:31 technically we don't need it in uEnv.txt.. but who wants to wait 10 Seconds waiting for a login to appear.. Dec 07 03:37:57 well I suppose I better remove it if I don't want messages coming out Dec 07 03:38:05 the problem for a lot of people... if your actually using the port with something.. you also need to quite MLO/u-boot.. Dec 07 03:38:41 oh so do more than just uEnv.txt? Dec 07 03:39:39 The easy way: just change u-boot to use a different serial port.. then you'll never see that either.. Dec 07 03:39:51 fun to debug.. Dec 07 03:39:52 via uEnv.txt? Dec 07 03:40:58 you wouldn't happen to know what disconnects getty in angstrom? I figured my first test would be to do that, then to yank the uEnv.txt line Dec 07 03:41:15 that's at least how I got success with ubuntu Dec 07 03:41:58 no just use a different serial port: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/omap3_beagle.h;hb=HEAD#l89 then u-boot will dump all the boot stuff somewhere else.. Dec 07 03:42:17 no idea, it's systemd... yuck.. Dec 07 03:44:03 any ideas on hunting down an apparent kernel-side memory leak on tegra3? Dec 07 03:44:16 i can only account for about 128m of userspace memory being used Dec 07 03:44:17 is that file used by the kernel or just u-boot? Dec 07 03:44:23 but kernel reports 420m gone Dec 07 04:06:57 so rcn-ee, if I want to stick with ubuntu yet leverage the prexisting kernel modules, is it best to drop back to 3.0.17 and use the BBxm modules, or try to use your 3.2 kernel? Dec 07 07:45:08 good morning Dec 07 07:45:39 morning Dec 07 07:46:30 dholbach: good morning Dec 07 07:46:39 hey achiang Dec 07 08:12:20 ogra_, I can't use onboard when gksu is active! Dec 07 08:12:42 yay for mouse grabs! Dec 07 08:12:56 aha, it's filed already: bug 421660 Dec 07 08:12:57 Launchpad bug 421660 in gksu (Ubuntu) "gksu's and gksudo's modal password prompt prevents OnBoard's virtual keyboard input, causing accessibility issues" [Medium,Confirmed] https://launchpad.net/bugs/421660 Dec 07 08:13:24 anyone here doing nexus7/tegra3 stuffs? Dec 07 10:11:17 * ogra_ waves to raster Dec 07 10:11:54 ogra_: moo Dec 07 10:13:02 i'm rolling the nexus images, whats your question Dec 07 10:13:33 memory Dec 07 10:13:41 i've found a 270mb memory black hole Dec 07 10:13:46 not in userspace Dec 07 10:13:51 not in kernel slab info Dec 07 10:13:55 i cant find it Dec 07 10:14:10 but theres 270mb or so of mem i cant account for no matter how i try Dec 07 10:14:18 fyi Dec 07 10:14:26 i've already chopped out 200m of memory usage Dec 07 10:14:31 using our image ? Dec 07 10:14:39 the standard setup uses about 630m Dec 07 10:14:40 yup Dec 07 10:14:48 is that 12.10 or 13.04 ? Dec 07 10:14:50 i'm down to around 430m Dec 07 10:14:52 12.10 Dec 07 10:14:58 13.04 is broken as it gets Dec 07 10:15:03 13.04 installs zram by default Dec 07 10:15:04 gl is busted nasty-like Dec 07 10:15:06 bah Dec 07 10:15:09 dont need zram Dec 07 10:15:10 :) Dec 07 10:15:13 hmm, i use it fine here Dec 07 10:15:25 it has some issues butu you can work around them Dec 07 10:15:29 if i can find this memory hole i'll have a base footprint of less than 130m Dec 07 10:15:47 thats plenty good enough for a 1g device and me :) Dec 07 10:15:53 did you check the cmdline ? the bootloader prefixes a mad amount of stuff to it ... hardcoded Dec 07 10:16:01 ummm Dec 07 10:16:05 i did indeed not Dec 07 10:16:32 where can i find it Dec 07 10:16:33 ? Dec 07 10:16:40 cat /proc/cmdline Dec 07 10:16:40 from regular userspace? Dec 07 10:16:43 aaaah of course Dec 07 10:16:44 nm Dec 07 10:16:47 * raster slaps himself Dec 07 10:16:56 heh, dont :) Dec 07 10:16:57 i was thinking grub Dec 07 10:17:06 but realised "hmmm.. no.. no grub there" Dec 07 10:17:10 then i blanked out Dec 07 10:17:11 :) Dec 07 10:18:02 abootimg is the tool to use for fiddling with cmdline, kernel or initrd bootloader stuff Dec 07 10:18:05 lp0_vec=8192@0xbddf9000 Dec 07 10:18:13 tegra_fbmem=8195200@0xabe01000 Dec 07 10:18:17 yeah. no idea how you can get rid fo that Dec 07 10:18:19 re thos in.. bytes? Dec 07 10:19:01 * ogra_ guesses they are Dec 07 10:19:06 not sure though Dec 07 10:19:16 ogra_, Hey man any info on the Nexus 32GB with 3G? Dec 07 10:19:16 hmm Dec 07 10:19:23 well 8mb for fbmem... Dec 07 10:19:26 just tried like 5 minutes ago installing the latest raring Dec 07 10:19:29 kind redundant to use that much Dec 07 10:19:35 still no go Dec 07 10:19:45 Ethernin, hmm, how does it hang ? Dec 07 10:19:53 ogra_: have u been in touch with the nvidia guys? Dec 07 10:20:09 the gl/tegra drivers are not doing vsyn swaps Dec 07 10:20:11 vsync swaps Dec 07 10:20:21 its severely offensive Dec 07 10:20:26 especially since i asked for them :) Dec 07 10:20:31 raster, only through some guys in #ac100 (tegra2 netbook) Dec 07 10:20:33 (set swapinterval to 1) Dec 07 10:20:45 but i doubt they will be able to help you here Dec 07 10:20:55 aaah boogers Dec 07 10:20:59 the stuff you look at comes hardcoded from the bootloader Dec 07 10:21:16 thats rather googles side of things i'd say Dec 07 10:21:25 ogra_, well i noticed that in the bootimg.cfg within the bootimg file it's still pointing to the partition9 instead of partition10 Dec 07 10:21:43 ogra_, cmdline = root=/dev/mmcblk0p9 ro console=tty0 fbcon=rotate:1 access=m2 quiet splash Dec 07 10:21:46 vmalloc is 128m Dec 07 10:21:49 hmm i wonder what that does Dec 07 10:21:55 Ethernin, yes, thats fine, it detects the right partition during first boot, resets the cmdline and reboots Dec 07 10:22:04 ok Dec 07 10:22:07 at least it is supposed to :) Dec 07 10:22:22 hmm Dec 07 10:22:41 i wonder if ont he tegra kernel the vmalloc literally snarfs those 128m away and never allows userspace to get it Dec 07 10:22:50 that accounts for almost half my vanished mem Dec 07 10:23:16 i would bet thats most likely used for the binary drivers Dec 07 10:23:20 i wonder ifr it gets it wrong and uses it as real physical ram Dec 07 10:23:25 ogra_, so i've tried downloading from http://hwe.ubuntu.com/uds-r/nexus7/ (the 32GB version) and the latest raring from: http://cdimage.ubuntu.com/daily-preinstalled/current/ Dec 07 10:23:30 ogra_: quite possible Dec 07 10:23:43 if its where ti stuffs texture and backbuffer data etc. Dec 07 10:23:53 neither one of those works using fastboot 1.6 flashing Nexus 32gb with 3g Dec 07 10:23:56 at least so far Dec 07 10:24:05 oh shit! Dec 07 10:24:06 or where it gets it from Dec 07 10:24:06 NM! Dec 07 10:24:08 it worked! Dec 07 10:24:11 wahoooo!!! Dec 07 10:24:12 :) Dec 07 10:24:14 yay! Dec 07 10:24:16 !_! Dec 07 10:24:24 BOOOYAH! Dec 07 10:24:27 ogra_: also.. wheni suspend.. it just insta wakes up Dec 07 10:24:30 liek suspend for 200ms Dec 07 10:24:31 then wake Dec 07 10:24:35 all onits own Dec 07 10:24:35 it was hanging at first saying is wasnt a modem or soemthing Dec 07 10:24:52 raster, i noticed that too, next suspend persists though Dec 07 10:24:56 /usr/sbin/pm-suspend Dec 07 10:25:00 when i go direct Dec 07 10:25:03 hmm Dec 07 10:25:07 nah - it keeps doing it every time for me Dec 07 10:25:13 again and again Dec 07 10:25:20 (using just the UI, not sure what that calls additionally beyond pm-suspend) Dec 07 10:25:21 i was wondering if i can figure out the wakeup src? Dec 07 10:25:25 dmesg didnt seem to help Dec 07 10:25:29 wsell not that i could find Dec 07 10:25:36 hmm ok Dec 07 10:25:40 i'm bypassing the ui Dec 07 10:25:40 :) Dec 07 10:25:44 heh Dec 07 10:25:51 trying to get E17 to work ? Dec 07 10:25:56 already working Dec 07 10:25:59 thats why i saved 200m Dec 07 10:26:02 :) Dec 07 10:26:04 heh Dec 07 10:26:11 compositing works a treat Dec 07 10:26:14 everything working Dec 07 10:26:16 multitouch works Dec 07 10:26:38 yeah, as bad as binary drivers are, the tegra ones are a pleasure to use Dec 07 10:26:44 it would seem the hw fb is actually portrait mode Dec 07 10:26:49 noting how the screen updates/scans Dec 07 10:26:51 or appears to Dec 07 10:26:51 heh, yeah Dec 07 10:26:57 we tricked it into landscape Dec 07 10:27:02 ewww Dec 07 10:27:11 using a desktop distro that somewhat seemed better Dec 07 10:27:11 can i untrick it Dec 07 10:27:14 without xrotate? Dec 07 10:27:17 :) Dec 07 10:27:28 i dont think you can untrick the touchscreen easily Dec 07 10:27:40 i noticed its dodgey when i xrotate back to portrait Dec 07 10:27:44 and noting the rendeirng speed Dec 07 10:27:58 it feels like its doing extra copies and rotates along the way Dec 07 10:28:00 maybe 2 times Dec 07 10:28:05 so render to buffer Dec 07 10:28:09 rotate to the tricked landscape Dec 07 10:28:13 then when in portrait Dec 07 10:28:15 but yeah, for the rest, there is a) a rotation option set on the cmdline (use abootimg on /dev/mmcblk0p2 to change it) and b) an xorg.conf snippet Dec 07 10:28:19 rotate YET again back to portrait Dec 07 10:28:35 ooh docs? Dec 07 10:28:48 abootimg -h Dec 07 10:28:49 :) Dec 07 10:28:54 aaah there it is Dec 07 10:28:58 fbcon=rotate:1 Dec 07 10:29:07 /dev/mmcblk0p2 carries the bootimg raw Dec 07 10:29:11 btw Dec 07 10:29:16 is the IO meant to be that slow? Dec 07 10:29:20 sudo abootimg -i /dev/mmcblk0p2 Dec 07 10:29:30 we didnt do much to optimize for MMC yet Dec 07 10:29:35 hmm Dec 07 10:29:41 fair enough - it's pretty sluggish Dec 07 10:29:45 i'll likely set some sysctrl bits during the cycle Dec 07 10:30:04 well ok- sluggish compared to equivalent devices i have.. around the place Dec 07 10:30:14 that lets say.. some big oem's like to make Dec 07 10:30:30 there isnt much we can do wrt filesystem optimization ... the ext4 we use needs to be created by the android tools to make it work with fastboot Dec 07 10:30:33 ie i can see 2-3x the io rate Dec 07 10:30:43 ext4 isnt the problem Dec 07 10:30:44 :) Dec 07 10:30:53 so on that side there isnt much we can imrpove Dec 07 10:31:01 it know - ext4 works a treat on some over-the-top ssd's i have Dec 07 10:31:05 but userspace surely still has room Dec 07 10:31:07 and on.. other arm devices on emmc Dec 07 10:31:14 oh btw Dec 07 10:31:22 do u try and change governor by default? Dec 07 10:31:31 i realized theres a new interactive governor Dec 07 10:31:34 well, ubuntu defaults to ondemand Dec 07 10:31:38 everywhere Dec 07 10:31:41 its AWESOMELY better than ondemand or conservative Dec 07 10:31:47 oh no no Dec 07 10:31:50 dont do that on this Dec 07 10:31:55 change to interactive Dec 07 10:31:57 file a bug ;) Dec 07 10:31:58 its like night and day Dec 07 10:32:11 nah :) i alrwady fixed that Dec 07 10:32:14 e17 just sets it itself Dec 07 10:32:20 i just have to select it in the menu Dec 07 10:32:22 :) Dec 07 10:32:34 there are the android init scripts that set a lot of these optimizations on boot, i havent had the time to go through all of them in detail yet Dec 07 10:32:49 when u get toit - i suggest u try it Dec 07 10:32:55 u can try it now to see what i mean Dec 07 10:33:03 iirc there is some code for the interactive governor Dec 07 10:33:48 Hey have any of you guys made a custom onboard keyboard before? Dec 07 10:34:08 just looking at trying to make it a little more usable on the nexus Dec 07 10:34:26 i know it uses svg files and you can create your own custom keyboard maps Dec 07 10:34:40 echo "interactive" > /sys/devices/system/cpu/cpu[0123]/cpufreq/scaling_governor Dec 07 10:34:42 just wondering if anyone had some good ideas on a simple way to do it? Dec 07 10:34:50 u dont need any code Dec 07 10:34:54 just do that and try it out Dec 07 10:35:02 well, interactive means you can set options ;) Dec 07 10:35:10 no Dec 07 10:35:17 i think it means its designed for interactivity Dec 07 10:35:23 ie so the gui is responsive Dec 07 10:35:29 as it beocmes really responsive Dec 07 10:35:39 it htink it clocks up fast Dec 07 10:35:41 https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/init.grouper.rc Dec 07 10:35:44 much faster than ondemand/conservative Dec 07 10:35:47 line 171 ff. Dec 07 10:35:49 sou get high clockrates fast Dec 07 10:35:52 then clocks down Dec 07 10:36:27 the lp_ options could probably help your suspend issue Dec 07 10:36:30 hmm Dec 07 10:36:45 interesting Dec 07 10:36:56 194 ff. looks intresting for MMC performance Dec 07 10:37:09 well the out-of-the-box interactive governor options make it great :) Dec 07 10:37:39 the prob is that we need to change a really badly implemented ubuntu default here Dec 07 10:38:01 i would much rather fix it by a complete re-implementation but wont have the time for this in 13.04 Dec 07 10:38:21 where are those lp_ options? Dec 07 10:38:37 hmm wtc Dec 07 10:38:39 wtf Dec 07 10:38:46 oooh Dec 07 10:38:47 2k Dec 07 10:38:49 nm Dec 07 10:38:56 wait Dec 07 10:38:57 2mb Dec 07 10:38:59 thats insane Dec 07 10:39:22 well, the device is pretty fast on android :) Dec 07 10:39:38 btw ... /etc/init.d/ondemand is what i was talking about above Dec 07 10:39:38 sure Dec 07 10:39:57 well for nexus7 i'd suggest using interactive Dec 07 10:40:06 just as is it makes it massively less sluggish Dec 07 10:40:18 oh Dec 07 10:40:59 right, the point is it should a) be autodetected which one is needed or b) be configurable Dec 07 10:41:01 u mean lp2_in_idle, no_lp, lp2_0_in_idle ? Dec 07 10:41:07 yes Dec 07 10:41:10 aaah yeah Dec 07 10:41:17 u want to have a single ubuntu image for eveyrhting Dec 07 10:41:18 sure Dec 07 10:41:57 no, but the things that are installed by default should work either automatically or be configurable to cover different tasks :) Dec 07 10:41:59 u COULD do some evil shellness in there looking at uname/proc/sys etc. Dec 07 10:42:12 And if in tegra3 ... then try a different one Dec 07 10:42:12 :) Dec 07 10:42:16 this initrscript is simply assuming the whole world wants ondemand all the time Dec 07 10:42:23 sure Dec 07 10:42:38 it dpeends if u are happy to hack init scripts to maek these work Dec 07 10:42:44 heh, sure Dec 07 10:42:51 personally i despise init scripts and want to see them die :) Dec 07 10:43:15 it just needs to function on x86, ppc, arm and under all ubuntu flavours after i touched it :) Dec 07 10:43:51 sure Dec 07 10:44:01 its not the coding, its the "make sure it does it right on all arches and flavours" bit thats hard for such generic bits in the distro Dec 07 10:44:05 and if [] ...; then ... ; else ;; fi Dec 07 10:44:16 boo Dec 07 10:44:20 to detect tegra3 at least .. if there is an interactive one Dec 07 10:44:31 case arch in; .... esac Dec 07 10:44:35 in fact i think if there were an interactive governor for desktop and laptop anyway u'd want it Dec 07 10:44:36 :) Dec 07 10:44:38 3x faster than if ;) Dec 07 10:44:50 its shell Dec 07 10:44:59 yep Dec 07 10:45:05 3x faster still means abotu the speed ofr continental drift :) Dec 07 10:45:14 but sure - i get it :) Dec 07 10:45:53 heh, well, if its a script executed during boot, 3x faster matters Dec 07 10:46:27 true Dec 07 10:46:37 tho imoh unity should take care of that higher up Dec 07 10:46:44 as such 1 size does not fit all with governors Dec 07 10:46:58 i have 1 laptop i have to clock at 600mhz Dec 07 10:47:03 right, but it should staay in the plumbing layer i think Dec 07 10:47:08 unity is to high up Dec 07 10:47:17 any more and it'll overheat after 1 min of compiling and throttle itself to death Dec 07 10:47:47 lovely ... Dec 07 10:47:53 as such i can clock in vast improvements in compiling times if i clokc to performance for the whole compile session Dec 07 10:47:59 then let it go back to auto afterwards Dec 07 10:48:02 write more shell and less C ;) Dec 07 10:48:11 thats why e17 has a control in it with some suid root fun Dec 07 10:48:19 hahaha Dec 07 10:48:32 I'd tend to agree that this doesn't need to be machine-specific, and interactive is the sane choice if it's available. Dec 07 10:49:18 infinity1, oh, you mean just looking at available_governors ? Dec 07 10:49:36 hmm, sounds like a good idea Dec 07 10:49:40 ogra_: Yeah. Dec 07 10:49:47 * ogra_ will play with that Dec 07 10:50:02 first .... coffee though .... Dec 07 10:50:03 brb Dec 07 10:50:06 ogra_: One could concievably build a kernel with no governors, and that init script should just exit silently in that case. Dec 07 10:50:24 ogra_: But if interactive is in the set, use that, else if ondemand, use that. Dec 07 10:52:24 ok Dec 07 10:52:30 lets hope the rotate thing is.. better Dec 07 10:53:01 ogra_: yeah - just use interative form avilable_governes if there.. if not - use ondemand :) Dec 07 10:53:04 simple Dec 07 10:54:31 but interactive is miles better Dec 07 10:54:38 hmm Dec 07 10:54:45 Yeah, I'm guessing it's not mainline yet. Dec 07 10:54:46 read are better with 2m readahead indeed Dec 07 10:54:54 My 3.7 kernel doesn't seem to have it built in, at any rate. Dec 07 10:55:05 infinity: i think its something android added Dec 07 10:55:10 i read about it as part of 4.0 or 4.1 Dec 07 10:55:21 its a new governor to improve interactivity Dec 07 10:55:26 yeah, we dont use it on x86 i think Dec 07 10:55:31 and it clocks up to max cloickrate almost immediately Dec 07 10:55:37 and then pulls back after that Dec 07 10:55:37 Yeah, it's definitely not in the 3.7 sources. Dec 07 10:55:47 so it leads to slightly more power drain Dec 07 10:55:53 raster: Yeah, I've read what it does, seems a bit saner. Dec 07 10:56:08 but its much more repsonsive as the cpu clocks up the moment it needs to do even just a little more work than the "trivial" Dec 07 10:56:10 And it's not necessarily more power drain, if it changes usage habits. Dec 07 10:56:18 sure Dec 07 10:56:28 Much like we discovered that 7200rpm laptop drives draw less power than 4200rpm ones. Dec 07 10:56:34 it makes sense to me - why it isnt in ondemand by default.. dunno Dec 07 10:56:34 :) Dec 07 10:56:35 Because they spin up faster, get shit done, and spin down. Dec 07 10:56:52 hmm, could it happen that not all cores have the same set of available governors ? Dec 07 10:57:05 ogra_: Not on any systems we support out of the box. Dec 07 10:57:11 k Dec 07 10:57:17 ogra_: that'd be highly odd Dec 07 10:57:27 Co, checking cpu0/available would be fine. Dec 07 10:57:32 Which is, I assume, why you asked. Dec 07 10:57:32 well, sysfs exposes it by core Dec 07 10:57:36 it could be that they cant all do the same clockrates tho Dec 07 10:57:44 s/Co/So/ Dec 07 10:57:45 so you can obviously set it by core Dec 07 10:58:04 which makes me think its not that odd (not that i see how it would help anything) Dec 07 10:58:11 No kernel we ship would/could have a different supported set per CPU. Dec 07 10:58:17 right Dec 07 10:58:24 One could potentially do such a thing, but it would be rather odd. Dec 07 10:58:30 yeah Dec 07 10:58:30 odd Dec 07 10:58:34 ok ok Dec 07 10:58:36 odd Dec 07 10:58:39 :) Dec 07 10:59:08 (Now, setting the governor per CPU is a less odd use-case, but that's left as an exercise for the end-user, not something we need to cater to) Dec 07 10:59:10 tho the tegra3 does have this awesome 5th cpu thing Dec 07 10:59:19 thats an example of 1 cpu only going up to.. hmm 400 or 500mhz Dec 07 10:59:22 Like having a many-core server with one core set to performance and the rest to ondemand. Dec 07 10:59:23 cant rememebr Dec 07 10:59:31 tho its jnot exposes in sysfs Dec 07 10:59:43 its glued in under the covers as u can do 4 cpus or 1 Dec 07 10:59:47 raster: Yeah, their own take on big.LITTLE, but not. Dec 07 10:59:48 depending on needs/clockrate Dec 07 10:59:53 yeah Dec 07 10:59:55 different Dec 07 11:00:08 but it was rather neat when i saw it in a presnetation from them a while back Dec 07 11:00:25 the fact that it uses a specific lower power process to make ti too i guess makes sense Dec 07 11:00:33 Yeah, all the big.LITTLE type ideas are pretty slick, both ARM's and NVIDIA's. Dec 07 11:00:36 either way - its just what us hackers need Dec 07 11:00:50 as we often just need a single core only going up to some middling clockrate Dec 07 11:00:57 eg to play some mp3 data Dec 07 11:01:01 we dont need the rest Dec 07 11:01:04 Kernel folks are still working on sane ways to make the scheduler take advantage of all of this. Dec 07 11:01:12 maybe just shuffle some bits from disk into the video decode buffers Dec 07 11:01:13 who knows Dec 07 11:01:45 The ARM big.LITTLE design involves a low-clocked A7 (the successor to the A9, which isn't confusing at all) and a bunch of A15s. Dec 07 11:01:59 But it definitely needs serious software support to make it as cool as the whitepapers and slides. Dec 07 11:02:47 sure Dec 07 11:02:55 Also has knock-on effect for high end computing clusters and such too, though, so it's an interesting problem to wrap one's head around. Dec 07 11:02:59 indeed not just kernel support Dec 07 11:03:04 but i think userspace too Dec 07 11:03:10 kernel cant predict what an app WILL do Dec 07 11:03:17 it can guess what it might based on history Dec 07 11:03:23 but an app is much more likely to know Dec 07 11:03:29 based on its knowledge of the world Dec 07 11:03:43 Yes, response time is one of the concerns if it's all kernel-side. Dec 07 11:03:47 so having interfaces to "hint" to the kernel what u are doing would be useful Dec 07 11:04:04 an example would be the std mainloop toolkits have Dec 07 11:04:16 when we wake up.. we take a quick look at the fd's that are active Dec 07 11:04:17 Since the initial cut here looks basically like an ondemand scheduler (again), but hotplugging cores in addition to frequency scaling. Dec 07 11:04:19 if x is active Dec 07 11:04:28 then we can assume we wil be doing some rendering Dec 07 11:04:41 so we can issue a "hey - clock up mate.. i need you now!" Dec 07 11:04:59 or if its an fd from wayland compositor Dec 07 11:05:02 or wherever Dec 07 11:05:03 :) Dec 07 11:05:10 we dont need absolute control Dec 07 11:05:18 but we need the ability to let the kernel knwo what we need Dec 07 11:05:22 or might need Dec 07 11:05:44 It goes back to the same discussion as hard drive RPM, really. Faster response times win the day (both in user experience and actual energy consumption), but you can't clock up "for no reason", or you lose hard on energy. Dec 07 11:06:16 not necessarily Dec 07 11:06:31 depending on soc/cpu/whatever Dec 07 11:06:37 eg 1.5ghz may be nice Dec 07 11:06:40 u CAN do 2ghz Dec 07 11:06:50 but you drain 3x the power as u have to up voltages and what not all over Dec 07 11:07:01 Oh, sure, clocking to max isn't always a win. Dec 07 11:07:02 theres a "fast sweetspot" Dec 07 11:07:11 I just mean "fast enough to get work done". Dec 07 11:07:12 and then thers the "give me everything u have" Dec 07 11:07:14 sure Dec 07 11:07:24 The key being that the largest power drain on these systems is actually the display. Dec 07 11:07:24 but if an app can hint at what it needs - semantically Dec 07 11:07:27 Then the RAM. Dec 07 11:07:28 Then the CPU. Dec 07 11:07:28 that'd be majorly helpful Dec 07 11:07:37 true Dec 07 11:07:45 ram? really? Dec 07 11:07:50 Yeah. Dec 07 11:07:53 thats the first time i hear it in the lsit Dec 07 11:07:55 its normally after cpu Dec 07 11:08:06 It's after CPU on low-RAM devices. Dec 07 11:08:11 hmm Dec 07 11:08:14 SRAM battery drain goes up rather quickly. Dec 07 11:08:22 oh sram... sure Dec 07 11:08:27 i'm thinking dram Dec 07 11:08:32 your usual run of the mill Dec 07 11:08:40 garden variety Dec 07 11:08:45 Anyhow. The display is always the biggest killer. Dec 07 11:08:57 So anything that gets the user through his task faster and the screen off faster is a win. Dec 07 11:09:01 To a point. Dec 07 11:09:13 As long as it doesn't mean "your cores are always awake and spun up, sucks to be you". Dec 07 11:09:19 Cause then the CPU takes over the battery wars. :P Dec 07 11:09:37 what is this no_lp thing... Dec 07 11:10:11 sure Dec 07 11:11:01 thats the "screen is on" scenario Dec 07 11:11:09 if its "screen off playing my music"... thats another matter Dec 07 11:11:26 a bit of amoled action and a nice dark theme... helpeth :) Dec 07 11:11:42 Yeah, that helps a lot. Dec 07 11:11:58 Though my phone isn't amoled. Dec 07 11:12:29 :( Dec 07 11:12:36 the samoleds are gorgeous Dec 07 11:12:38 i have to say Dec 07 11:12:44 tho they suffer from burn-in Dec 07 11:12:57 and pentile is just plain offensive Dec 07 11:12:58 The LG IPS displays are also pretty sexy. Dec 07 11:13:09 well offensive to me Dec 07 11:13:16 :) Dec 07 11:13:17 the s2 was the only one to get it right so far Dec 07 11:13:38 tho the s3 is getting into "totally silly" dpi land so it begins to all just vanish in the blur :) Dec 07 11:15:05 No DPI is silly, it just needs marketing fluff comparing it to your ocular anatomy and suddenly it's "innovative". Dec 07 11:15:09 Duh. Dec 07 11:15:26 hahaha Dec 07 11:15:40 sure Dec 07 11:15:46 hmm Dec 07 11:15:53 time to go home and see if my rotate works... Dec 07 11:15:55 or non-rotate Dec 07 11:16:06 enough sshying twice acorss the pacific to talk to my nexus7 Dec 07 11:19:13 infinity, http://paste.ubuntu.com/1416620/ Dec 07 11:22:14 is there a bot in here that keeps track of the last time someone said something? Dec 07 11:22:21 nope Dec 07 11:22:26 ogra_: That's an inverse optimisation for the less likely case. Dec 07 11:22:57 hmm Dec 07 11:24:51 ogra_: Dropping the block at the top with the exit would solve that, ish. Dec 07 11:25:07 ogra_: Forking grep for every core is a bit much too, though. Dec 07 11:25:14 not really, let me think about something where we dont run grep all the time :) Dec 07 11:33:13 ogra_: fork-free version: http://paste.ubuntu.com/1416644/ Dec 07 11:33:52 awesome Dec 07 11:33:56 let me test that Dec 07 11:36:42 Seems to DTRT here in some quick testing with governors I actually have. Dec 07 11:37:35 yeah, rebooting the nexus now Dec 07 11:38:08 is raring usable now on the nexus7? Dec 07 11:38:28 it has issues and bugs but isnt much worse than 12.10 was Dec 07 11:39:49 ogra_: On a side note, I find that once you wrap your head around "while read foo; do ...; done < /file", it becomes a claw hammer to remove many a shell-forking nail. Dec 07 11:40:11 yeah Dec 07 11:41:01 i was thinking about how to use case here ... "while read" wasnt striking me though :) Dec 07 11:41:06 then I may flash raring, instead of using quantal as I do now... Dec 07 11:42:02 gurgalof, there are some input issues with onboard in the graphical installer where you cant type into text fields, for some people it works to reboot the device if that happens Dec 07 11:42:17 thats the only blocker i currently know about Dec 07 11:42:42 ogra_: Actually, being a single line file, the while loop is unnecessary. Dec 07 11:42:52 ogra_: Though, upstream could always make it multiline just to prove me wrong. :P Dec 07 11:42:57 heh Dec 07 11:43:01 unlikely though Dec 07 11:43:51 ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Dec 07 11:43:51 interactive Dec 07 11:43:51 interactive Dec 07 11:43:51 interactive Dec 07 11:43:51 interactive Dec 07 11:43:53 great Dec 07 11:44:05 and raster was actually right, it feels a lot more responsive Dec 07 11:44:18 (finger scrolling in the browser actually got smooth) Dec 07 11:44:50 http://paste.ubuntu.com/1416666/ Dec 07 11:44:56 ^-- Ditching the while loop. Dec 07 11:45:06 And renaming the variable to something more readable. Dec 07 11:46:04 ogra_: Want me to upload this, if you're happy with the testing? Dec 07 11:46:08 ogra_: Is there a bug ref? Dec 07 11:46:08 case "$(cat $AVAILABLE)" in Dec 07 11:46:14 save you the read Dec 07 11:46:22 Err, but it forks cat. Dec 07 11:46:24 no bug ref, nope Dec 07 11:46:28 read is a builtin. Dec 07 11:46:31 Which was the point. Dec 07 11:46:32 oh,. fork free, indeed Dec 07 11:46:42 heh Dec 07 11:46:47 yeah, go ahead and upload Dec 07 11:47:10 raster just came up with it during conversation, there was no time for a bug :) Dec 07 11:48:45 case $governors in Dec 07 11:48:45 *conservative*) Dec 07 11:48:45 GOVERNOR="interactive" Dec 07 11:48:45 break Dec 07 11:48:45 ;; Dec 07 11:48:55 infinity, better dont upload it that way :) Dec 07 11:49:14 Yeah, that was me testing. :P Dec 07 11:49:18 guessing you want to match interactive for interactive Dec 07 11:49:23 :) Dec 07 11:49:26 (Since I don't have interactive). Dec 07 11:49:34 But I appreciate the review concern. :) Dec 07 11:49:48 your manager should really give you one of the nexuses he sits on :P Dec 07 11:51:12 ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Dec 07 11:51:12 userspace Dec 07 11:51:14 hrm Dec 07 11:52:05 ogra_: I have one, but I was iterating on the laptop cause, well, laptop. Dec 07 11:52:16 ah Dec 07 11:52:21 well, it didnt work here Dec 07 11:52:42 Oh. You mean, even after fixing it, it doesn't do anything? Dec 07 11:52:54 it is set to userspace Dec 07 11:53:04 which the kernel defaults to Dec 07 11:53:05 That's odd, since if you neuter the echos and test it, it does exactly what it used to (except for adding interactive as an option). Dec 07 11:53:12 (performance makes it hang) Dec 07 11:53:19 Does that mean it wasn't set to ondemand before either? Dec 07 11:53:26 it was Dec 07 11:54:20 * ogra_ doesnt see any paste errors or typos Dec 07 11:54:24 (base)adconrad@cthulhu:~$ ./ondemand background Dec 07 11:54:25 echo -n interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Dec 07 11:54:25 echo -n interactive > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor Dec 07 11:54:25 echo -n interactive > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor Dec 07 11:54:25 echo -n interactive > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor Dec 07 11:54:45 Don't make me reflash my N7 at 5am to test this... Dec 07 11:55:09 I guess I may as well. Dec 07 11:55:23 nah Dec 07 11:55:32 Nah, I have to get a recent image on it anyway. Dec 07 11:55:35 This is a fair excuse. Dec 07 11:55:41 And I want to know why this fails. Dec 07 11:55:51 i'm running a set -x atm Dec 07 11:55:59 but missed to take out the sleep 60 :P Dec 07 11:56:03 bah Dec 07 11:56:41 The only thing I can think is that AVAIL points to nowhere on your device. Dec 07 11:57:03 http://paste.ubuntu.com/1416687/ Dec 07 11:57:39 weird Dec 07 11:57:47 why didnt it work at boot then Dec 07 11:57:50 That looks right... Dec 07 11:57:56 yeah, it is Dec 07 11:58:02 * ogra_ reboots again Dec 07 11:58:49 oh, wait ! Dec 07 11:58:52 ? Dec 07 11:58:54 heh Dec 07 11:58:59 i was likely to fast Dec 07 11:59:04 there is that sleep 60 Dec 07 11:59:13 Oh, you may have checked too early? Dec 07 11:59:16 Derp. Dec 07 11:59:22 ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Dec 07 11:59:22 userspace Dec 07 11:59:31 * ogra_ twiddles thumbs for a minute Dec 07 11:59:49 ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Dec 07 11:59:49 interactive Dec 07 11:59:51 HA ! Dec 07 11:59:53 Why is it that, even though I own about 400 micro USB cables from my Nokia days, I can never find one? Dec 07 12:00:09 Okay, panic averted, this works? Dec 07 12:00:13 yep Dec 07 12:00:19 just the silly sleep Dec 07 12:00:43 i guess though, we could also solve that on a kernel level Dec 07 12:00:43 Uploaded, then. Dec 07 12:01:01 we cant run performance by default on boot anyway Dec 07 12:01:08 We could default the kernel to interactive, but this is still "more right" for all devices, IMO. Dec 07 12:01:16 so instead of pointing to userspace we could as well just default to interactive Dec 07 12:01:30 oh, yeah, toitally independent from that fix Dec 07 12:01:33 If/when interactive gets mainlined, this is what I want ondemand doing. Dec 07 12:01:57 Doesn't "userspace" end up being "fully clocked until you do something to it" anyway? Dec 07 12:02:05 well, i wonder if preformance is broken because interactrive is there :) Dec 07 12:02:21 Yeah, it could just be that the code around performance is broken. Dec 07 12:02:29 since interactive seems to be an android thing Dec 07 12:02:48 but yeah, i think userspace behaves similar to performance Dec 07 12:02:54 if you dont touch it Dec 07 12:03:16 Right, then that's what we want on boot. Dec 07 12:03:21 That's why we have the 60s delay. Dec 07 12:03:32 Suck battery while booting, but get it done quick and without scaling getting in the way. Dec 07 12:03:34 Then scale. Dec 07 12:03:36 yep Dec 07 12:03:54 hmm, so should i ship a default-settings file for the SD card sysctrl Dec 07 12:03:59 # Default Read Ahead value for sdcards Dec 07 12:03:59 write /sys/block/mmcblk0/queue/read_ahead_kb 2048 Dec 07 12:03:59 write /sys/block/mmcblk1/queue/read_ahead_kb 2048 Dec 07 12:04:06 thats what the android init script sets Dec 07 12:04:43 i wonder if we should make that generic, i see that value used in BSPs since years Dec 07 12:05:17 I wouldn't be against that being true for every system. Dec 07 12:05:24 At which point, it probably belongs in all the kernels. Dec 07 12:05:26 not sure how it affects i.e. a vfat card from a camera on x86 though ... i.e. if you dont run your rootfs from the SD Dec 07 12:05:34 But I'm not opposed to a global sysctl hack for now. Dec 07 12:06:10 I'd think it would improve typical VFAT usage too, since those are usually large (ish) files. Dec 07 12:06:17 true Dec 07 12:06:33 Oh bah. There's no raring version of the nexus7-installer PPA. Dec 07 12:06:49 its 5 cmdline commands to flash Dec 07 12:07:07 Yeah, I wanted to try this the "blessed" way for once, instead of being a hack. Dec 07 12:07:11 wget/zsync the img.gz and bootimg ... Dec 07 12:07:22 unzip it to get an img Dec 07 12:07:30 I full well know how to do it the hack way. :) Dec 07 12:07:35 oh, ok Dec 07 12:07:44 i dont think ita a hack way :) Dec 07 12:07:53 its my preferred way ;) Dec 07 12:07:59 It's a hack if it's not what we tell other people to do. Dec 07 12:08:18 well, its just what the zenity shell script does in the backend Dec 07 12:08:34 Bah, and this version of fastboot doesn't ship with a sane udev rule, does it? Dec 07 12:08:40 * infinity grumps about having to be root. Dec 07 12:08:54 you dont if you have the udev rules installed Dec 07 12:09:06 wow, interactive is way faster, just had to try... Dec 07 12:09:07 we'lll ship them with usb-creator later Dec 07 12:09:41 ogra_: Yes, I don't if I have the udev rules installed, which I don't. That was my point. :P Dec 07 12:09:55 heh Dec 07 12:09:59 Cause android-tools-fastboot only has /usr/bin/fastboot Dec 07 12:10:14 We had an old fastboot package from elsewhere that had pretty udev rules. Dec 07 12:10:35 the installer has the udev rules since we switched to the debian packaged fastboot Dec 07 12:10:37 hmm.... Dec 07 12:10:46 * xnox wonders where I lost those. Dec 07 12:10:47 Hrm, does it? Dec 07 12:10:56 Oh, maybe this is because I plugged it in before installing the packages. Dec 07 12:11:04 that might be Dec 07 12:11:23 Nope. Dec 07 12:11:24 iirc it is supposed to run root-less Dec 07 12:11:30 so it needs the rules Dec 07 12:12:09 ogra_: no udev rules in android-tools-fastboot from the mirror. I think I may have lost them somewhere, as I sure have to be root when flashing =/ Dec 07 12:12:37 xnox, well, we could add them to fastboot Dec 07 12:12:49 No udev rule in the installer package either. Dec 07 12:12:51 ogra_: can you point me to where I can find those? Dec 07 12:13:18 I can fish my udev rules off my old laptop. Dec 07 12:13:29 * ogra_ is looking Dec 07 12:15:38 SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", TAG+="udev-acl" Dec 07 12:15:58 SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d001", TAG+="udev-acl" Dec 07 12:16:06 something like that shoudl work Dec 07 12:17:27 probably even only the first line, the second one is for detecting the device in recovery mode iirc Dec 07 12:18:14 (while the first one is for flash mode) Dec 07 12:18:50 Hrm, I seem to have misplaced my old android/fastboot rules. Dec 07 12:18:57 I guess the above works. :P Dec 07 12:26:27 * ogra_ goes for a break Dec 07 12:32:37 it would be nice witch hardware accel in firefox Dec 07 12:32:59 now it says "GLXtest process failed" Dec 07 12:33:15 in about:support Dec 07 12:36:28 chrisccoulson: ping? Dec 07 12:44:24 chrisccoulson: well, you'll find out soon enough :-p Dec 07 12:44:37 mjrosenb, hi, what's up? Dec 07 12:46:55 chrisccoulson: ahh. i've heard that you are responsible for firefox on ubuntu/arm? Dec 07 12:47:15 i'm responsible for firefox. not specifically on arm though Dec 07 12:47:59 ahh. Dec 07 12:48:54 so, in about a month, we're going to be putting out 18, which will have ionmonkey as part of its js engine Dec 07 12:49:26 and it doesn't have hardfp support yet. Dec 07 12:55:46 mjrosenb, it's still possible to run it on systems that provide hardfp though, isn't it? Dec 07 12:56:05 we have 18.0 builds already, and nobody has mentioned that they don't work yet :) Dec 07 12:56:43 you'd need to either turn off the new jit, or grab the patch that i'll be landing today... for 20.0 Dec 07 12:57:30 Can I force unaligned memory access on armhf port because a very silly application that wants unaligned memory access. Dec 07 12:57:33 chrisccoulson: I'm not horribly surprised, since the calling conventions are the same for functions that only take integers or values Dec 07 12:57:59 And what are the consequences of unaligned memory access for other applications? Dec 07 12:58:02 chrisccoulson: but they differ when passing doubles, and I suspect on pages like slashdot, you don't call math.pow() that frequently Dec 07 12:58:35 xnox: Uhm, what? Dec 07 12:58:40 xnox: Fix the silly code. Dec 07 12:59:33 mjrosenb, ah, i've just noticed there's quite a lot of test failures on our armhf builds Dec 07 13:00:15 Yeah, there would be. Dec 07 13:00:20 infinity: oh, it's not a bug, but an "architecture design feature" they load memory mapped files from disk and do loads of crazy things. Dec 07 13:00:56 xnox: Sounds like a bug to me, still. Dec 07 13:00:56 mjrosenb, hopefully we'll notice these in the future, as i'm working on exposing test results via https://jenkins.qa.ubuntu.com/ ;) Dec 07 13:01:13 xnox: Given the number of platforms that just plain Won't Work on, that's unportable to the extreme. Dec 07 13:01:22 xnox: And probably also slower on x86 than it needs to be. Dec 07 13:01:54 morning Dec 07 13:01:56 chrisccoulson: how are you running the tests? Dec 07 13:03:47 infinity: the package in question is mongodb =))) Dec 07 13:04:07 xnox: Yeah, mongodb in unportable code shocker. Dec 07 13:04:26 xnox: They're the same upstream that spent a year saying "we only support x86, cause everything else is toooo haaaard". Dec 07 13:04:53 mjrosenb, we're packaging most of the tests and running them on an installed system Dec 07 13:05:06 * xnox goes away to write some portable C Dec 07 13:05:34 chrisccoulson: firefox has like 10 testsuites :-p Dec 07 13:06:25 mjrosenb, yeah, we're doing it with all of the xpcshell tests, reftests, crashtest, js tests and mochitests. but we run everything that normally runs during make check as part of the build Dec 07 13:06:57 cool. Dec 07 13:07:44 chrisccoulson: random note: I found that using gold with xpcshell on arm generated an xpcshell that is incapable of running. Dec 07 13:08:24 mjrosenb, ah, i've not tried using gold yet. i just build it with our defaults. thanks for letting me know though Dec 07 13:09:29 mjrosenb, so, i guess for pre-firefox 20 builds we should be using --disable-ion on armhf? Dec 07 13:10:05 of course, it might just be something else related to my setup. Dec 07 13:10:25 chrisccoulson: that is probably a good idea, unless you want to backport this patch. Dec 07 13:10:57 mjrosenb, i finish for the rest of the year today, so i'll probably go with the easy option for now :) Dec 07 13:11:49 https://bugzilla.mozilla.org/show_bug.cgi?id=802358 Dec 07 13:11:51 Mozilla bug 802358 in JavaScript Engine "IonMonkey: (ARM) Add support for hardfp" [Normal,New] Dec 07 13:11:53 there we go Dec 07 13:12:29 Reasonably simple patch. Dec 07 13:12:38 I'd go for backporting it so we can get some testing, personally. Dec 07 13:13:34 mjrosenb, thanks Dec 07 13:14:17 chrisccoulson: not a problem. Dec 07 14:03:42 ogra_: ping Dec 07 14:06:59 sfeole, whats up ? Dec 07 14:07:20 ogra_: hey, any word on the brcm-patchram for raring? Dec 07 14:07:43 not sure yet, its an evil hack Dec 07 14:08:08 is that being tracked somewhere in LP ? Dec 07 14:08:32 just so i dont have to keep pestering you ;P Dec 07 14:08:59 not that i know of, i know there was some upstream work to support patchram Dec 07 14:11:22 bug 1065400 Dec 07 14:11:22 Launchpad bug 1065400 in linux (Ubuntu Raring) "Support for loading Broadcom bluetooth firmware" [Medium,In progress] https://launchpad.net/bugs/1065400 Dec 07 14:11:35 sfeole, ^ Dec 07 14:11:41 ogra_: sweet thx Dec 07 14:13:18 it might need a newer kernel than we have on the nexus though Dec 07 15:08:17 ogra_, so we will hod our weekly un7 meeting in 50 minutes. mostly status updates. Dec 07 15:08:37 yep, np Dec 07 15:08:41 thanks Dec 07 16:02:57 nexus7 meeting is in #ubuntu-meeting right now Dec 07 16:46:25 xnox, so originally i thought i would like ot keep the two file approach, simply to make manual flashing easier (having to unzip the img.gz is already annoying) .... but noticing that even infinity preferred the installer script i might reconsider my attitude here Dec 07 16:47:42 ogra_: I was chatting with vanhoof the other night. How about publishing just a single tarball, which has: individual bits to construct boot img + userdata squashfs. Dec 07 16:48:03 and then do the whole sparse image packaging client side & constructing the boot image. Dec 07 16:48:15 i dont want to put to much local processing in Dec 07 16:48:29 currently you could flash from windows Dec 07 16:48:45 we would lose that opportunity Dec 07 16:49:00 (or from fedora or suse) Dec 07 16:49:46 so i prefer to have ready made images .... i donw mind to repack them on the fly, but the generic image we offer should just be flashable from any fastboot install you have imho Dec 07 16:49:56 ogra_: ok. Dec 07 16:50:18 ogra_: just trying to figure out the easiest way to resize is the tricky part, its easy w/ the tarball, suppose we could unpack/rebuild Dec 07 16:50:47 and /me didnt notice xnox was building -fsutils now (thanks xnox for the update in the ppa btw!) Dec 07 16:51:19 right, we would need make_ext4fs Dec 07 16:51:20 ogra_: so a tarball of bootimg & userdata? can we still publish just the user-data tarball as well? (the way some images publish their inner squashfs) Dec 07 16:51:26 ans simg2img Dec 07 16:51:44 *and Dec 07 16:51:54 for the repacking to larger sizes, while still by default offering "flash & go" Dec 07 16:52:01 xnox, well, i can just tar up both files in debina=cd, thats most trivial Dec 07 16:52:13 *debian-cd Dec 07 16:52:24 ogra_: don't the simg2img require target space size (8GB?!) =/ Dec 07 16:52:49 not that much Dec 07 16:52:54 its still a sparse img Dec 07 16:53:09 but yeah. you require some space for repacking Dec 07 16:53:11 and root Dec 07 16:53:35 you need to loop mount the img, copy the tarball somewhere and call make_ext4fs on that Dec 07 16:53:52 ogra_: by "packing both files" do you mean the download will be ~ double the current size and contain: bootimg, userdata.img, userdata-just-tarball? Dec 07 16:54:12 bootimg and img.gz in one tarball Dec 07 16:54:24 ogra_: yeah, but I can't loop mount simg, and img is 100% the size. Dec 07 16:54:29 ogra_: ah, ok. Dec 07 16:54:39 ogra_: why .gz? Dec 07 16:54:48 size ... :) Dec 07 16:54:52 saves 100M Dec 07 16:54:55 saves ~100m iirc Dec 07 16:55:00 tar.gz: boot.img & img.gz Dec 07 16:55:09 we wont need that if we wrap a tar.gz around it Dec 07 16:55:19 i guess Dec 07 16:55:27 i'll do some tests on the weekend Dec 07 16:55:37 how much size differs Dec 07 16:56:01 also note that i'm not sure the image will be flashable in its current state if you resize it Dec 07 16:56:18 i fear it will get to big to be flashed without -S switch to fastboot Dec 07 16:56:47 fo that we have a plan but nobody worked on it yet ... Dec 07 16:57:14 (using tar.xz instead of tar.gz for the internal tarball( Dec 07 16:58:15 doing that will need some work on cdimage/debian-cd that i wont manage to do before end of the year though Dec 07 16:58:20 ogra_: to what extend have you tried the bog standard mkfs.ext4 and tweaking it's settings? to the point that it doesn't ever work with img2simg, or it's too big, or you tried every mkfs.ext4 option to try to reduce the size and it was still too big? Dec 07 16:58:37 its way to big Dec 07 16:58:39 ogra_: tar.xz is interesting. Dec 07 16:58:45 like 200m bogger than fsutils Dec 07 16:58:52 *bigger Dec 07 16:58:54 argh. Dec 07 16:59:19 i think the tar.xz way is best Dec 07 16:59:34 but for that we need to re-write the image creation stuff quite a bit Dec 07 17:00:12 (xz compression is to slow to run on the live builder, builds already take over 2h) Dec 07 17:01:24 (currently the whole build is done by live-build, we need to move 50% out of that and into debian-cd) Dec 07 17:03:43 xnox, i think targeting the usb-creator bits for alpha2 should be fine and not put to much pressure on us Dec 07 17:04:01 until then vanhoof's installer will serve us fine Dec 07 17:04:21 (A2 is due on feb 7th) Dec 07 18:17:21 sfeole, hmm, was that mail actually supposed to go to canonical-tech ? (sounds more like it was intended for ubuntu-devel tbh) Dec 07 18:23:58 ogra_: I don't think it hurts sending to canonical-tech, I was just doing it as a general announce. There have been many emails like that in the past to CT. Dec 07 18:24:25 well, i think we should make the info a bit more widely known :) Dec 07 18:26:36 ogra_: Sure! I will forward to ubuntu-devel as well Dec 07 18:26:46 ++ Dec 07 18:26:49 :P Dec 07 18:26:53 enjoy your vaca btw Dec 07 18:27:02 have a safe rest-of-2012 Dec 07 18:27:05 * ogra_ will blog on the weekend so it goes on planet as well Dec 07 18:27:25 heh, dont think you will get rid of me for the rest of the year :) Dec 07 18:27:42 * ogra_ will be around on IRC and surely work on non work related projects Dec 07 18:28:01 i dont really feel like doing vacation ... its just a formal thing to burn the days Dec 07 18:44:03 ogra_: you never know, the mayan's could be right ;) Dec 07 18:44:54 they just used too small data type for their timestamp Dec 07 18:45:11 lol, yeah i was saving the buying of xmas presents for the 22nd this year Dec 07 18:45:20 just to be sure Dec 07 18:45:35 best idea i heard all day! Dec 07 18:52:05 *snicker* Dec 07 22:48:48 vanhoof: hi, i'm lazy and jetlagged. where can i download a copy of the installer that would run on precise? :) Dec 07 22:49:28 achiang: same place as always Dec 07 22:49:50 apt-get install ubuntu-nexus7-installer Dec 07 22:49:56 you'll get 1.7~p Dec 07 22:50:13 rad Dec 07 22:50:36 the ~{p,q,r} are just rebuilds of the same bits for diffrerent series Dec 07 22:50:44 so anyone can install from the ppa Dec 07 22:51:00 sfeole and bjf asked that I upload a ~r today Dec 07 22:52:28 ah, i don't have the ppa in sources.list Dec 07 22:52:44 * achiang goes to download the .deb :) Dec 07 22:52:48 vanhoof: When is the installer going to switch to installing raring by default? Dec 07 22:53:01 infinity: 8 hours ago Dec 07 22:53:05 Hah. Dec 07 22:53:07 :) Dec 07 22:53:08 Nice. Dec 07 22:53:23 Did you update the wiki to reflect that? Dec 07 22:53:37 infinity: believe sfeole did, but ill check Dec 07 22:53:50 Yup, apparently so. Dec 07 22:54:24 Though, it now has "Installing 13.04" twice. Maybe the second section should have a "Manually" prepended. :P Dec 07 22:54:27 infinity: figured w/ the changes that landed today, its a good time to move folks to raring for new installs vs the quantal image at UDS Dec 07 22:54:37 Been using raring images for a few days now. It's quite usable and will be even more so once that button1 stuck bug is fixed. :) Dec 07 22:55:12 The raring images should get much more responsive as of my initscripts change earlier this morning. Dec 07 22:55:56 infinity: what changed there? Dec 07 22:56:01 http://launchpadlibrarian.net/125105308/sysvinit_2.88dsf-13.10ubuntu13_2.88dsf-13.10ubuntu14.diff.gz Dec 07 22:56:41 Android kernels have a shiny new governer that behaves a bit more pleasantly than ondemand. Dec 07 22:56:54 Kinda hoping this lands in mainline sometime, my laptop would be much happier. Dec 07 22:56:56 interesting. upstream has been recommending ondemand for a long time Dec 07 22:57:17 Which upstream? Dec 07 22:57:33 lkml? Dec 07 22:57:49 Well, lkml isn't really relevant here, interactive isn't in mainline. Dec 07 22:58:00 ondemand is the best we've got on non-Android kernels. Dec 07 22:58:54 infinity: did you test interactive vs ondemand for power consumption? Dec 07 22:59:41 No, if it proves horrible, we can revert. Dec 07 22:59:47 achiang: got some feedback from our 32G+3G folks as well, they're happy with 1.7 as well Dec 07 23:00:00 It's the default governor on most Android devices, though, and they seem better at power than we are. :P Dec 07 23:01:12 * achiang just has latent suspicion of all governors !ondemand but maybe that's outdated knowledge by now Dec 07 23:04:08 infinity: if you give a new install a whirl lmk Dec 07 23:04:56 vanhoof: Probably not today. I've been up and working since midnight or so. :P Dec 07 23:05:21 yeah i know i slept last night but i swear you're in every hour of scrollback somewhere :) Dec 07 23:06:41 I try for 24/7 coverage. Dec 07 23:08:22 infinity: well you made diwic happy w/ his pa upload today :) Dec 07 23:08:26 so infinity++ :D Dec 07 23:37:41 cool, from 0% to 12% battery. maybe i can try an install now :) Dec 07 23:43:29 achiang: lmk how it goes Dec 08 00:20:52 vanhoof: all went well, going through oem-config now Dec 08 00:23:48 cool Dec 08 00:24:09 i got through it no probs a few times Dec 08 00:24:12 you should be all set Dec 08 00:25:06 achiang: screen /dev/ttyACM0 115200 ... once you're done Dec 08 00:25:09 * vanhoof is in heaven Dec 08 00:26:19 what's that, debug console? Dec 08 00:26:26 yup Dec 08 00:26:33 usb/serial Dec 08 00:26:48 full console even Dec 08 00:27:16 whee, i'm on R Dec 08 00:27:21 machine name is 'mfer' Dec 08 00:27:21 ;) Dec 08 00:27:27 lol Dec 08 00:27:50 what's new and shiny for me to play with? Dec 08 00:28:29 plymouth, usb-serial, an actual panel, oem-config? :) Dec 08 00:28:38 ah, the answer is "nothing" because i hit the button1 stuck issue Dec 08 00:28:39 feh Dec 08 00:29:19 you're landscape? Dec 08 00:29:26 yeah Dec 08 00:29:29 * vanhoof must have small fingers Dec 08 00:29:40 i dont hit that often :) Dec 08 00:30:47 achiang: if you get bored play w/ sound Dec 08 00:31:03 i had some troubling noises today playing radio w/ rb Dec 08 00:31:15 not sure if its my own breakage Dec 08 00:33:03 achiang: but now you have dailys to flash ;) Dec 08 00:33:22 from here on out, it's dist-upgrade every day, baby Dec 08 02:14:23 * sfeole reads scrollback Dec 08 02:16:02 achiang, vanhoof , infinity : Yea guys, I went on a wiki updating rampage today. sort of sloppy but got the job done. Everything should be up there, updating instructions / new features / some bug updates etc... Dec 08 02:16:10 * sfeole goes back into his cave Dec 08 02:20:24 also i fixed the 2nd heading for installed 13.04 on the nexus7, looks like my draft never saved. Dec 08 02:21:02 it now says "Manually Installing... blah blah" **** ENDING LOGGING AT Sat Dec 08 02:59:59 2012