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