michaedwzyga: hit any blockers?00:29
zygamichaedw, no, not yet, still working on assorted things00:29
zygamichaedw, I want to wrap up my work and hit the bed though :-)00:29
michaedwzyga: sure, just wanted to make sure I'd answered any questions you had before I wandered off :-)00:31
michaedwand in particular, resolved any problems you had with the tarball-downloading bits00:31
zygamichaedw, it was annoying to change all the places where it stores things00:31
zygamichaedw, :-)00:31
michaedwthere may be a few untested paths in there, because I grandfathered in a tarball cache I already had from the home-grown scriptage00:32
michaedwI do think you'd have a little bit easier time of it if you went the "make install" route00:32
michaedwmost of the places-where-it-stores-things are then configurable in .config00:33
michaedw(not all easy to find in the menuconfig interface, but you can edit .config directly)00:33
michaedwzyga: did the bzr clone for the gcc source work for you?00:34
zygamichaedw, I have a local copy, I did not want to clone it again00:34
zygamichaedw, I did not finish the process though00:35
zygamichaedw, just figured out where to look next once I implement something on my side00:35
michaedwzyga: very good; if you have questions, you can usually ping me here (California time but I've been working longish days lately :-P)00:37
michaedwzyga: or email at m.k.edwards@gmail.com or michaedw@cisco.com00:37
zygamichaedw, I'll stay in touch, I'm CET but mostly stay up much longer 00:37
zygamichaedw, you can reach me at zygmunt.krynicki@linaro.org00:38
zygamichaedw, I'll announce lava-dev-tool 0.1  on linaro-dev soon00:38
zygamichaedw, I'll CC you :-)00:38
michaedwzyga: thx!  And if it grows in the general direction of automated validation, I'd be thrilled00:39
michaedwand I'll try to get the next phase pushed out ASAP00:39
michaedw(as soon as I run our newly built hard-float OpenGL libs through their paces)00:40
michaedwzyga: btw, you may notice that there's a funny gcc patch in there, which adds a neon-d16-fp16 model00:41
michaedwzyga: because I intend to reserve the upper half of the NEON register bank for in-kernel use00:42
michaedwzyga: if you wind up doing some benchmarking, make sure you've got apples and apples :-)00:42
michaedwzyga: (there are -march, -mcpu, -mfpu defaults baked into the toolchain, set in .config)00:43
=== prpplague^2 is now known as prpplague
james_wmwhudson, would you add doanac to https://launchpad.net/~linaro-android-builders/+members please?01:41
mwhudsonjames_w: done01:42
mwhudson"assign me" on the team add member form does not make a lot of sense01:42
james_wnot really01:43
plarsmwhudson: hi02:00
mwhudsonplars: hello02:00
plarsmwhudson: linaro-meeting?02:00
plarsmwhudson: it might be more of a sync though :)02:01
plarsmwhudson: I don't see springz yet02:01
mwhudsonplars: oh, i thought it was "the other week" for some reason02:01
plarsmwhudson: yeah, that was my fault, I sent you a correction in email :)02:01
mwhudsonyou did?02:02
=== asac_ is now known as asac
michaedwsorry, ww02:38
michaedwbut since I mention it, what exactly is happening in Dublin next week?  ;-)02:38
michaedwah, looks like Ubuntu Platform Sprint02:41
michaedwCanonical internal02:41
michaedwso no, zyga, I guess I won't be attending <g>02:42
=== agreen-away is now known as agreen
zygamichaedw, aww, too bad, well linaro is just one month later03:09
zygaI'm off now, good night03:09
=== michaelh1 is now known as michaelh1|away
Quintasanericm|ubuntu: ping08:09
ericm|ubuntuQuintasan, pong08:10
Quintasanericm|ubuntu: I believe persia contacted you about imx-libs FTBFS08:10
ericm|ubuntuQuintasan, persian pinged me this morning about your issue08:10
ericm|ubuntuQuintasan, yes08:10
ericm|ubuntuQuintasan, actually paulliu knows the detail much better than I do08:10
ericm|ubuntupaulliu, ^^08:10
Quintasanhrw: \o08:11
paulliuQuintasan: ok... Do you have a bug number?08:13
paulliuQuintasan: Where did you get the imx-lib?08:13
Quintasanpaulliu: Nope, I was doing it late in the morning and went straight to bed after it failed08:14
Quintasanpaulliu: I downloaded L2.6.35_11.05.01_ER_source_bundle from Freescale website08:14
QuintasanIt was there under pkgs/08:14
QuintasanThe thing I am actually trying to compile is xserver-xorg-video-imx-11.05.0108:14
Quintasanbut I was missing linux/mxcfb.h which is apparently not part of linux-headers-2.6.35-1001-linaro-lt-mx5308:16
paulliuQuintasan: hmm. we have debian packages for imx-lib..08:16
persiapaulliu, In the archive?08:16
paulliupersia: no.. it's on PPA08:16
Quintasanpaulliu: Where? I think I have all Freescale Landing Team PPA's added08:17
persiaLet's fix that :)08:17
paulliupersia: ok.. but it needs adding kernel headers...:)08:17
Quintasanpaulliu: Any chances xserver-xorg-video-imx-11.05.01 is there too?08:17
hrwxserver-imx does not require z160.h anymore?08:17
persiapaulliu, To what?  To linux-linaro-lt-mx5 or linux-linaro-mx5?08:17
persiahrw, Depends on the model: i.MX53 has a Z180, rather than a Z16008:18
paulliuQuintasan: All the middleware is there... X, 3D, and gstreamer codecs08:18
paulliuhrw: yes, it needs z160.h....08:18
Quintasanhrw: No idea, it failed to build with missing linux/mxcfb.h08:18
paulliuQuintasan: yes..because mxcfb.h is not in linux-libc-dev08:18
QuintasanWhich I copied from linux-fsl-imx51 from some well hidden Canonical Kernel PPA08:18
Quintasanpaulliu: It wasn't in linux-headers-2.6.35-1001-linaro-lt-mx53 either08:19
paulliupersia: I'm currently using the header from linux-linaro-lt-mx5..but I think we should add that header into the package..08:19
hrwpersia: I was building for mx51 only08:19
paulliuQuintasan: Should be in linux-headers.2.6.38-*-mx508:19
persiapaulliu, I think copying it is likely safest, as most Ubuntu folk are more likely to be using linux-linaro-mx5, which has more restrictions on what can be added.08:20
persiahrw, Don't do that.  Generic solutions are the new black!08:20
paulliupersia: the libz160 in our PPA should work on both mx51 and mx5308:20
hrwpersia: it used libz160 which was iirc closed so crap anyway08:20
paulliuhrw: yes.. binary blob08:21
hrwmy efikasb now runs fbdev with mainline kernel08:21
persiapaulliu, Ah, cool!08:21
Quintasanpaulliu: Hmm, I'm running 2.6.35 so that might be why I don't have them :S08:21
paulliupersia: that's why I don't want to upstream xserver-xorg-video-imx08:21
persiapaulliu, Yeah.  I can understand not upstreaming it: there's heaps to do to make it more sensible.  That said, I'd like to have it in the repos (separately) so it's easier for folk to find.08:22
paulliuQuintasan: ok.. So you might need to copy the headers out and build imx-lib with it.08:22
paulliuQuintasan: There are lots of headers needs to copy out. Security modules headers is also needed by imx-lib08:22
paulliupersia: ok... Do you mean PPA?08:23
persiapaulliu, No.  Because it's a binary blob, probably multiverse, assuming the blob can be redistributed.08:23
persiaPPAs are hard for folk to find.08:24
alfasac: fabo: joey: What is the naming convention for packages based on our components eg if tarball is xyz-1.2-2011.06-2.tar.gz what should the debian package version be?08:24
paulliupersia: ok.. We have to solve license issues first... And we still have it..08:24
paulliupersia: BTW, I don't know why Efika can ship those libs...08:24
paulliuFrom freescale I heard that it is still licensed under a 'click-before-download' or 'click-before-install' license.08:25
paulliuincluding libz160..08:25
paulliuimx-lib is free... And it doesn't depends on non-free stuff.08:25
persiapaulliu, I (intentionally) don't know the specific terms of agreement, but it's common that binary drivers are licensed to OEMs in a way that allows the OEMs to ship them with their product, or for "recovery" or "updates".  I suspect that's what Genesi has done.08:25
paulliuxserver-xorg-video-imx is free, but depends on non-free libz16008:25
paulliupersia: ok..08:26
paulliupersia: So does that mean we can do the same thing?08:26
persiaDunno, and depends on "we".08:26
paulliupersia: Seems we need some lawyers or PM to take care of the licensing again..08:26
paulliupersia: I mean Ubuntu08:26
paulliuOK.. I'll ask the PM to ask Freescale for the licensing..08:27
persiaSo, Ubuntu can distribute anything that the archive-admins accept, for which someone has granted a license to Ubuntu (but not specific to Ubuntu).08:27
paulliuAt least libz160 should be in multiverse08:27
paulliuto make X works08:27
persiaIn practice, this means that some developer uploads it, using their rights under their license to extend the license to Ubuntu.08:27
persiaWhich means that for Ubuntu to ship it, *someone* needs to have a license that allows them to distribute it to Ubuntu.08:28
hrwpaulliu: but all that with assuming that imx5x boards/devices are running .35 freescale kernel. Which is not always granted.08:28
persiaAnd since Ubuntu requires the license to not be specific to Ubuntu, this means Ubuntu would have the right to distribute to mirrors, who have the right to distribute to users, etc.08:28
Quintasanpaulliu: I'll just upgrade to .3808:28
Quintasanhrw: That's what got installed with linaro-media-create :)08:28
persiahrw, These drivers can't work with linux-linaro-mx5, without the landing team patches?08:29
hrwpersia: I did nto tried linaro kernels on efikasb08:29
paulliupersia: hmm.. I know.. 08:29
persiapaulliu, So, one example I used to use a lot, is the sun-java6 package (you'll want to get the one from Debian these days).08:30
paulliupersia: It is the same requirement for Debian non-free section..08:30
persiaIt has an implementation of a requires-acceptance-before-use solution that is compatible with mirrors.08:30
paulliuOK.. I'll discuss this with Freescale... to allow us have multiverse-allowed licenses for libz160..08:32
faboalf: replace "-" of the debian version by "+" -> 1.2+2011.06+2-108:32
alffabo: ok, thanks!08:33
paulliuQuintasan, which Linaro hwpacks you are using?? The one from Landing team?08:38
Quintasanpaulliu: hwpack_linaro-lt-mx53loco_20110617-0_armel_supported.tar.gz08:38
paulliuQuintasan: yeah, that's good.. It should have lots of things there.08:39
paulliuQuintasan: the built imx-lib should be there already..08:39
paulliuQuintasan: but imx-lib is not the dependencies of xserver-xorg-video-imx anymore...08:40
paulliuQuintasan: Because freescale doesn't want Xv in X driver anymore.. They use v4l2sink for video...08:41
QuintasanI figured as much this morning when I compiled it and installed and it still didn't work08:41
Quintasanpaulliu: There is not imx-lib package, do you mean that it is already installed there "manually"08:41
paulliuQuintasan: should be installed.. dpkg -l should find that?08:42
Quintasanlet me try that when I'm done with installing kernel08:42
paulliuQuintasan: ok..:)08:42
=== bero is now known as Guest52594
=== bero|2 is now known as bero
dirk_bQuintasan: I'm no graphic expert, so sorry if I missed the point of above discussion ;) But just fyi, linux/mxcfb.h is in Freescale's git : http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=tree;f=include/linux;h=88bfa487adcbb3a33b5210867f8d7056ca1410e8;hb=refs/heads/imx_2.6.35_11.05.0109:07
asacalf: good question09:09
asacalf: what do you suggest?09:09
asacalf: s/-/+/ ?09:10
alfasac: fabo suggested exactly that09:10
alfasac: it sounds good09:10
asacguess thats a deal then09:11
asacalf: how is unity coming along09:12
asacalf: does it work from packages yet?09:12
alfasac: besides some strange compiz/nux interaction blending issues, you can install from ppa:rsalveti/unity-3d-gles and get something decent ;)09:14
rsalvetiasac: install the unity package and be happy :-)09:15
rsalvetijust remaining the gl_blend issue09:15
asacrsalveti: what are you doing here09:15
asacrsalveti: is my clock broken?09:15
asacrsalveti: do we already have that in our image?09:15
rsalveticouldn't sleep, so I'm fixing another bux in unity :-)09:15
rsalvetiasac: that's what I'm currently doing09:15
asacok once there is an image i am happy to test ;)09:16
rsalvetijust ported the unity_support_test to use gles09:16
rsalvetinow the fallback is working fine when you don't have a valid driver09:16
alfrsalveti: cool!09:16
asacvery good09:16
rsalvetiso we can have unity-3d now installed by default09:17
rsalvetitogether with unity-2d09:17
rsalvetiand at runtime it'll select the best one :-)09:17
asacthis is awesome09:17
rsalvetiI'm just about to update the package now09:17
asacvery good09:17
rsalvetithen will change the seed, create an image and test :-)09:17
asacrsalveti: btw, is ds-5 in ppa yet?09:17
rsalvetithe ppa is there, just got the first packages yesterday 09:18
rsalvetishould be pushing them later today09:18
asacyeah that would be cool. it feels like a timebomb i would rather see defused09:19
rsalvetiyeah, but now it seems we'll be able to at least deliver something09:20
rsalvetiasac: just pushed a new firefox version that works with webm09:20
rsalvetihad to disable thumb209:20
rsalvetiso now you can watch youtube html5 videos on your panda09:21
rsalvetiasac: as you like firefox, https://bugzilla.mozilla.org/show_bug.cgi?id=649525#c9 seems a nice thing to integrate09:21
ubot2Mozilla bug 649525 in Canvas: WebGL "WebGL layer compositing through the BasicCanvasLayer is very slow (desktop version)" [Normal,New: ]09:21
rsalvetiyou can then compile with --enable-egl-xrender-composite and have egl/gles support at firefox09:22
rsalvetiseems to make things a little bit faster09:22
faboericm|ubuntu: what about the lt kernel tag?09:27
ericm|ubuntufabo, the tags are missing on git.l.o?09:28
faboericm|ubuntu: dunno, I didn't check the repos. I expected a notification. is it already done?09:29
asacrsalveti: very cool. seems our mozilla maintainer doesnt look for such things x)09:29
asaci will poke him09:29
ericm|ubuntufabo, nope09:30
ericm|ubuntufabo, but that's definitely a good proposal09:30
asacok poke sent09:31
ericm|ubuntufabo, did anyone propose this idea on linaro-dev?09:31
asaclets see if chrisccoulson will take it on ;)09:31
* asac just found he is also here09:31
faboericm|ubuntu: you should have received a mail on 2 forms :)09:31
ericm|ubuntufabo, Grrr... I don't check linaro-dev constantly09:32
faboericm|ubuntu: it isn't on linaro-dev, you have received a mail directly09:32
asacmichaelh1|away: what is graphite?09:33
asackenws: ^^ do you know?09:33
ericm|ubuntufabo, ok - I'm embarrassed :-PO09:33
faboericm|ubuntu: "Linaro 11.06 release preparation" :)09:33
ericm|ubuntufabo, so is this something the Kernel WG is doing?09:33
michaedwasac: a build prerequisite for recent GCC09:33
asacjserv is talking about graphite here: https://wiki.linaro.org/JimHuang/Sandbox/LinaroToolchainAndroidBenchmarking09:33
michaedwasac: http://gcc.gnu.org/wiki/Graphite09:33
faboericm|ubuntu: it's for each Linaro deliveries :) kernel, toolchain, lt,  platform, etc...09:34
ericm|ubuntufabo, ok09:34
michaedwasac: in that page, "Graphite" appears to be shorthand for "with optimization flags that back-end on Graphite"09:35
michaedw-floop-interchange -floop-strip-mine -floop-block09:36
asacmichaedw: i dont understand the ubild insstructions ... they do not really look special09:36
asacmichaedw: ah so its those optimization flags09:36
michaedwand in the April benchmark, -ffast-math -funsafe-loop-optimizations09:36
asacmichaedw: thats also graphite? where is that documented on the gcc wiki ;)?09:37
michaedw(-ffast-math is not Graphite per se, but does permit the use of vectorized NEON FP, which Graphite can then massage)09:37
asaclet me check something09:37
davidgilukmichaedw: Other than the move of that last dmb is my atomic stuff holding together?09:38
michaedwdavidgiluk: haven't really exercised it yet, been sidetracked on priority inheritance mutexes09:39
michaedwwhich my test suite relies on for the case where the otherwise lock-free queue is fully drained09:39
michaedwI can work around that by rebuilding without setting the PI attribute09:40
michaedwI will report one way or the other by Monday09:40
asacmichaedw: do you know if we have backported graphite to our final linaro 4.4?09:40
asacor just 4.5?09:40
davidgilukmichaedw, Thanks09:40
michaedwasac: don't know, I came in with the 4.5 branch09:40
asachere the latest android toolchain benchmarks btw ... comparing google 4.4 to our 4.4, 4.5, 4.6 https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-0609:41
asacguess we will do another run fo4 4.5 and 4.6 with graphite09:41
asacalso probably should try to make the graphite options the default for our platform builds in 10.0709:41
asacmichaedw: so you say -floop-interchange -floop-strip-mine -floop-block -ffast-math -funsafe-loop-optimizations -> graphite?09:42
michaedwthat is my interpretation of that wiki page :-)09:42
michaedwbut it also makes sense in terms of what Graphite is for09:42
michaedwit's used for loop transformations09:43
asacquestion is if we need to build the toolchain in a special way09:45
asacbut the instructions just look normal09:45
asaclike if its merged into the branch its all fine09:45
michaedwasac: it's a build requirement in 4.5 and later09:45
michaedwpart of the whole CLooG/PPL machinery09:46
asacmichaedw: whats the minimum cloog version we need?09:46
michaedwfor 4.5.x, I use 0.15.909:47
michaedw4.6.x requires 0.15.10 and PPL 0.11.209:48
michaedwpresumably the same for mainline09:48
Quintasanpaulliu: This imx X driver has acceleration for OpenGL ES?09:48
michaedwI don't think 0.16 is out of "experimental" status yet09:49
davidgilukasac: You don't know if any of those spend useful amounts of time in libc/bionic do you?09:49
fabonytowl: origen hwpack build completed :) thanks09:50
asacdavidgiluk: the benchmarks?09:52
asacdavidgiluk: thats a good quesiton ... if they do, then the benchmarks we are doing are wrong because we didnt run them on a platform that was build with the same compiler version09:52
asaci asked doanac to check if he can see any difference at all09:52
asace.g. build benchmarks with 4.6 and run it on target with 4.4 ...vs. 4.509:53
asacwe have to wait what he says when he is back09:53
michaedwif these benchmarks are C++-ish, you definitely want to use the same compiler version throughout :-)09:53
asacthey are C09:53
asacmichaedw: i think its a confined benchmark ... e.g. the benchmark builds something all-static09:53
asacat least i hope ;)09:54
michaedwasac: including glibc and libgcc?09:54
asacmichaedw: we use bare metal toolchain09:54
michaedwyou probably want the NEONized string operations09:54
asacgoogle doesnt need non-bare metal luckily09:54
michaedwalthough I don't know how they compare to the autovectorized load/store that was backported to the Linaro branches this month, actually09:55
michaedwyou are using 2011.06 or bzr head?09:55
davidgilukasac: If the python stuff is pybench I seem to remember it doesn't use much library stuff at all09:55
asaci think the stuff in there doesnt use much from the target09:56
asacbut if anyone with a clue could check we would know better ;)09:56
asacjust clone it and check what it does. we definitely build it with a bare-metal toolchain ... which doesnt mean much of course09:56
dlezcanorsalveti: ping ?09:56
asacmichaedw: we use 2011.06 for 4.5 and 4.609:56
asacfor 4.4 we use last release made by TCWG09:56
asacmichaedw: https://android-build.linaro.org/09:57
asac4.6 is on the "All builds" page because its a preview as it breaks the android boot09:57
asacIf you build everything with it09:57
asacsome odd issue with a regex parsing error at runtime09:58
asac-> thats the 4.6 toolchain build09:58
asac-> thats the 4.6 panda build that shows the odd issue09:58
michaedwasac: I'm not sure the vectorized load/store is in the 2011.06 release09:59
asackenws was looking into that but got dragged into something else09:59
asacmichaedw: 2011.06 is the latest released ;) ... we also have daily builds somewhere (i think)09:59
michaedwit may have come in along with the A5 tuning branch; ask ramana09:59
michaedwI am running bzr head :-)09:59
asacthey are not built daily, but i can kick one off10:00
* asac does it10:00
asacbuild started for both10:00
asacmichaedw: bzr head == gcc 4.6? or trunk?10:00
michaedwhow odd; that's built with cloog 0.15.910:01
michaedwI could have sworn gcc 4.6's configure rejected that as too old10:01
asacwell, the build service never lies :)10:02
michaedwthe 4.6 branch at the moment, though I've also set up trunk in crosstool-ng10:02
ramanaIIRC - the a5 tuning branch was purely a backend specific changes for the infrastructure. It shouldn't have made any changes to the way in which code was generated for the A9 IIRC. It could be something else. Happy to look at it if there's a simple testcase.10:02
michaedwramana: did the autovectorized load/store get merged from that branch, or was it committed directly to the 4.6 branch before the 2011.06 cut?10:03
ramanamichaedw: the strided loads and stores seems to have made into the 4.6 release. 10:05
ramanaThe A5 tuning branch didn't make it till after the 2011.06 release so if the issues are with 2011.06 release then it's not the a5 tuning merge. 10:05
ramanaThe Autovectorized vld2 and vld3 stuff has made it in . 10:06
ramanamichaedw: ^^^10:06
asaclets see10:06
michaedwramana: do you have a feel for whether the residual bug that michaelh1|away mentioned, the one involving multiplication, could induce asac's regex parsing error?10:06
ramanamichaedw: it's looking for a needle on a haystack. there's probably no point in speculating. 10:07
ramanamichaedw: without even looking at the code that comes out of it. 10:07
asacsee https://wiki.linaro.org/Platform/Android/Builds/Wip/Build1AsacPandaGccLinaro4.6Noprelink?action=AttachFile&do=view&target=minicom.cap.txt10:07
asacline 39810:07
asacthats the odd issue we see when booting android platform built with gcc 4.610:07
ramanaline 398 for me says . 398 W/dalvikvm(  937): Exception Ljava/util/regex/PatternSyntaxException;10:08
asacthats the same build just with the 4.510:08
asacworking fine10:08
asacramana: right... thats what feels odd ... e.g. that we get a regex pattern issue just because we build with 4.6 ;)10:09
ramanaasac: Fine - someone has to go through the work of discovering what is different between the 2. 10:09
michaedwhmm, wacky10:09
asackenws started looking into it10:09
michaedwbut I was not originally asking about the autovectorization because of the bug :-)10:09
asacnot sure where his investigation ended when he was pulled out to do other stuff ;)10:09
michaedwI was more interested in whether asac's benchmark run will include its benefits10:10
asacso no ;)10:10
ramanait should include it's benefits as long as things which need to be vectorized are carefully chosen and tried to be vectorized with. 10:11
michaedwthere is a (probably unrelated) bug that I hit, and worked around with a patch that reverts the probable trigger10:11
ramanayeah please do report any bugs you find to bugs.launchpad.net10:11
michaedwsorry, haven't reported a launchpad bug yet; it's known in gcc upstream10:12
ramanawell if it is reported upstream then that's fine to start with but we probably need to know to backport this10:12
michaedwthis patch fixes the FTBFS but I haven't yet verified that it works afterwards10:13
asacrsalveti: where did you push the firefox version that you talked about to?10:14
michaedwfrying a somewhat bigger fish at the moment; priority inheritance mutexes are broken on SMP ARM10:14
michaedwwhich breaks my principal test suite, and incidentally pulse-audio, if I understand correctly from Stskeeps10:15
michaedwdavidgiluk: should I take the clrex out of my variant of your 64-bit atomics patch?  I am concerned that it might be needed in kernel code10:16
michaedw(I am replacing the in-kernel atomics — which are not actually atomic on SMP — with GCC intrinsics)10:17
davidgilukmichaedw: I think you should remove the clrex; all the ARM guys are saying it's unneeded10:18
michaedwright, unneeded outside context switch code10:18
michaedwI'm convinced10:19
davidgilukmichaedw: Which intrinsics are you using in the kernel?  Watch out for what happens if the kernel gets built for something pre-armv6k10:19
michaedwdavidgiluk: building for armv7-a, for local proof-of-concept purposes10:20
Stskeepsmichaedw: btw, gcc atomics in glibc causes qemu git problems in the linux-user emulation, in case you ever run into complaints about that10:21
michaedwbut there shouldn't be any pre-armv6 SMP ARMs, right?10:21
davidgilukmichaedw: Probably true - I think there were some hacks10:23
davidgilukStskeeps: Can you give some details; 10:24
michaedwthe path that is currently killing me is in arch/arm/include/asm/futex.h10:25
Stskeepsdavidgiluk: http://pastie.org/2106361 will break on linaro and qemu-git - it's a autoconf test in gzip and m4 testing printf surviving out of memory conditions. the configure test stalls completely. remove the atomics (sync and swap gcc stuff) from glibc and the issue disappears10:26
Stskeepsdavidgiluk: i've reproduced it on meego as well, which is where issue came from10:26
Stskeeps(qemu used in the chroot fashion, with qemu-arm-static, etc)10:26
davidgilukmichaedw: Well it's using ldrex/strex - but I guess it's missing the barriers?10:26
michaedwdavidgiluk: yes, and it's skipped when CONFIG_SMP is set10:27
michaedwnote the preempt_disable()10:28
davidgilukStskeeps, Weird; that doesn't look like it has anything too odd in it10:29
Stskeepsdavidgiluk: stalls in futex something, according to gdb10:30
michaedwdavidgiluk: I'm looking at http://lxr.free-electrons.com/source/arch/arm/include/asm/futex.h?a=arm10:30
davidgilukmichaedw, Yeh but that's in the !SMP case isn't it?10:30
michaedwdo you have a kernel in which this has been fixed?10:30
michaedwthe SMP case goes to asm-generic/futex.h, which returns ENOSYS10:31
davidgilukmichaedw: Oh, so the version in the linux-linaro-2.6.38 git tree has an SMP case which uses ldrex/strex10:31
michaedwwell I guess that's what I needed :-)10:31
michaedw(probably needs memory barrier fixups, but that's cake)10:32
michaedwI keep telling people we need to switch to Linaro kernels, rather than what TI tosses over the fence10:33
michaedwthey're perfectly competent, but they're tasked with supporting existing design-ins10:33
michaedwnone of which have our concurrent set of requirements10:34
davidgilukmichaedw: Hang on, I'm getting confused a sec10:34
davidgilukmichaedw: I'm confused by those ifdef's - the 1st ifdef (USE_DOMAINS && SMP) ends up at generic, but the else case then has the SMP code in which uses ldrex/strex10:36
michaedwdavidgiluk: the contended path for PI mutexes calls futex(0xd27e0, FUTEX_LOCK_PI_PRIVATE, 1) = -1 ENOSYS (Function not implemented)10:37
davidgilukmichaedw, Look at : http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=blob;f=arch/arm/include/asm/futex.h;h=8c73900da9ed01dba62045fc376aabd07d8ce9bb;hb=HEAD10:37
davidgilukmichaedw: The kerne.org tree looks similar10:38
michaedwthat futex_atomic_cmpxchg_inatomic() implementation looks fine10:39
michaedwit has the memory barriers before and after, even10:41
davidgilukright, time for me to go into the office - back on line in ~40mins10:42
=== apachelogger is now known as rohansgoogle
michaedwit's nearly 3AM here, I'm knockin' off10:42
=== rohansgoogle is now known as apachelogger
davidgilukyouch; erm well since it's already well into your weekend; have a good one10:42
michaedwdavidgiluk: thanks much for the pointer to the fix10:42
michaedw3AM Friday; still a long day ahead10:43
davidgilukoh right; your on the other side10:43
davidgilukanyway, later10:43
michaedwnight, day, whatever :-)10:44
michaedwjserv--: in https://wiki.linaro.org/JimHuang/Sandbox/LinaroToolchainAndroidBenchmarking , benchmarks marked "Graphite" are the same code with added gcc flags, right?10:49
michaedw-floop-interchange -floop-strip-mine -floop-block in March10:49
michaedw and -floop-interchange -floop-strip-mine -floop-block -ffast-math -funsafe-loop-optimizations in April10:50
jserv--michaedw, hi !10:50
michaedwhi ;-)10:50
jserv--michaedw, yes, enable graphite optimizations10:50
jserv--michaedw, are you trying to reproduce?10:51
michaedwasac was working out how to run equivalent benchmarks with current Linaro gcc10:51
michaedwand I want to do much the same10:52
michaedwonly with a few added wrinkles10:52
michaedwhas anyone tried building Android with the hard-float ABI?10:52
pm215I love the floop options, they have such a great sound. floop floop floop...10:52
michaedwpm215: but I want gloop, too10:53
michaedwbloop, floop, gloop!10:53
asacmichaedw: no we havent ;) would be interesting to see though10:57
asacits n our list somewhere 10:57
michaedwjserv--: specifically, I am interested in whether combining hard-float and the autovectorized load/store is a noticeable improvement over the load/store alone10:57
michaedwbecause I keep going around saying that it matters to let the compiler reorder NEON fetches across function calls10:58
michaedwand I would like some data in support of that claim :-)10:58
paulliuQuintasan: The OpenGL ES is provided by seperated library. It have to replace the mesa lib10:59
michaedw(It matters in principle, especially when the data is not in cache and you want a whole cache line's worth; but it's not clear whether the compiler will actually generate code accordingly yet)11:00
michaedwis there any way to hint to gcc that accesses through a given pointer are probably going to miss cache, and should be scheduled accordingly?11:01
michaedwI suppose that's a question for ramana or rsandifo11:03
jserv--michaedw, I heard Google Android guys were working on hardfp.  But I have no idea how they handle ABI.11:04
michaedwand probably not a question for 3AM my time :-P11:04
michaedwjserv--: the ARM EABI also has a hard-float variant11:04
michaedwso I don't see why I shouldn't be able to build a bare-metal toolchain that way :-)11:05
michaedw(i. e., defaulting to -mfloat-abi=hardfp -mfpu=neon)11:05
jserv--michaedw, I think it should be possible if you configure all JIT compilers off. (dalvik, v8)11:06
michaedwthat ought to be enough to unlock the vectorized fetch/store11:06
michaedwsure, it will break JITs11:06
rsandifomichaedw: I don't think there's a hint for that, sorry11:07
michaedwmmm, I bet hardfp will break ocamlopt; that's too bad11:07
michaedwrsandifo: I'm spoiled by Intel's auto-prefetch11:08
michaedwis, say, the cortex-a9 scheduler tuned for latencies to L2 or L3?11:09
michaedwand when deciding whether to do its fetches and stores from the NEON side, does it take into account its dedicated lanes to cache?11:09
michaedwrsandifo: I'm looking to see whether there are low-hanging fruit in accesses to uncacheable, write-combining memory11:11
=== TheDaniel0108 is now known as Daniel0108
rsandifomichaedw: I think the scheduler assumes an L1 hit11:12
ramanathe scheduler only works with the L1 hits. 11:12
michaedwhmm.  so if I want to force cold-cache-appropriate latencies, I need to do some fancy dancing.11:14
rsandifomichaedw: is scheduling really going to a significant factor?  Are these accesses in really big basic blocks?11:14
michaedwrsandifo: Qt glyph cache is one example11:15
michaedwhas to be mapped uncacheable so the GPU doesn't see stale data11:15
ramanamichaedw: in that case you are probably better off trying to put in intelligent preloads or use the feature that 4.6 has with automatic generation of preloads for cortex-a9 at O3. 11:15
ramanamichaedw: just noticed your next statement after writing my last one. if you have uncached data that's a different requirement. 11:16
michaedw(we have this problem on a non-ARM system today, where we can reliably force glyph corruption by running a large image through the cache — and thereby purging most of the real working set — and then rendering text, which stalls in the cache now that there isn't enough pressure from the rest of the working set to force it out before the render happens)11:17
michaedwI will probably have to trampoline through a buffer on stack11:18
michaedwand play stupid volatile games to keep the copies between the uncacheable area and the stack buffer from getting rescheduled around or optimized away11:19
michaedwwhat I really want is to label the pointer with __attribute__((writecombine))11:20
michaedwand have GCC know to schedule fetches based on latency to main memory11:21
michaedwand aggregate them up into cache-line-sized NEON multiple-fetch operations11:22
michaedwand especially to aggregate up the stores that way, so we don't pay the read-modify-write penalty11:22
michaedwbut that's a lot to ask of the compiler ;-)11:22
michaedwramana: can I get the auto-preload feature at -Os with an -f flag?11:23
ramanamichaedw: hmm with Os it will be interesting. 11:26
ramanaauto-preload generation requires a bit of unrolling which might not be very useful if you are at Os. 11:26
ramanafprefetch-loop-arrays is your friend11:27
ramanabut you need to set the appropriate params 11:27
michaedwI want -Os partly because we are tight on code size, but much more importantly because it's the same setting we use on non-ARM platforms11:27
ramanait needs to be used carefully though. 11:27
ramanaIt's not typically a combination that's tested by the compiler so you might run into issues. 11:27
michaedwand to the extent that it affects the front end (vs. code generation), I would prefer not to have that difference to diagnose11:27
ramanai wouldn't recommend doing that by default in a production system . 11:28
ramanai.e. Os + fprefetch-loop-arrays11:28
ramanawithout doing some tests. 11:28
michaedw(in case of compiler bugs or, far more frequently, bugs in the code being compiled that are differently exposed at -O3 and -Os)11:28
michaedwthat's what unit tests are for :-)11:28
davidgilukcan't you switch optimisation levels on a per-file or even per-function level these days?11:28
ramanayou can do that on a per-file basis depending on your build system11:29
ramanaper-function level ought to work but I don't think the ARM backend will cope well with that. 11:29
davidgilukprobably the safest thing would be to build most -Os and then the file that has the stuff you really want to optimise the heck out of do it with -O3 and the prefetch stuff11:29
ramanayeah 11:30
michaedwI will probably set extra CFLAGS on specific files, based on benchmarks11:30
ramanaif you wanted to use fprefetch-loop-arrays you do want to use the L1_CACHE_LINE_SIZE etc options that exist. 11:30
michaedwbut I'd like to be able to flip that specific flag globally and build benchmarks to see where it does some good :-)11:30
michaedwthose params aren't already set by -mcpu=cortex-a9 -mtune=cortex-a9?11:31
michaedwI already run into odd bugs by virtue of the fact that I compile the whole system at -Os11:32
zygamichaedw, good morning11:32
michaedwa few extras due to -Os -fprefetch-loop-arrays I can probably live with :-)11:32
zygamichaedw, still up or just up?11:32
ramanamichaedw: those parameters should be set up with mcpu=cortex-a9 I think 11:33
michaedwzyga: sadly, still up; I wanted a real-time conversation with a colleague in Norway11:33
zygamichaedw, I know the pain all too well11:33
michaedwwhy I'm still up an hour later is another question11:33
davidgilukmichaedw: You mentioned some bugs yesterday - have you got them filed somewhere?11:33
michaedwit looks like I will make Cambourne11:33
michaedwdavidgiluk: generally, yes; I didn't file a launchpad for the one that hit OpenSSL at -Os because I hadn't confirmed the fix yet11:35
michaedw(it was already filed upstream)11:35
michaedwbut it's now on ramana's radar11:35
davidgilukmichaedw: OK11:35
michaedwdid I mention anything else without a bug number?11:36
michaedwthe PI mutexes don't count, that's me failing to use a Linaro kernel ;-)11:36
* davidgiluk can't actually remember11:37
michaedwthe eglibc thumb-2 issue got filed and fixed long since, I think11:37
michaedwanother artifact of -Os11:37
michaedwltrace is still a bit of a mess11:37
davidgilukmichaedw: ltrace is less of a mess than it was; it's believed ther eis now a working version11:38
michaedwbut that's kernel-side again (ltrace wants the single-step ptrace API)11:38
davidgilukmichaedw: See bug 77180511:38
ubot2Launchpad bug 771805 in ltrace "[armel] ltrace hangs" [Undecided,Confirmed] https://launchpad.net/bugs/77180511:38
michaedwit may be willing to fall back to normal ptrace if the kernel refuses to offer it, rather than barfing when it's used11:39
davidgilukmichaedw: With the small patch in there and a recent kernel it apparently works11:39
davidgilukmichaedw; And if you can't get that to work, consider latrace that I got to work on ARM11:39
hrw~curse LIBRARY_PATH in gcc11:40
hrw~curse multiarch gcc patches too11:40
michaedwmmm, have you looked at the recent work on ltrace to make it handle multi-threaded programs more sanely?11:40
davidgilukmichaedw: No, I just hit it with a large hammer until it almost worked on ARM11:40
loolsuihkulokki: Hey, I see you posted a linux-user patch series on Monday, but I couldn't find the ppc/syscall_nr.h change we had discussed; is this in another pipe?11:41
michaedwvalgrind needed a bit more Thumb-2 love last time I tried it11:41
davidgilukhrw: Have you had the gcc testsuite to work on natty; I hit library path issues on things like libgomp and libmudflap tests11:41
hrwdavidgiluk: did not tested11:41
michaedwdavidgiluk: I will try your ltrace patch, and generally apply anything that's in natty and not in mine11:42
michaedwbut probably not today <g>11:44
loolmichaedw: when was that?  Julian Edwards cares about fixing thumb2/armv7 compat issues these days11:44
loolor at least did some months ago11:44
michaedw(right now I am trying to focus on things that block either getting a clean run of my atomic/lock-free/MT test suite — like the PI mutex issue — or getting working hard float OpenGL libraries)11:45
michaedwlool: I've been tracking that big "valgrind on Android" bug11:45
davidgilukmichaedw: Yeh that has an ldrexd/strexd fix - but only for ARM11:46
pm215Julian Edwards> do you mean Julian Seward?11:46
loolUh yes, sorry11:46
loolWe have a Julian Edwards in my company and I keep mixing the last names  :-/11:47
loolneed... brain... surgery...11:47
michaedwlool: http://pastebin.com/gdaFfZr511:47
michaedwdavidgiluk: can you tell offhand whether the unhandled instruction is a thumb-2 strexd or some such?11:49
davidgilukmichaedw: The thumb ldrexd is 0xe8d3 .... while the ARM one is 0xe1b2....11:50
michaedwdavidgiluk: 0xF3BF 0x8F2F ring any bells?11:50
davidgilukF? No11:50
michaedwmmm, and by the way, just to keep things fun, I am starting to look at big-endian11:51
loolmichaedw: do you have a bug tracking this, and a piece of source code or a binary you could share?11:51
loolideally a valgrind bug, otherwise a launchpad one11:51
davidgilukmichaedw: That looks like a thumb dmb 11:51
michaedwspecifically, running BE-8 binaries in a chroot in an otherwise little-endian system11:51
pm2150xF3BF 0x8F2F> CLREX, enc T111:51
michaedwyeah, that would be a likely opcode to be missing from valgrind :-)11:52
davidgilukmichaedw: Oh yeuch, you're THE big endian user ?11:52
loolmichaedw: gosh11:52
pm215what's the use-case for CLREX in user-mode code?11:53
michaedwdavidgiluk: not for my own sake; there is other Cisco code for which big-endian is … of interest11:53
michaedwpm215: there isn't one, really11:53
loolmichaedw: big-endian?  is this to work with some weird devices, or for performance reasons because you have to do less swaping11:53
michaedwporting old code that has always run on big-endian processors11:53
michaedwpm215: the clrex is only there because I patched gcc to put it in, so I could use the same compiler intrinsics for atomics in userland and kernel11:54
pm215not convinced you need it in kernel atomic intrinsics either, just in the context-switch code11:55
michaedwinitially I thought I might need it, based on a misreading of the ARM ARM, and wanted to be able to pair ldrex with strex/clrex in traces11:55
michaedwand also have it as a reliable marker of whether a given atomic had been generated with my compiler or not11:56
michaedwto flush out assembly implementations lurking in well-meaning userland packages (<cough> Qt <cough>)11:57
michaedwpm215: and you're probably right that I don't need it in general kernel atomics either11:57
doko_kenws: is uli online today?11:58
davidgilukdoko_; I don't think Ken is back until Tuesday12:03
doko_ok, thanks12:03
michaedwdavidgiluk: one more thing, while I'm thinking about it; if the trailing dmb is needed for GCC's atomics, is it also needed for Qt's, despite their "relaxed" memory semantics?12:13
michaedwI'm probably going to stick to what I've got (replacing Qt's assembly code with GCC intrinsics), whether or not upstream goes that route12:14
michaedwbecause, absent benchmarks, I am more interested in not having subtle bugs than in that particular micro-optimization12:15
michaedw(ditto the madness that is mutexes_cond_using_pthread_condvars.c in the SGX support12:17
davidgilukmichaedw, I don't know the innards of Qt12:18
=== xvilka is now known as xvilka-sceptic
michaedwdavidgiluk: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/49037112:20
ubot2Ubuntu bug 490371 in qt4-x11 "Atomic operations not safe for ARMv7,Thumb-2 and multicore" [Medium,Fix released]12:20
michaedwI was probably wrong about it being a problem for loads to get speculated into the critical region12:21
michaedwbut dmart's concerns are probably valid12:22
michaedwthey basically resemble mine in the GCC bug report12:22
michaedwdavidgiluk: maybe you or Marcus could circle up with dmart and settle that particular issue once and for all?12:24
davidgilukmichaedw, The Qt one?12:25
michaedwthe trailing-dmb-in-ordered-semantics one12:25
davidgilukmichaedw: I thought Marcus replied to your gcc bug saying you were right12:25
michaedwwhich it looks like we have agreement on in gcc, but not yet in Qt12:26
davidgilukthey should just use the intrinsics and be done with it12:27
davidgilukmemory ordering code is hard enough to think about without having 3 or 4 versions of the code12:27
michaedwthat's how I feel about it, all right12:29
michaedwand really I'd say the same about the kernel version, if it weren't for the desire to have their atomics independently audited and safe from compiler bugs12:30
michaedwand the existence of special cases like the context switch path12:31
michaedwdavidgiluk: should I try again with upstream, or ping the launchpad bug, or just point janimo at the GCC bug for comparison?12:33
davidgilukmichaedw, all of the above :-)   I guess it's worth checking if Qt actually defines the semantics in the same way - I mean a cmpxchg that didn't require the barrier in the fail case wouldn't be unreasonable12:35
michaedwdo you happen to know whether an inline assembly block will be kept contiguous even if it doesn't have the "memory" attribute?12:36
michaedwi. e., the compiler will schedule loads/stores across the assembly block if it isn't "memory", but will it plunk them between lines of the block?12:37
davidgilukI'd assumed it wouldn't but I don't know for sure12:37
michaedwbecause explicit memory accesses can't be allowed to creep in between the ldrex/strex pair12:37
michaedw(though Marcus has convinced me that speculative loads are not an issue)12:38
michaedwI also think that the ref/deref semantics ought to be fully ordered12:41
michaedwbut I don't know enough about Qt to insist on that, either12:42
michaedwjust enough to know I'm going to make them that way in my build ;-)12:42
Jay7btw, I can suggest good event in Russia to have some talk/presentation of Linaro for future possible developers :)12:43
michaedwanyhow, I have *got* to get some sleep.  'night12:43
michaedwah, Jay7!  Did you hear from Alexey?12:43
Jay7Chaos Constructions - this is yearly lan/demo/hack-party in St.Petersburg, Russia12:43
Jay7michaedw: hi12:44
Jay7michaedw: what I should hear? :)12:44
Jay7and from which Alexey? :)12:44
michaedwwe want to talk with you about kexec; he has come around to the idea that it may work better for us than u-boot12:45
Jay7didn't hear but ready :)12:45
michaedwnot that u-boot isn't good, but we have this splash screen requirement ...12:45
Jay7my spoken english isn't good but we may talk over irc (I hope my written english is better ;) )12:45
michaedwAlexey Polyudov, apolyudo@cisco.com; I'll try to make sure we circle up soon12:46
Jay7michaedw: feel free to propose time12:46
michaedwI suspect that, among the three of us, we can make the communication work :-)12:46
Jay7I'm following CET12:46
Jay7nice, hope we will made some progress :)12:47
michaedware you up in St. Petersburg now?  White Nights?12:47
Jay7no, I'm in Ulyanovsk :) but hights are short really :)12:47
Jay7my real TZ is MSK but I'm living in CET time :)12:48
michaedwwell, I'm in PDT, and I'm seeing 5AM from the wrong side, so I will have to go night-night now12:49
michaedwbut we'll hook up sometime early next week12:50
Jay7nice :)12:50
davidgiluk(he said that at 3AM_12:50
michaedwsp'konye noche (or something like that)12:51
Jay7michaedw: hehe, right :)12:51
=== xvilka-sceptic is now known as Carlos
=== Carlos is now known as xvilka
=== doko_ is now known as doko
armin76lool: got an origen board? :D13:09
loolarmin76: nope13:14
loolarmin76: do you?  :-)13:14
loollinaro got some though13:14
armin76lool: nope, i thought you were linaro :P13:14
loolarmin76: this is not a sufficient condition13:14
armin76oh :(13:15
armin76i know someone who has bought one, but he doesn't have it yet, afaik they haven't been shipped yet13:15
nytowlfabo, why is there no link at snapshots,linaro.org to the daily "build" directory ?13:25
rsalvetiasac: bug 78919813:49
ubot2Launchpad bug 789198 in linaro-ubuntu "Firefox crashes when attempting to play webm video OMAP4 Panda Board" [Medium,In progress] https://launchpad.net/bugs/78919813:49
rsalvetisent the merge proposals and also building a version for our ppa13:50
rsalvetibut will take some time still13:50
rsalvetiasac: should we have both a headline and an acceptance criteria per blueprint?13:53
asacrsalveti: dont know ... you can just try it out ;)13:53
rsalvetiacceptance criteria is good to have so we can validate that the work is really done :-)13:54
asacrsalveti: is the firefox patch upstream?13:54
rsalvetiyeah, will try to spend some time on it today13:54
asacrsalveti: i really think we should blueprints for the gcc cross packages (e.g. each deliverable should have something ... even if it just gives the reader some info what was done)13:55
rsalvetiasac: we don't yet have the real fix for it (fix the thumb2 support), I'm still building the latest daily package to report the bug upstream13:55
rsalvetiasac: yup, that's still my plan13:55
asacrsalveti: the merge proposal disables thumb2?13:55
rsalvetiasac: yes13:55
asacrsalveti: i can help you on massaging the blueprints (thats why i started) ... just dont want to do stuff you will hate :)13:55
rsalvetiwhile this is fixed upstream13:55
asacrsalveti: should we make the package available in linaro-mainatiners?13:56
rsalvetiasac: that's what I'm doing13:56
asacwould be a good headline ;)13:56
rsalvetiasac: package still building13:56
rsalvetiasac: yeah, if you have some time to spend on those BPs it will be really helpful 13:57
rsalvetijust didn't put a lot of stuff yet because the lack of time :-)13:57
asacrsalveti: sure. unfortuantely i am not fully up to date on whats going on etc.13:57
asacso i cannot split them up as i dont know if maybe some items are actually done ;)13:57
asacrsalveti: sure. just want to ensure that we have the things in the image that we really want 13:58
rsalvetiasac: don't worry, I'm planning to finish all that today, so just putting info like this headline is cool enough 13:58
asacso i might ask stupid quesitons13:58
asacah kk13:58
rsalvetisure, not a problem 13:58
asacrsalveti: what is hte status of the qemu-linaro egl?13:58
asaci started writing a headline, but then didn tknow what would get done so felt the headline might need to be different13:58
rsalvetiasac: suihkulokki reported that he got it all working in a state that can be released at the ppa, just fighting with one remaining bug13:59
asacrsalveti: but what of the work items does that cover?13:59
rsalvetithat almost 50% of the time you start es2gears it crashes with segfault13:59
rsalvetiyeah, he's not up-to-date with the bp WIs14:00
rsalvetiasac: and the bug doesn't happen when he fire it with gdb14:01
pm215the ppa> nb that this is not "qemu-linaro", just to avoid confusion14:01
alfrsalveti: asac: do we have a frozen LEB image I should validate my components against or should I just grab the latest snapshot?14:03
rsalvetialf: latest is enough14:04
rsalvetiit's the stable one, so it should be safe14:04
alfrsalveti: thanks14:04
rsalvetialf: what do you need to validate?14:05
alfrsalveti: glmark2 etc14:05
rsalvetialf: oh, ok14:05
asacalf: yeah for initial validation that should be enough. we have to run through this i guess for validating the final images too - wonder how we coordinate that.14:07
asacalf: can you write two lines for each component you validate so we can add that to release test plan?14:07
asacand hand it to fabo ;)14:07
alfasac: something like "install glmark2-es2, run it, ensure it shows something sensible" ?14:09
rsalvetialf: that's a start already :-)14:09
rsalvetiasac: more 7 hours to get firefox built :-)14:11
asacalf: sure. thats a good start ;)14:16
davidgilukramana: I might be able to fix that misplaced memory barrier in my 64bit atomic patch15:03
ramanadavidgiluk: if you can tease that bit out it might be useful .15:04
davidgilukramana: You mean as a separate piece of code?15:07
ramanadavidgiluk: if that's possible for a bug fix. 15:07
ramanasince it needs to be backported to 4.6 15:07
ramanaI'm not sure I want to backport 64 bit sync primitives for 4.6.2 FSF . 15:08
davidgilukramana, hmm ok, this is my 1st gcc patch so I'm not that quick at going through the process15:10
ramanadavidgiluk: sure. that's fine. 15:10
ramanaat this point the bug fix is of interest for 4.6.2 FSF (which is a few months away) - trunk - and Linaro 11.07 I'd suspect. 15:11
ramanathat's when it will make it into a release. 15:11
alfAny updated recommendations on what file system to use when creating linaro images (for best performance on panda)?15:27
=== prpplague is now known as prpplague^2
hrwalf: good usbhdd will beat any-on-sd16:17
=== TheDaniel0108 is now known as Daniel0108
alfhrw: agreed, but are there any recommendations regarding sd cards?16:20
davidgilukalf: Well there is some data https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?action=show&redirect=WorkingGroups%2FKernelConsolidation%2FProjects%2FFlashCardSurvey16:26
alfdavidgiluk: thanks, that is useful, but it still doesn't answer my question: assuming a good SD card, what filesystem should I prefer for general usage right now?16:32
davidgilukalf: I'd use ext3/4 - not for any good reason other than they tend to work16:34
davidgilukStskeeps, Hi16:55
hrwhave a nice weekend people16:56
rsalvetihrw: you too, see you in dublin17:04
rsalvetialf: I still prefer to use ext417:05
Stskeepsdavidgiluk: pong17:13
davidgilukStskeeps, That thing about the futex hanging - in that test are you sure it's legal to call an exit(1) where it's being called? In a signal handler as I remember?17:14
Stskeepsdavidgiluk: well, gnu gzip ships that test, but the thing is that the signal handler shouldn't happen i think, just printf getting ENOMEM17:16
dokoams_cs: online?17:27
ams_csdoko: hi17:28
davidgilukhttp://lwn.net/Articles/448726/ is kind of fun - security problem in crypt_blowfish on those odd machines that have signed char's17:28
davidgilukmight have confused people though; ARM won't have been producing the same crypt as x86 - although it sounds like that's about to get fixed17:30
=== agreen is now known as agreen-away
Quintasanpaulliu: What is the library that provides OpenGL ES? I have libegl1-mesa installed and you told me it's not that18:14
paulliuQuintasan: In Freescale BSP it is amd-gpu-x11-bin-mx51-11.01.00.tar.gz18:15
Quintasanpaulliu: Thanks!18:16
paulliuQuintasan: We split that to different binary debian packages. Which Conflicts, Provides and Replaces mesa lib18:16
QuintasanAwesome. Let me try doing that18:16
alfhmm, what is the password for the linaro ubuntu LEB? "linaro" doesn't seem to work...18:24
apacheloggerQuintasan: libegl1-x11, libgles1, libgles2, libopenvg1, libgles1-dev, libgles2-dev, libopenvg1-dev18:28
Quintasanapachelogger: What about those packages?18:30
apacheloggerwhat is package?18:33
Quintasan http://paste.kde.org/8718118:33
apacheloggerthat is the stuff you are supposed to replace18:34
apacheloggerQuintasan: imx_drv.c:33:25: fatal error: linux/mxcfb.h: No such file or directory18:34
Quintasantold you18:34
Quintasaninstall the .38 kernel18:34
apacheloggerI does not see that mentioned on the wikies18:34
apacheloggerQuintasan: what is the exact name?18:35
apacheloggerQuintasan: http://people.ubuntu.com/~apachelogger/tmp/debian/18:40
* Quintasan tries18:42
apacheloggerQuintasan: ditch linux-headers-2.6.38-1000-linaro-lt-mx518:47
* apachelogger has copynpaste fail all day already18:47
Quintasanconflicts, conflcts everywhere18:49
apacheloggermy chromium seems kaput :/18:52
apacheloggerQuintasan: how did you flash the .38 kernel?18:52
QuintasanI didnt18:52
QuintasanI just installed headers18:52
Quintasanand the image18:52
Quintasanand rebooted18:52
Quintasanbut it still is runing .3518:53
apacheloggerthen you are still running the .35 though? :P18:53
apacheloggerthat is fail my friend18:53
QuintasanThat crap of a package you made doesnt work18:54
Quintasani.e. replaces, provides etc dont really work18:54
apacheloggerwell, not on dpkg :P18:55
apacheloggerjust force it and then remove all the mesa stuff18:55
QuintasanSD Class 4 doesnt make it fast :P18:56
apacheloggerQuintasan: the good news is that the .38 kernel fails to bring up VGA18:58
Quintasanapachelogger: How exactly is that good news?19:00
apacheloggermore fun19:00
* Quintasan reboots board and tries plasma-mobile --opengl19:00
markos_doko, hi, are you one of the ecj maintainers as well?19:09
apacheloggerQuintasan: did you by any chance copy headers around?19:10
markos_doko, if that's so could you please take a look at #631070?19:10
Quintasanapachelogger: nope19:14
Quintasanapachelogger: ^19:15
apacheloggerQuintasan: are you running .38 yet?19:18
Quintasanapachelogger: there is no way I'm flashing it before you figure out how to bring up VGA19:28
apacheloggeryou can flash back19:28
QuintasanWhat would the point of such operation?19:28
apacheloggerperhaps I broke something and it is generally working19:29
Quintasanoh lulz19:29
Quintasanlinaro@linaro:~$ sudo flash-kernel 19:30
QuintasanCannot find a default kernel in /vmlinuz or /boot/vmlinuz19:30
apacheloggerQuintasan: sudo flash-kernel 2.6.38-1000-linaro-lt-mx519:30
apacheloggeror perhaps you broke your /boot :P19:30
apacheloggeractually it might be that the video bootargs are useless now19:33
Quintasanapachelogger: As in removing /boot/boot.scripts might help?19:35
apacheloggerperhaps not19:35
apacheloggerin fact removing stuff is a dangerous thing ^^19:35
QuintasanIn other words you want me to test it?19:35
apacheloggerlinaro@linaro ~/g/GPUSDK/demos % ./pageflip/pageflip_fb 19:36
apacheloggerEGL init failed19:36
QuintasanI wonder why there are is no doc about that19:36
Quintasanapachelogger: Why didn't we try the stock SD that came with the board?19:37
Quintasanon it19:38
apacheloggerbecause it is lucid meaning we'd have had to build all of a Qt and KDE19:38
QuintasanCan't you force install natty packages and pray it works?19:39
* Quintasan thinks it would work19:40
apacheloggerfeel free to try19:40
QuintasanI no longer have the stock contents of the card19:41
plarspfalcon: hi, quick question for you... on android-build, is there (currently or planned) an api for requesting a new build?19:57
pfalconplars: well, jenkins has such API, that's essentially what we use in the frontend (https://android-build.linaro.org/ is frontend app on top of jenkins)19:58
pfalconplars: we can "reexport" it if needed to talk in terms of build configs19:59
plarspfalcon: but that particular build already has to be defined in jenkins and you have to know the magic url right?19:59
pfalconplars: yes. it's also possible to create a new build job.19:59
plarspfalcon: is that documented somewhere?  trying to get an idea of what is possible, and how it would work20:00
pfalconplars: jenkins API index page is https://android-build.linaro.org/jenkins/api/ I'm not sure if it lists all APIs though, but googling for jenkins docs may give more info20:02
pfalconplars: generally, all you see at https://android-build.linaro.org/ is done via jenkins api, so it's possible to list jobs, get detail for one, create new, start build, get its current status20:03
plarspfalcon: does that all happen locally on the same machine? or is it via remote api like xml-rpc that you need to authenticate against?20:04
pfalconplars: it happens locally, AJAXy XML/JSON APIs, authed via HTTP basic auth. generally, nothing would preclude that to be done across hosts via SSL.20:06
plarspfalcon: ok, thanks20:06
=== Quintasan_ is now known as Quintasan
michaedwasac: if you're still puzzling over that Android / GCC 4.6 failure, I suggest you try with CLooG/PPL 0.15.1021:01
michaedwasac: see Ryan Hill's comment at http://patchwork.ozlabs.org/patch/77619/21:01
michaedwit seems that the combination of CLooG/PPL 0.15.9 and PPL 0.11.x is broken21:02
=== jkridner_ is now known as jkridner
=== Stskeeps is now known as Stskeeps|holiday
rsalvetiAmaranth: any news about the blend issue?22:02
=== prpplague^2 is now known as prpplague
Amaranthrsalveti: My workaround is to just comment out the call to glDisable(GL_BLEND) in nux22:18
Amaranthrsalveti: it causes other issues but it does work22:18
Amaranthrsalveti: should do it as a patch to the package though22:18
rsalvetiAmaranth: I tried that, the only annoying issue is that launcher never really goes away22:18
Amaranthrsalveti: Yeah22:18
AmaranthBut everything else works correctly22:18
rsalvetiany idea why launcher behaves this way?22:19
Amaranthrsalveti: haven't been able to figure that out22:21
ash_charlesrsalveti, just trying to test your EDID stuff on Overo attached to different screens22:22
Amaranthrsalveti: I'm going to get us back in sync with the regular DX team releases instead of using a random snapshot of things, hopefully that'll help22:22
rsalvetiAmaranth: yeah, ok22:22
ash_charlesrsalveti, I pulled from git://kernel.ubuntu.com/rsalveti/linux-linaro-2.6.38.git on the beagle-fixes branch...is this the best place?22:22
rsalvetiash_charles: currently I'd get linaro 38 or TI LT 3822:23
rsalvetiboth have the patches22:23
ash_charlesrsalveti, hmmm---display is not working for me with linux-linaro-2.6.38...msg about 'generic panel has no connector'22:24
rsalvetilet me check22:24
rsalvetiash_charles: can you boot with omapdss.debug=1 and drm.debug=7 and paste me your dmesg?22:26
ash_charlesrsalveti, okay---just rebuilding now.  What is best: build kernel with make and manually copy over or build deb and install?22:29
rsalvetiash_charles: for your testing just cross build it manually and copy uImage over, once you get a working kernel you can then generate a package :-)22:30
ash_charlesrsalveti, cool---that is certainly much faster :)22:30
ash_charlesrsalveti, http://pastebin.com/E4mpBeUA has these options enabled with a hwpack from yesterday.22:59
ash_charlesrsalveti, here is the one I just built: http://pastebin.com/an2qHbwm23:01
rsalvetilet me check23:01
ash_charlesrsalveti, I just tried with a different Tobi board (expansion board for the Overo) and the screen worked....urrg....I hate hardware sometimes.23:11
ash_charlesrsalveti, I think this looks a little better http://pastebin.com/1QPaYV1V23:11
rsalvetiash_charles: Not enabling generic panel as no connector is detected: means that it failed to probe the edid from i2c23:11
rsalveticheck drivers/video/omap2/display/panel-generic-dpi.c23:12
rsalvetithen [    4.073760] omap_gpu omap_gpu: tv has no driver.. skipping it23:12
rsalveti[    4.079925] omap_gpu omap_gpu: lcd35 has no driver.. skipping it23:12
rsalvetibecause it couldn't find the drivers for it23:12
rsalvetiprobably not compiled23:12
ash_charlesa standard hdmi/dvi monitor is supported by panel-generic correct?23:13
rsalvetiash_charles: yup, there you can see that it got the edid23:13
rsalvetiash_charles: yup23:13
rsalvetiash_charles: but the error message happens when it can't even probe a byte from the i2c bus23:14
ash_charlesrsalveti, this would indicate either an i2c problem or some problem with the display23:15
rsalvetiash_charles: yeah, but generally if it's an issue with the monitor you'll only get a invalid edid, or just 023:15
rsalvetibut you still get something23:15
ash_charlesrsalveti, the only reason I wondered is because I get the twl_i2c error often23:16
rsalvetihm, ok, that might explain23:16
ash_charlesrsalveti, i.e. twl: i2c_read failed to transfer all messages23:16
ash_charlesrsalveti, I'll give a lcd43 panel a try now23:17
rsalvetiyeah, it gets the i2c_adapter (meaning the kernel part is there), but probably fails while executing i2c_transfer23:18
rsalvetiwhen this happen the driver thinks there's no monitor attached to the board23:18
ash_charlesrsalveti, okay---I gave the hardware pack a try with an lcd43. http://pastebin.com/uA5g7xsA23:26
ash_charlesrsalveti, it looks like the display is detected but fails to initialize as per https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/79749123:27
ubot2Ubuntu bug 797491 in linux-linaro-omap "overo lcd43 touchscreen does not work" [Undecided,New]23:27
rsalvetiash_charles: yeah, seems this is the right bug23:31
rsalvetithat wasn't on my radar23:31
rsalvetiseems the patch is fine, will give it a try and see if we can still push it for this release23:35
rsalvetiash_charles: can you test and post your result at this bug?23:36
ash_charlesrsalveti, just testing atm...unfortunately it doesn't fix for me23:36
ash_charlesI'm happy to add to the bug report---what is the best practice for including log files? Attach? Pastebin?23:38
rsalvetihe had to add omapdss.def_disp=lcd4323:41
rsalvetilet me properly check your latest dmesg23:41
rsalvetiash_charles: either way is fine23:41
rsalvetiyeah, you get the same Not enabling generic panel as no connector is detected23:43
ash_charlesrsalveti, http://pastebin.com/SnfsnmkF is the log with the suggested patch applied.  I'm going to verify the panel itself just to make sure I don't have any hardware issues23:45
rsalveti[drm:omap_connector_init], lcd43: failed to enable: -1923:47
rsalvetiint ret = dssdev->driver->enable(dssdev);23:48
rsalvetiit's failing when running the enable function from the driver23:48
rsalvetiash_charles: can you try it again after adding "omapdss.def_disp=lcd43"?23:49
rsalvetithen there's also the drm_mode_vrefresh issue that it's not in that patch23:49
rsalvetibut described by the bug23:49
ash_charlesrsalveti, sure---I'll give this a go.23:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!