#ubuntu-arm 2009-09-01 <ali1234> does console-kit-daemon really need to use all spare cpu time or is it a bug? <lool> ali1234: it's a bug <lool> ali1234: What environment do you see this in? <ali1234> lool: i'm running on omap850 after using the "root from scratch" script with --seed=lxde,gdm <lool> ali1234: Could it be an option missing from your kernel? <ali1234> yes, it certainly could. but which one? <lool> ali1234: I would strace consolekit to see whether it's failing a syscall or something like that <lool> ogra: Did you ever see 100% used with CK? <lool> I didnt ever see this <ogra> nope <ogra> but i remember the desktop team had a bug about it early in jaunty ... though that was fixed for release <ogra> CK did spawn threads endlessly iirc <ali1234> i saw that bug on launch pad, it seems to be a memory leak issue with lots of ssh connections. i only have one <ali1234> strace just says: restart_syscall(<... resuming interrupted call ...> <ali1234> then nothing <ogra> hmm, why dont we have a dove image today <ali1234> it almost is a kernel issue since i'm using 2.6.25 and no particular config <ali1234> *almost certainly <ogra> lool, Couldn't open .flint/dbw/postlist.baseA: Too many open files <ogra> Couldn't open .flint/dbw/postlist.baseB: Too many open files <ogra> ) <ogra> do you think it's worth trying to giv that back ? <ogra> (thats xapian-core) <ogra> seems like a buildd issue <lool> hmm <lool> Any other build like this? <ogra> nope <ogra> xapian seems to hammer the disk during its test phase <lool> I guess you could give it back <ogra> we have two idling buildds, i'll just try <lool> ogra: livefs failed to build <lool> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu-dove/latest/livecd-20090901-armel.out <lool> empathy: Depends: libmissioncontrol-client0 (>= 4.37) but it is not installable <ogra> ah, yeah, empathy <lool> evolution and others <lool> evolution: Depends: evolution-common (= 2.27.90-0ubuntu2) but it is not going to be installed <ogra> i just gave back evo, it always needs handholing <ogra> seb never waqits until the "all" packages are published <ogra> hmm, xapian has the same issue on ia64 <ogra> and on sparc <ogra> lool, i dont get why dove wouldnt use an older livefs as all other arches do though * ogra pbuilds xapian-core locally <lool> Oh that's unrelated, I actually broke the build but I fixed it now <lool> Well I think, I'm test building <lool> poumpoudoum <ogra> poumpoudoum ? <lool> lalala if you wish <lool> ok it built <lool> hmm that's bad <lool> /home/lool/cdimage/debian-cd/tools/pi-makelist-vfat: Couldn't list any drive <ogra> oh <ogra> i thought you were talking about xapian and wondered whn you secretly pushed that to the buildds :) <ogra> ETOOMANYTOPICSATONCE <lool> Oh <lool> We never actually cared to support partition=1 in pi-makelist-vfat <lool> only no partition or part 2 <ogra> which didnt fail since we never used partition 1 yet <lool> Hmm oddly it doesnt work with partition=1 either <lool> Ok found another bug in that script which went unnoticed <lool> Oh no it was just local to my edit, some typo during copy-paste caused a lowercase or something <lool> and it worked, cool <lool> all deployed, just waiting to confirm I can kick a rebuild <lool> Sure enough http://cdimage.ubuntu.com/ports/daily-live/20090831/karmic-desktop-armel+dove.list was empty <rabeeh> lool: which machine are you using for that build? <rabeeh> lool: are dove machines already part of the buildd cloud? <ogra> rabeeh, nope <lool> rabeeh: No, imx51 based <ogra> we hope to add dove soon though <lool> rabeeh: I dont think we can get z0 stable enough and we dont have enough yX <rabeeh> isn't that incremental work? meaning if you have 1 yx then you can add to buildd, and if you have 2 then you can add 2? <lool> My main worry is silent breakage: it might be ok if a buildd goes completely missing and has to be remote rebooted but it's not ok if it breaks in the middle of a build: it could either cause a subtle breakage to go unnoticed and if it actually fails the build we cant distinguish hardware errors from software ones which we need to fix :-/ <rabeeh> i mean you can start with what you have, and get more soon. <ogra> but we dont have a single one we can spare yet <lool> rabeeh: I think we could start like that, but we have no facility to schedule builds on this or that buildd <rabeeh> so, what is the yx board allocation o buildd/developer? <rabeeh> btw - is it possible to set a board remotely part of a buildd? <rabeeh> for example i have my own y0 board; that is free at nights and weekends; can i set it (behind a firewall) to be part of the buildd cloud? <rabeeh> (i know; this is intermediate solution until you get the amount of boards you have requested) <ogra> we have 7 armel buildds atm ... https://launchpad.net/builders <rabeeh> for example, you can never ssh to the board; but the board can poll and pull build requests from the web <ogra> and as you can see currently two are idle, one is in maintenance <ogra> having more doesnt really help, having faster ones will ... <ogra> which is why we look forward to add doves <rabeeh> hmm. why? <ogra> because one package is built on one buildd <ogra> if you take openoffice it takes about 36h to build <rabeeh> but they are idle :) <rabeeh> don't they have queues for karmic builds? <ogra> having it building in 24h would improve ... having one more buildd wouldnt help speeding it up <ogra> its not a cluster where adding more power would improve anything for the single build <ogra> adding more machines just lets the qeue get empty faster <ogra> butu the queue as you can see is empty most of the time ... it might indeed help at high times where you have tons and tons of uploads <ogra> the amount of 7 machines is quite ok ... replacing them incrementally with doves will help a lot but we currently need the few doves we have for development and QA of the dove image we build <rabeeh> which machines you have here are running on discovery 78100? <rabeeh> i recall canonical had few of those machines for jaunty armv5 armel distro <rabeeh> my point is can we use armv5+vfp machines for armv6+vfp? <ogra> right, but after the alpha5 release (thursday) we will default to only build for v6 <ogra> no, you cant use v5 machines for that <rabeeh> (implementing software instruction abort handlers for the armv6 part) <ogra> thats why we currently are stuck with imx51 machines <ogra> how stable would such a software layer be ... how much slowdown would you get through such an additional layer <rabeeh> well. it's hard to guess; but armv6 has big SIMD addition; which is never used in integer/floating based application <lool> sorry had an UPS delivery <rabeeh> it is used in packages like ffmpeg; and might only break if the debian/rules calls some test to use that <lool> and it's broken so I need to deal with it <rabeeh> lool: hope it's not Dove :) <lool> It's not :) <ogra> my assumption is that if you develop such a layer to run on v5 buildds you invest a lot of time to make sure its stable enough, do QA on it etc <ogra> and i bet once you are done the amopunt of y0 we want is available :) <ogra> so using imx51 until that point serves as well without risking stability <rabeeh> right. and i'm looking at the instruction set addition; and seems lots of instructions being added <ogra> right <rabeeh> will take lots of time to implement those exception handlers <rabeeh> ogra: what i can promise is that y1 boards will come with 1GB of DDR :) <ogra> effectively you would end up with something like qemu-arm inbetween the CPU and userspace <ogra> WOW ! <rabeeh> right <ogra> that will make a huge improvement ! <ogra> the diskspeed already is a huge improvement on the dove vs imx <ogra> adding more ram will make the builders fly :) <rabeeh> personally i think we should have buildd version of dove <rabeeh> overclocked and even more DDR <rabeeh> lunch time :) ttysw <ogra> :) <lool> rabeeh: It's common for packages to call binaries from others; not frequent but common enough that it needs to work well; for instances all GStreamer apps call the equivalent of gst-inspect on startup which will cause all plugins to be loaded <lool> Including ffmpeg <lool> (Now Gst is a special case because it actually traps sigill but still :) <rabeeh> ogra: back to the original question; is it possible that put my board part of the buildd cloud? (inside a firewall) <rabeeh> lool: got it. <ogra> rabeeh, nope, our IS team wouldnt allow that i guess <tlee> Has karmic's arm build system move to vfp yet? <ogra> after alpha5 we'll move immediately <tlee> Thanks Ogra. How many days (weeks) is that from now? Also how long you think it would take to rebuild all the packages? <ogra> alpha5 images will be released on thursday <ogra> (including a dove live image btw) <ogra> testing appreciated :) <ogra> no idea how long it will take to rebuild the whole archive ... i'd guess a week or two <ogra> lool, any idea ? <lool> ogra: we moved already <lool> to vfp <lool> tlee: we're using v6+vfp at the moment <ogra> oh ! <lool> We wont rebuild the archive <ogra> dont we do a complete rebuild anyway during the process ? <lool> What do you mean? <tlee> wow. <ogra> lool, on the std arches we usually do a complete archive rebuild before final <ogra> https://wiki.ubuntu.com/KarmicReleaseSchedule spt24th <ogra> *sept <ogra> and oct 15th <lool> ogra: That's out of archive <lool> We dont keep the results <ogra> oh, i thought we did <lool> ogra: So did you get like thousands of packages to download on the week before release? :) <ogra> why would i if the versions dont change <lool> ogra: Because the binaries arent identical <lool> ogra: It would be a terrible idea to have two .debs with different md5 and contents named the same thing and using the same version; we never do that <ogra> oh, indeed <lool> And it's also why we wont rebuild the whole archive just for armel <ogra> yeah, understood <ogra> thast a bit sad though <lool> Not too much <lool> But it's why the lack of buildd was such a big deal <ogra> indeed <lool> But given the number of uploads before release it's not that bad <ogra> true <ogra> problematic is that we wont see fallout caused by the setting for packages that werent uploaded <ogra> we'll likely hit the ftbfs'es for these in karmic+1 only <tlee> Have any of you seen this "BUG: soft lockup - CPU#0 stuck for 61s!"? <ogra> nope, not on armel yet <tlee> Google it and it seems to happen a lot of times in kernel. <ogra> i have seen it on via eden <ogra> and other thin clients i worked with (geode etc) <tlee> orga: turn on nullmailer and see if you can see what I seen on karmic. <ogra> oh, wait, looking at my dmesg ... <ogra> http://paste.ubuntu.com/263307/ <tlee> I believe I have 400+ email Q to send out and nullmailer is trying to run every few minutes. Seems to trigger that erorrs for me. <ogra> it's currently doing a heavy duty build <tlee> on Karmic. Quite offer. <ogra> NCommander, http://paste.ubuntu.com/263307/ <tlee> On Jaunty, I see the bash has issue. <ogra> NCommander, watch your dmesg on the dove under load, appears to be a kernel bug <tlee> On Karmic, seems only the nullmailer. <ogra> well, i'm building a package here <ogra> and it seems to have been triggered by bash <tlee> Do you know any method to help track this bug down? <ogra> i pinged bjf in #ubuntu-kernel <bjf> orga, I can *sigh* here just as easily <ogra> heh <ogra> note that i use the -201 build still <bjf> ogra, oh! well that's obviously your problem :-) <ogra> not sure if 202 or 203 fix it, but i guess tlee runs something newer <ogra> i cant replace the kernel before webkit isnt finished, i need the log <ogra> and that might go on for the rest of the nigh ... <ogra> +t <bjf> ogra, I'll boot mine up and see what I see <ogra> i didnt see it before <ogra> seems to be load related <tlee> orga: what do you mean by 201, 202, 203? <ogra> the kernel builds <ogra> its the ABI version of the packaged kernels we use <bjf> tlee, you will see the version as 2.6.31-203.8, the 203 is the API versions <ogra> http://ports.ubuntu.com/pool/main/l/linux-mvl-dove/ <tlee> I am still back in 2.6.30. I built 2.6.31 last week, have not try it yet. <ogra> linux-image-2.6.31-203-dove_2.6.31-203.7_armel.deb is the current package <ogra> (i think there is one pending in the queue though) <bjf> ogra, yes there is one "in the queue", it has some of the latest mvl changes and we are building zImages instaed of uImages <ogra> yeah, i saw the thread on the ML <tlee> Ok, I will try to sync it up tomorrow. Have some demo to do today. Don't want to mess with the demo god for now. <ogra> heh <bjf> tlee, I hear that! <tlee> I am in trouble now. Lighting is stiking from above..... run ..... :-) <ogra> haha <NCommander> ogra, yeah, I've seen that. Thought it was an issue with the old kernel I was using <NCommander> It didn't reappear since I updated to a 202 kernel, although I haven't been using that as extensively <NCommander> actually <ogra> ok, i'll see what 203 does for me then <NCommander> er <NCommander> 203 <NCommander> er, 202 or 203 <NCommander> I used to get it trying to spin livecd-rootfs's <NCommander> then it went away when I updated the kernel <tlee> There is no uImage in the linux-image-2.6.31-203-dove_2.6.31-203.7_armel.deb. How do I make the uboot to load vmlinuz? #ubuntu-arm 2009-09-02 <NCommander> tlee2, you have to use the mkimage command <NCommander> tlee2, we made that change to make other things in our backend work a bit more sanely :-) <erikcorry> Anyone awake? <erikcorry> I tried rootstock. <erikcorry> It did a whooole lot of work. <erikcorry> I'm wondering if it made anything. <erikcorry> No new files in current directory. <erikcorry> Where should I be looking? <ogra> there should be files in the current dir <ogra> what was the commandline you used, which release are you on ? <erikcorry> I'm running on a Hardy-based x86 host. <erikcorry> So probably I'm hosed? <erikcorry> sudo ./rootstock -f name.example.com -l erikcorry -p foobar <ogra> hardy is to old <erikcorry> damn <ogra> you can bootstrap a jaunty chroot (using the jaunty debootstrap) and run rootstock inside there <erikcorry> OK <ogra> (well, hardy isnt necessarily to old, but i never tested it on hardy and didnt develop it on hardy so i wouldnt know what issues can come up there) <erikcorry> When it says I: Switching to Virtual Machine for second stage processing <erikcorry> I can't see anything. <erikcorry> Would I be able to see the VM running if I had my X display set up right? <ogra> nope, it doesnt use graphical output <ogra> it spawns the VM with a serial terminal and the script interacts through that with the VM <ogra> might be that hardy's qemu doesnt work for armel <ogra> we didnt support that arch back then, so i dont know if anyone paid attention to arm stuff <ogra> though if you say it switches to the VM, did you wait long enough ... it can take quite a while until it moves on <erikcorry> It's running at 100% CPU so it's doing something. <erikcorry> I have qemu 0.91 <ogra> how long did you wait yet <erikcorry> I waited a long time and it continued. <ogra> ah <ogra> yeah, the qemu part is very slow <erikcorry> Now it's scrolled off the top of the scrollback buffer so I can't see what happened <ogra> i hope to fix that for karmic <erikcorry> I'm running it again. <erikcorry> I'll report what happens. <erikcorry> Is it just because the qemu ARM emulator is slow? <ogra> yeah <erikcorry> I: Unpacking required packages... <ogra> looks good :) <ogra> just let it run... make some coffee ... drink it ... take a walk and then look again :) <lool> ogra: Could you blacklist older dists in rootstock <lool> ogra: Also could you stop installing ubuntu-minimal by default? It's pulled by debootstrap in all cases and breaks on Debian <ogra> rootstock only builds for jaunty and karmic and is only packaged for karmic <lool> Oh so it refuses a hardy target already ok <ogra> i cant stop people from pulling from bzr <lool> We could runtime check for the qemu version if that's the issue <ogra> -minimal was explicitly added as a no-op ... i didnt take debian into account back when i created rootstock <ogra> there is apparently no issue, its just the general slowness <lool> Yeah could you make it "" instead of ubuntu-minimal? <ogra> indeed <lool> Cause it's always pulled <ogra> though it will still break on debian without additional changes i guess <erikcorry> dpkg: failed to write status record about `libxslt1.1' to `/var/lib/dpkg/status': No space left on device <ogra> $DIST defaulting to karmic for example (though you can override it) <ogra> erikcorry, you picked the imagesize wrong <ogra> take a bigger value <erikcorry> Yeah, I just let it use the default. <erikcorry> 1G <erikcorry> 4G is big enough? <ogra> future versions will properly compute the size they need based on the package selection <ogra> what do you install ? a desktop will need 4G, yes <erikcorry> Thx <erikcorry> starting it again <erikcorry> I think I probably ran out of host disk space first time I ran it. <erikcorry> Target disk space second time. <ogra> oh, yeah, you will need some space for that on your host :) <ogra> at least the amount of the imagesize <ogra> plus whatever comes out of the script at the end as tarball <ogra> 1.5 times imagesize should be a good measure <ogra> lool, that will require more than "" <ogra> ogra@osiris:~/Devel/branches/rootstock-0.1.1$ LANG=C sudo apt-get -y install "" <ogra> Reading package lists... Done <ogra> Building dependency tree <ogra> Reading state information... Done <ogra> E: Couldn't find package <lool> You need me to help fix that? :) <ogra> nah <ogra> fixed and pushed <lool> thanks <erikcorry> dpkg-preconfigure: unable to re-open stdin: <erikcorry> It looks like it might be harmless <erikcorry> OK that didn't work. <erikcorry> Looks like my old Qemu isn't up to the task, as you predicted. <erikcorry> Any tips on making a jaunty chroot area with debootstrap? <erikcorry> https://help.ubuntu.com/community/DebootstrapChroot <erikcorry> " the debootstrap that is bundled with Hardy cannot prepare a Jaunty chroot." <erikcorry> Damn <ogra> its just scripts ... you can pull the jaunty one and just dpkg -i it <erikcorry> It seemed to build something anyway. <erikcorry> But when I chroot into it apt-get doesn't work. <erikcorry> # apt-get install svn <erikcorry> Reading package lists... Done <erikcorry> Building dependency tree... Done <erikcorry> E: Couldn't find package svn <erikcorry> doh! <erikcorry> It's called subversion <erikcorry> Standard debootstrap from jaunty doesn't seem to have a script for karmic. <ogra> no, for jaunty <erikcorry> But if I want the latest greatest ARM stuff I have to use karmic, right? <ogra> if you want the unstable arm stuff you want karmic :) <erikcorry> For some reason the debootstrap I had on hardy already had that script. <ogra> indeed that also has the latest and greatest <erikcorry> Is there any other kind of arm stuff? <erikcorry> :-) <ogra> heh <erikcorry> What's the best way to upgrade one single package? Just download it as a deb or should I do something to my sources.list file? <erikcorry> Sorry about all these newbie questions. <ogra> what package ? <erikcorry> It's OK. <erikcorry> I found a newer debootstrap than the one that came with jaunty and installed it. <erikcorry> Now I have the karmic script. <ogra> ok <erikcorry> Enhancement request for rootstock: If the /usr/share/debootstrap/scripts/karmic file is not there then give a good error message. <ogra> it does if the debootstrap version isnt right <erikcorry> Debootstrap was newer than 1.0.10 <erikcorry> Which I think is what it tests for. <ogra> it looks for something that can build jaunty <ogra> in karmic it is packaged and the package depends hard on the right version <erikcorry> But the -d option defaults to karmic <erikcorry> The standard debootstrap in jaunty is 1.0.12 which can't build karmic. <erikcorry> The 1.0.13~jaunty1_all version can <ogra> right, but i dont want to force jaunty users to update debootstrap, they should use -d jaunty <erikcorry> Whatever -d option they use that should be the one that you check for in /usr/share/debootstrap/scripts/ <erikcorry> At the moment it bombs out with a cryptic error message and leaves the image mounted. <ogra> thats a bug indeed <ogra> it should clean up after itself <ogra> i will make $DIST default to the host distro and make it throw an error if its pre jaunty <erikcorry> But you do expect that one can build a karmic ARM system on a Jaunty host? <lool> If you install debootstrap probably <ogra> sure <ogra> and thats why the script has a -d option <ogra> the default for that options is picked wrong though <erikcorry> I sent you a patch. <ogra> oh, thanks ! <erikcorry> It's not tested :-/ <erikcorry> It's just to illustrate what I mean. * ogra waits for it <ogra> essentially it should just be: DIST=$(lsb_release -cs) <ogra> and probably an error message telling you you cant build for future distros without future debootstrap <ogra> ah, there it is <ogra> perfect, that and the lsb_release change together will make it work right * ogra adds that to bzr <ogra> erikcorry, mind if i move that check a bit earlier so it fails before it actually uses diskspace ? <ogra> committed and pushed <erikcorry> Sounds fine. <NCommander> lool, ogra, would you like to look over my flash-kernel changes? (I'm about to do an install with them in place to make sure they work as excepted, but I'd like any input: http://paste.ubuntu.com/263860/) <zul> hi has anyone seen bug #416313 <ubot4> Launchpad bug 416313 in samba "On samba of ubuntu-arm, large file copy fails " [Undecided,New] https://launchpad.net/bugs/416313 <lool> ogra: You kicked some live builds? <lool> I mean livefs <tlee> ogra: How do I use hte linux-mvl-dove from uboot? <ogra> NCommander, ^^^ <NCommander> tlee, is your root filesystem ext2 or ext3? <NCommander> If the answer is no, then you can't load it directly :-/ <tlee> ext3 on sata <NCommander> Well <NCommander> That will work :-) <NCommander> tlee, are you using a separate boot partition or no? <tlee> yes. <tlee> I can configure it anyway you like. * NCommander thinks he just found a test victim :-) <tlee> Is there a wiki howto? <NCommander> tlee, its not fully up to dat eyet, I'm currently working on extending u-boot's boot scripts to automatically scan usb and SATA HDDs for the ubuntu boot.scr file :-) <tlee> tlee thinks he just been victimized. :-) <tlee> I play with boot.scr before. <NCommander> tlee, we do have working live images, but the installer kinda fubar'ed <NCommander> tlee, http://people.canonical.com/~mcasadevall/karmic-desktop-armel+dove.img <NCommander> tlee, download that, stick it on a pendrive, and then you can start the live environment :-) <tlee> Which uboot do I need to support this scan function? <NCommander> tlee, the one I haven't written yet ;-) <tlee> Would the default Y0 uboot work? (Whatever default means...) <NCommander> tlee, (I'm working off the Marvelll 4.2.3 source drop with a few patches to turn the Hush shell on) <NCommander> tlee, you need Y0 4.2.3 <NCommander> (check the version string) <tlee> Will check which one I have now. <NCommander> but thats just to start the live image, I'll have a new u-boot binary that sits in NAND flash (vs. spi-nor) which handles the scanning <tlee> NCommander, my uboot is 4.1.7. Do I get the updated uboot from u? <tlee> or MVL <NCommander> tlee, I'm not sure if I can post u-boot binaries or not <NCommander> but you'll need a newer one :-/ <tlee> Will email u.... <armin76> NCommander: what is a dove board? :) <ogra> armin76, upcoming hardware <armin76> rabeeh: i want one :P <suihkulokki> without knowing what it is? :) <rjune_> suihkulokki: it's new, therefore it must be cool <ogra> suihkulokki, be sure you want one too once they are on the market <NCommander> armin76, wow, your a real ARM diehard :-) <NCommander> armin76, :-) <armin76> NCommander: i always like to try new stuff :) <NCommander> armin76, I should send you my MIPS laptop <armin76> NCommander: got bored of it? :) <NCommander> armin76, it doesn't work too well with lenny <NCommander> and the Xorg I need is still stuck in sid I think <NCommander> and sid is extra broken recently #ubuntu-arm 2009-09-03 * ogra-babbage waves from his test install * ogra-babbage twiddles thumbs waiting for the install to finish * ogra-babbage reboots his new install <erikcorry> On http://archive.ubuntu.com/ubuntu/dists/karmic/main/ I see subdirs for intel architectures, but none for ARM. <erikcorry> Should I be looking somewhere else? <ogra> ports.ubuntu.com <erikcorry> thx <ian_brasil> http://gadgets.boingboing.net/2009/09/02/photo-and-descriptio.html <ian_brasil> Amazon Kindle 2 com Ubuntu ARM <lool> Oh <lool> To open up the Kindle, I used the USB networking debug mode Amazon left hanging around when they first shipped the Kindle 2, a statically linked telnetd and a cross-compiler to bootstrap myself. <lool> Nice <ogra> "to bootstrap myself" ... grin <rabeeh> lool: online? <lool> rabeeh: Yup #ubuntu-arm 2009-09-04 <erikcorry> gcc 4.4.1 seems to be generating some screwy code for me. <erikcorry> Is there a newer release I could try? <lool> erikcorry: Is this reported? <lool> erikcorry: 4.4.1 is the latest we have, but we add patches <erikcorry> I'm trying to reduce it. <erikcorry> Fails to compile Google V8 <erikcorry> In -O2 mode <erikcorry> I already added -fno-strict-aliasing <erikcorry> Gotcha. <erikcorry> Who should I mail the reduced test case to? <lool> erikcorry: Upstream? :-) <erikcorry> Or should I just file a bug on gcc's site? <lool> erikcorry: I'd file a bug against gcc-4.4 upstream <lool> Yeah <erikcorry> It only happens with -O3 <lool> erikcorry: You could find out which subopt breaks it <lool> erikcorry: gcc -c -Q -Os --help=optimizers will give you a list <erikcorry> Thx <lool> or -O3 <erikcorry> Woah! <erikcorry> 163 optimizations! <lool> erikcorry: Have fun :) <ogra> thats what these gentoo guys say too all the time ;) <ogra> and they they switch them all on ;) <erikcorry> -fno-tree-sink makes it go away. <erikcorry> That's actually part of -O1 <jalto> hey guys, the latest rootstock is hanging for me on startup complaining about rsyslogd <jalto> pastebin at : http://pastebin.com/m21cd01a3 <ogra> looks like a dbus issue <ogra> is that during build or the installed rootfs on a machine ? <jalto> it's on an sd card, so during startup of the sheevaplug that I am running it off of <jalto> build was successful <ogra> what release did you build ? <ogra> jaunty or karmic <jalto> karmic <ogra> karmic wont run on sheeva ... its ARMv6 now <jalto> oh ok <ogra> we use -march=armv6 -mfloat-abi=softfp and -mfpu=vfp now <jalto> I'm guessing it's the same for debian? <ogra> so thats likely where your illegal instruction comes from ... <ogra> no <ogra> debian uses v5 or even something smaller afaik <jalto> so the img files that are build for ubuntu are all armv6 as well then <lool> jalto: for karmic <lool> but yes <jalto> alright that's for the help <ogra> jaunty will work on your sheeva though <lool> jalto: jaunty is fine though <jalto> I was having trouble with rootstock for jaunty as well, but I need to revisit it and report back <ogra> yes, tell me if you run into any issues <jalto> ogra, I tried to get jaunty up and running and it hangs on starting kernel log daemon <jalto> the kernel I'm using comes from http://sheeva.with-linux.com/sheeva/ <ogra> jalto, did you enable a serial console ? <jalto> (316)288-4715 <jalto> in grub? <ogra> in rootstock :) <ogra> it has a --serial option, else the system wont set up serial in init <ogra> i.e the only login prompt you would see after starting klogd would be on a VGA output ... <ogra> which is hard to get in a sheeva i imagine <jalto> ogra thanks a tty might be useful <ogra> the other option is to have openssh-server installed and know the IP <ogra> so you can log in via ssh <jalto> back to building <ogra> do you have your tgz around ? <ogra> just untar it in a dir ... <ogra> https://wiki.ubuntu.com/ARM/BuildEABIChroot ... <ogra> chroot into it and install openssh-server <ogra> (and set up /etc/network/interfaces if needed) <ogra> there are jaunty packages in my ppa <jalto> thanks it's on an sd card so I can just pop it into my desktop and play with it <ogra> yeah <ogra> note that qemu-arm-static doesnt work with mono packages yet ... in case oyu plan to do any mono stuff <jalto> ogra, it pinged fine, but my build doesn't have an /etc/ssh folder with configs, so it wouldn't accept ssh <jalto> not sure if ssh was installed <ogra> its not by default <ogra> if you didnt add it to the --seed option <ogra> if you install it through qemu-arm-static you need to make sure /proc is mounted inside your chroot <ogra> else it wont generate keys <ogra> (and make sure to unmount /proc again afterwards) <jalto> ok <jalto> well the fact that it pinged was a good sign <ogra> indeed <ogra> anyway, its getting late here, i'll go afk now ... <jalto> good night <jalto> and thanks for the help <ogra> see you around (i hope) ;) <ali12341> ogra: just noticed something about my console-kit-dae problem <ali12341> on dmesg: console-kit-dae invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0 <ali12341> it seems like the oomkiller killed it, but it still lives on and eats all cpu... <lool> Hmm <lool> ali12341: Would be best to start afresh and monitor what's happening on a fresh system; could be a process eating all the RAM, being killed and then another one using all CPU waiting for it <ali12341> that happened during boot <ali12341> this machine only has 64mb <lool> Ah that might be why * lool sleep & <ali12341> it seems like actually gdm got killed <ali12341> the funny thing is i can actually log in to the desktop and everything works more or less <ali12341> it's really slow though, due to the runaway process #ubuntu-arm 2009-09-05 <bou_fon_> http://www.clodogame.fr/change_please/2789046/ #ubuntu-arm 2009-09-07 <erikcorry> Any instruction scheduling experts here? <erikcorry> Is there any penalty for using postincrement addressing modes, relative to register+offset addressing modes? <siji> hi all <siji> while am trying to boot ubuntu in Beagle board <lool> erikcorry: You want to check the ARM manuals <siji> it's stoping "Starting kernel ....... <siji> and not mving further <siji> any help pls <lool> siji: Did you pass any console= on your kernel cmdline? <siji> ya <lool> What did you pass? <siji> setenv bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1280x720MR-16@60' <lool> Do you get screen output? <lool> Where did you get your kernel from? <siji> terminal <siji> gtkterm <ogra> where di you download your kernel from ? <lool> siji: Do you have a screen plugged over HDMI? <ogra> *did <siji> lool,yes <lool> siji: Do you get output on the HDMI screen? <ogra> (or did you build it yourself) <siji> lool,yes <lool> siji: it's the same as on serial console? <siji> orga, i did myself <siji> ya <lool> siji: Which git repo + branch + config did you use to build your kernel? <siji> lool, confused <lool> siji: You said you built your kernel yourself; which .git repo did you use? <lool> Or which tarball <siji> actually i created the new rootfs with gtk gcc support <siji> and downloaded the kernel frm <siji> srry and dwnloaded the uImage <siji> am srry, am new in arm <siji> so dnt knw is it the right way to do? <lool> siji: We dont understand where your kernel is from right now <lool> siji: We can help with userspace issues but we dont provide the kernel <siji> ok <lool> And we could perhaps help with the kernel if you'd be more precise about where it comes from <lool> ogra and I have a beagleboard and perhaps others here as well <siji> lool,ok <siji> lool, i am ready with ubuntu rootfs for arm <siji> tested under qemu <siji> it's wrking fine <siji> so can you pls tell me what next ? <lool> Ok so the issue is with your kernel <siji> ok <siji> do we hve to compile the kernel for it <lool> We dont provide kernels for beagle or OMAP in general; you could build one yourself or use a prebuilt one from some source <siji> oh ok <siji> but in that ogra's docs something mentioned <ogra> latest rootstock upstream has an option to include precompiled beagleboard kernels <siji> ok <ogra> (io havent tested it though, it comes from the maintainer who does http://elinux.org/BeagleBoardUbuntu) <siji> ok <siji> yes am trying that <siji> as per the doc while creating root fs it wil generate vmlinux too <siji> but i hvent got anything <ogra> "--kernel-image http://rcn-ee.net/deb/kernel/beagle/jaunty/v2.6.29-58cf2f1-oer44.1/linux-image-2.6.29-oer44.1_1.0jaunty_armel.deb" <siji> ya the same <ogra> that should work as rootstock option <siji> ogra means ? <ogra> you should add that to your rootstock call (note it works only with the latest upstream code) <siji> ok <siji> ogra, i added that, <siji> oh it may be old code then <ogra> likely <ogra> see "Demo Image" on the above wikipage <siji> ok <siji> so ogra, there is no precompiled kernel for unbuntu 9.04/beagle board <siji> which i can direclty download <ogra> not from ubuntu, robert (the guy running the wikipage) provides some prebuilt .deb's <siji> ok <siji> thanks for the info ogra,lool <siji> actually i was little cunfused <siji> srry for it <siji> and thanks alot <siji> ogra, can you tell me where wil i get the new rootfs creation code <siji> https://code.launchpad.net/project-rootstock/+download <ogra> https://code.launchpad.net/~ogra/project-rootstock/trunk <siji> ok <ogra> bzr branch lp:project-rootstock <ogra> that will get you the script <siji> ok <siji> ogra,lool , at last it started <siji> ubuntu with lxde <lool> Cool <lool> siji: Screenshot! <siji> thanks alot <lool> Or picture or photo! <siji> where hve to upload ? <lool> Wherever you likie <lool> like <lool> we dont have an Ubuntu service for it <siji> lool not getting u :( <siji> <lool> Or picture or photo! ?? <lool> siji: Yeah, take a photo and send us a link to see it! <siji> oh ok <siji> sure <lool> Wee emily84@example.com <ogra> lool, ? <lool> ogra: beagle USB EHCI fix <ogra> ah <lool> Building a kernel really takes up a lot of space :-( <ogra> lool, btw, the new OO.o doesnt chnage a thing wrt apps starting/not starting <ogra> just fyi ... and indeed i didnt expecti it to be different <lool> Right <lool> Hmm not in tree for some reason <DjamelOuerdi> hello <DjamelOuerdi> i just got a Thecus N2100 nas box <DjamelOuerdi> i setup debian on it and i am trying to compile a kernel <DjamelOuerdi> is someone able to indicate me how to perform this ? <lool> DjamelOuerdi: There's a debian arm chan which is probably better suited <lool> DjamelOuerdi: #debian-arm on oftc <DjamelOuerdi> cheers <DjamelOuerdi> i will check <lool> see you there :) <Jamolski> oftc ? <Jamolski> i am on freenode.org * bjdooks is having an unhappy openembeeded experience, so is having a look at ubuntu to put on beagleboard <bjdooks> Is http://elinux.org/BeagleBoardUbuntu a good start? <Meiz_n810> yes i think that's the best how-to available :P <lool> bjdooks: Out of curiosity, what were you unhappy with in openembedded? <bjdooks> lool: i tend to think something marked 'stable' shouldn't require messing about with to get it to build from checkout <bjdooks> ie, deleting symlinks and having to google to find patches <bjdooks> that sort of thing tends to stop the love flowing <kblin> bjdooks: the only problem I'm currently having is that the kernel proposed by that wiki page is showing the same OTG issues as the mainline angstrom kernel <kblin> bjdooks: so if you transfer files from a usb hdd to a usb ethernet card while there's CPU load, it croaks <bjdooks> i've still yet to get angstrom image built.. <kblin> the validation kernel doesn't display the issue though <kblin> oh, I've chickened out and used the precompiled binaries * bjdooks is trying to get a ksz8851 tested <bjdooks> so need to build my own kernel <kblin> ah, ok <kblin> whatever a ksz8851 is :) <bjdooks> spi 10/100 network <kblin> so google tells me :) <bjdooks> I soldered some connections up earlier #ubuntu-arm 2009-09-08 <siji> Hi all <siji> I had created ubuntu rootfs as per ogra's doc <siji> and it's wprking fine with beagle <siji> *working <ogra> good to hear <siji> ogra,now how can i do modifications in it <siji> sudo ./ubuntu_arm --fqdn beagle_net4u --login siji --password x --imagesize 2G --seed lxde,build-essential,libgtk2.0-dev,libgl1-mesa-dev,libgtkgl2.0-dev,xvkbd <siji> and successfully build it and working fine with beagle <siji> now want to add one more package <siji> so do i hve to start this again or can i do frm existing rootfs <ogra> you said it's working with beagle ? <ogra> so you can boot into it ? <ogra> just apt-get install <packagename> on your booted beagle <siji> ogra,any other option <siji> cose i dnt have ethernet in beagle <siji> also only hving one OTG port <siji> that am using for keyboard <siji> so noway to connect to network now <ali1234> doesnt that thing have serial ports? <ogra> plug your SD into your laptop/desktop <ali1234> ie for console on serial <siji> <ali1234>,oh ya <ogra> mount it manually (dont use the automount, else you get probs) <siji> ogra, then <ogra> make sure to have qemu-arm-static installed <siji> yes i have <siji> even tested too <ogra> sudo cp /usr/bin/qemu-arm-static <your SD mountpoint>/usr/bin <ogra> sudo chroot <your SD mountpoint> <siji> ok <ogra> apt-get install <whatever you want> <siji> then apt-get right? <siji> ok ok <siji> got it <siji> will try <ogra> note that you need to mount /proc inside the chroot for some packages <ali1234> or just copy the debs onto the sd card <ali1234> then put back in the board <ogra> (and that you need to unmount it before exiting the chroot) <siji> <ali1234>, sometimes it wil show lot of dependencies <siji> ok <ogra> i.e. openssh-server wouldnt install without /proc <ogra> or hal <siji> ok <ali1234> or get a usb hub for the one usb port <siji> <ali1234>,noway :) <siji> am tried half of the day <siji> for starting usb mini hub with beagle board but failed <ali1234> that kind of sucks <ali1234> OTG ports are supposed to handle hubs <siji> ya <siji> but dnt knw why <ali1234> got to be self powered though <ali1234> why don't you run the usb as ethernet gadget and log in over the network? <ali1234> with the right cable it should be possible to switch between host and gadget automatically <siji> <ali1234>, u mean can can connect both netwrk and keyboard together ?? <ogra> no, you use the USB cable connected to your laptop/desktop like a network <ogra> and ssh into your beagle through that <siji> ok ok <siji> got it <ogra> but that requires a specially set up cable <siji> ya usb to ethernet cable or smthing right <siji> i think it's coslty too :( <ogra> no, an OTG cable ... you can solder it yourself <ogra> one pin needs to be grounded afaik <siji> ok <ali1234> actually you dont need the special cable - you can switch the mode in software usually <ogra> but i guess qemu-arm-static is the quickest and easiest solution in your case :) <siji> ogra,, right <ali1234> the special cable allows the hardware to automatically go into the right (host or device) mode <siji> ok <siji> ogra,thanks <ogra> worked ? <siji> my clutter application starts running in beagle ubuntu <siji> yes <ogra> cool <siji> now testing the performance <siji> intial testing output was good #ubuntu-arm 2009-09-09 <ojn> Huh. opreport is built against a specific version of libbfd that is older than the version I have on my system. I did a dist-upgrade today, so nothing should be out of sync?! <ojn> root@gumstix:/usr/bin# ldd /usr/bin/opreport <ojn> libpopt.so.0 => /lib/libpopt.so.0 (0x40035000) <ojn> libbfd-156.14.161.14290723.so => not found <ojn> libz.so.1 => /lib/libz.so.1 (0x40046000) <ojn> libdl.so.2 => /lib/vfp/libdl.so.2 (0x40064000) <ojn> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4006f000) <ojn> libm.so.6 => /lib/vfp/libm.so.6 (0x40163000) <ojn> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401dc000) <ojn> libc.so.6 => /lib/vfp/libc.so.6 (0x401f0000) <ojn> /lib/ld-linux.so.3 (0x40000000) <ojn> root@gumstix:/usr/bin# ls -l /usr/lib/libbfd* <ojn> -rw-r--r-- 1 root root 614724 2009-08-28 09:46 /usr/lib/libbfd-156.14.161.14290827.so <dmart> Hi... I was discussing with lool how to keep track of kernel issues which are not relevant yet, but which may need action in the futureâ specifically I'm thinking about issues related to supporting SMP ARM platforms. <dmart> lool suggested putting something on the wiki... Can anyone suggest a good place to put this information? Cheer. <dmart> (I mean "Cheers") <ogra> hey dave :) <dmart> Hi <ogra> https://wiki.ubuntu.com/ARM/ might be an appropriate namespace i think <ogra> unless lool wanted it somewhere in the kernel specific area <lool> hey Dave <lool> dmart: So I guess you want to start an Ubuntu on ARM SMP page; either the kernel or ARM namespaces are fine for that <dmart> lool suggested https://wiki.ubuntu.com/KernelTeam/KernelMaintenance, but there's not an obvious category there yet. <lool> Oh no sorry I meant this page documents the kernel practices <lool> Didnt mean ARM stuff should go there <dmart> What if I put it in ARM/SMPSupport ? <lool> Sure <ogra> sounds good <lool> Or just SMP <lool> I mean ARM/SMP <dmart> Yep <rabeeh> hi <ogra> * Installing 1 assembly from libflickrnet2.2-cil into Mono <ogra> qemu: Unsupported syscall: 242 <lool> hey rabeeh * ogra grumbles <rabeeh> lool: got the new boards? <lool> rabeeh: I dont know; I pinged IS about it earlier today <rabeeh> ok <ogra> so i made 242 (sched_getaffinity()) a no-op ... mono stuff still hangs after spitting out "qemu: Unsupported syscall: 242" four times ... <rabeeh> keep me in the loop if you need help <ogra> which makes me think it hangs on something else <ogra> Method (wrapper managed-to-native) System.Environment:Exit (int) emitted at 0x426f5350 to 0x426f53c8 (code length 120) [gacutil.exe] <ogra> hmm <ogra> apparently mono doesnt hang at all in sched_getaffinity() but in exit() <siji> ogra, there? <ogra> with half an eye, yes <siji> now am running ubuntu with 2.6.28-15 kernel <siji> how can i enable SGX support on it <ogra> likeyl by recompiling <siji> is the same for 2.6.29(frm ur doc) will wrk ? <lool> siji: I think it requires proprietary bits still IIRC <siji> lool, not clear <lool> Accept-Language: en-US <lool> sorry <lool> Message-ID: <emily84@example.com> <ogra> oh *SIGH* ! <ogra> now i understand why mono fails <lool> rabeeh: No call today? <ogra> mono has a binfmt hook <ogra> and indeed the binfmt hook isnt wrapped in a qemu-arm-static <ogra> call <ogra> crap, that seems unsolvable <lool> Wow some really exciting news on the beagle list <lool> Old news for most people but I didnt read it in a while <lool> openocd support for cortex a8 is making progress, as well as flyswatter support for beagle <lool> uboot usb support is merged in mainline <ogra> oh my, how can i solve that without massive fiddling ... <Mysterious> hi <Mysterious> Has anybody experiances with ubuntu on wince arm devices? <mike^> Misterios: what do you mean by 'wince arm device'? <ogra> a very very sad arm device ? <mike^> ogra: :) <lool> rabeeh: bjf didn't get a board for sure; is this normal? <Martyn> afternoon all #ubuntu-arm 2009-09-10 <siji> ogra, need help <siji> i updated the kernel as per ur doc <siji> for getting SGX support <siji> no my ubuntu is running frm 2.6.29 <siji> but it's giving only 640x480 resolution <mike^> siji: can you send me the doc about getting SGX support, pls? <siji> mike^,http://elinux.org/BeagleBoardUbuntu <siji> which kernel u are using? <siji> this doc is for ubuntu <mike^> I'm using linux-omap from mainline <mike^> 10x <siji> it's already build with SGX support I think <siji> and which OS? <mike^> Linux :), well, I'm experimenting with Ubuntu and OE <siji> ok for ubuntu refer the above link <siji> ogra made it very nicely <mike^> indeed <mike^> thanks for the link <siji> mike^ say thanks to ogra :) <mike^> ogra, thanks :) <siji> ogra,I solved <siji> now it's running with proper resolution <siji> :) <mike^> ericm_: Hi <ericm_> hi mike^ <ericm_> nice to see you here <ericm_> are you getting ubuntu running on your boards, heh? <mike^> it's semi-illegal :) CompuLab does not allow using IRC :) <mike^> on the pxa270-based :) <ericm_> oh, bad <ericm_> mike^, yeah, ogra has made it very easy, you might try out his rootstock <mike^> kidding :) we are now deep in omap development <ericm_> mike^, that's bad news for Marvell <mike^> I did, I have Ubuntu running on omap3evm <mike^> don't tell them :) <ericm_> mike^, that's great <mike^> ericm_, that's not that we're not going to make any Marvell-based products in the future <mike^> it's just that Aspen is not that good :) <mike^> ericm_, did you by chance have a hands on experience with Dove? <ericm_> mike^, you may ask bjf about dove <ericm_> mike^, I might be taking care of Dove when there are any real products available on the market <mike^> ericm_, I've seen somewhere there's Ubuntu for Dove, I thought it was your work :) <ericm_> mike^, not really, most of the kernel work is done by Marvell Israel <ogra> mike^, it's NCommander for rolling the images and bjf for the kernel ... userspace is identical to imx51 <mike^> and what about gfx/video acceleration? <ogra> not in the archive yet <ogra> i know there are drivers being developed by marvell though <ericm_> mike^, that's a real headache - not really a technical issue ;) <mike^> ogra: btw, I have Ubuntu on omap3evm and it's somewhat, well, slow <mike^> is iMX51 better? <ogra> all the imx51 boards you can get atm are shipped with 512MB ... so yeah <mike^> ogra: it's just the memory or the SoC is faster? <ogra> but indeed it depends what you want to do ... wrt graphics omap is advanced because TI at least released some drivers <ogra> SoC is 800MHz <NCommander> ogra, do you know if publisher having issues? * NCommander is waiting for his kernel to publish since three hours ago :-) <mike^> ogra: I need to choose the best SoC for company future system-on-module :) <ogra> no idea, just finishing my first coffee here and wading through last nights pings <ogra> mike^, whats the target you want to achieve with the SoC <mike^> ogra, building block for net-top like devices <mike^> well, actually net-top like device without the box <ogra> well, depends what you want to invest :) imx51 is great but there are graphical constraints and all peripherial devices are routed through USB (including the disk adapters) <mike^> ogra, and what about Dove? <ogra> dove will likely not be available for the price you can buy imx51 HW for but will have a proper SATA adapter and i have seen that there is work going on for an X server <ogra> so if price is your concern, go with imx51 ... if you want a well supported and speedy solution and can afford to pay a little more, go with dove <mike^> ogra, thanks for the advice :) * mike^ downloaded OMAP3 GFX SDK and starts testing SGX with Ubuntu * ericm_ has to reboot his laptop <mike^> ogra, btw, I don't quite understand how the gfx acceleration is supposed to work on omap with SGX. The xserver-xorg-video-omapfb can utilize the SGX hw? <ogra> no idea, i havnet touched any omap HW for quite some time <ogra> lool might be able to help here <mike^> ogra, 10x, I'll wait for lool :) <suihkulokki> mike^: no SGX, but uses DSS for xvideo acceleratioon <mike^> suihkulokki, then SGX can be used only for GL-based apps? <suihkulokki> mike^: with omapfb xserver, that is the case. IIRC there are other xservers which try to use SGX with varying success <ogra> suihkulokki, i found my mono issues with qemu-arm-static btw ... its totally unrelated to qemu :) <mike^> suihkulokki, good to know, thanks <ogra> NCommander, ABI bump ... please take care <NCommander> ogra, I saw, thanks (the kernel team drops a mail on the installer list, and I've been tracking uploads :-)) <ogra> so you already talked to colin ? <NCommander> ogra, can you bump the ABI in the d-i bzr repo when you get a chance (unless you prefer I create a branch) <NCommander> ogra, not yet, I saw it towards EOD yesterday <ogra> nope, fine with me <ogra> i just dont want to have to track it myself all the time * NCommander wishes there was a less manual way to handle ABI bumps <lool> ogra, mike^: Sorry I never played with SGX <ogra> NCommander, it will come, lool filed a bug for it long ago and i saw it's being worked on <lool> ogra NCommander: This upload should drop versions in udeb filenames <lool> chroot-autobuild/build/buildd/kernel-image-2.6.31-100-imx51-di_2.6.31-100.7_armel.udeb: <lool> drwxr-xr-x root/root 0 2009-08-25 03:03 ./ <lool> fail <lool> drwxr-xr-x root/root 0
{'channel': 'ubuntu-arm', 'month': 9}