| lool | persia: Wow flags: OC in /usr/share/binfmts/qemu-arm | 09:29 |
|---|---|---|
| lool | but flags: in /proc | 09:30 |
| lool | Pff someone typo-ed that | 09:30 |
| lool | persia: Just after fixing flags, it works | 09:36 |
| lool | persia: I can sudo | 09:36 |
| lool | No change needed to qemu | 09:37 |
| persia | Heh. It takes a night's sleep to try the obvious :) | 09:40 |
| 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:00 |
| persia | I saw the discussion in -devel. Looks promising :) | 11:01 |
| * persia presses the "me too" button | 11:01 | |
| lool | (works here) | 11:01 |
| ogra | sudo worked for me yesterday btw ... i only had a hostname not found warning | 11:03 |
| persia | ogra: OK. Were you root at the time? Based on the docs I read 12 hours back, it couldn't have worked. | 11:05 |
| persia | Because all setuid bits are being dropped by the binfmt_misc handler. | 11:06 |
| * persia notes that opening a chroot whilst not being root can be tricky | 11:07 | |
| 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:09 |
| 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:10 |
| ogra | hmm, and LP doesnt respond | 11:11 |
| ogra | heh, that just looked like a loose cable in the DC ... all back :) | 11:11 |
| 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:21 |
| 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:23 |
| lool | ogra: Did you file a bug? | 11:24 |
| lool | I didn't try running gtk+ apps | 11:24 |
| 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:25 |
| lool | Would anybody be interested in doing the reverse of the cleanup I did to the qemu versatile config? | 11:26 |
| 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:27 | |
| 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:28 |
| 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:29 |
| 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:32 |
| 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:33 |
| lool | cpuinfo doesn't matter for neon | 11:39 |
| lool | I just got the double free (fasttop) error when installing packages | 11:52 |
| lool | It's not specific to gtk+ apps | 11:52 |
| lool | It was during the ldconfig trigger | 11:53 |
| lool | startx segfaults in Xorg here | 11:55 |
| lool | I also get it with gtk-demo in Xorg | 12:04 |
| 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:08 | |
| 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:09 |
| apw | heh, lets hope it builds in there :) | 12:10 |
| ogra | wow, that changelog looks like someone nearly rewrote ext4 :) | 12:10 |
| apw | heheh | 12:11 |
| ogra | lool, i have no segfault with an .xsession that just contains xterm | 12:11 |
| lool | apw: This is boot speedup work for imx51? | 12:12 |
| ogra | lool, for ubuntu in general | 12:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| * 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:17 |
| 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:18 |
| apw | keybuk deals with all that side, i thought all devices were made which were registered in the kernel | 12:19 |
| 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:24 |
| lool | Setting MALLOC_CHECK_=0 I can actually run the app | 12:26 |
| asac | ericm_: -meeting? | 13:18 |
| lool | ogra: I definitely get the segfault when exiting from xterm | 13:25 |
| lool | "startx" startx an xterm, I ^D and I get a segfault | 13:26 |
| ogra | hmm, i didnt have one yesterday | 13:26 |
| lool | dmart: Hey | 13:54 |
| lool | dmart: I have this glibc errors which ogra mentionned | 13:54 |
| 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:55 |
| 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:56 |
| 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 | 13:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| lool | Ok; never tride this | 14:05 |
| lool | A simple g_slice checks works | 14:07 |
| lool | Folks, the glib atomics patch was removed in january | 14:07 |
| dmart | Hmmm, maybe we need it back in? | 14:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 | |
| 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:15 |
| lool | slice-test does pass though | 14:16 |
| lool | So it could also be a gtk+ issue | 14:16 |
| lool | In gtk+, the only failing test is abicheck; again the testsuite might not be running all tests | 14:17 |
| ogra | lool, it couls also be a codesourcery issue, lets wait for the actual archive build of versatile | 14:30 |
| * ogra still thinks its kernel related | 14:31 | |
| 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:33 |
| lool | Hmm it's not the same error as with ldconfig | 14:35 |
| lool | ldconfig was on fasttop, gtk+ is on !prev | 14:35 |
| ogra | lets be patient and see what an in-archive kernel brings us :) | 14:36 |
| lool | There's an experimental-malloc in eglibc which takes another code path | 14:40 |
| lool | MALLOC_CHECK_=0 G_SLICE=debug-blocks doesn't catch the error | 14:43 |
| 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:54 |
| 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:55 |
| === 18VAACOTE is now known as Meizirkki | ||
| 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:56 |
| 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:57 |
| 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:58 |
| lool | It's SLAB on versatile | 14:59 |
| lool | I think ARM requires SLAB anyway | 14:59 |
| dmart | /boot/config.blah says CONFIG_SLUB=y | 15:00 |
| ogra | yeah | 15:01 |
| dmart | dunno whether that's better though | 15:01 |
| 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:08 |
| 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:09 | |
| 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:10 | |
| lool | Ok; that worked, let's see if I can build a working kernel with it | 15:12 |
| lool | it built, but for some reason I'm missing disk drivers; /me tries again | 15:23 |
| === asac_ is now known as asac | ||
| lool | So it still fails | 15:35 |
| lool | I have CONFIG_SLUB=y | 15:35 |
| lool | Same symptoms | 15:36 |
| lool | dmart: Did you manage to test on real hardware? | 15:37 |
| dmart | not yet... trying to do too many things at the same time... | 15:40 |
| dmart | argh, more update problems | 15:41 |
| lool | What's the issue? | 15:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| lool | ogra: Is there a bug about the mono-runtime binfmt format that doesn't work with qemu? | 15:54 |
| ogra | no, there are plenty in debian i think | 15:55 |
| ogra | they all point to syscall 242 though which is nonsense | 15:55 |
| ogra | get_sched_affinity() | 15:56 |
| 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:57 |
| 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 | 15:58 |
| ogra | dmart, btw, do you use update-manager ? my upgrade works fine here just removes some stuff i'd rather keep, but still | 16:12 |
| 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:13 |
| 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:14 |
| lool | Gah karmic userspace doesn't boot with devtmpfs | 16:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| lool | I see some commits from you, so I guess you do :) | 16:24 |
| lool | You probably develop it too | 16:24 |
| suihkulokki | yep | 16:25 |
| suihkulokki | ogra: ...didn't stop you from shipping mx51 and dove kernels ? | 16:26 |
| 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:27 |
| ogra | s/arches/subarches/ :) | 16:28 |
| persia | Does mainline linux-omap work on qemu cleanly? Might be easier to align, rather than chasing -versatile. | 16:30 |
| * 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:10 |
| ogra | finally some progress ... | 17:11 |
| ogra | seems its actually an oem-config bug | 17:11 |
| ogra | phew | 17:11 |
| 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:15 |
| * ogra wonders why others sponsor fixes to rootstock ... why dont file people bugs so i can sponsor it :P | 17:16 | |
| 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:18 |
| 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:19 |
| ogra | i guess they are using it very rarely :) | 17:20 |
| ogra | probably even only testing it on x86 for milestones | 17:20 |
| * 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:22 |
| ogra | its like 50 mails already | 17:23 |
| ogra | nearly beats the "OMG OO.o was dropped by canonical" one | 17:23 |
| ogra | rm / | 17:28 |
| ogra | oops | 17:28 |
| persia | Um, did you really mean to run that locally? | 17:32 |
| persia | That command is usually followed by a ping timeout | 17:32 |
| ogra | heh, no i hit tab and was on an SD card subdir in another term :) | 17:34 |
| 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:02 |
| lool | I know you use NEON heavily, but I'm not sure you went through the thumb2 pain yet | 18:03 |
| lool | It's eglibc | 18:25 |
| lool | Well upgrading it breaks things at least | 18:25 |
| ogra | funny that we dont see it on real HW | 18:27 |
| 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:28 |
| ogra | anyway, break before the call | 18:29 |
| 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:20 |
| cwillu_at_work | also, when setting mpurate=720, how does one also bump the voltage, or is the recommendation to do that obsolete? | 19:23 |
| 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:02 |
| therealgalen | I'll get clearer | 20:03 |
| 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:06 |
| therealgalen | ojn, ogra, cwillu_at_work: does that give you a better idea the performance range I am looking at? | 20:07 |
| 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:08 | |
| 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:09 |
| 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:10 |
| 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:11 | |
| cwillu_at_work | ogra's tongue-in-cheek response makes sense now :) | 20:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| ogra | well its a reliable methot to measure ... at least in the blister/no blister area of precision ;) | 20:17 |
| ogra | *method | 20:17 |
| 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 | 20:22 |
| therealgalen | ojn: freescale's CPUs are very expensive! | 21:10 |
| therealgalen | at least the PPC line | 21:10 |
| persia | ogra: Did you ever find a good way to suppress the extensive "qemu: Ubsupported syscall:" lines? | 21:47 |
| lool | persia: Implement them? :) | 22:42 |
| 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. | 22:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!