[10:24] <sveinse> I have a natty system which locks up during boot. My suspicions goes to mountall as previously discussed on  here.
[10:25] <sveinse> I've created an early login with getty on ttyO2. I notice that echo foobar >/dev/console does not print anything on my console, yet the kernel is setup with console=ttyO2,115200n8
[10:26] <sveinse> Why could that be? Does ubuntu initramfs do anything special to the console?
[10:34] <sveinse> I.e. where does /dev/console go if not to the console i've specified on the kernel command line
[10:58] <ogra_> sveinse, do you have devtmpfs enabled ? thats usually mounted by initramfs as first thing
[11:02] <mik1> cd
[11:02] <mik1> ll
[11:03] <ogra_> file not found
[11:08] <sveinse> ogra_ yes I think so. When logged into the system devtmpfs is mounted.
[11:13] <sveinse>  /dev/console has another major/minor number than ttyO2, so I presume the kernel handles this redirection?
[11:14] <ogra_> if your console= args are right
[11:21] <sveinse> ogra_ I wouldn't get the initial demesg output from kernel without it. However I have observed for a long time that when the initramfs takes over, any output to the console is stopped
[11:21] <ogra_> you would get the initial dmesg oputput
[11:22] <ogra_> for a console on ttySX you need two console args
[11:22] <sveinse> I have console=ttyO2,115200n8
[11:23] <ogra_> (forst is for kernel, second for userspace)
[11:23] <ogra_> *first
[11:23] <sveinse> aha. so console=ttyO2,115200n8 console=ttyO2
[11:25] <ogra_> try that and see if you get more
[11:25] <ogra_> also make sure to not have "quiet" set
[11:25] <ogra_> this will definitely suppress all msgs from initrd
[11:25] <sveinse> thanks, I'll certainly try
[11:41] <sveinse> ...and all of the sudden I cant binfmt armel exec's (e.g. debootstrap) on my natty host (amd64). Has something changed recently in respect of kernel
[11:42] <sveinse> I notice binfmt_misc.ko is not loaded automatically any longer, and modprobing it does not help the issue :(
[11:46] <mik1> guys is anyone of you playing audio from the beagleboard? if yes could you please advice which distro to use?
[11:53] <sveinse> All binfmts were apparently set to disabled. update-binfmts --enable qemu-arm did the trick. Wonder why though
[12:06] <ayaka> could i let second-stage bootloader don't anything in  a android mobile to boot a linux kernel
[12:55] <sveinse> ogra_ I worked by doubling console=, thanks! It also reveals why mountall is apparently locked up, see http://paste.ubuntu.com/881794/
[12:55] <sveinse> Note that I'm not using fixrtc in this setup
[12:56] <ogra_> apparently :)
[12:56] <ayaka> could i let second-stage bootloader don't anything in  a android mobile to boot a linux kernel
[12:58] <sveinse> ogra_ I have basically two options: Either run with fixrtc but then I need the patch you made (haven't checked if the patch has made into natty-update though)
[12:59] <sveinse> Or without fixrtc, but then I need to get past this interactive part which I pasted
[13:00] <sveinse> We had a discussion internally, and we prefer not using fixrtc as it has unexpected sideeffects if the user (for some reason) needs to set the time backwards
[13:03] <ogra_> well, make your installer remove fixrtc from the cmdline after its clear the clock is right, thats the only sane option
[13:03] <ogra_> imho
[13:05] <sveinse> yes, I partly agree. Since the product has no interactive way of dealing with questions from mountall, its not an acceptable option either. The RTC battery will expire within the lifetime of the product
[13:08] <sveinse> Unless other simpler options I am considering making a plymouth theme which can respond to such messages and supply keystrokes to allow it to continue
[13:14] <danboid> Would anyone know of any newer kernel packages for 11.10 armel Panda as the repo ones don't have ALSA sequencer support compiled in it seems
[13:15] <ogra_> danboid, you could ask linaro or check the TI PPA
[13:17] <danboid> ogra_, I've tried 3.1.0 from the PPA but that had the same issue- I presume I can use the linaro 11.10 PPA with canonical Ubuntu right?
[13:17] <danboid> ogra_, 3.1.0 from the ti ppa
[13:17] <ogra_> for just the kernel that should be fine
[13:21] <danboid> So what does Linaro offer over the canonical builds/distros?
[13:22] <danboid> Whats the relationship between Linaro and Canonical?
[13:26] <gildean> danboid: http://www.linaro.org/engineering/
[14:44] <sveinse> ogra_ , does initramfs honor/bring along /etc/e2fsck.conf ?
[14:45] <sveinse> I.e at the time of mountall and e2fsck, /etc is inside the initramfs, right
[14:45] <ogra_> well, if its in place it should be used
[14:45]  * ogra_ hasnt tried it ever 
[14:45] <sveinse> ok, thanks
[15:45] <sveinse> Has ureadahead any improving features on armel (natty)? On my system it just reports ureadahead terminated with status 5
[15:45] <sveinse> ..running off a sdcard
[15:46] <ogra_> its in two parts, one improves the loading at boottime, the other runs in userspace and preloads libs etc
[15:46] <ogra_> even if the first part terminates, the second will still gain you improvements
[15:47] <sveinse> I also have two accounts of "init: ureadahead-other main process (829) terminated with status 4"
[15:48] <sveinse> I have no problems leaving it as-is, just OOI
[15:48] <ogra_> hmm, might be that your kernel is missing options
[15:49] <sveinse> That is what crossed my mind as well. Where can I find these options?
[15:49] <ogra_> no idea :)
[15:49] <ogra_> i would compare your config with an equivalent one of an ubuntu kernel
[15:52] <sveinse> Well I did that some time ago, and there's a ton of differences. Ubuntu kernel = generic. Our kernel = specific. But I'll start looking.
[15:54] <sveinse> ogra_ if you care at all: Adding /etc/fsck.conf fixed the problem with using the broken_system_clock option. This will ensure e2fsck never fails due to missing or clock in the past.
[15:54] <ogra_> yeah, i know
[15:54] <ogra_> it was added upstream a cycle after fixrtc was added
[15:55] <ogra_> we had some discussions with ted about it
[16:59] <HokieTux> Hey all - Does Ubuntu-ARM support the NEON instruction set?  The top comment in this bug (https://bugs.launchpad.net/ubuntu/+bug/848154) seems to indicate that NEON is disabled in Ubuntu builds for non-v7 support?
[16:59] <ubot2`> Launchpad bug 848154 in ubuntu "ARM version not supporting V6 RaspPi" [Undecided,Invalid]
[17:01] <GrueMaster> HokieTux: Neon support and V6 Raspberry Pi support are two separate issues.  By default, the main packages do not use neon, as there are several v7 SOC's that do not use neon (nVidia Tegra series, Marvell Armada series, etc).
[17:02] <HokieTux> GrueMaster, yeah, I know they are separate issues - that is just one of the threads that came up when I was searching for details, and the top comment seemed relevant to non-Pi platforms.
[17:02] <infinity> HokieTux: We "support" NEON, we don't build with it enabled by default, except in packages where run-time selection can be done.
[17:02] <GrueMaster> Raspberry Pi uses armv6 which means no thumb2 support.  All of our packages are currently compiled for thumb2 since Lucid.
[17:03] <HokieTux> infinity, GrueMaster - I'm specifically working on OMAP3 platforms, on the moment, and using Angstrom.
[17:03] <HokieTux> I am investigating using Ubuntu, and that comment just made me suspicious.  So it is possible to build Ubuntu-ARM with NEON support, then?
[17:03] <GrueMaster> We fully support omap3 (see our omap3 images - they work on beagle systems).
[17:03] <infinity> HokieTux: You could rebuild the whole archive with neon enabled by default, it would buy you very little.
[17:04] <infinity> HokieTux: The packages that have hand-tuned NEON routines tend to have those enabled at runtime already.
[17:04] <infinity> HokieTux: libjpeg-turbo being a good example.
[17:04] <infinity> HokieTux: "turning on NEON optimisation" does very little without special consideration in the code, from what I've seen, so I wouldn't worry too much about it. :P
[17:05] <HokieTux> infinity, aha - so the packages that have them auto-detect support at runtime?
[17:05] <HokieTux> That more or less answers my question.
[17:05] <infinity> HokieTux: Certainly not every single package that could have NEON support does run-time autodetection, but a good many do.
[17:06] <HokieTux> Ah - so it isn't disabled in the kernel, then; it's just that not all packages are necessarily built with it?
[17:07] <infinity> HokieTux: Anyhow, I'd recommend trying out the precise armhf/omap images and just seeing how it all works for you.
[17:07] <infinity> HokieTux: The kernel couldn't care less.  And the compiler and assembler are more than capable of doing NEONy things.  As you surmise, we just don't build with it on by default (except where it can be done at runtime).
[17:08] <infinity> Because, as GrueMaster says, we support v7 SoCs that don't have NEON.
[17:08] <infinity> So, the world would explode for them. :P
[17:08] <HokieTux> Great =)
[17:08] <infinity> One could argue that ARM oopsed a bit by not requiring NEON in the ARMv7 spec, but a bit late now. ;)
[17:08] <HokieTux> infinity, I almost certainly will try it, then.  If that comment about NEON being disabled at the kernel level in all Ubuntu-ARM builds were true, it wouldn't be worth my time at all since NEON is 100% required for my application.
[17:08] <HokieTux> That's why I was asking-before-trying
[17:08] <HokieTux> Thanks for clearing up my confusion, though =)
[17:09] <infinity> HokieTux: Did Oli mention kernels in that comment?  If so, he was typing faster than he was thinking.
[17:10] <infinity> HokieTux: Anyhow, in your specific case, yeah, life's good.  The toolchain will happily compile your NEON-needing application, and the userspace and kernel will happily run it.
[17:10] <HokieTux> Hah, no, he didn't specifically mention kernels - he said "... NEON which we forbid to be build-time enabled by default due to teh fact that we support non NEON armv7 devices"
[17:10] <infinity> Yeah, that's fairly accurate.
[17:10] <infinity> If a bit awkwardly-worded. ;)
[17:10] <HokieTux> Yeah, it sounds scary to people that require it, hah.
[17:11] <infinity> Well, "forbid" probably needed a caveat of "for distro packages".
[17:11] <infinity> The toolchain will let you do whatever you want to your own stuff. ;)
[17:11] <HokieTux> Aha
[17:12] <HokieTux> infinity, so the short version is that distro-wide packages are built WITHOUT NEON support for compatibility, and  most libraries that have hand-tuned NEON assembler will auto-detect compatibility at run-time?
[17:12] <infinity> Roughly that, yes.
[17:13] <HokieTux> and if we wanted to add hand-tuned NEON to distro packages, we would need to use the toolchain to build our own packages
[17:13] <infinity> Or, rather, things that can auto-detect, we let them.  Things that are compile-time "on or off", it's off.
[17:13] <infinity> So, if you want to add hand-tuned NEON to distro packages, make it a run-time detection, not a compile-time option.
[17:13] <infinity> And everyone wins.
[17:16] <HokieTux> infinity, great
[17:18] <HokieTux> I really appreciate your time and help =)
[17:34] <ogra_> grmbl
[17:34] <ogra_> so no initrdless boot for now :(
[17:38]  * ogra_ wonders if CONFIG_UNIX98_PTYS is set to M in the panda config 
[17:39] <ogra_> else i dont get why i see bug 954243
[17:39] <ubot2`> Launchpad bug 954243 in linux-ti-omap4 "booting pandaboard without initrd dies with "init: no available ptys"" [Undecided,New] https://launchpad.net/bugs/954243
[17:40] <sveinse> Is double usage of console= in kernel commandline mutually exclusive with plymouth? My splash went away when I started using console=...
[17:40] <ogra_> plymouth shuts down the splash if it detects a serial console option
[17:41] <ogra_> silly upstream decision, was discussed at lenght a while ago
[17:42] <sveinse> Hmm ok. Doesn't work too well when the [serial] console != display unit
[17:43] <ogra_> it omits the splash as soon as you set "console=" iirc
[17:44] <sveinse> omit = not starting plymouth
[17:45] <ogra_> well, at least not showing a splash, i'm not sure how the plymouth daemon acts
[17:47] <ogra_> crap ... so i guess we need to drop the idea of initrdless boot ...
[17:47] <ogra_> doesnt look like the kernel can mount devpts automatically
[17:47] <ogra_> and without it upstart will fall flat on its face
[17:48] <sveinse> in which you need to do mountall / fstab...
[17:49] <GrueMaster> ogra_: Was this even tested on x86?  Seems to me it would fail there as well.
[17:49] <ogra_> yes, it would, it used to work in oneiric
[17:50]  * ogra_ tries with fstab entry but i doubt that saves me 
[17:50] <ogra_> since upstart will likely fail before
[17:52] <ogra_> nope, fails the same way as expected
[17:53] <infinity> ogra_: perhaps upstart changed to require UNIX98 ptys, and it used to fallback to /dev/tty* or something?
[17:54] <ogra_> something like that i guess
[17:58] <ogra_> the kernel config (which i suspected first) is definitely fine
[17:58]  * ogra_ gives up for the day
[18:01] <GrueMaster> I'd double check the kernel config.  We were bitten by these changes when cooloney copied the omap4 kernel config for the armadaxp kernel.  He reverted some of these omap4 specific changes lst night and it runs fine now.
[18:11] <ogra_> GrueMaster, i did before haking up fstab
[18:24] <sveinse> oh joy! AFAICS the splash-off feature in plymouth when using serial console is hardcoded into plymouth
[21:36] <dpcrespo> hi
[21:37] <dpcrespo> i try booting ubuntu 11.10 on igepv2
[21:37] <dpcrespo> and not working
[21:38] <dpcrespo> i read this https://wiki.ubuntu.com/ARM/OmapNetbook
[21:39] <dpcrespo> but the last message i have is "Uncompressing Linux... done, booting the kernel."
[21:40] <GrueMaster> What image are you trying?
[21:41] <dpcrespo> http://cdimage.ubuntu.com/releases/11.10/release/
[21:41] <dpcrespo> this
[21:41] <GrueMaster> Desktop or server?
[21:42] <dpcrespo> Desktop
[21:42] <GrueMaster> Do you have a keyboard, mouse, and monitor hooked up to your system?
[21:42] <dpcrespo> keyboard and mouse
[21:42] <dpcrespo> no
[21:42] <dpcrespo> i have only monitor
[21:43] <GrueMaster> And nothing shows up on the monitor?
[21:43] <dpcrespo> no
[21:43] <dpcrespo> when it is booting
[21:44] <dpcrespo> the monitor change to orange color
[21:44] <dpcrespo> and after without signal
[21:44] <GrueMaster> Try the server image to see if it gets further.  Unfortunately, that platform is untested by us, so may not work with our image.
[21:44] <GrueMaster> I assume the message you are getting is via serial console.
[21:45] <dpcrespo> yes with minicom
[21:45] <dpcrespo> you know stable version
[21:45] <dpcrespo> with igepv2
[21:46] <GrueMaster> We do not actively test on that platform.  I'm told it should work, but I have no way of knowing.  I recommend trying the server image, because it is designed to do all of the installation steps through the serial console.
[21:46] <dpcrespo> ok
[21:47] <dpcrespo> i try this
[21:47] <dpcrespo> thx for your help
[21:48] <dpcrespo> when i test
[21:49] <dpcrespo> i tell you
[21:49] <dpcrespo> thx
[23:57] <jbicha> hi, I need some help figuring out how to get cogl to build on arm