[04:58] <krosswindz> I am having issues when trying to compile Ubuntu kernel in ARM cross chroot
[04:58] <krosswindz> The error I am getting is http://pastebin.pandaboard.org/index.php/view/43458006
[04:59] <krosswindz> I noticed a bug report for precise https://bugs.launchpad.net/ubuntu/+source/tree/+bug/904763
[04:59] <ubot2`> Launchpad bug 904763 in tree "Unable to build tree for armel" [Undecided,New]
[05:00] <krosswindz> I was wondering on how do I change the CFLAGS for the same
[06:49] <person987> having trouble with initial boot of ubuntu on a pandaboard...
[06:50] <person987> during the initial "resizing the filesystem" stage, it says "Errors were found while checking the disk drive for /."
[07:14] <infinity> person987: If the resize is failing, the original write to the SD was bad.
[07:15] <infinity> person987: Which could be either (A) because something went wrong, or (B) the card is dead/dying.
[07:15] <infinity> person987: My bet's usually on B, but you can try rewriting and see if it likes you the second time.
[07:22] <infinity> krosswindz: That bug looks bogus to me (or, rather, their "fix" for it).
[07:23] <infinity> krosswindz: I suspect dropping optimisation would be enough to solve your problem.
[07:24] <infinity> krosswindz: But, honestly, if you have to do such nasty things to cross-compile, you might want to rethink things and compile natively. :P
[07:24] <person987> I have tried writing the image to this SD card twice or 3 times now.  Maybe you're right and the card is bad, I'll get another one tomorrow.
[07:25] <person987> Has anyone had problems with hard-locks using ubuntu 11.10 on a pandaboard?
[07:26] <infinity> Under seriously heavy load (ie: running as a buildd), we manage to lock them once in a while.
[07:26] <infinity> But that's fairly rare, compared to the pain they're being put through.
[07:28] <person987> I have another SD card which works but I have been getting regular hard-locks.  Probably once every half hour.  I was trying to build a new image on the new SD card to see if maybe I've gotten a bad driver or something like that (pretty new to Ubuntu/Panda)
[07:29] <person987> I'm often running some OpenGL code which renders Kinect data when I'm using the pandaboard
[07:30] <infinity> Well, I'd suggest installing to a real hard drive at some point to rule out bad media.
[07:30] <infinity> But if you're doing intense OpenGL stuff, it may well be that.
[07:30] <person987> My typical usage is to write some code, run for a bit, write some more code, maybe a couple web searches, etc.  It will lock up during any of the above, including just typing.
[07:31] <infinity> Locking up during typing, on the other hand, definitely shouldn't be happening.
[07:31] <infinity> We have machines with uptimes in the weeks and months around here.
[07:33] <person987> I suspect the graphics driver/opengl stuff.  I tried to install the drivers to get opengl hardware acceleration and it didn't seem to fully work.  For example, I'd get one boot where the desktop was really high res, then the next would be back to 1024x768, the 3D performance is really bad too; only 20fps for a trivial rotating quad; so I don't think I've got the video stuff working correctly.
[07:34] <person987> Good to know that you have not had lockups, I have a friend who said his pandaboard has never locked.  I tried my SD card on it and it eventually locked on me :-)
[07:34] <infinity> Yeah.  May well be your software/driver setup.
[07:34] <infinity> If you're having troubles with the TI binary drivers, I'd recommend poking ndec.
[07:34] <infinity> I don't touch them.
[07:34] <person987> what is ndec?
[07:35]  * infinity points at ndec.
[07:35] <infinity> He's a who, not a what.
[07:35] <person987> hehe
[07:35] <infinity> TI developer, packages the binary stuff.
[07:37] <XorA> a who can become a what after application of numerous alcoholic drinks :-D
[07:37] <person987> oh great!  well you have been a huge help.  I will get another card and re-install everything.
[08:10] <janimo> jcrigby, rsalveti the 3.1 kernel for mx5 has been running all night. I have not tested it heavily but I'd say it is good to  upload to precise
[08:11] <jcrigby> janimo, ok will do
[08:14] <XavB> person987: we (TI) have made a major update few hours ago, let us know if you are still seeing bad perf. Note that you will boot with TI kernel with DVFS on-demand by default. Then we are having perf impact with metacity compositing on and with unity-launcher running. More improvements shall come.
[08:15] <XavB> Note: I am working with ndec... ;)
[10:03] <burli> Hi, is it possible to run Ubuntu on this tablet? http://www.zenithink.com/Eproducts_C71.php
[10:04] <burli> It has an Amlogic 8726-M and 512MB RAM
[11:10] <Ziomuschio> hi there
[11:10] <Ziomuschio> may I ask some info about a problem with echi-omap when installing ubuntu-omap-extras in pandaboard?
[14:03] <rsalveti> janimo: great, thanks
[14:55] <krosswindz> infinity: It takes forever to compile on the board, the reason I setup an ARM cross chroot on my x86 laptop
[14:55] <krosswindz> infinity: The fix might appear bogus, I will try to disable optimization and see if it builds
[14:55] <krosswindz> infinity: there definitely is some issue as I am running into exactly the same problem
[15:12] <krosswindz> I am seeing oops when I try to either halt or reboot the board using this kernel.
[15:12] <krosswindz> The trace is available here http://pastebin.pandaboard.org/index.php/view/94450538
[15:16] <person987> XavB: thanks, I'm sorry but I don't understand most of your comment (DVFS on-demand? metacity? unit-launcher?)  My background is graphics programming but I'm a complete noob to Ubuntu.  I'd love to take a look at your latest update.  It would be great to solve my "hard-lock" problems as well as get some improved 3d performance.  If I can help you in any way with logs or details on my system
[15:16] <person987> config I would love to.  (you might have to give me detailed instructions tho! :-)  How exactly do I get your latest update?
[15:18] <XavB> person987: ok, no pb. So first step would be to upgrade to last sw and let us know if it improves the situation.
[15:19] <XavB> then there are several settings you can do to improve graphics performance
[15:20] <XavB> 1- modify DVFS that will decide about CPU ussage strategy, it is by default set to ondemand into file /etc/init.d/ondemand
[15:20] <XavB> If you comment the setting or force performance value, you might gain few fps.
[15:22] <XavB> Then by default you will be using Unity2D so metacity. Metacity is using compositing so graphics performance are impacted, you can install gconf-editor, then go into apps->metacity and uncheck box compositing manager. You will gain few more fps.
[15:24] <person987> I can try this right now, first step was to "upgrade to last sw", how?  (sorry I'm new!)
[15:24] <XavB> Last point is about unity panels, they are having an impact on graphics, you can kill them to gain few more fps: "sudo killall unity-panel-service unity-2d-panel unity-2d-launcher" 2 times.
[15:24] <XavB> person987: You have installed TI PPA already right?
[15:25] <XavB> or "TI OMAP Addons"
[15:27] <person987> In the "Ubuntu Software Center", I had a package named "ubuntu-omap4-extras".  About 1/2 hr ago I removed that and rebooted to see if the hard-locks would go away.  Is that what you're referring to?
[15:28] <person987> in software sources, I have ppa.launchpad.net/tiomap-dev...
[15:29] <XavB> person987: yes
[15:29] <OlivierN1> person987: fine, then re-install this package, and run an upgrade
[15:29] <XavB> So perform an "apt-get update" then install manaually "ubuntu-omap4-extras"; it will be fine.
[15:34] <person987> Ok, installing, it gave a warning about future updates not including some other linux kernel stuff.
[15:41] <XavB> person987: normal
[15:42] <XavB> You will have a TI kernel
[15:46] <person987> Ok great.  I'm not too concerned about perf, my requirements are not too high.  The only reason I mentioned it was that I wasn't sure if I had things installed correctly.  So this is helping greatly.  I will probably not kill the panels but I'll try out disabling compositing. Almost done installing.
[16:02] <XavB> person987: of course you'll need to reboot at the end of install
[16:12] <person987> XavB: That brings up another thing, it hasn't been shutting down cleanly.  I always eventually have to pull power because it just sits on the ubuntu screen with the dots that cycle.  Is that normal?
[16:14] <XavB> person987: I can observe wrong reboot with canonical kernel, new one shall "reboot fine"
[16:14] <XavB> after reboot "uname -a" shall return: Linux ubuntu-desktop 3.1.0-1282-omap4 #10 SMP PREEMPT Tue Jan 24 15:52:14 CET 2012 armv7l armv7l armv7l GNU/Linux
[16:15] <XavB> person987: is your reboot ok? UI up etc...
[16:51] <person987> XavB: actually the update was still going.  It failed: Not all updates can be installed - run a partial upgrade to install as many updates as possible.
[16:52] <person987> XavB: I'm going to have to get to work but I'll build a new image this weekend and get back to this point.
[16:52] <XavB> person987: if you do it in 2 steps (2 dist-upgrades) it shall work, no need to reboot between both
[17:09] <lool> Hey folks
[17:11] <lool> The web indices for e.g. http://uec-images.ubuntu.com/precise/20120203/ which I think are generated from cdimage code say "For ARMv5t processors and above"; it's because for "armel" images we say "For ARMv5t processors and above." -- which was true in jaunty; since we don't really have any official ARM images for anything older than lucid which is ARMv7t2, I propose that we change it to ARMv7; is that ok?  would you rather have a different wording?  a
[17:11] <lool> infinity, ogra_: ^
[17:12]  * ogra_ has no clue about uec images, nor why there would even be arm ones
[17:13] <ogra_> better ask #ubuntu-server ?
[17:13] <ogra_> we didnt enable that
[17:14] <lool> ok
[19:17] <morphis> heyho
[19:18] <morphis> I am wondering wether it's possible to build currently for armhf with uploading packages to my ppa
[19:18] <morphis> anyone knows if it's possible?
[19:19] <infinity> morphis: We don't currently offer ARM PPAs to the public for security reasons (we don't have virtualised ARM builders)
[19:19] <infinity> morphis: That's in the works, but not done yet.
[19:19] <infinity> morphis: If you want armel and armhf builds, your only option right now is to build locally.
[19:20] <morphis> infinity: ok, thats good to know as it's very hard to find details about building for armhf and ubuntu today
[19:21] <morphis> infinity: is there a definitive way how to build packages and images?
[19:21] <morphis> I saw there is support for pbuilder to build packages with qemu
[19:23] <infinity> morphis: If you don't have native hardware, qemu is certainly the easiest way to go.
[19:23] <morphis> infinity: ok
[19:24] <morphis> infinity: can you tell me also which hardware is recommended for building? I read about debian is using some i.MX53 boards but whats with the panda boards?
[19:24] <morphis> whats cannoncial using for the armhf bootstrapping?
[19:25] <infinity> morphis: We support both the Panda and mx53.  Ubuntu's buildds are Pandas, Debian's are mx53.
[19:25] <morphis> ok
[19:25] <morphis> infinity: you work for cannonical?
[19:25] <infinity> morphis: If you can get your hands on a Pandaboard ES, they're well supported in Precise, and probably the fastest generally-available hardware right now.
[19:25] <infinity> morphis: I do, yes.
[19:25] <infinity> morphis: I was the person who did the armhf bootstrap.
[19:26] <morphis> infinity: ah :D
[19:26] <morphis> infinity: I already though about the Pandaboard ES
[19:27] <morphis> I have done a lot with OpenEmbedded in the past were everything is cross compiled
[19:27] <infinity> Yeah, we don't treat any of our ports as "embedded" targets.  armel/armhf are still complete Ubuntu builds and self-hosting.
[19:27] <infinity> So, it's no different than x86 in that regard.
[19:27] <morphis> thats somethine I really like
[19:27] <morphis> cross compilation is sometimes very hard
[19:27] <infinity> Honestly, most "embedded" work these days isn't. :P
[19:27] <infinity> It's general-purpose OSes.
[19:28] <morphis> as you have to map all the different build systems against the cross compilation (automake/cmake/...)
[19:28] <infinity> Yeah, I know.  I used to work in scratchbox a lot with Maemo.  It was vile.
[19:28] <morphis> :)
[19:28] <infinity> And there was no good reason for it, once maemo was targetting devices as fast as the N900.
[19:28] <morphis> but OpenEmbedded adds a very easy to use abstraction layout on top of it
[19:30]  * infinity rnus off to lunch.
[19:30] <morphis> infinity: Bon appétit!
[19:40] <GrueMaster> ogra_:  Can you think of any omap/omap4 specific boot parameters that should be kept during netboot install?  I have "console=", "mem=", and "fixrtc".
[19:51] <infinity> vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 fixrtc
[19:51] <infinity> ^-- Should do it.
[19:53] <GrueMaster> I'm trying to avoid hardcoding as much as possible.  If they weren't on the netboot boot.scr, they won't get passed through, although I would also like to get the preseed "d-i debian-installer/add-kernel-opts" section.
[19:54] <GrueMaster> Not sure how to get that info in f-k-i.
[19:55] <infinity> I suppose f-k-i could grow preseed support (at least, for that one option)
[19:56] <GrueMaster> Yea, I'm looking into it now.
[19:57] <GrueMaster> I have other changes I will be pushing soon (expect a merge request before EOD).
[20:04] <infinity> GrueMaster: Looks like user-params from debian-installer-utils may be what's needed.
[20:04] <GrueMaster> grmbl.  Netboot is having some serious issues this morning.  It is failing to install packages and sometimes losing connection to my mirror.
[20:04] <GrueMaster> Ok, I'll look at that.
[20:05] <infinity> Oh, maybe not.
[20:05] <infinity> That's the inverse.
[20:07] <infinity> Or, rather, what it does doesn't seem to match the README...
[20:07] <infinity> Ahh, no.  I misread.
[20:08] <infinity> The README says it "doesn't include preseeded values", what it really means is it literally doesn't include pressed/command/syntax=foo stuff on the commandline it spits out, which is what you want.
[20:09] <infinity> But it does include stuff that's been preseeded *from* add-kernel-opts.
[20:09] <infinity> So, yeah.
[20:09] <infinity> user-params is probably what we want to run in f-k-i to transfer the installer commandline to the final system.
[20:11] <infinity> Looks like grub-installer uses it, so that's comforting.
[20:19] <GrueMaster> I just ran it and it is missing a few params.  It only spews fixtrc, console=, and mem= lines.  Missing vram= and (in one case) smsc95xx.macaddr=
[20:23] <GrueMaster> Oh, nevermind.  It pulls that from the preseed (duh).
[20:23] <GrueMaster> (I didn't look at the preseed of my currently running system).
[22:03] <niklasfi> hi, obviously my beagleboard is ooming with the syslog repeatedly statign "eth0 kevent 2 may have been dropped", when doing a lot of io. I have had this issue since i got my beagle board back in 2010 and noticed the same behaviour on debian. did someone else notice this?
[22:04] <krosswindz> I have noticed that on the pandaboard that I got 2 weeks back
[22:04] <niklasfi> krosswindz: ohh good. then you saved me from making a bad purchase
[22:05] <niklasfi> i was hoping this would be resolved due to more throughput
[22:05] <krosswindz> niklasfi: not sure what the issue is google isnt helpful on it
[22:05] <niklasfi> krosswindz: well not really, but as you may have noticed there is a workaround
[22:06] <krosswindz> niklasfi: yes I noticed the work around but no real solution
[22:06] <niklasfi> krosswindz: what value did you have to pump min_free_kbytes up to?
[22:06] <infinity> Well, I see it very very infrequently on the Panda, and it has no adverse effects.
[22:06] <niklasfi> infinity: it totally locks up my machine to the point that i have to press the reset button
[22:06] <krosswindz> niklasfi: I havent played with that yet
[22:07] <krosswindz> niklasfi: I am still trying to get my kernel compiled for it
[22:07] <infinity> But, really, heavy I/O on a system where almost everything is on the same USB bus (such as the Beagle and Panda) will occasionally hitch up.
[22:07] <infinity> niklasfi: I never have to reset, though I suppose if I was impatient, I might.
[22:07] <infinity> niklasfi: (As in, the machine might seem unresponsive for a bit, but it always comes back)
[22:07] <niklasfi> infinity: is waiting for half an hour impatient?
[22:08] <krosswindz> niklasfi: I havent had the panda lock up yet
[22:08] <infinity> niklasfi: No, probably not.  Unless you're doing half an hour of long I/O. :P
[22:08] <niklasfi> is there a way to disable syslog? i think writing thousands of syslog messages does not help the situation
[22:08] <infinity> niklasfi: But I was referring to the behaviour being mostly harmless on Pandas.  I don't have a Beagle.
[22:08] <infinity> What's writing thousands of syslog messages?
[22:09] <infinity> syslog culls duplicates.
[22:09] <niklasfi> infinity: when the system freezes, it does. and no it does not filter out the duplicates
[22:10] <infinity> Weird.
[22:10] <infinity> And if it's flushing buffers and writing logs, I'd hardly call that "frozen".
[22:10] <infinity> Just "really busy".
[22:11] <niklasfi> infinity: if you connect via serial port you just see thousands of messages, and if you use ssh, it does not respond
[22:14] <niklasfi> ok. between 11:57 and 12:00 the system froze and generated 10000 lines of syslog. then again at 12:04 the system froze for another five minutes leaving another 10000 lines of syslog
[22:14] <krosswindz> wow that is a lot
[22:15] <krosswindz> what i/o load were you generating around then?
[22:15] <niklasfi> just for today i have 69418 lines of syslog
[22:15] <niklasfi> umm. i don't really know actually most of today was downloading stuff from the internetz so i guess maybe 800kB/s
[22:15] <niklasfi> over a long period of time
[22:16] <niklasfi> the system is capable of doing up to 4MB/s for short intervals, of maybe 1 or two minutes before locking up
[22:16] <mythos> is canonical paid for to develop this SDK "http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/index_FDS.html" for TI?
[22:17] <infinity> mythos: If they are, I don't know about it (and I'm "them").
[22:18] <mythos> hmm... thx infinity. i only ask, because my boss said, that citrix said, that ti is paying canonical for this SDK...
[22:19] <niklasfi> is there a board available that is more stable maybe even with (e-)sata support?
[22:19] <infinity> mythos: That's a rather roundabout list of saids. ;)
[22:19] <mythos> infinity, yeah, that's why i asked =)
[22:19] <infinity> niklasfi: The i.MX53 QuickStart has SATA.
[22:20] <GrueMaster> niklasfi: The Freescale Quickstart has SATA and we support it.
[22:20] <infinity> For some value of "support".
[22:20] <infinity> But we have images, and they work.
[22:21] <niklasfi> infinity: can i boot from sata?
[22:22] <mythos> so you are canonical's "arm-team", infinity? ^^"
[22:22] <niklasfi> sadly it does not have gigabit ethernet :(
[22:25] <niklasfi> is that possible though with current arm hardware?
[22:25] <infinity> mythos: I'm one of them. :P
[22:25] <infinity> niklasfi: It's not that it's not "possible", there are two primary reasons why it's not often done.
[22:26] <niklasfi> infinity: what are they?
[22:26] <infinity> niklasfi: 1) Most of these cheap dev boards like to hang all their devices off USB.  USB can't do GigE (well, it could, but not at full-speed, so why bother?)
[22:26] <infinity> niklasfi: 2) GigE is wildly more expensive than 100baseT, and they're trying to keep the dev boards affordable.
[22:26] <niklasfi> am I the only one who thinks these boards make perfect home servers?
[22:27] <infinity> niklasfi: If you want something designed to be a server instead of a cell phone dev platform, you might want, say, a Trimslice.
[22:28] <infinity> niklasfi: They're a tiny bit (not much) more expensive, but come with GigE and SATA options.  And actual cases.
[22:28] <mythos> so, if i have a dev board with 2 gbit ports, i have a very expensive one? o.o
[22:28] <infinity> mythos: From the POV of cost-cutting, yes. :P
[22:28] <infinity> mythos: (Which board is that?)
[22:29] <mythos> infinity, http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/exports/DM814x_AM387x_EVM_Quick_start_guide.pdf
[22:29] <mythos> there are some images in the pdf too
[22:30] <mythos> rather nice. i boot it via sdcard and mount the rootfs via nfs
[22:32] <infinity> mythos: Shiny.
[22:34]  * infinity is trying to resist buying a Trimslice.
[22:34] <mythos> re
[22:34] <mythos> what was the last thing, i wrote here?
[22:35] <infinity> 15:30 < mythos> rather nice. i boot it via sdcard and mount the rootfs via nfs
[22:35] <mythos> oh, ok... thx
[22:36] <niklasfi> infinity: are they that tempting?
[22:36] <infinity> niklasfi: I like toys.
[22:37] <niklasfi> infinity: but i don't know. i really can't trust these guys if they make their webpage that crappy
[22:37] <infinity> And it would replace my mx53 as my archive mirror.
[22:37] <infinity> Your trust is based on the quality of people's web design? :)
[22:37] <infinity> It's actually not that bad for a small manufacturer.
[22:37] <infinity> I've seen much worse sites. :P
[22:38] <niklasfi> infinity: yes, it is very much in deed. if people can't set up a proper site using a markup language, how can i trust them with turing complete languages, or even hardware
[22:40] <infinity> Hardware nerds don't tend to care much about pretty web sites, in my experience.
[22:40] <infinity> So, really, what you're looking for is "did they hire a good web monkey", to which the answer appears to be "no".
[22:40] <infinity> (Hint, Canonical employs web developers to work on the website, and they're not the same people who work on Ubuntu, so judging one by the other would, again, be silly, right?)
[22:41] <niklasfi> infinity: i guess the problem is that i am no hardware nerd. I sometimes would very much like to understand what you guys do, but i haven't even gotten to learning all of the boot options i need to manually start my ubuntu from grub
[22:42] <mythos> uboot is/was new to me too
[22:42] <niklasfi> infinity: yes. but it gives me information about how much they care about their user base. if they are alright with making them suffer by showing them crappy web pages, they are probably alright with making them suffer by giving them bad support
[22:43] <mythos> but with some time, you can learn everything
[22:49] <infinity> niklasfi: Most of the support for the Trimslice is via their wiki.  Then again, that's not much worse than the situation with most dev boards. :)
[22:50] <infinity> (To be clear, I have no affiliation with them, and I don't even own one, but they look neat and, like I said, I like toys)
[22:57] <GrueMaster> infinity: On this f-k-i bootparm issue, I'm trying to figure how best to ensure some kernel parameters are passed from cmdline or enabled via preseed.  I need to make sure none are duplicated.  Suggestions?
[22:58] <GrueMaster> I really don't like scripting in shell.  Especially busybox.
[22:58] <infinity> GrueMaster: Well, I get the impression that user-params smooshes together both command line and preseed into one.
[22:59] <infinity> GrueMaster: I didn't look closely, but I assume it removes dupes?  Dunno.  If not, it should.
[22:59] <GrueMaster> Nope.  Just preseed from what I can tell.
[22:59] <infinity> GrueMaster: No, not just preseed.  It starts by parsing cmdline.
[23:01] <infinity> GrueMaster: Most of the script is about parsing and filtering cmdline, then it adds the preseed bits at the end.
[23:02] <infinity> GrueMaster: Although, I think it only parses and collects options after the "--" (ie: user-added options)
[23:02] <GrueMaster> Possible.  I'm looking at it now.
[23:02] <infinity> GrueMaster: Which makes sense, since f-k-i or grub-installer, etc, should be what's responsible for making sure platform-specific options are in place.
[23:03] <GrueMaster> So the mem= lines should be on by default for omap4.  makes sense.  I can do that.
[23:04] <infinity> GrueMaster: Anyhow.  Avoiding duplicates is easy enough, we can just loop through our options in f-k-i.
[23:04] <GrueMaster> What I don't see though is things like module parameters, or console parameters.  Not that either are critical for first boot afaict.
[23:05] <infinity> GrueMaster: Well, if you were to add module params manually, they'd land after the -- ... Or they should.
[23:05] <infinity> So, user-params would pick them up.
[23:06] <GrueMaster> Ok.  The kernel shouldn't care I guess.
[23:57] <GrueMaster> d-i sucks in so many ways.  http://paste.ubuntu.com/828261/
[23:58] <infinity> GrueMaster: I don't see anything sucking there.
[23:59] <infinity> GrueMaster: Everything's listed the same number of times it's provided.  We can easily make them unique later.
[23:59] <GrueMaster> Only that user-params is spewing both /proc/cmdline and preseed.
[23:59] <infinity> GrueMaster: It's supposed to.
[23:59] <infinity> GrueMaster: Like I said, everything after the -- on cmdline, plus preseed.  That's intentional.