| === Sarvatt_ is now known as Sarvatt | ||
| === bizkut-miau is now known as bizkut-redhat | ||
| shenki | armin76: o/ | 03:06 |
|---|---|---|
| shenki | asac: so you need to build for armv7 but no neon? | 03:06 |
| shenki | fta: isn't the localtime bug (the one you were referring to as the javascript bug) fixed in newer versions of the nivia driver? | 03:07 |
| persia | Anyone ever heard of "xpg3sh" as a shell? | 03:46 |
| asac | shenki: hi | 09:04 |
| asac | shenki: still there? | 09:04 |
| shenki | asac: yeah | 09:04 |
| asac | shenki: yes. if such a disable_neon=1 flag would magically appear in gyp I would start to cry ;) | 09:04 |
| shenki | okay, i will write the patch | 09:04 |
| asac | there are a few other things that need to get fixed | 09:05 |
| shenki | asac: why do you need this? | 09:05 |
| asac | we dont have NEON on armv7 | 09:05 |
| asac | because not all armv7 things support that | 09:05 |
| persia | Hrm? I thought it was only available on *some* armv7, rather than none. | 09:05 |
| shenki | ok, so some non-cortex chipset? | 09:05 |
| asac | yes ... also old cortex chipsets have issues - like CPU hangs etc. - I was told | 09:06 |
| shenki | hrm. i wonder if this stuff should be runtime-dependant, like the ffmpeg sse asm | 09:06 |
| asac | i asked for that in the bug | 09:06 |
| shenki | which bug is this? | 09:06 |
| asac | cant remember who replied, but that guy said that chromium doesnt want it | 09:06 |
| asac | one sec | 09:06 |
| asac | http://code.google.com/p/chromium/issues/detail?id=30991 | 09:07 |
| persia | Wasn't there a couple chips that claimed NEON support, but it didn't work? I thought I saw a bug about that. | 09:08 |
| asac | not sure. in the end it boils down to NEON not working eeverywhere ;) | 09:09 |
| asac | thats why we ended up with this approach | 09:09 |
| persia | Well, yeah. I'm just not even sure it's safe to do runtime-detect (like for altivec) | 09:09 |
| shenki | asac: so what floating point hardware do these boards have? | 09:10 |
| shenki | ah, the dove ones. i should read the entire bug. | 09:11 |
| shenki | 43 celcius here today, brain is suffering | 09:12 |
| asac | i thÃnk you have no specialized code for those atm | 09:12 |
| asac | heh. thats 50 hoter than here ;) | 09:12 |
| asac | are you in the outback ;)? | 09:12 |
| shenki | heh, nup. i leave next to the sea | 09:12 |
| shenki | s/leave/live | 09:13 |
| * asac thinks it must be near a desert :) | 09:13 | |
| asac | only 48 ... its -5 atm | 09:13 |
| shenki | nice. i was looking at footage of england on the news, the entire landmass covered in snow. a world away. | 09:14 |
| asac | we also need http://code.google.com/p/chromium/issues/detail?id=31274 | 09:19 |
| asac | and -fno-tree-sink for gcc44_version=1 http://code.google.com/p/chromium/issues/detail?id=31063 | 09:19 |
| asac | (or -fstrict-aliasing) | 09:19 |
| asac | shenki: ^^ | 09:20 |
| shenki | ok | 09:20 |
| shenki | woah, how did you build v8 with strict aliasing turned on? | 09:23 |
| shenki | it used to not build with that... dtoa.c was the main culprit, but there was other issues iirc | 09:23 |
| asac | shenki: it just builds ;) | 09:31 |
| asac | w dont run the test suite | 09:31 |
| asac | but the resulting binary worked well too | 09:31 |
| shenki | there you go | 09:32 |
| asac | in which direction :-P? | 09:33 |
| ogra | mind the walls ! | 09:33 |
| shenki | ha | 09:33 |
| asac | anyone awake with a dove board? | 09:44 |
| asac | persia: how did the lsb lib packaging mess work out last night? | 09:50 |
| asac | i saw things about /opt etc ;) | 09:50 |
| persia | tet-harness is complete. Haven't yet determined if it's sufficient to build t2c-harness yet. | 09:53 |
| persia | s/yet/ | 09:53 |
| asac | super | 09:56 |
| asac | persia: do you have a qemu chroot? | 10:02 |
| asac | that works quite well for stuff not too big | 10:02 |
| persia | I have hardware :) Can't run a karmic or lucid kernel, but chroots are fine for building. | 10:03 |
| persia | The issue is more the complete lack of documentation on t2c-harness, rather than anything else. The docs about t2c-harness talk about t2c-desktop, and the instructions for t2c-desktop don't actually do the expected stuff for t2c-harness. | 10:04 |
| persia | Plus, almost none of the code is actually licensed :) | 10:04 |
| persia | But I do have a patch to make t2c-harness build for arm: it's just a matter of fiddling to get a debian/rules that can build it. | 10:05 |
| asac | sounds like a perfect job ;) | 10:08 |
| * persia really prefers nice clean upstreams | 10:08 | |
| asac | that reminds me to poke ccheney ;) | 10:09 |
| persia | heh | 10:09 |
| asac | about ugly backports for rolling ffox 3.6 to hardy ;) | 10:09 |
| persia | Um, I don't want to know anything more about that. | 10:10 |
| asac | hehe... its actually about rolling lucid webkit to hardy ;) | 10:10 |
| asac | including all the gnome libs | 10:10 |
| asac | required for that mess | 10:10 |
| asac | better? | 10:10 |
| asac | ;) | 10:10 |
| persia | That's going to totally break some stuff. Like midbrowser. | 10:10 |
| persia | Just hope nobody with Ubuntu MID has backports enabled. | 10:11 |
| fta | shenki, yes, it's the one. there's already a patch: http://codereview.chromium.org/525109 | 10:24 |
| shenki | fta: okay. so ubuntu still ships old nvidia drivers? | 10:27 |
| fta | shenki, depends. we have several flavors. but as i do backports of chromium down to hardy, i have to workaround that bug | 10:28 |
| shenki | ah | 10:28 |
| shenki | i forgot that you build for old releases | 10:29 |
| === jmc93739653 is now known as jmc93739653_AWAY | ||
| fta | asac, d'oh! http://identi.ca/notice/18474703 | 11:07 |
| asac | ouch | 11:10 |
| armin76 | ricing fail | 11:16 |
| shenki | why do you guys have so much trouble getting it built :/ | 11:16 |
| shenki | looks like i was pretty lucky to have it run | 11:16 |
| ogra | because we live on the edge | 11:18 |
| shenki | :D | 11:18 |
| ogra | latest toolchain and compiler as well as the most modern build defaults have their costs | 11:19 |
| fta | asac, boooo, upgraded my desktop (karmic), same error | 11:33 |
| asac | ok ... escalation needed i guess | 11:33 |
| asac | would love to have a working tarball for the archive upload ;) | 11:34 |
| asac | :-P | 11:34 |
| asac | fta: you said that dev channel isnt updated anymore? | 11:34 |
| asac | maybe because of breakages like this? | 11:34 |
| asac | fta: gyp was NEWed by heroic seb128 btw | 11:35 |
| asac | i already filed a bug ;) | 11:35 |
| asac | bug 504716 | 11:35 |
| fta | no, the channels (mine) are no updated because they stopped maintaining the LATEST.txt file i use to get the revisions | 11:35 |
| fta | noT | 11:35 |
| ubot4 | Launchpad bug 504716 in gyp "debian/copyright incomplete" [High,Triaged] https://launchpad.net/bugs/504716 | 11:35 |
| asac | any info what they do now? | 11:35 |
| asac | or any official reason why they stopped that? | 11:35 |
| fta | not yet, internal discussions still going on | 11:36 |
| asac | also no reason? | 11:36 |
| fta | nope | 11:36 |
| asac | sigh | 11:36 |
| asac | would prefer to do uploads to archive from dev channel | 11:36 |
| fta | sure | 11:37 |
| asac | rather than random happy uploads | 11:37 |
| fta | but channels are obviously frozen atm | 11:37 |
| shenki | dev channel has started up again yesterday | 11:38 |
| fta | not in ubuntu | 11:38 |
| shenki | oh, your channels are frozen? | 11:38 |
| asac | imo they need to use the same resource that we use | 11:39 |
| asac | otherwise it will always end up like that | 11:39 |
| fta | shenki, yes, because http://src.chromium.org/svn/releases/LATEST.txt is frozen | 11:40 |
| asac | similar to mozilla build systems make install always being busted because they dont use it for their own builds | 11:40 |
| shenki | asac: where does your system differ? | 11:41 |
| asac | from what i understand google uses something internally to update the channels ... | 11:41 |
| asac | while LATEST was just for chromium | 11:42 |
| fta | yes | 11:42 |
| shenki | oh. they use svn to branch and release from those | 11:42 |
| shenki | those branches | 11:42 |
| asac | well all the DEPS revisions etc. | 11:42 |
| asac | all that info isnt available ... e.g. what revision of webkit they pull for a dev update etc. | 11:42 |
| asac | so we cannot produce sources matchine their chrome releases | 11:43 |
| asac | we can only build trunk ;) | 11:43 |
| shenki | okay. i thought that was fixed a while ago...there was a windows guy who kept asking for it | 11:43 |
| asac | yes, they introduced LATEST.txt | 11:43 |
| shenki | i used to have an awesome contact in the google team, he mentord me for the summer of code | 11:43 |
| asac | but as they seem to have stopped it i assume they didnt use the same ... e.g. it was just a secondary service for us | 11:44 |
| shenki | but he quit not long after, and i dont really know anoyne else on the team quite as well | 11:44 |
| asac | imo something they dont use will never be reliable enough | 11:44 |
| asac | yeah. but even then. thats probably a huge process internally | 11:45 |
| shenki | yeah | 11:45 |
| fta | shenki, i know a bunch of people there, they are working on the problem | 11:45 |
| asac | most likely someone loves their cool build system so much that they cannot move to something like LATEST | 11:45 |
| asac | but i have no idea whats the status or problems are ;) ... and given that it stalled just a few days ago, i am not yet panicking ;) | 11:46 |
| shenki | okay | 11:46 |
| asac | most likely fta noticed it before they noticed it ;) | 11:47 |
| shenki | are any of the ubuntu arm guys going to be at linux.conf.au? | 11:47 |
| asac | not that i know. when is that? | 11:47 |
| shenki | week of the 18th | 11:47 |
| asac | january? | 11:47 |
| shenki | in new zealand | 11:47 |
| shenki | yeah | 11:47 |
| asac | ah. so yeah. they guy wanting to go there was pulled into something more important ... | 11:48 |
| asac | so no. | 11:48 |
| shenki | ok | 11:48 |
| asac | is that particular important for arm? | 11:48 |
| asac | or just a conference you are attending and would like to meet? | 11:49 |
| shenki | the latter | 11:49 |
| asac | kk | 11:49 |
| fta | asac, http://paste.ubuntu.com/353424/ | 11:49 |
| asac | so it still works without sandbox? | 11:50 |
| asac | ;) | 11:50 |
| fta | ok, there's already a popular bug: http://code.google.com/p/chromium/issues/detail?id=31809 | 11:50 |
| * asac voted | 11:50 | |
| ogra | so plymouth dies | 12:17 |
| asac | yeah | 12:30 |
| asac | i think we can live with that for now | 12:30 |
| asac | also its not even seeded in desktop so there probably is a reason - maybe this? | 12:30 |
| ogra | might be | 12:42 |
| JamieBennett | oh, nice - http://www.engadget.com/2010/01/07/freescale-smartbook-prototype-is-a-dockable-tablet-we-go-hands/ | 13:29 |
| persia | nifty | 13:29 |
| persia | I remember playing with an old HTC device like that at the shop last year, but feared I'd lose the keyboard. This one looks a little bigger. | 13:30 |
| asac | plars: here ;) | 14:15 |
| plars | asac: so the uboot package version is useful? How if it is different from what's in flash? | 14:15 |
| asac | plars: for imx with bootfloppy the uboot package updates the bootloader on install/upgrade .. so there it should match | 14:16 |
| asac | i would think we are doing the same for flash on dove | 14:16 |
| asac | plars: does dove install update flash? | 14:17 |
| * asac has no dove | 14:17 | |
| plars | asac: the times I've updated uboot on dove before, it was through a tftp image | 14:17 |
| plars | manual process, though there may be a better way now | 14:17 |
| asac | plars: ok so for now i dont see that we can do anything different than getting the information we see at runtime | 14:18 |
| asac | we could mark uboot version as "MIGHT NOT BE RIGHT" | 14:18 |
| asac | one thing we could make happen is to pass parameters to the kernel | 14:18 |
| persia | Even if there is an mtd driver, and one can access the flash, it's tricky to determine useful information from binary blobs. | 14:18 |
| asac | that we can the read later | 14:18 |
| asac | like teach uboot to append stuff we want to know: XX_info_uboot_version=XXX | 14:19 |
| plars | asac: this might be a good one to defer till A3, when we have uboot support for imx51? | 14:19 |
| asac | yeah. i think so | 14:19 |
| asac | but we should clarify what info we need for that item | 14:19 |
| asac | currently there is just "uboot etc." :) | 14:19 |
| plars | certainly | 14:20 |
| plars | asac: something we should probably discuss is the review of tests on suspend/resume testing | 14:21 |
| plars | the summary data for most of them is filled in, a few NEEDINFO's still there | 14:21 |
| plars | but most are not the base tests | 14:21 |
| asac | let me check | 14:21 |
| plars | asac: https://wiki.ubuntu.com/Specs/Mobile/Lucid/ArmSuspendResumeTesting for the wiki page | 14:22 |
| asac | good lp is slow as hell for me atm ;) | 14:22 |
| plars | asac: heh | 14:22 |
| plars | asac: one of the items targetted for A2 was to review these with you and discuss which should be targetted to do this cycle | 14:22 |
| asac | plars: ok lets go through them and assign priorities | 14:22 |
| plars | asac: sounds good | 14:23 |
| asac | let me dumb what i think maybe update the wiki for things you agree: | 14:23 |
| asac | network -> high | 14:23 |
| persia | Are these two-level priorities, beyond the BASE, STD, EXTRA we already did? | 14:23 |
| asac | no ;) | 14:24 |
| asac | heh | 14:24 |
| asac | good | 14:24 |
| asac | so its done ;) | 14:24 |
| persia | I did that last month :) | 14:24 |
| plars | I wasn't part of the conversation on base, std, extra | 14:24 |
| asac | right. but you didnt put that in the prio column ;) | 14:24 |
| plars | so that was a question I had for you | 14:24 |
| plars | right | 14:24 |
| plars | I'll fix that | 14:24 |
| asac | i think memory is not high | 14:24 |
| plars | I was thinking that the intention could have been to have priority different from class | 14:25 |
| persia | Um, yes it is. | 14:25 |
| asac | its of course important | 14:25 |
| asac | but we cant test | 14:25 |
| persia | If a bank of memory doesn't come back, bad things happen. | 14:25 |
| plars | memory/ECC, my thoughts on this were to run [insert memory test here, TBD] while doing suspend/resume, see if anything ugly happens in the process | 14:25 |
| asac | besides general stability | 14:25 |
| persia | We can certainly test to make sure the amount of ram is the same. | 14:25 |
| persia | We can't test the subtleties. | 14:25 |
| asac | how do you run a memory test in a running system? | 14:25 |
| asac | but do we know that a problem would show up as "reduced amount of memory"? | 14:26 |
| asac | otherwise i am fine with that | 14:26 |
| plars | that sounds more reasonable | 14:26 |
| asac | for me it feels more likely that the system crashes :) | 14:26 |
| persia | I can't remember the command right now. There's one that shows you the detected physical memory map. | 14:26 |
| plars | asac: true, and things are using memory no matter what... should get tested implicitly to some degree | 14:26 |
| asac | right. what we could write is a script that fills up memory until OOM | 14:27 |
| asac | or something | 14:27 |
| asac | or just arbitrary use of something that uses lots of mem after resume | 14:27 |
| asac | we can certainly compare /proc/meminfo | 14:28 |
| asac | is that avail on arm | 14:28 |
| asac | ? | 14:28 |
| plars | yes | 14:28 |
| persia | Yep | 14:28 |
| plars | memtotal should match before/after suspend | 14:28 |
| persia | Right. That's enough of a test. | 14:28 |
| persia | Anything else is subtle | 14:28 |
| asac | ok | 14:29 |
| asac | we could run soimething that makes abit extensive use of mem | 14:29 |
| asac | but lets use the memtotal thing for now | 14:29 |
| plars | asac: I suspect that will be implicitly covered in some of the other tess | 14:29 |
| plars | tests | 14:29 |
| plars | for instance, video playback while suspend/resume | 14:30 |
| asac | yes, but crashes in there could easily come from graphics driver etc. | 14:30 |
| asac | so we have to be carefuly | 14:30 |
| asac | some memory intensive calculation algorithm would be a base test | 14:30 |
| asac | more we cant do | 14:30 |
| asac | audio devices -> the stream should resume where it stopped | 14:31 |
| asac | how can that be done? | 14:31 |
| asac | using aplay to play something we know how long it is | 14:31 |
| asac | and measure the time before suspend and after resume until it finishes? | 14:31 |
| asac | and then if the time is close enough we are done? | 14:31 |
| plars | asac: that has to be somewhat manual I'm afraid, ask the user to be aware that it doesn't start over, or suddenly skip to the end | 14:31 |
| persia | pacat and parec might be a test that more closely matches the audio subsystems in use. | 14:32 |
| asac | but we shouldnt use any high level app to rules out app bugs | 14:32 |
| plars | asac: user is going to have to listen for it anyway, aplay can't tell you if sound is actually still coming out | 14:32 |
| asac | right. but we can measure if it skipped something | 14:32 |
| asac | user still needs to provide feedback if there was sound after resume | 14:32 |
| persia | Can that just pull the standard test from the desktop hardware testing suite? | 14:33 |
| asac | is there such a test? | 14:33 |
| persia | Err, yes, but nevermind. | 14:33 |
| asac | lets not check how to implement it now | 14:33 |
| asac | but rather what we want | 14:33 |
| plars | yes, iirc it plays a tone and asks the user if they heard something | 14:33 |
| persia | We need to test that it doesn'T skip on suspend, not that it might break on suspend. | 14:33 |
| asac | right. but we want to check if things got skipped ... which i am not sure how that can be a suspend/resume problem | 14:33 |
| asac | at least not hardware/driver | 14:34 |
| asac | feels really like that skipping or starting over would be app prob | 14:34 |
| asac | is this spec supposed to cover that? | 14:34 |
| asac | if so we should use the default media player | 14:34 |
| plars | I recall that was one of the things that was mentioned as an interesting way to test it during the UDS session | 14:35 |
| asac | what way is that? | 14:35 |
| asac | using default media player? and getting manual confirm that the music continued? | 14:35 |
| asac | lets do that then | 14:35 |
| plars | if there was heavy skipping, starting over, etc | 14:35 |
| asac | ok lets do that | 14:35 |
| plars | even if it's an app problem... if it's something that doesn't normally happen, but only happens when returning from resume, then it's good to catch it here I think | 14:36 |
| asac | fan/cooling -> we dont have fans on arm, do we? | 14:36 |
| asac | thats not BASE imo | 14:36 |
| plars | I don't think it's *that* important to have microsecon. accuracy to determine if some amount of audio was skipped though | 14:36 |
| asac | cpufreq/voltage can be done by compraing /proc/cpuinfo i woul dhope | 14:36 |
| asac | plars: yes. lets implement that .. .asking the user if the music continued | 14:37 |
| asac | (explicitly saying: did it start over etc.) | 14:37 |
| plars | asac: so should we cancel fan/cooling? I haven't seen a fan on any of my arm procs so far | 14:37 |
| asac | move to EXTRA | 14:37 |
| asac | thats currently the dump that doesnt get implemented by us | 14:37 |
| plars | hmm | 14:37 |
| asac | ok for cpufreq test? | 14:38 |
| plars | no | 14:38 |
| plars | cpuinfo will not tell us that | 14:38 |
| plars | iirc, bogomips only gets calculated on boot, everything else there is pretty static I think | 14:38 |
| asac | ok. then you want to do what? see how long a algorithm takes with nice -MAX ? | 14:38 |
| asac | yes. but if there is cpufreq change on my intel/amd the output adapts e.g. for powersave | 14:38 |
| asac | if thats not good enough we should run something complex and see how long it takes with max prio | 14:39 |
| asac | and if it doesnt deviate consierably (like 20%) we are fine | 14:39 |
| asac | makes senes? | 14:39 |
| asac | i am spotting media playback in STD | 14:40 |
| asac | so how about really keeping the desktop test case for the audio devices test | 14:40 |
| asac | and doing the media player tihng we discussed there? | 14:40 |
| asac | PLUS video | 14:40 |
| plars | asac: you mean combining it? | 14:41 |
| asac | yes. e.g. the STD: media playback thing would get the high level app testing we discuss | 14:41 |
| asac | and the BASE one would be just the current test we already have | 14:42 |
| asac | e.g. BASE == hardware ... STD == application level | 14:42 |
| plars | asac: sounds good | 14:42 |
| asac | cool | 14:42 |
| asac | SD card removal during sleep | 14:42 |
| asac | for mounted devices | 14:42 |
| asac | ? | 14:42 |
| asac | without replug= | 14:42 |
| asac | ? | 14:42 |
| plars | that is what was discussed at UDS | 14:43 |
| asac | same for usb/usb ... isnt that covered by the BASE HID test? | 14:43 |
| plars | mounted, but should not be in use | 14:43 |
| asac | plars: ok so we want to see that removing mounted SD card during suspend gets unmounted on resume | 14:43 |
| plars | I wouldn't think that would be in base HID | 14:43 |
| asac | thats easy to check | 14:43 |
| asac | plars: the usb/usb thing? | 14:43 |
| plars | asac: right, usb | 14:43 |
| asac | why not? we have a bunch of usb stuff for HID | 14:43 |
| plars | asac: ah, I'm referring to USB block devices, not char | 14:44 |
| plars | usb char devs, such as kbd, mouse, etc would certainly be covered under HID | 14:44 |
| asac | ok so cant we make a generic "block device" removal + unmount test? | 14:45 |
| asac | e.g. combine that with the SD thing? | 14:45 |
| asac | anyway, if thats clear its ok to keep it | 14:45 |
| plars | asac: it would save us one test, but might muddy up the results | 14:45 |
| asac | we can figure that during implementation | 14:45 |
| asac | but checking for something being not in mount after resume is easy enough | 14:46 |
| plars | if the tester forgets to specify (we hope not, but still) then you know that there was either a problem with SD removal, or USB removal | 14:46 |
| asac | lets clarify on wiki that usb/usb is about block devices ... then i am happy | 14:46 |
| asac | STD:NAND/MTD -> i think that should go to extra unless we know whats going on | 14:46 |
| plars | agree | 14:46 |
| asac | for now i would think that NAND is only relevant during boot | 14:46 |
| asac | so it isnt even touched at resume/suspend | 14:47 |
| asac | cool lets move it down, maybe dropping that comment in there ... | 14:47 |
| persia | Um, depends on the device. | 14:47 |
| persia | NAND *is* the primary secondary storage on a number of devices. | 14:47 |
| persia | But the test is easy: just confirm you can read from the mtd | 14:48 |
| persia | writing is a bonus. | 14:48 |
| plars | persia: you have generic way of doing that? | 14:48 |
| asac | if you think its doable thats ok. is NAND a secondary storage on any of our supported devices? | 14:48 |
| asac | how do we detect NAND mounts? | 14:48 |
| persia | Umm... | 14:48 |
| asac | for me it feels like EXTRA ;) | 14:49 |
| persia | Fine. | 14:49 |
| asac | backlight ... no idea how to test that. for some devices we might be able to check the value in /sys/proc | 14:49 |
| persia | plars: I have a way that works on my hardware. No idea if it works on supported boards. | 14:49 |
| asac | add persia to the comments column ;) | 14:49 |
| persia | asac: Do any supported boards have built-in screens? | 14:49 |
| asac | no. but devices | 14:50 |
| asac | like smartbooks ;) | 14:50 |
| persia | Yeah, but it's a lot harder to test backlights when you can't see them. | 14:50 |
| plars | right, I don't have a way of testing it with anything I have at the moment | 14:50 |
| persia | I'd be happy to do a backlight test, if I had a kernel :) | 14:50 |
| asac | we can see them. we need a pegatron or something | 14:50 |
| asac | plars: manual would be only option | 14:50 |
| asac | imo its EXTRA too ;) | 14:51 |
| asac | maybe we can ask if chaning backlight after resume works still | 14:51 |
| asac | that would be more STD | 14:51 |
| plars | asac: fair enough, we can easily implement a manual test for it at the moment, and that can be adapted later if we have an improved way | 14:51 |
| asac | wireless soft switch is a none issue ... for instance NM resets that on resume ;) | 14:51 |
| asac | plars: so asking if changing backlight still works or if screen is still same brightness? | 14:51 |
| persia | asac: wireless soft switch is to confirm that NM *can* reset it on resume | 14:52 |
| plars | asac: both! | 14:52 |
| asac | the summary says its supposed to test if its the same | 14:52 |
| asac | problem is that we have a race | 14:52 |
| persia | Then drop it. Doesn't make sense to test that. | 14:52 |
| asac | but its doable | 14:52 |
| asac | we can compare rfkill info | 14:53 |
| asac | thats easily | 14:53 |
| persia | If it's easy, then nevermind. | 14:53 |
| asac | yes. lets keep it. rfkill compare ... and ensuring that its off in the end | 14:53 |
| asac | a) compare rfkill output from before suspend with before NM gets resume dbus call | 14:54 |
| asac | b) does NM reset it | 14:54 |
| asac | latter probably manually | 14:54 |
| asac | we can certainly do a) | 14:54 |
| asac | keyboard softswitches is probably ok. | 14:54 |
| asac | not sure if that is that important though ;) | 14:54 |
| asac | if they work its fine | 14:54 |
| asac | but thats covered by HID somewhat | 14:55 |
| plars | hmm... is there an easy automatic way to determine if caps/num, etc are set/unset? | 14:55 |
| asac | encryption engine? ... maybe for installs with encrypted home check if we can still read from home? | 14:55 |
| persia | I don't like the HID testcase. | 14:55 |
| asac | why? | 14:55 |
| persia | I think the thing to check is that putting power back on USB actually restores the device function. | 14:55 |
| persia | Not just removal during sleep. | 14:55 |
| plars | encryption engines I believe should be in extra | 14:55 |
| persia | I've had laptops where USB HID didn't work over suspend/resume. | 14:56 |
| plars | persia: so a better test you think would probably be just to see if they still work after resume? makes sense | 14:56 |
| persia | plars: Both make sense, but HID still working after resume is significantly more critical than being able to hotplug. | 14:57 |
| plars | agree | 14:57 |
| asac | encrypted home is a official install option. if that falls under encryption engine we should keep it in STD | 14:57 |
| persia | Because if some device has internal USB HID connections to, say, the keyboard, the end user isn't going to be able to reset it. | 14:57 |
| asac | persia: HID definitly covers that it still works | 14:58 |
| asac | its about replugging while asleep | 14:58 |
| plars | asac: I took encryption engine to refer to hardware special purpose processors that some devices may/may not have | 14:58 |
| asac | we can extend that test case to ask for not replug though | 14:58 |
| persia | asac: But I also want to test that it works when you don't do anything and sleep. | 14:58 |
| asac | plars: ok. then extra | 14:58 |
| plars | if we extend it to cover ecryptfs, then it's not hardware related at all | 14:58 |
| asac | persia: right. lets extend the test case ... add that to summary | 14:58 |
| persia | I thought encryption was about encrypted home too, which is why I put it in STD. | 14:58 |
| asac | plars: yeah. not sure if the fs thing would make use of those hardware things | 14:59 |
| asac | i would hope it does | 14:59 |
| persia | Not by default. | 14:59 |
| asac | but then i dont think we support hardware that has that? | 14:59 |
| persia | Well, at least usually. | 14:59 |
| asac | ok its EXTRA | 14:59 |
| plars | which is why I think it should be in extra | 14:59 |
| asac | i think bluetooth feels more like STD | 14:59 |
| asac | but thats not arm specific i would think | 15:00 |
| asac | plars: yes. thats fine | 15:00 |
| plars | nothing I have has bluetooth builtin | 15:00 |
| asac | ok lets just check what of extra might need to be std | 15:00 |
| plars | would need to add a dongle | 15:00 |
| asac | plars: right. i would expect that devices will have that usually though. so we should ensure that test cases are there | 15:00 |
| asac | its something the QA team probably also would wnat | 15:00 |
| persia | bluetooth is extra because it's not well supported for any arch right now (although it's getting there) | 15:01 |
| asac | well. its really important for us even if its not yet perfect ;) | 15:01 |
| asac | but its not really arch dependent, i agree | 15:01 |
| persia | And it'S not onboard for any supported boards. | 15:01 |
| asac | right. its not arm/hardware specific | 15:01 |
| asac | it would be a win for QA | 15:01 |
| asac | i am fine to keep it in extra | 15:02 |
| asac | just wonder if we should maybe ask QA team to implement it | 15:02 |
| asac | aka suggest it | 15:02 |
| persia | I think it's EXTRA in the context of suspend/resume | 15:02 |
| asac | yes | 15:02 |
| asac | fine with me | 15:02 |
| asac | anyone managed to keep track ;)? | 15:02 |
| persia | I think it would be good to add to the standard checkbox test suite | 15:02 |
| asac | right. lets file a bug and mark that as DONE then ;) | 15:03 |
| persia | The channel is logged, so we have notes :) | 15:03 |
| plars | asac: file what bug? | 15:03 |
| persia | plars: against checkbox asking for BT testing | 15:03 |
| asac | checkbox -> add bluetooth suspend/resume testcase | 15:03 |
| persia | No. | 15:03 |
| asac | wishlist | 15:03 |
| persia | checkbox gets bluetooth "does it work" testing | 15:03 |
| persia | suspend/resume gets bluetooth as EXTRA | 15:04 |
| plars | persia: that may already be in the works | 15:04 |
| persia | plars: That's what I heard. | 15:04 |
| asac | dont care ... | 15:04 |
| plars | I think that oem already has some that have not been pulled in yet | 15:04 |
| persia | Moving on... | 15:04 |
| asac | you can file a generic bug for bluetooth support ;) | 15:04 |
| asac | in checkbox | 15:04 |
| asac | and say that we came from suspend/resume testing ;) | 15:04 |
| persia | PCMCIA and eSATA are EXTRA because of hardware availability with our kernels. | 15:04 |
| persia | NFS/CIFS/etc. is just app-level testing of network | 15:05 |
| asac | dont we have eSATA? | 15:05 |
| persia | Do you? | 15:05 |
| asac | i dont know. thought we have SATA ... no clue what it is | 15:05 |
| persia | I heard about SATA, but not about eSATA. | 15:05 |
| plars | well, my sata port looks pretty external, but that's only because I don't have an enclosure :) | 15:05 |
| persia | eSATA is External SATA | 15:05 |
| asac | ah | 15:05 |
| ogra | asac, i think i found the partition issue ... | 15:05 |
| asac | ogra: rocking | 15:06 |
| ogra | # round size to next block; note we assume blocks of 512 B | 15:06 |
| ogra | IMG_SIZE_BLOCKS="$((($FIS_SIZE + $IMAGE_SIZE + 512 - 1) / 512))" | 15:06 |
| ogra | thats from the original script :P | 15:06 |
| persia | nbd\iSCSI/etc. is again just more network tests, really. EXTRA | 15:06 |
| asac | i tried that | 15:06 |
| ogra | i must have been blind to missi it | 15:06 |
| asac | exactly that ;) | 15:06 |
| asac | odd | 15:06 |
| asac | but great | 15:06 |
| persia | multicore runs into hardware issues, as does radio/telephony. | 15:06 |
| persia | DOne. | 15:06 |
| asac | i first tried round to blocks | 15:06 |
| ogra | for what exactly ? | 15:06 |
| asac | then i tried to round to cylinders ;) | 15:06 |
| asac | ogra: for all partitions | 15:07 |
| plars | persia: otoh, I think multicore would be good to revisit if/when we have supported multicore systems, extra until then though | 15:07 |
| ogra | IMG_SIZE_BLOCKS is used in the dd command that creates the raw image | 15:07 |
| ogra | before partitioning it ;) | 15:07 |
| asac | hmm | 15:07 |
| asac | that adds meta info? | 15:07 |
| ogra | no | 15:07 |
| ogra | but uses a bs=512 ;) | 15:07 |
| asac | whats the difference? | 15:08 |
| asac | in the end everything is zero ;) | 15:08 |
| ogra | that the dd'ed image has a blocksize | 15:08 |
| asac | so if there is no meta data then | 15:08 |
| asac | so there is meta info | 15:08 |
| asac | :) | 15:08 |
| asac | thats what i mean | 15:08 |
| ogra | there are block boundaries | 15:08 |
| asac | right. | 15:08 |
| asac | thats meta info | 15:08 |
| ogra | its not "meta info" | 15:08 |
| asac | sure | 15:08 |
| asac | its definitly not payload ;) | 15:08 |
| asac | anyway very good | 15:08 |
| asac | now i want my board back ;) | 15:09 |
| ogra | its just the way the raw image is built | 15:09 |
| asac | still ... its meta info ;) because its not payload | 15:09 |
| asac | it must be somewhere in the blob | 15:09 |
| ogra | anyway, that should give us properly partitioning | 15:09 |
| asac | and does not carry data | 15:09 |
| asac | right | 15:09 |
| asac | please verify | 15:09 |
| asac | then lets move swiftly for the uboot spec :) | 15:09 |
| asac | plars: so all fine? | 15:10 |
| asac | persia: any of the testcases you want to be peer or even owner for? | 15:10 |
| plars | asac: yes | 15:10 |
| asac | also setting "fill out the wiki items" to DONE | 15:11 |
| asac | as i assume you add some stuff we mentioned | 15:11 |
| plars | asac: yes, of course | 15:11 |
| asac | plars: actually all items are done, right? | 15:11 |
| asac | e.g. we decided what is automated too? | 15:11 |
| plars | asac: pretty much I think | 15:12 |
| asac | plars: you might want to reorder the implementation work items | 15:13 |
| asac | that went into extra | 15:13 |
| asac | plars: anything from BASE we cant implement? | 15:14 |
| asac | i guess we had an idea for everything, right? | 15:14 |
| plars | asac: yes | 15:14 |
| plars | we're good | 15:14 |
| asac | ok | 15:14 |
| asac | great | 15:14 |
| asac | that brings us close the trendline | 15:14 |
| plars | thanks :) | 15:14 |
| plars | asac: I might have to move my final two items for the install testing to A3 | 15:15 |
| asac | plars: thats ok. what is blocking that? | 15:15 |
| asac | note: we still have a few days left and you are not bound to freezes ;) | 15:15 |
| plars | I've talked to ara about them, and have a RT ticket to get access to the system for adding the tests to the tracker DB | 15:15 |
| asac | ok | 15:15 |
| asac | thats blocking both? | 15:16 |
| plars | if it happens before the cutoff, I could do it, but it may be better to wait anyway | 15:16 |
| plars | yeah, but it can't really start until AFTER alpha2 drops | 15:16 |
| asac | lets keep them there until tuesday ... and then move them | 15:16 |
| plars | so, it's better probably not to go mucking with that db right now anyway | 15:16 |
| asac | ok | 15:16 |
| asac | lets move them | 15:16 |
| plars | otherwise, it's ready to go, and regardless of whether those milestones get created now, or after a2 drops, it will not change the timeline for it actually starting to happen | 15:17 |
| asac | plars: one thing. do you have a list of changes to RC bugs ? | 15:17 |
| asac | ;) | 15:17 |
| asac | since last meeting ... | 15:17 |
| plars | no, sorry, I do not | 15:17 |
| asac | kk | 15:17 |
| asac | ok moved | 15:18 |
| ogra | hrm, no, doesnt work either | 15:33 |
| asac | plars: isnt bug 431963 fixed | 15:33 |
| ubot4 | Launchpad bug 431963 in linux-fsl-imx51 "io/fs errors when launching gdm on imx51 with sata" [High,Fix committed] https://launchpad.net/bugs/431963 | 15:33 |
| asac | ogra: fdisk -l looks good? | 15:33 |
| ogra | i guess the image needs to exactly be a multiple of 512 | 15:33 |
| ogra | no | 15:33 |
| asac | i would think that some of the bounds might be wrong | 15:34 |
| asac | e.g. -1 | 15:34 |
| asac | +1 | 15:34 |
| asac | etc. | 15:34 |
| plars | asac: yes, fix released for lucid, and the sru for karmic was just recently confirmed by GrueMaster | 15:34 |
| asac | so you probably trash the partition as i expected | 15:34 |
| asac | plars: why is it fix committed? | 15:34 |
| plars | asac: that's for karmic | 15:34 |
| asac | sure? | 15:34 |
| asac | thoght the bot always posts the default | 15:34 |
| asac | ok | 15:34 |
| asac | bug 453682 | 15:34 |
| plars | asac: according to the bug, the lucid task is fix released | 15:35 |
| ogra | asac, parted needs exact 512 bytes boundaries | 15:35 |
| ubot4 | Launchpad bug 453682 in linux-mvl-dove "late resume failure on dove" [High,Fix committed] https://launchpad.net/bugs/453682 | 15:35 |
| asac | plars: that one? | 15:35 |
| asac | also? | 15:35 |
| plars | asac: same there | 15:35 |
| ogra | so we need to adjust our partition sizes accordingly | 15:35 |
| plars | asac: fix released for lucid | 15:35 |
| asac | bug 456659 | 15:36 |
| ubot4 | Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,Confirmed] https://launchpad.net/bugs/456659 | 15:36 |
| asac | no need to comment | 15:36 |
| asac | just trying to get info ;) | 15:36 |
| asac | bug 499881 | 15:36 |
| ubot4 | Launchpad bug 499881 in linux-fsl-imx51 "usb storage with ext4 does not work in lucid" [High,Confirmed] https://launchpad.net/bugs/499881 | 15:37 |
| plars | asac: I haven't seen an movement from kernel team on 456659, but it seems to work better for me now on bbg3 at least, still may not be quite fixed though | 15:37 |
| asac | bug 458501 | 15:37 |
| ubot4 | Launchpad bug 458501 in gnome-screensaver "[armel] screensaver hangs on unlock, eats cpu" [High,Confirmed] https://launchpad.net/bugs/458501 | 15:37 |
| plars | 458501 is fixed in lucid | 15:38 |
| asac | bug 494667 | 15:38 |
| ubot4 | Launchpad bug 494667 in squashfs-tools "[armel] non-ISO-C misaligned pointer punning causes slowness and SIGILLs" [Critical,Fix released] https://launchpad.net/bugs/494667 | 15:38 |
| asac | really? | 15:38 |
| asac | cool | 15:38 |
| * asac moves to fix | 15:38 | |
| plars | someone didn't subscribe 499881 to ubuntu-armel... :) | 15:39 |
| asac | i searched for armel tag ;) | 15:39 |
| asac | hopefully that has all | 15:39 |
| plars | yeah, I need to pull the list of unsubscribed bugs with armel tag again | 15:39 |
| plars | ideally, they should also be subscribed to ubuntu-armel if we may do something with them | 15:40 |
| asac | https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=armel&field.tags_combinator=ANY&field.has_no_package.used=&search=Search | 15:40 |
| asac | maybe compare that with the lucid list you get for ubuntu-armel ;) | 15:40 |
| asac | if you see a difference let me know so i can add tha to the report :) | 15:40 |
| asac | bug 462798 | 15:40 |
| ubot4 | Launchpad bug 462798 in ubiquity "selecting 'new partition table' confuses the partitioning" [Medium,Triaged] https://launchpad.net/bugs/462798 | 15:40 |
| plars | asac: I have a script that will show me he ones tagged, but not subscribed | 15:40 |
| plars | asac: NCommander is aware of that one | 15:41 |
| plars | was something we found towards the end of karmic | 15:41 |
| asac | cool | 15:41 |
| asac | the other way around would be good for me atm ;) | 15:41 |
| asac | e.g. not tagged but subscribed and targetted for lucid :) | 15:41 |
| asac | but i can search for that in a bit on my own | 15:41 |
| asac | bug 451553 | 15:41 |
| plars | I updated it recently | 15:41 |
| ubot4 | Launchpad bug 451553 in linux-mvl-dove "Lots of errors during install on dove" [Medium,Confirmed] https://launchpad.net/bugs/451553 | 15:41 |
| asac | whats that? | 15:41 |
| asac | why is a medium bug targetted for release? | 15:42 |
| asac | plars: do you still see that? its old aka october | 15:42 |
| plars | asac: i believe the importance may have been lowered at some point | 15:42 |
| asac | ok untargetting | 15:42 |
| plars | I still see some of those errors, last I checked, but not all of them | 15:43 |
| asac | moving to normal baug | 15:43 |
| plars | odd | 15:43 |
| plars | the lucid task was targetted for karmic updates?! | 15:43 |
| asac | yeah ;) | 15:43 |
| asac | removed the milestone now | 15:43 |
| plars | probably the lucid task was opened after that was milestoned | 15:44 |
| plars | that's likely what happened... neat trick though! | 15:44 |
| asac | bug 458537 | 15:44 |
| ubot4 | Launchpad bug 458537 in linux-fsl-imx51 "hibernate does not work" [High,Triaged] https://launchpad.net/bugs/458537 | 15:44 |
| plars | hmm? wontfix for lucid? | 15:44 |
| asac | plars: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid -> check that | 15:44 |
| asac | plars: wontfix is the way to untarget it ... so the "normal" task reappears | 15:45 |
| asac | its the only way ;) | 15:45 |
| asac | so ignore that. just means its not tracked by release team anymore | 15:45 |
| plars | I see | 15:45 |
| plars | odd | 15:45 |
| asac | plars: the bug progress was nice this week ;) | 15:45 |
| asac | cool | 15:45 |
| asac | well not really week ;) | 15:45 |
| plars | asac: move 453682 to fix released for lucid | 15:46 |
| plars | and 458501 | 15:47 |
| plars | oh | 15:47 |
| plars | nm | 15:47 |
| plars | I see the category now | 15:47 |
| * plars needs more caffeine | 15:47 | |
| plars | I keep thinking the fixed this week is the backlog category for some reason | 15:47 |
| plars | because the one under it is fix available I guess | 15:48 |
| asac | plars: could you test the alternate images? | 15:51 |
| asac | do they work | 15:51 |
| asac | ? | 15:51 |
| plars | asac: I have not so far, but I could pull them and take a look if you'd like | 15:51 |
| plars | I thought that ogra or someone had said they had looked recently | 15:52 |
| ogra | NCommander did say that | 15:52 |
| ogra | but i think he only chacked dove | 15:52 |
| NCommander | ogra, they boot for dove, installatoin fell flat on its face due to installability errors | 15:53 |
| ogra | aha | 15:53 |
| asac | JamieBennett: ogra: plars: GrueMaster: NCommander: persia: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid | 15:58 |
| asac | anything for weekly summary? | 15:58 |
| GrueMaster | asac: lsb-lib test porting is done; all that's left is the packaging. | 15:59 |
| asac | good | 15:59 |
| NCommander | asac, probably want the bug report for thumb, but I haven't written it up yet as I'm reinstalling with latest packages to get the best possible report | 15:59 |
| GrueMaster | I'm dropping libstdc++-tests as they only test for api existence, not functionality. | 16:00 |
| asac | * lsb-lib porting | 16:00 |
| asac | added that to summary | 16:00 |
| NCommander | asac, we also want to track alternates for this alpha, but they aren't a blocker on working/not working | 16:00 |
| asac | NCommander: did you read that wiki page? | 16:00 |
| asac | thanks | 16:00 |
| ogra | whats https://bugs.launchpad.net/bugs/499881 ? | 16:00 |
| asac | * mobile-lucid-arm-alternate-images: DONE - verification pending. | 16:00 |
| NCommander | asac, oops, sorry | 16:00 |
| ubot4 | ogra: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/499881) | 16:00 |
| asac | ogra: thats my usb storage not working in lucid | 16:00 |
| asac | works perfect in karmic | 16:01 |
| asac | but with lucid is broken | 16:01 |
| ogra | why the heck is none of these bugs properly subscribed to ubuntu-armel ? | 16:01 |
| ogra | i havent heard of either of them | 16:01 |
| plars | ogra: I'm pulling a list of unsubscribed bugs right now, will go through them and see if we are still missing some important ones | 16:02 |
| ogra | thanks a lot | 16:03 |
| plars | there was another one like that I caught earlier this morning too | 16:03 |
| ogra | thats a month old, i might have debugged it already had i known about it | 16:03 |
| ogra | asac, ok, going through the script items manually i at least get a proper "Non-FS Data" partition again in fdisk | 16:05 |
| ogra | and with handing -C to fdisk it doesnt complain anymore ... | 16:05 |
| ogra | http://paste.ubuntu.com/353524/ | 16:06 |
| asac | so ooo failing to biuld would be a problem? | 16:06 |
| asac | is it easy for us to unseed? | 16:06 |
| asac | or are there libs that are pulled in as base stuff? | 16:06 |
| ogra | not easy | 16:06 |
| ogra | but possible | 16:06 |
| asac | why not? | 16:06 |
| ogra | language packs | 16:06 |
| asac | seems we get an alpha-2 upload before a2 so i want to discuss with slangasek | 16:07 |
| asac | but need to understand how bad it owuld be | 16:07 |
| asac | ooo upload before a2 | 16:07 |
| ogra | it needs some very intrusive shuffling of the translation packages to actually get everything off the image | 16:07 |
| ogra | slangasek knows what i'm talking about | 16:08 |
| ogra | we did it together the last time we unseeded oo.o because it failed | 16:08 |
| ogra | oh ! | 16:10 |
| * ogra glares at dd if=/dev/zero of=./boot.img bs=1024 count=$(($BOOT_SIZE / 1024)) | 16:10 | |
| ogra | why do we use bs=1024 here ... hmm | 16:11 |
| asac | ok | 16:16 |
| ogra | aha ! | 16:17 |
| ogra | http://paste.ubuntu.com/353529/ <- as soon as i create the second partition | 16:18 |
| asac | yes. i think you need to add a better start | 16:19 |
| asac | e.g. try to add more offset | 16:19 |
| ogra | well, i did it manually | 16:19 |
| asac | or dont change the fs type before | 16:19 |
| ogra | and made it start 1byte after the end of part 1 | 16:20 |
| ogra | the fstype is changed in the table not on the partition | 16:20 |
| asac | try to give it a full block offset | 16:20 |
| ogra | yes, thats what i'll try next | 16:20 |
| ogra | either a full block or probably better the exact start of the next 512B block | 16:21 |
| ogra | i think the latter will solve it | 16:21 |
| ogra | but i dont get why ... | 16:22 |
| ogra | since we dont need this in the original script on the builder | 16:22 |
| ogra | nope, same breakage | 16:34 |
| asac | GrueMaster: plars: how do you organize testing of standing RC bugs? do you check each every day? or only if someone claims it to be fixed? | 17:12 |
| plars | generally only if someone claims that it has been fixed, or that there is a test package for it. However, some that are much more obvious will be much more likely to get noticed in testing of daily images | 17:13 |
| GrueMaster | I try to test once it's marked as fixed. Otherwise, I also try to monitor the package in the manifest to see if it changes there. | 17:14 |
| plars | asac: what did you recommend for cpufreq/voltage? we discussed that cpuinfo was insufficient to tell us anything there, but going back through the logs it was unclear as to whether you were suggesting to move that one to extra, or the previous item we discussed | 17:25 |
| asac | plars: some more or less long running computing thing that doesn consume much memory (e.g. no swapping) run with high prio | 17:26 |
| asac | measuring time | 17:26 |
| asac | i think priority isnt important if we look at CPU time actually | 17:27 |
| plars | still in base? | 17:27 |
| asac | why not? | 17:27 |
| plars | ok | 17:27 |
| asac | feels doable and good to check ;) | 17:27 |
| plars | I was wondering... is cpufreq subsystem not supported under arm? | 17:27 |
| plars | might give us a better test | 17:27 |
| asac | CPU time should be a real test. cpufreq is just exported by kernel and might not match actual performance if there is a bug | 17:28 |
| asac | or isnt that true? | 17:28 |
| asac | but well. if we have that and the time measuring doesnt feel good, thats probably ok too | 17:28 |
| plars | asac: I was thinking in terms of adjusting the freq, making sure it matches after resume | 17:29 |
| plars | sure | 17:29 |
| ogra | we could grep BogoMIPS from /var/log/dmesg :) | 17:31 |
| plars | ogra: iirc, bogomips only gets updated at boot, not on resume | 17:31 |
| ogra | yeah, most likely | 17:32 |
| ogra | ogra@babbage2:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq | 17:34 |
| ogra | 800000 | 17:34 |
| ogra | btw | 17:34 |
| suihkulokki | mmh.. on a preemptively multitasking OS asking the cpu performance is usually wrong question | 17:34 |
| plars | ogra: odd, I don't see that on my b3 | 17:35 |
| ogra | plars, you dont use the shiny new kernel from cooloney ;) | 17:35 |
| plars | ogra: ah | 17:35 |
| ogra | i wasnt thrilled by nothing when i said we have all devices working ;) | 17:35 |
| ogra | that first shot is really better than any released kernel we had before | 17:36 |
| asac | its still kernel statistics vs. actual performance | 17:36 |
| asac | actual performance is the best test imo | 17:36 |
| asac | kernel statistics could be busted | 17:37 |
| ogra | indeed | 17:37 |
| asac | checking both is the best | 17:37 |
| asac | because we dont want good actual performance with busted kernel stats for instance :) | 17:37 |
| ogra | i doubt we actually want to scale it at all | 17:37 |
| ogra | as long as all graphics rendering is framebuffer and software based it makes no sense to scale down | 17:38 |
| ogra | at least with the max 1GHz machines we have atm | 17:38 |
| asac | is that relevant? | 18:01 |
| asac | ;) | 18:01 |
| ogra | well, what for is measuring good if you dont change the value anyway :) | 18:03 |
| === asac_ is now known as asac | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!