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