[09:29] <lool> persia: Wow flags: OC in /usr/share/binfmts/qemu-arm
[09:30] <lool> but flags: in /proc
[09:30] <lool> Pff someone typo-ed that
[09:36] <lool> persia: Just after fixing flags, it works
[09:36] <lool> persia: I can sudo
[09:37] <lool> No change needed to qemu
[09:40] <persia> Heh.  It takes a night's sleep to try the obvious :)
[11:00] <lool> persia: LP #519228
[11:00] <ubot4> Launchpad bug 519228 in binfmt-support (Ubuntu) "Support for C flag (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519228
[11:01] <persia> I saw the discussion in -devel.  Looks promising :)
[11:01]  * persia presses the "me too" button
[11:01] <lool> (works here)
[11:03] <ogra> sudo worked for me yesterday btw ... i only had a hostname not found warning
[11:05] <persia> ogra: OK.  Were you root at the time?  Based on the docs I read 12 hours back, it couldn't have worked.
[11:06] <persia> Because all setuid bits are being dropped by the binfmt_misc handler.
[11:07]  * persia notes that opening a chroot whilst not being root can be tricky
[11:09] <ogra> persia, i have to be root to chroot :)
[11:09] <ogra> well, i usually dont use fakechroot or fakeroot :)
[11:09]  * persia uses schroot
[11:09] <ogra> ah, right
[11:10] <persia> The other option is to do something like sudo to some unprivileged user inside the chroot.
[11:10] <ogra> whoops, i just dropped off the canonical server
[11:11] <ogra> hmm, and LP doesnt respond
[11:11] <ogra> heh, that just looked like a loose cable in the DC ... all back :)
[11:21] <lool> ogra: Try su - someuser in your chroot, and then sudo something
[11:21] <lool> It wont work
[11:21] <lool> See above bug
[11:23] <ogra> yes, i just read it
[11:23] <ogra> lool, btw, do you see something like http://paste.ubuntu.com/371902/ trying to start any gtk apps in qemu ?
[11:24] <lool> ogra: Did you file a bug?
[11:24] <lool> I didn't try running gtk+ apps
[11:25] <ogra> not yet, i was researching oem-config and ran into it ... wanted to see if its only me or a missing dep in my minimal setup rootfs
[11:26] <lool> Would anybody be interested in doing the reverse of the cleanup I did to the qemu versatile config?
[11:27] <ogra> the reverse ?
[11:27] <lool> Basically there are some configs which I turned on and ended up being armel specific (or versatile specific; it's the same) but are useless and should be turned off again
[11:27] <lool> To minimize delta with other Ubuntu configs
[11:27] <lool> For instance CONFIG_MTD doesn't actually work with qemu/versatile, so could be turned off to reduce delta
[11:27]  * ogra doesnt really care as long as there are no lockups or other bad breakage
[11:28] <lool> Flags in debian.master/configs/armel/flavour.versatile should be examined
[11:28] <ogra> and i'm sure the kernel team wont care either unless they actually get a patch
[11:29] <ogra> if something gets in my way i'll research the issue and make a change, but if its just a silent delta i'm really not concerned
[11:32] <ogra> lool, i'm currently more worried about the glibc failure i have seen and start to suspect its caused by the v7 hack we use
[11:33] <ogra> since it only fakes the v7 CPU but doesnt actually add the features cpuinfo exposes (i.e. neon)
[11:33] <ogra> (not that i have run any neon capable apps, but you know what i mean i guess)
[11:39] <lool> cpuinfo doesn't matter for neon
[11:52] <lool> I just got the double free (fasttop) error when installing packages
[11:52] <lool> It's not specific to gtk+ apps
[11:53] <lool> It was during the ldconfig trigger
[11:55] <lool> startx segfaults in Xorg here
[12:04] <lool> I also get it with gtk-demo in Xorg
[12:08] <ogra> startx works for me if i just use xterm
[12:08] <ogra> as soon as i use a toolkit it breaks, plain X seems to work
[12:08] <lool> I get a segfault when Xorg quits
[12:08] <ogra> yay, imx51 with populate_rootfs \o/
[12:08] <lool> Try running startx, leaving  your session; do you have a segfault in /var/log/Xorg.0.log?
[12:08]  * ogra hugs ApOgEE__ 
[12:09] <ogra> opps
[12:09] <ogra> apw i meant :P
[12:09] <apw> ogra, ?
[12:09] <ogra> lool, only if i use toolkit based apps
[12:09] <apw> ogra, thank me if it boots for you
[12:09] <ogra> apw, <ogra> yay, imx51 with populate_rootfs \o/
[12:09] <ogra> i will as soon as i can get it from the archive :)
[12:10] <apw> heh, lets hope it builds in there :)
[12:10] <ogra> wow, that changelog looks like someone nearly rewrote ext4 :)
[12:11] <apw> heheh
[12:11] <ogra> lool, i have no segfault with an .xsession that just contains xterm
[12:12] <lool> apw: This is boot speedup work for imx51?
[12:12] <ogra> lool, for ubuntu in general
[12:13] <lool> Oh and it was borken on imx51?
[12:13] <ogra> it just didnt make it in yet
[12:13] <apw> its a rebase for security and stable updates, plus a couple of patches from brian for performance
[12:13] <apw> (boot performance)
[12:13] <ogra> we try to get all the sweetness from our mainline kernel backported now that the patches dont create any hassle
[12:14] <ogra> lool, the fsl patchset just applied smoothly this time so we actually have time for kernel improvements which we try pull in as many as we can from the ubuntu kernel
[12:14] <apw> dunno if you will gain anything with such cpu limited platforms, i assume brian tested it and measured it before asking for it
[12:14] <ogra> no weird forward porting makes everything so much easier
[12:15] <apw> shame they still frig about in usb, and then wonder why usb drives fail to work properly
[12:15] <ogra> well, the devtmpfs backport surely gained us a lot already
[12:16] <ogra> so i'm suspecting the populate_rootfs stuff will too
[12:16] <apw> ogra, 'surley' ... i am guessing noone tested
[12:16] <apw> ogra, in my experience its not a gain if you only have 1 cpu
[12:16] <ogra> i did and see 2-3 sec speedup
[12:16] <persia> apw: Note that there exists Ubuntu-compatible hardware for other architectures with even less CPU performance than most available ARMv7 hardware.
[12:16] <apw> persia, indeed, but we are not targetting any specific performance for them
[12:16] <ogra> are you talking celeron without L2 cache ? :)
[12:17]  * ogra has such a thing and its slower than my babbage board
[12:17] <lool> apw: I did test devtmpfs with 2.6.32 kernels in qemu, and I can say the MAKEDEV was taking more than 5 seconds in qemu
[12:17] <lool> apw: BTW, there are further MAKEDEVs on startup ATM, perhaps we could add more devices to devtmpfs and avoid one more call?
[12:18] <apw> saved about .2s on a real machine as i recall
[12:18] <lool> apw: /etc/init/mounted-dev.conf still calls /sbin/MAKEDEV fd in all cases
[12:18] <persia> ogra: That would be but one example of a large class :)
[12:18] <ogra> i dont think it was produced in large amounts actually
[12:18] <lool> apw: Also, I wonder whether we could avoid remounting devtmpfs on top of devtmpfs; that's probably not very long, but still...
[12:19] <apw> keybuk deals with all that side, i thought all devices were made which were registered in the kernel
[12:24] <lool> I get the glibc corruption with a minimal gtk+ program which does gtk_window_new + widget_show_all + gtk_main, but not without the window
[12:26] <lool> Setting MALLOC_CHECK_=0 I can actually run the app
[13:18] <asac> ericm_: -meeting?
[13:25] <lool> ogra: I definitely get the segfault when exiting from xterm
[13:26] <lool> "startx" startx an xterm, I ^D and I get a segfault
[13:26] <ogra> hmm, i didnt have one yesterday
[13:54] <lool> dmart: Hey
[13:54] <lool> dmart: I have this glibc errors which ogra mentionned
[13:55] <lool> dmart: I wrote a trivial gtk program which reproduces these
[13:55] <lool> and it aborts but, the backtrace is either useless or useless
[13:55] <lool> dmart: I've installed our -dbgsym packages for libc6, libx11-6, gtk, pango, and cairo
[13:55] <lool> I even got a gdb segfault at some point, but not consistently
[13:55] <lool> dmart: How would I track this down?
[13:56] <lool> I can break on main() in gdb, but when I get the actual abort, it's somewhere down the gtk internals, and it's hard to break on that
[13:58] <lool> Ah!  G_SLICE=always-malloc also fixes the bug
[13:58] <lool> So it's either a bug in glib'c gslice support on armel, or in glibc's memory checks on armel
[14:00] <dmart> Add some trace I guess, if you can't get a backtrace from the segfault/abort.
[14:00] <lool> What do you mean by add some trace?
[14:00] <dmart> Don't really have bright ideas here I'm afraid
[14:00] <lool> dmart: Do you find gdb useful on armel these days?
[14:00] <lool> It frequently crashes for me
[14:01] <dmart> Which version are you using?  lucid's gdb seems a lot more stable than karmic's gdb, but maybe I was lucky.
[14:01] <lool> lucid's latest
[14:01] <lool> 7.0 helped, but it's still crashy and frequently fails finding backtrace
[14:01] <lool> In this case, I get either a corrupted backtrace or an infinite loop
[14:02] <dmart> hmmm, is there any way you can reproduce the crash?  I often get no backtrace though.  I wondering whether some components are built in a way which nukes the backtrace; or maybe there's some broken unwind info support in gdb.
[14:03] <lool> The crash only happened one time out of 6 or so, but perhaps I will be able to reproduce it
[14:03] <lool> I suspect the versatile kernel under qemu might be having some issues of its own which don't help gdb
[14:03] <dmart> Maybe you can catch it with nested gdb
[14:04] <lool> dmart: So you gdb gdb?
[14:04] <dmart> I'm sure I've managed to do this in the past.  gdb has special support for this.
[14:05] <lool> Ok; never tride this
[14:07] <lool> A simple g_slice checks works
[14:07] <lool> Folks, the glib atomics patch was removed in january
[14:08] <dmart> Hmmm, maybe we need it back in?
[14:09] <lool> I suspect we do, that might explain my issue
[14:09] <dmart> Anyway why it was pulled out?
[14:09] <lool> Is https://bugs.launchpad.net/bugs/491342 the correct reference?
[14:09] <ubot4> Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released]
[14:09] <lool>   * debian/patches/70_glib2.0-gatomic-arm.patch:
[14:09] <lool>     - dropped since that patch was added without details nor reference
[14:09] <lool>       to a launchpad or upstream bug and it's not clear if it's still required
[14:09] <lool>       now with the change done upstream recently
[14:10] <lool> Seb, who removed the patch, had fixed it when syncing 2.23.1-1 over:
[14:10] <lool>   * debian/patches/70_glib2.0-gatomic-arm.patch:
[14:10] <lool>     - change to fix the build for armel
[14:10] <dmart> If the change is upstream, it shouldn't be needed; maybe take a look at the patch and make sure the relevant changes are in the code?
[14:11] <lool> Yes; glib wouldn't build without it, would it?
[14:11] <dmart> Probably not... it was a swp issue
[14:11] <lool> It built on armel
[14:12] <lool> https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342 was forwarded at https://bugzilla.gnome.org/show_bug.cgi?id=603780
[14:12] <ubot4> Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released]
[14:12] <lool> Which points at https://bugzilla.gnome.org/show_bug.cgi?id=531902 which is closed
[14:12] <ubot4> Gnome bug 531902 in general "Use GCC atomic buildins for g_atomic*" [Enhancement,Resolved: fixed]
[14:12] <lool>   Bug 531902 -  Use GCC atomic buildins for g_atomic*
[14:12] <lool> Summary: 	Use GCC atomic buildins for g_atomic*
[14:12] <ubot4> lool: Error: Bug #531902 not found.
[14:12]  * persia pets ubot4 for trying
[14:12] <dmart> :)
[14:13] <dmart> Looks like it was fixed upstream, so long as ubuntu's package is now based on the new enough version.
[14:13] <lool> It's merged in out glib2.0 ubuntu package
[14:13] <lool> checking whether to use assembler code for atomic operations... checking whether GCC supports build-in atomic intrinsics... yes
[14:13] <dmart> looks good
[14:14] <dmart> Perhaps your problems are caused by something else...
[14:14]  * dmart has do disappear for a bit
[14:14]  * dmart also can't spell
[14:15] <lool> I looked at the testsuite, there is one failure trying to create files in the non-writable home, another one on threadpool-test
[14:15] <lool> and there might be more since it doesn't complete
[14:16] <lool> slice-test does pass though
[14:16] <lool> So it could also be a gtk+ issue
[14:17] <lool> In gtk+, the only failing test is abicheck; again the testsuite might not be running all tests
[14:30] <ogra> lool, it couls also be a codesourcery issue, lets wait for the actual archive build of versatile
[14:31]  * ogra still thinks its kernel related
[14:33] <lool> I have the same issues with my own cross-gcc
[14:33] <lool> Which is based on a relatively recent FSF tree
[14:33] <ogra> hmm
[14:35] <lool> Hmm it's not the same error as with ldconfig
[14:35] <lool> ldconfig was on fasttop, gtk+ is on !prev
[14:36] <ogra> lets be patient and see what an in-archive kernel brings us :)
[14:40] <lool> There's an experimental-malloc in eglibc which takes another code path
[14:43] <lool> MALLOC_CHECK_=0 G_SLICE=debug-blocks doesn't catch the error
[14:54] <lool> Ah slice-test actually fail under my kernel
[14:54] <lool> dmart, ogra: Could one of you try on real hardware with lucid userspace?
[14:54] <lool> To check whether it's a toolchain or kernel regression
[14:55] <ogra> lool, i have no issues at all on imx51
[14:55] <ogra> since weeks
[14:55] <lool> just build slice-test from glib2.0
[14:55] <ogra> i'm not sure i can get to that today but will do so if nobody else does
[14:55] <ogra> my babbage is fully swamped today
[14:56] <dmart> I'll have a go... what's the easiest way to build just the affected test?
[14:56] <lool> dmart: unpack memchunks.c and slice-test.c from glib2.0's tests/
[14:57] <lool> dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c memchunks.c
[14:57] <lool> dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c slice-test.c
[14:57] <lool> dmart: And then basically gcc -o slice-test *.o `pkg-config --libs glib-2.0 gthread-2.0`
[14:57] <lool> (Sorry for the noise)
[14:58] <lool> So ./slice-test 1 c 100 works and ./slice-test 1 c 1000 fails
[14:58] <dmart> ok, I'll let you know what happens.
[14:58] <lool> It works up to 512 and fails starting at 513
[14:58] <lool> dmart, ogra: What's the kernel memory allocator on your kernel?
[14:59] <lool> It's SLAB on versatile
[14:59] <lool> I think ARM requires SLAB anyway
[15:00] <dmart>  /boot/config.blah says CONFIG_SLUB=y
[15:01] <ogra> yeah
[15:01] <dmart> dunno whether that's better though
[15:08] <lool> dmart: There was a recent post of slab versus slub on kernel-team@lists.ubuntu.com
[15:08] <lool> I don't know whether it's better or worse, but I care that it works or not   :-)
[15:08] <lool> versatile_defconfig has SLAB=y instead
[15:09] <lool> lpia, i386, amd64 and ports have SLUB=y; pretty much only versatile has SLAB=y
[15:09]  * dmart is still updating his fs
[15:10] <dmart> The versatile is probably derived from the ARM kernel trees, which tend to use a more traditional/embedded style config (for whatever reason)
[15:10]  * lool tries turning on SLUB
[15:12] <lool> Ok; that worked, let's see if I can build a working kernel with it
[15:23] <lool> it built, but for some reason I'm missing disk drivers; /me tries again
[15:35] <lool> So it still fails
[15:35] <lool> I have CONFIG_SLUB=y
[15:36] <lool> Same symptoms
[15:37] <lool> dmart: Did you manage to test on real hardware?
[15:40] <dmart> not yet... trying to do too many things at the same time...
[15:41] <dmart> argh, more update problems
[15:41] <lool> What's the issue?
[15:42] <armin76> ricing
[15:42] <dmart> Any idea what's causing the contents of the archive to be broken at the moment?  I get a load of conflicts
[15:42] <lool> dmart: I don't have that
[15:42] <lool> dmart: Perhaps some packages you have are missing on armel; I have a minimal chroot
[15:42] <ogra> mono
[15:43] <lool> Yeah I was about to mention it
[15:43] <lool> Currently mono-runtime is older than mono-gac
[15:43] <ogra> mono breaks the world and the desktop team made half the world depend on it
[15:43] <lool> So you can't install mono or ubuntnu-desktop
[15:43] <ogra> so lots of stuff is outdated
[15:43] <ogra> asac, is working on the mono ftbfs
[15:43] <dmart> Hmm, I didn't even find that among the conflicts.  But trying to install/upgrade ubuntu-desktop is certainly broken right now.
[15:43] <ogra> right
[15:44] <ogra> laincpad-integration and all the indicator- stuff are broken
[15:44] <ogra> anything that uses either will likely fail to install
[15:44] <dmart> Is that really all caused by mono?
[15:44] <ogra> yes
[15:44] <dmart> argh
[15:44] <ogra> most of the indicator bits hard depend on mono now
[15:45] <lool> Oddly it took 2 hours to build in karmic and has been building since 3 hours in lucid
[15:45] <ogra> as well as LP-integration
[15:45] <lool> Looks like the build hanged in configure
[15:46] <ogra> oh, and nautilus depends on mono as well now
[15:46] <asac> mono is a mess
[15:46] <asac> it opens zillions of files ... but only on arm
[15:46] <lool> asac: Does the buildd output looks normal to you?
[15:46] <ogra> lool, forget about the buildd :)
[15:46] <lool> ogra: ?
[15:46] <asac> lool: what do you mean?
[15:46] <ogra> for now we'd be happy to be able to build on sane HW we have full access to
[15:46] <asac> lool: i tried it locally and found that we hit the 1024 open files barrier
[15:46] <lool> asac: https://launchpad.net/ubuntu/+source/mono/2.4.3+dfsg-1ubuntu1/+build/1477421
[15:47] <asac> lool: no. that doesnt look normal
[15:47] <dmart> lool, looks like a won't have time to try and reproduce your issues right now
[15:47] <asac> and isnt what usually happened
[15:47] <lool> dmart: Ok; thanks
[15:47] <lool> I'd love to know whether this is kernel specific or not
[15:47] <dmart> sorry
[15:47]  * ogra smells one of the regular buildd segfaults
[15:47] <asac> yeah
[15:47] <lool> Perhaps someone else could try it on real hardware with up to date lucid?>
[15:48] <ogra> asac, you gave it back today, didnt you ?
[15:48] <asac> i tried it on real hardare
[15:48] <asac> same issue ... open files barrier
[15:48] <asac> i am now going to debug that
[15:48] <ogra> asac, i think lool means the qemu issue
[15:48] <asac> unfortunately i trashed the build tree
[15:48] <lool> asac: Did you complete a build after bumping the open file limit?
[15:48] <asac> oh
[15:48] <asac> sorry
[15:48] <asac> lool: no it failed later on jocote
[15:48] <lool> Yeah, I have an issue with glib under qemu
[15:48] <asac> havent tried to finish it here ...
[15:48] <lool> asac: Ah so no mono anytime soon
[15:49] <lool> I wanted to look into the double binfmt issue
[15:49] <asac> will do that after confirming for the mono guy which mono it is
[15:49] <asac> which files are kept open
[15:49] <lool> config.status: creating mono/arch/s390x/Makefile
[15:49] <lool> make: *** wait: No child processes. Stop.
[15:49] <lool> make: *** Waiting for unfinished jobs....
[15:49] <lool> make: *** wait: No child processes. Stop.
[15:49] <lool> Session terminated, killing shell... ...killed.
[15:50] <ogra> yes, we see frequent random segfaults on the buildds since a while
[15:50] <asac> thats not the real issue. most likely just random buildd bustage as ogra said
[15:54] <lool> ogra: Is there a bug about the mono-runtime binfmt format that doesn't work with qemu?
[15:55] <ogra> no, there are plenty in debian i think
[15:55] <ogra> they all point to syscall 242 though which is nonsense
[15:56] <ogra> get_sched_affinity()
[15:57] <lool> ogra: could you file a launchpad bug?
[15:57] <ogra> lool, i filed the one on the possible use of binfmt_ vs non binfmt_
[15:57] <lool> What is that?
[15:57]  * ogra cant remember the number
[15:57] <ogra> lool, bug 427863
[15:57] <ubot4> Launchpad bug 427863 in linux (Ubuntu) (and 1 other project) "binfmt allows breaking out of chroots due to not respecting namespaces (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/427863
[15:58] <lool> ogra: That one is blocked on information on your side
[15:58] <lool> Upstream and Kees both asked you for more info
[15:58] <ogra> which i dont really have time for to gather atm
[15:58] <lool> Since September?
[15:58] <ogra> yes
[16:12] <ogra> dmart, btw, do you use update-manager ? my upgrade works fine here just removes some stuff i'd rather keep, but still
[16:13] <dmart> No, that was via apt-get dist-upgrade.  I should probably switch to apt-get upgrade so it doesn't unexpectedly uninstall half the system :P
[16:13] <ogra> you are not using netbook yet i guess
[16:14] <ogra> for me only two indicators, rhythmbox, nautilus and the netboot-meta package are removed
[16:14] <ogra> stuff i can live with until it comes back
[16:17] <lool> Gah karmic userspace doesn't boot with devtmpfs
[16:18] <lool> This so sucks
[16:18] <suihkulokki> iirc the problem with mono in qemu is that it uses boehm gc which reads /proc/self/maps
[16:18] <lool> suihkulokki: that's a good point
[16:18] <lool> suihkulokki: Do you have any clue on the slice-test issues I have (see above)
[16:19] <lool> It's under qemu-system-arm with a versatile kernel, not qemu-arm-static
[16:19] <suihkulokki> havent seen any such issues
[16:19] <lool> suihkulokki: You can run gtk+ apps fine under qemu-system-arm/versatile?
[16:20] <suihkulokki> well, haven't tried versatile for ages
[16:20] <lool> You're using OMAP?
[16:20] <suihkulokki> but on omap2/omap3 no problems with our gtk
[16:20] <ogra> is omap stable already ?
[16:21] <lool> yeah, I've been tempted to switch to OMAP kernels for qemu
[16:21] <lool> suihkulokki: So which tree do you use to run qemu/omap?  plain upstream, or do you need linux-omap for qemu too?
[16:21] <ogra> is there enough in upstream to make use of it for qemu ?
[16:23] <suihkulokki> so far I've just used linux-omap kernels.
[16:23] <lool> suihkulokki: You're using the maemo OMAP3 qemu support?
[16:23] <ogra> sad, no distro option for us atm
[16:24] <lool> I see some commits from you, so I guess you do  :)
[16:24] <lool> You probably develop it too
[16:25] <suihkulokki> yep
[16:26] <suihkulokki> ogra: ...didn't stop you from shipping mx51 and dove kernels ?
[16:27] <ogra> suihkulokki, no, but for other arm stuff we can only refer to mainline, for these two arches the kernel team made explicit exceptions
[16:28] <ogra> s/arches/subarches/ :)
[16:30] <persia> Does mainline linux-omap work on qemu cleanly?  Might be easier to align, rather than chasing -versatile.
[17:10]  * ogra files bug 519398
[17:10] <ubot4> Launchpad bug 519398 in oem-config (Ubuntu) "oem-config with debconf frontent goes into endless loop (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519398
[17:11] <ogra> finally some progress ...
[17:11] <ogra> seems its actually an oem-config bug
[17:11] <ogra> phew
[17:15] <persia> Can you replicate with a normal desktop install, or does it only happen with rootstock?
[17:15] <ogra> no idea, i wont do any normal desktop install atm
[17:15] <ogra> since i a) dont have a spare desktop machine to test on and b) it takes extra time :)
[17:16]  * ogra wonders why others sponsor fixes to rootstock ... why dont file people bugs so i can sponsor it :P
[17:18] <ogra> persia, though given that the debconf frontend isnt used on desktops it would have to ba a server install i guess
[17:18] <ogra> *be
[17:19] <persia> Does -server support oem-config?
[17:19] <ogra> yes
[17:19] <persia> Aha.  Make them do the testing on !armel :)
[17:19] <ogra> you can do oem server installs nowadays apparently
[17:19] <ogra> how without HW and broken qemu ?
[17:20] <ogra> i guess they are using it very rarely :)
[17:20] <ogra> probably even only testing it on x86 for milestones
[17:22]  * ogra cant belive there is a thread in ubuntu-users about /bin/flase being to big
[17:22] <persia> I thought they had working kvm.
[17:22] <ogra> *false
[17:22] <persia> heh :)
[17:23] <ogra> its like 50 mails already
[17:23] <ogra> nearly beats the "OMG OO.o was dropped by canonical" one
[17:28] <ogra> rm /
[17:28] <ogra> oops
[17:32] <persia> Um, did you really mean to run that locally?
[17:32] <persia> That command is usually followed by a ping timeout
[17:34] <ogra> heh, no i hit tab and was on an SD card subdir in another term :)
[18:02] <lool> haha
[18:02] <lool> the slice-test issue doesn't affect karmic
[18:02] <lool> So it's either a toolchain regression or a qemu bug with thumb2
[18:02] <lool> suihkulokki: ^  :)
[18:02] <lool> suihkulokki: BTW do you use thumb2?
[18:03] <lool> I know you use NEON heavily, but I'm not sure you went through the thumb2 pain yet
[18:25] <lool> It's eglibc
[18:25] <lool> Well upgrading it breaks things at least
[18:27] <ogra> funny that we dont see it on real HW
[18:28] <lool> It might be a bug in qemu or linux/versatile with thumb2
[18:28] <ogra> yeah
[18:28] <ogra> i find versatile most likely
[18:28] <ogra> we just patch the CPU naming but nothing of the instruction set at all
[18:29] <ogra> anyway, break before the call
[19:20] <cwillu_at_work> there isn't a thermal sensor on the beagle is there?
[19:20] <ogra> use your thumb ?
[19:20] <ogra> :)
[19:20] <cwillu_at_work> I can't log my thumb :p
[19:23] <cwillu_at_work> also, when setting mpurate=720, how does one also bump the voltage, or is the recommendation to do that obsolete?
[20:02] <therealgalen> Hey, I'm looking for vendors who produce high-performance ARM CPUs for use with Linux... who's out there?
[20:02] <cwillu_at_work> like, ti?
[20:02] <ojn> therealgalen: depends on what you consider high performance to be. everything is relative.
[20:02] <ogra> freescale, marvell, qualcomm
[20:03] <therealgalen> I'll get clearer
[20:06] <therealgalen> I'm looking for ARM CPUs with PCI-Express support. Examples: Marvell 88F6282 (1.6-2 GHz), Marvell MV78200 (800 MHz - 1 GHz dual core), Cavium Networks CNS3420-700 (700 MHz dual core)
[20:07] <therealgalen> ojn, ogra, cwillu_at_work: does that give you a better idea the performance range I am looking at?
[20:08] <ojn> therealgalen: Marvell is the only provider with pci-express solutions to date, I think. most others are targeting mobile devices where there's less need for high-performance interconnects.
[20:08] <therealgalen> ojn: Cavium has PCI Express too
[20:08] <therealgalen> I'm trying to find if there are any others
[20:08] <ojn> Cavium makes ARM processors? I thought they were mips
[20:08] <therealgalen> Without wading through the 300+ ARM licensees
[20:08]  * ogra has only seen marvell boards with PCI 
[20:09] <ojn> ogra: dove has pci-e
[20:09] <ogra> and i'm not even sure these ones were PCIe
[20:09] <therealgalen> hey, a few starting points are better than 300+ :)
[20:09] <therealgalen> ojn: what is dove?
[20:09] <ojn> therealgalen: if PCI-e is a hard requirement, and ARM is a soft requirement, take a look at Freescale's PPC offerings as well.
[20:10] <ojn> therealgalen: The eval board for marvell's armv7 chip
[20:10] <therealgalen> ah
[20:10] <therealgalen> ojn: is it at all price competitive?
[20:11] <ojn> therealgalen: I have no idea where any of the vendors price their parts
[20:11] <therealgalen> the CNS3420-700 costs like $17/unit in 1k quantities
[20:11]  * cwillu_at_work should stop asking beagle specific questions in #ubuntu-arm
[20:12] <cwillu_at_work> ogra's tongue-in-cheek response makes sense now :)
[20:13] <therealgalen> man, powerpc...
[20:13] <therealgalen> a blast from the bast
[20:13] <therealgalen> *past
[20:13] <ogra> cwillu_at_work, nah, there are ,many people using our userspace on beagle :)
[20:14] <cwillu_at_work> ogra, I know, I'm one of them :p
[20:14] <cwillu_at_work> I just didn't realize I was in this channel:  I don't expect hardware questions to get good answers here :p
[20:15] <therealgalen> i'll just take whatever i can find, haha
[20:15] <ogra> cwillu_at_work, pfft
[20:15] <cwillu_at_work> ogra, you told me to use my thumb when I asked about the thermal monitor :p
[20:17] <ogra> well its a reliable methot to measure ... at least in the blister/no blister area of precision ;)
[20:17] <ogra> *method
[20:22] <ogra> cwillu_at_work, but you are right, i could tell you more about imx51 than omap currently my beagle B3 is sitting on the shelf collecting dust
[21:10] <therealgalen> ojn: freescale's CPUs are very expensive!
[21:10] <therealgalen> at least the PPC line
[21:47] <persia> ogra: Did you ever find a good way to suppress the extensive "qemu: Ubsupported syscall:" lines?
[22:42] <lool> persia: Implement them?  :)
[22:44] <persia> lool: Well, that works too.  ogra was talking at some point about some way to collect them and report each one only once or something.