[09:28] <cooloney> ogra: /win_xp/5
[09:28] <cooloney> ogra: sorry. typo
[11:16] <ogra> cooloney, intrestingly i think last time i tried suspend worked for me, it just didnt resume
[11:17] <ogra> i.e. there is no way to wake up the board
[11:58] <lool> asac: The logic to disable CONFIG_NEON in the kernel because chromium will pick it up if present seems bogus to me (LP #507416)
[11:58] <ubot4> lool: Bug 507416 on http://launchpad.net/bugs/507416 is private
[11:59] <ogra> lool, as i understood the plan is to switch it in the kernel at runtime/boottime
[11:59] <lool> ogra: Read the bug
[12:00] <ogra> i'm subscribed to it
[12:00] <ogra> however it doesnt match what was discussed on IRC
[12:00] <ogra> as i understood cooloney does have a patch that can switch it dynamically
[12:01] <lool> Yes, that's what he says in the bug
[12:01] <ogra> right
[12:01] <ogra> so apps can look at cpuinfo and switch accordingly
[12:01] <lool> It's not cpuinfo but whatever
[12:01] <ogra> if apps cant do it we'll have a -neon package of selected apps
[12:11] <asac> lool: yes, the way he refers to chromium is odd ;)
[12:11] <asac> i think thats none-sense
[12:11] <asac> chromium will use either no NEON
[12:11] <asac> or runtime detection ...
[12:11] <asac> but upstream doesnt want to do that so the patch would need to come from us
[12:11] <asac> so plan is to make a special NEON build available so we can compare benchmark
[12:12] <asac> and if its worth it consider doing the real implementation
[12:26] <cooloney> hi guys, am i wrong with the NEON issue?
[12:26] <cooloney> i am quite confused indeed, heh
[12:30] <ogra> thats the drugs :P
[14:40] <asac> plars: so
[14:40] <plars> asac: yes?
[14:40] <asac> plars: if you install dove alternative ... and use ssh to log in
[14:40] <asac> and start apps
[14:40] <asac> do you still get the lock-up?
[14:41] <asac> not sure if you already answered that
[14:41] <plars> asac: haven't tried since last week, but I have no reason to suggest that it changed.  All I was doing was booting in single - works booting to full gui - doesn't
[14:42] <asac> plars: right. so what we should do in any case is figure if its really dependent for some comüponent
[14:42] <plars> asac: with alternate, it recycles through the GDM constantly many times before locking up.  With live image, the login is bypassed and it goes right into a session, where it locks before coming up completely
[14:42] <asac> so imo logging in using ssh and seeing if X apps still work would be great to narrow down to X server/graphics driver
[14:42] <dmart> Could be worth trying to bring Xorg by hand
[14:43] <asac> plars: yes, i mean: try to not start X ... check if X apps alone over ssh trigger this. if not try to start X with stripped down features etc.
[14:43] <asac> until we know what is causing this.
[14:44] <plars> asac: I'll install with latest alt and give it a try in a bit, have to run to a doctor appointment right now
[14:45] <asac> ok thanks
[14:45] <asac> plars: the gdm restarts ... are those SIGILLs?
[14:46] <dmart> If we get SIGILL, we at least have some chance to debug...
[14:46] <plars> asac: didn't catch if they were or not, very possibly
[14:48] <asac> so gdm restarts ... gnome-panel restarts
[14:49] <asac> when does it lock-up completely?
[14:49] <asac> just random i guess
[14:53] <asac> NCommander: can you kick off a gcc-4.4  package build on your dove? we might get something out of that from the testsuites run at the end of the build
[14:58] <asac> ok out for some errand
[15:30] <ogra> dmart, ping
[15:51] <ogra> dmart, unping (solved the issue)
[15:51] <dmart> unpong
[15:51] <ogra> heh
[16:10] <GrueMaster> Now that is a true sign of nerddom.
[18:14] <armin76> asac: btw, chromium works fine here with v8 disabled...
[18:14] <armin76> iow, it fails to run on armv5te only
[18:14] <armin76> with v8 enabled v8 fails to build, with it disabled it fails to run :D
[18:15] <armin76> however on armv7 works both ways
[18:15] <armin76> guess it fails on <armv6j
[19:06] <asac> armin76: v8 disabled?
[19:06] <asac> so basically nothing?
[19:11] <armin76> asac: you know, the snapshot=false thing
[19:11] <armin76> javascript works anyway
[19:11] <armin76> it just doesn't on armv5te
[19:20] <asac> kk
[19:20] <asac> snapshot=true builds and just crashes?
[19:20] <asac> armin76: ?
[19:32] <armin76> asac: on armv5te, snapshot=true fails to build, false fails to render any js page
[19:35] <asac> armin76: fails to build or crashes during build? in mksnapshot?
[19:37] <armin76> crashes during build, mksnapshot
[19:50] <armin76> asac: http://dpaste.com/147596/
[19:52] <asac> armin76: for us it crashed there with gcc 4.4 because of inlining bug
[19:52] <asac> -fno-tree-sink or -fstrict-aliasing worked
[19:52] <asac> but i guess you face a different issue
[20:00] <armin76> asac: its gcc-4.3 and works on armv7, so...
[20:00] <asac> ok
[20:06] <NCommander> asac, re: building gcc-4.4 (sorry for the delay on this work item): my dove board keeps hanging or gcc segfaults
[20:07] <armin76> you broke it
[20:14] <asac> NCommander: while building or in the testsuite?
[20:15] <NCommander> asac, while building
[20:17] <NCommander> asac, I'm going to try one more trick up my shelve before giving up completely, but its not pormising
[20:17]  * NCommander sighs
[20:18]  * NCommander just hung in apt-get update
[20:20] <asac> NCommander: are you running lucid?
[20:20] <NCommander> asac, yup
[20:40] <asac> NCommander: so trick didnt work?
[20:41] <asac> maybe this gives more when run inside gdb session?
[20:41] <asac> i mean... just the gcc compile
[22:24] <plars> wow, that's just crazy
[22:24] <plars> I think it's bootchart that's killing it