=== bjf is now known as bjf-afk === dyfet_ is now known as dyfet [10:17] hello [10:17] is someone running linux in qemu here by any chance?) [11:15] neure: We do from time to time [11:16] doko: Thanks for the upstart -fPIE hint; it's good enough for now to not build the testsuite with -fPIE on armel [11:19] do you have real hw also? [11:19] http://pastebin.com/m17a3f14e [11:19] in case someone can try [11:19] the thing just hangs in qemu :/ [11:20] im trying to figure out why, but I've got no good clues yet [11:56] neure: It works on x86 and not on armel? [11:57] neure: It hangs because you still have a thread running (the forever one); it needs to leave its loop and pthread_join [11:58] Or you need to cancel it [11:58] I don't think you strictly need to join it before exiting; I guess it's like free-ing memory before exit [12:06] the thing is [12:06] pthread_create doesn't return [12:06] yes [12:06] it works on x86 [12:06] and on armel.. it works if you run with gdb [12:06] without gdb pthread_create doesn't return [12:14] neure: It works for me [12:14] pthread_create... [12:14] entering forever [12:14] pthread_create done [12:14] pthread_detach... [12:14] pthread_detach done [12:14] calling pthread_detach() ok [12:14] in what system? [12:14] On an imx51 Babbage board running armel [12:14] right [12:14] (jaunty) [12:14] this seems to be qemu problem :/ [12:17] neure: What output do you get under qemu? [12:17] only the first two lines [12:18] if i run with gdb, it does all, which I find a bit strange [12:27] ogra: lool: any recipes to use the ethernet port on B2 to download kernels? [12:28] if you still use redboot it should work through http [12:29] our uboot-imx we'll use doesnt have networking support (though its likely faster to just cp the kernel to /boot on the SD anyway) [13:03] ogra: I shouldn't be using redboot? u-boot port is fully working now? [13:04] apart from networking [13:06] ogra: i just need something faster and more reliable than xmodem [13:07] uboot should work, but wait for NCommander to get up to confirm and being able to give you instructions [13:07] due to the fact that i dont have a B2 anymore i cant help much === cbrake_away is now known as cbrake [13:11] amitk: Things like: [13:11] ip_address -l 192.168.0.106 -h 192.168.0.103 [13:11] load -r -v -b 0x00f00000 -m http /initrd [13:11] load -r -v -b 0x00200000 -m http /vmlinux [13:11] amitk: But this is for another board [13:11] amitk: -l is the local IP address, -h the server address [13:11] amitk: You need to load the kernel last [13:12] amitk: You can find the addresses where to load stuff with fis list [13:13] lool: any special config for the http server? [13:13] -h is the server IP, I assume [13:14] amitk: Well just make sure you can get stuff using just the IP address [13:14] i.e. that wget http://x.y.z.w/foo works [13:14] amitk: 14:11 < lool> amitk: -l is the local IP address, -h the server address [13:14] Yes it's only IP; there's no DNS [13:14] ok, thanks lool [13:15] amitk: That said, I think it didn't work for me on B1 or B2 with latest redboot; perhaps you're lucky and it does; I think you might have to set the MAC address or BOOTP on startup or something like that in "fconfig", otherwise the NIC might not be initializes [13:15] *d [13:16] sigh [13:16] The ethernet driver used to be buggy with very old redboots on B1, but worked good enough for TFTP [13:16] i tried clone and it behaves exactly like pthread_create [13:30] sigh [13:30] i dont even need to create thread [13:30] just doing for(;;){} in one program totally blocks for example doing anything in the file system [13:30] even with nice -n 19 [13:32] neure: what libc/userland do you have? [13:32] this is standard debian lenny [13:33] Linux debian-armel 2.6.26-1-versatile #1 Sun Mar 15 05:49:36 UTC 2009 armv5tejl GNU/Linux [13:35] seems like qemu somehow breaks the scheduler :/ [13:35] i wonder if there is any way to improve it [13:50] lool: RedBoot> ip_address [13:50] Sorry, networking is not available. [13:50] :-/ === bjf-afk is now known as bjf [14:04] 2.6.26 has CFS, right? === bjf is now known as bjf-afk === bjf-afk is now known as bjf [16:46] what are the chances of an arm build of mplayer? I'm about to file a bug, but I figured I'd ask here first in case someone can give me some insight into the state of ubuntu-arm and why mplayer hasn't been built yet [16:47] http://launchpadlibrarian.net/28458535/buildlog_ubuntu-karmic-armel.mplayer_2%3A1.0~rc3%2Bsvn20090426-1ubuntu4_FAILEDTOBUILD.txt.gz [16:47] thats the build log [16:54] :'( [17:07] auntieNeo : I have a very low priority bug to fix mplayer. It's priority 6 [17:07] auntieNeo : Two codecs need porting, and they won't be easy to port [17:10] Martyn: mmm... alright [17:10] auntieNeo, and indeed patches accepted (as long as they dont break mplayer on the other arches) [17:10] :) [17:11] are they arm5 specific bugs? there's already an arm mplayer in debian... [17:12] ogra : Jån Jørgensen is working on fixing vlc [17:12] auntieNeo: the debian mplayer was fixed by cutting out code [17:12] it 'runs but doesn't work" [17:12] or doesn't fully work [17:12] :( [17:13] auntieNeo : VLC should work however [17:13] beyond that we target ARMv6 in ubuntu now [17:13] auntieNeo : So you're not without a video player :) [17:13] totem definately works atm [17:13] I'm an mplayer kind of guy ;P [17:13] jk [17:13] we definately focus in getting the default desktop 100% working [17:14] which means gstreamer and its frontends will work [17:14] if somone fixes other stuff or sends (or points to) patches nobody will stand in the way [17:15] yep [17:15] ogra : I found bugs with vfp and numerous other kernel bugs that cause OOPS and crashes in cortex-a9 [17:15] we've got a lot of work [17:15] idle_pm is also broken [17:15] on -a9 [17:16] * ogra would be happy to have kernels for the arches we currently support first before even thinking about -a9 [17:16] I've also asked my boss, and ARM, and Canonical to help me give you all access to the PBX-a9's [17:17] It's all parallel work. [17:17] getting these to work is hard enough atm [17:17] I'm already doing the heavy lifting on -A9, and have the entire dist working. I'm working on an installer [17:17] installing onto a USB drive doesn't yet work,and I'm working on debugging the issue [17:18] I mounts the root fs, but then claims that init is killed [17:18] bah who needs init anyway :D [17:19] considering I can't even get it to run /bin/sh .. [17:19] 8heh* [17:19] okay, off to work [17:51] hmm, why does xplc build flawless on debian but not for us ? [17:51] https://buildd.debian.org/fetch.cgi?pkg=xplc;ver=0.3.13-2;arch=armel;stamp=1233251415 looks fine [17:51] http://launchpadlibrarian.net/28443749/buildlog_ubuntu-karmic-armel.xplc_0.3.13-2_FAILEDTOBUILD.txt.gz doesnt === Nicke_ is now known as Nicke [18:44] Sarvatt, it started failing when they moved to lzma compression [18:45] that wouldnt happen to have been between 6-30 and 7-07 would it? :D [18:46] Sarvatt, sounds about right [18:47] Sarvatt, as I previous said, I setup the launchpad-buildd code so I could reproduce the full environment (I thought we had a possible hang in pkgstriptranslations) [18:47] Sarvatt, but once the build timeout was bumped long enough, I had a successful build [18:48] Sarvatt, bbiab [18:48] thanks for the info! [18:50] we need to get you slower hardware ! [18:50] so it matches the buildds [19:08] is it me or did qemu-arm slow down 10x in the past 6 months? 5 minutes to set up openssh-server! (2.4ghz turion x2 on x64) [19:12] * Sarvatt is scared to think how long mesa will take to build on a G1 [19:13] ogra, I just had a brainwave [19:13] OMG ! [19:13] (yay for 20 minutes of doing something else to kickstart the brant) [19:14] ogra, question one, did we change GCC to use VFP this cycle? [19:14] and if 1 is yes, has lzma been rebuilt since then [19:14] i think 1 is yes [19:14] and i dont know about 2 [19:15] ogra, of 2 is no, we might know why we're dealing with such epic slowness w/ lzma [19:16] ogra, no uploads since hardy [19:16] ogra, we *might* just have a winner [19:16] try a no change rebiuld [19:16] or probably forst a local one :) [19:16] ogra, I just popped on rimu to test my theory [19:17] ogra, I'll rebuild lzma, then start a build of mesa with my lzma in the PATH [19:17] cool [19:17] indeed that sounds like a valid theory [19:17] ogra, cold water to the brain can do that :-) [19:17] CONFARGS += --with-arch=armv5t --with-tune=cortex-a8 [19:17] #CONFARGS += --with-float=softfp --with-fpu=vfp [19:17] ? [19:18] Hrm [19:18] That's ... odd [19:18] thats 4.4.0-8ubuntu2 [19:18] I'm not sure if we're building with VFP or not now [19:19] Sarvatt: ssh-server creates a ssh server key - and that depends on available entropy [19:20] it took 5 hours to set up a build-essential seed qemu image with ogra's script :( [19:22] and it deleted it after aparently, DOH! [19:25] it creates a tgz if you dont tell it differently [19:25] thats its main purpose [19:25] ogra, seems my theory is a bust :-/ http://paste.ubuntu.com/218187/ [19:25] yeah i used --notarball [19:25] ? [19:25] er [19:26] ogra, we're not build w/ VFP ... [19:26] sudo ./rootstock --fqdn qemu-test --login qemu --password qemupwd --notarball --imagesize 3G --seed build-essential,openssh-server [19:27] mcasadevall, i thought we did already [19:28] ogra, doko says we're not [19:28] oh, right, not before the new HW arrives i guess [19:29] ogra, ok, so lets see what sort of difference VFP makes [19:29] for lzma? [19:29] yeah [19:30] you don't need testing to figure that out :) [19:31] suihkulokki, well, it might determine how we can easily fix out lzma makes ARM go *splat* boom [19:31] Sarvatt, well, that should keep an img file around [19:33] suihkulokki, -mfpu=vfp should do the trick, no? [19:33] mcasadevall: I can save your time - vfp wil have 0, nada, nil, etc difference for lzma [19:34] suihkulokki, ? [19:34] suihkulokki, why? [19:36] looks like it saved it to /tmp and got wiped on reboot, my mistake [19:37] ouch [19:37] it should have copied it to your current dir though [19:38] save_qemu_img() [19:38] { [19:38] cp $IMAGENAME $DIR [19:38] echo "I: Qemu image saved as $DIR/qemu-armel-$STAMP.img" [19:38] } [19:38] mcasadevall: why do you think it would have any effect? [19:38] DIR is $(pwd) [19:38] suihkulokki, I would think use of floating point operations would greatly speed up a compression engine written in C [19:39] * ogra rushes out to the store [19:40] thats odd, it was a ntfs-3g mounted partition i did it in because i was out of space, maybe a permission problem or something [19:41] mcasadevall: why would a lossless general purpose compressor use floats? [19:59] suihkulokki, indeed. so that theory is bunk [20:00] suihkulokki, Oh well. Got any good ideas short of creating a distlzma/distlzmad ;-) [20:16] mcasadevall: I suggest reading http://tukaani.org/lzma/benchmarks and the repeating the relevant parts on arm and selecting then a lzma/gzip compression level that makes sense [20:35] hi [20:36] i wonder if there are prebuilt images anywhere? [20:37] there are, for the imx51 architecture, nslu2 and qemu [20:37] oh great [20:37] where? [20:37] how come i failed to find them [20:37] http://cdimage.ubuntu.com/ports/releases/jaunty/release/ [20:37] the nslu2 one is a netboot one [20:38] as well as the versatile [20:38] which one is good for qemu? [20:38] http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/current/images/ [20:39] versatile netboot? [20:40] yep [21:19] mm how do i start this? [21:35] should i do something like: [21:35] qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.28-11-versatile -initrd initrd.gz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M" [21:35] ? [21:38] yeah [21:38] it worked [21:39] well at least it booted [21:46] Installing the base system [21:46] dumdidum [21:47] 0% [21:47] .. [21:47] this is going to take a while i guess [21:55] that Installing the base system progress bar could use some calibration :) [21:56] but i guess those are kind of hard [21:56] to get them right you'd need one calibration pass [21:59] awww this is really going to take a while [22:01] you know net installer was not exactly 'prebuilt' i had in mind [22:02] and here i am talking to myself :D [22:08] bae system.. 50% :) [22:08] base === j_ack_ is now known as j_ack === cbrake is now known as cbrake_away