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