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