[00:44] <brandini> what does the one LED that flashes all the time mean on ubuntu?
[00:50] <infinity> ?
[00:50] <infinity> On which hardware?
[00:51] <brandini> the pandaboard
[00:52] <brandini> the hardware specs say that it's user defineable
[00:53] <infinity> "STATUS1" (the LED furthest from the SD card on a Panda) is USB activity, I believe, and STATUS2 is SD activity.
[00:54] <infinity> I'm not positive on the STATUS1 thing, though.
[00:54] <infinity> It does seem to go up when I shove things through the USB bus, though. :P
[00:56] <infinity> I suspect the kernel knows for sure.
[01:02] <brandini> hrmmm
[01:10] <rsalveti> brandini: heartbeat
[01:11] <rsalveti> one is for heartbeat and the other is for sd activity
[01:27] <infinity> rsalveti: It's a pretty inconsistent heartbeat.
[01:27] <rsalveti> infinity: well, depends on the cpu usage
[01:44] <brandini> mine seems regular enough :)
[02:52] <dash> woo hoo, got my mx53
[02:53] <dash> looks like it's got its own kernel package. anybody using natty with this board?
[06:20] <ria_> hi, i have installed ubuntu 10.10 on my pandaboard, kernel version  2.6.35-903-omap4 #14-Ubuntu SMP PREEMPT
[06:20] <ria_> i am getting the following error during startup
[06:20] <ria_>  Unhandled fault: imprecise external abort
[06:20] <ria_>  Internal error: : 1406 [#2] PREEMPT SMP
[06:20] <ria_> ...
[06:21] <ria_> Process pulseaudio (pid: 1273, stack limit = 0xae4e42f8)
[06:21] <ria_> any idea what is wrong with my system?
[06:21] <twb> Use a pastebin if you have lots more lines
[06:21] <twb> Dunno about the error, but disabling pulseaudio would seem to be a good first thing to try
[06:23] <ria_> couldnt get the totem player to work... it reports "cannot connect to server.... jack server is not running or cannot be started"
[06:26] <twb> I dunno about GUI stuff
[06:26] <twb> If you just want to test sound try aplay(1)
[06:27] <twb> jack and pulseaudio are huge behemothic things, it wouldn't really surprise me if they fell down and died for some silly reason on non-x86 hardware
[06:27] <ria_> thanks i'll give it a try
[07:12] <sniperjo_> Hi guys, I've got 2.6.32 running with an oneiric roots. when booting it seems to get to" udevd[2861]: unable to receive ctrl connection: Function not implemented" and then just repeats this over and over again. Any ideas ?
[07:14] <Jack87> (
[07:16] <twb> sniperjo_: it wouldn't surprise me if oneiric simply doesn't work with a kernel that old
[07:17] <twb> It sounds like udev vs. kernel version incompatibility to me
[07:18] <sniperjo_> GrueMaster and infinity  seem to think there wouldn't be too much of a problem with the kernel
[07:19] <sniperjo_> twb:  basically i have a working version of angstrom and I'm looking to get ubuntu on it. this is the angstrom kernel is quite old !
[07:21] <twb> I would try to make lucid work first, since that shipped with .32
[07:22] <sniperjo_> twb: I've been trying for the past week solid to do it! what would you recommend, just swapping the roofs over ?
[07:24] <twb> I'm no expert, man
[07:24] <twb> I can't even get a new bootloader to work on my device
[07:24] <sniperjo_> I'm not the only one who has problems then!
[07:30] <infinity> sniperjo_: Hey, don't drag me into this.  I didn't say 2.6.32 would work. :)
[07:30] <infinity> But yeah, looks like a kernel/userspace disagreement with udev. :/
[07:31] <twb> I expect there is an anti-udev bigot in the audience who would like to interject at this point :P
[07:32] <infinity> I used to run udevless all the time.  But I'm not sure if MAKEDEV will actually create all the nodes his system needs to get away with it.
[07:34] <twb> But udev does all sorts of extra, scary shit now
[07:34] <sniperjo_> infinity: i thought you said something along the lines of new userspace should work fine with older kernels, or something like that ! :P
[07:34] <twb> sniperjo_: well, in theory it should
[07:34] <infinity> sniperjo_: Well, in every respect other than udev, sure.  Old kernels and new chroots are happy.
[07:35] <sniperjo_> well last night we ended up disabling udev, and still don't seem to get a login prompt
[07:39] <infinity> No udev means no devices.
[07:39] <twb> Isn't there some kernel pseudofs that can do it instead of MAKEDEV
[07:39] <infinity> If you can chroot into that system and "cd /dev && MAKEDEV" it might fix you up.
[07:39] <twb> sniperjo_: also if you refer to e.g. root=LABEL=fred you need udev
[07:40] <infinity> twb: devfs might be dead.  If it's not, it should be.
[07:40] <twb> infinity: I had some memory that it was used before udev in the initramfs-tools or something
[07:40] <twb> I'm probably just misremembering
[07:41] <sniperjo_> something like Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait ?
[07:41] <twb> sniperjo_: does mmcblk0p2 exist when you just mount the rootfs somewhere?
[07:41] <twb> The device file, I mean, inside /mnt or wherever you mount it
[07:42] <infinity> Almost certainly not.
[07:42] <sniperjo_> twb: arm no, i think its a function of board
[07:42] <twb> Ya so fix that
[07:44] <sniperjo_> twb: how?
[07:45] <twb> 17:39 <infinity> If you can chroot into that system and "cd /dev && MAKEDEV" it might fix you up.
[07:46] <sniperjo_> ah i missed that
[07:46] <sniperjo_> so boot in with angstrom and try it?
[07:47] <infinity> And then disable udev again, so it stops having a hissy fit.
[07:47] <infinity> Well, after you MAKEDEV, check and see if the device node you need is there.
[07:47] <infinity> If it's not, you'll get to look up the major and minor of mmcblk* and mknod. :P
[07:48] <infinity> (I can't imagine why we replaced all this with automation)
[07:51] <twb> sniperjo_: no just chroot in from a real machine
[07:51] <sniperjo_> twb: ok, because i was just about to say, chroot from the arm could be a little challenge
[07:52] <twb> infinity: obviously what we should be doing is just referring directly to /sys/dev/<major>/<minor> and forego this wussy "naming" thing
[07:55] <sniperjo_> erm for some reason Ichroot  media/de74c7e5-118c-4da7-b7a9-858cf661c650 ,: chroot: cannot run command `/bin/bash': No such file or directory
[07:56] <infinity> sniperjo_: Err, you can't chroot from a non-ARM system into an ARM one.
[07:56] <sniperjo_> infinity: twb: sniperjo_: no just chroot in from a real machine
[07:57] <sniperjo_> ah ok
[07:57] <infinity> A real ARM machine? ;)
[07:57] <sniperjo_> ah, that bit was lost in translation !
[07:58] <infinity> (You could do it with qemu-user-static, I suppose... But I'm too tired to walk through setting that up for chroots)
[07:58] <infinity> Well, it's not rocket science, I guess.
[07:58] <infinity> You install it in the host, "dpkg -L qemu-user-static", grab the *arm* binaries and place them in the same filesystem location in the chroot.
[08:00] <infinity> I think it's way past bedtime here, though.
[08:00] <sniperjo_> same file system location ?
[08:00] <sniperjo_> lol
[08:00] <sniperjo_> are you sure you don't want to solve an un-solvable problem ?
[09:05] <ogra_> bah, the answer tracker of LP sucks
[09:06]  * ogra_ just asked a question janimo asked already :(
[09:06] <janimo> ogra_, which question?
[09:06] <ogra_> "cant install from usb stick"
[09:07] <ogra_> i use to read my mails in order but somehow the mails from the answer tracker dont get threaded anymore
[09:07] <ogra_> i guess that happens if someone answers by mail directly instead of using the web ui or so
[09:08] <janimo> so you asked or answered the same question?
[09:08] <ogra_> well, i asked if he had partitions at all
[09:08] <janimo> ah ok
[09:08] <ogra_> just to see a few mins later that he has a fourth partition but no others
[09:09] <janimo> yet another mobile operating system with intel cofounding  - tizen.org
[09:09] <janimo> dithcing native linux app stack for html
[09:09] <ogra_> doesnt mozilla do that as well ?
[09:10] <ogra_> funny that everyone tries to reimplement webos :)
[09:11] <janimo> I think ti actually is a better dev platform than the mixed crack we have now in ubuntu
[09:11] <janimo> html5 & co that is
[09:12] <ogra_> sure, i would have gone for a webos solution years ago :)
[09:12] <ogra_> but implementing the desktop apps in html/javascript wasnt the answer it seems :)
[09:12] <ogra_> janimo, btw, you run bootchart on your ac100 ?
[09:12] <ogra_> how do you fit that into the initrd ?
[09:13] <ogra_> my system blows up if i pass the 3.something Mb
[09:13] <ogra_> (for the compressed initrd)
[09:14] <janimo> ogra_, I did not even know boothcart is put in intrd - althought it makes sense
[09:14] <janimo> My boot part is 8 Mb
[09:14] <ogra_> mine too
[09:14] <janimo> I built a kernel with all ac100 modules (~35) as builtins
[09:14] <ogra_> the bootloader falls over of you get somewhere between 3-4M
[09:14] <janimo> and it grew by less than 1.5M
[09:15] <janimo> ogra_, not here apparently
[09:15] <ogra_> yeah, the kernel size isnt the prob
[09:15] <ogra_> how big is your initrd atm ?
[09:15] <janimo> les than 2M
[09:15] <ogra_> aha
[09:15] <janimo> I doubt bootchart would be that big
[09:15] <ogra_> it has deps
[09:15] <janimo> standard ac100 from package
[09:15] <ogra_> i wonder how you got it that small
[09:15] <ogra_> thats a default install ?
[09:15] <janimo> yes
[09:15] <ogra_> weird
[09:16] <ogra_> mine is 2.9M
[09:16] <janimo> ok, letme double check then
[09:16] <ogra_> close to the edge of falling over
[09:16] <ogra_> though this is my upgraded natty
[09:16] <ogra_> if we actually end up with less than 2 i can turn plymouth back on !
[09:17] <janimo> ogra_, ramdisk 2.19 Mb
[09:17] <ogra_> hmm
[09:17] <janimo> time to test our daily images don;t you think :) ?
[09:17] <sniperjo__> join /#angstrom
[09:17] <sniperjo__> wooops
[09:17] <ogra_> well, i still have a few bugs to fix on omap4
[09:17] <ogra_> and in the ac100 installer
[09:18] <janimo> and doing the work on the ac100 for it?
[09:18] <ogra_> sure
[09:18] <janimo> don;t you have one just for testing?
[09:18] <janimo> anyway I can run bootchart fine
[09:18] <ogra_> well, currently its a builder
[09:18] <ogra_> great
[09:18] <janimo> but found no low hanging fruit :(
[09:19] <janimo> boot varies betwen 38 and 45 secs
[09:19] <janimo> even without changes, not alwaay determinitsic
[09:19] <ogra_> did you upload the png somewhere ?
[09:19] <janimo> not yet, but I plan to
[09:19] <ogra_> k, point me to it once you have :)
[09:19] <janimo> I thought it is so easy to run and without an analysis I did not start uploading yet
[09:19] <ogra_> i'd like to see the IO
[09:19] <janimo> I tried disabling readahed but little effect
[09:19] <ogra_> well, it requires a reboot :)
[09:20] <janimo> I tried building all modules in the kernel, again no visible effect
[09:20] <janimo> well I am at bootvchart png-20 so I guess  I have afew reboots :)
[09:21] <janimo> for some reason I was expecting significant gains from modules being builtin
[09:21] <ogra_> heh, no
[09:21] <janimo> but apparently modprobe is very fast nowadays
[09:21] <ogra_> and we only load them late
[09:21] <ogra_> initrd doesnt contain any modules by default
[09:21] <janimo> they are loaded during boot in the first 40 secs
[09:22] <janimo> no modules in initrd?
[09:22] <ogra_> right, but after you moved to the actual root
[09:22] <ogra_> no, that would make it over 4M
[09:22] <ogra_> the installer puts an initrd config in place with MODULES=dep set ...
[09:22] <ogra_> (which is equal to no modules)
[09:24] <ogra_> well, i'm lying ... if you actually install a package that forcefully drops a module into the initrd you will indeed have modules :)
[09:24] <ogra_> i.e. mdadm or lvm userspace stuff
[09:24] <ogra_> or cryptsetup
[13:52] <brandini> I'm having trouble getting the TI addons installed
[13:53] <ogra_> what release ?
[13:54] <brandini> Unable to locate package ubuntu-omap4-extras
[13:54] <ogra_> they only fully exist for maverick (10.10), for natty (11.04) TI didnt provide any
[13:54] <brandini> I'm on the daily from 09/26
[13:54] <brandini> ahhh ok
[13:54] <brandini> :)
[13:54] <ogra_> ah, yeah, not done yet
[13:54] <ogra_> it should be ready by release
[13:54] <brandini> I wonder if that's what's causing my go time test from failing
[13:54] <brandini> s/from/to/
[13:56] <xranby> brandini: if i understand the situation correctly, ti do not make the driver themself   they get it from Imagination Technologies' that own the design for the POWERVR™ SGX unit inside the omap
[13:57] <ogra_> xranby, ubuntu-omap4-extras is a lot more than just the GLES driver
[13:57] <ogra_> in fact we should have the driver for all releases in the PPA
[13:57] <ogra_> but the other bits only exist for maverick
[13:58] <ogra_> iirc ubuntu-omap4-extras-graphics should be installable on all but oneiric atm
[13:58] <ogra_> (not sured if rsalveti added a metapackage for -graphics when uploading the driver to the PPA)
[14:11] <sniperjo__> Hi guys, I've got 2.6.32 running with an oneiric roots. when booting it seems to get to" udevd[2861]: unable to receive ctrl connection: Function not implemented" and then just repeats this over and over again. Any ideas ?
[14:11] <ogra_> get a newer kernel, thats a typical error for the kernel missing bits for udev support
[14:12] <sniperjo__> ogra_: My board only seems to work with this kernal
[14:14] <sniperjo__> GrueMaster: seemed to think i would be able to do a little changing to get it to work
[14:15] <xranby> sniperjo__: the target kernel for oneiric are 3.0    the ac100 are an exception that will still use 2.6.38
[14:15] <xranby> sniperjo__: which board are you using?
[14:16] <sniperjo__> a technexion tsunamipack, omap3530
[14:17] <ogra_> sniperjo__, there is surely a way to do it without udev, how much of userspace breaks throught it missing is hard to predict though, xorg and friends for example rely on udev info
[14:18] <sniperjo__> the board comes with angstrom with that kernel, and id like to get at least lucid on it
[14:19] <sniperjo__> the guys here last night thought going for the newest rootfs
[14:19] <ogra_> well, ask the vendor for the source i'd say
[14:19] <ogra_> and switch on SIGNALFD or whatever udev misses in your build
[14:20] <ogra_> after all its linux, and its unlawful for them to not give you the source if ou bought their board
[14:21] <sniperjo__> del we ended up disabling udev last night, but still diddnt get a console
[14:21] <sniperjo__> i have all the source
[14:21] <ogra_> because you dont have devices i guess
[14:21] <ogra_> well, then rebuild your kernel !
[14:22] <sniperjo__> i have no idea how to, I've spent the last week  following every possible tutorial
[14:23] <ogra_> you take your source, unpack it, geta cross compiler, run make menuconfig in the source tree and make zImage
[14:23] <sniperjo__> I've been on here everyday a sing about swapping rootfs and other ways around it
[14:24] <ogra_> why work around it if you can make it work properly
[14:24] <ogra_> really, kompile your own kernel with the right options and be done
[14:24] <ogra_> *compile
[14:25] <sniperjo__> how long would that take ?
[14:25] <ogra_> 1h or less
[14:25] <ogra_> cross builds should be pretty fast
[14:26] <sniperjo__> i need to find someone to help me ....
[14:26] <ogra_> http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/
[14:26] <sniperjo__> followed that
[14:27] <ogra_> well, then you should have a uImage
[14:27] <ogra_> (you dont need xdeb btw, since you dont build any packages)
[14:28] <ogra_> (you only want the last paragraph actually)
[14:29] <janimo> sniperjo__, indeed, that is what I use and it works fine
[14:30] <sniperjo__> ogra_: do i need to add any repos ? linux-source-2.6.35 can't be found
[14:30] <ogra_> sniperjo__, why would you want that ?
[14:30] <janimo> sniperjo__, which kernel do you want to build? what device?
[14:30] <ogra_> you said you have the source of your vendor
[14:30] <janimo> you need to get the appropriate source for that
[14:30] <ogra_> so you indeed want to build that one
[14:31] <ogra_> apt-get install gcc-arm-linux-gnueabi
[14:31] <sniperjo__> ok so, what would the source look like ?
[14:31] <ogra_> thats all you should need
[14:31] <ogra_> you said you have it ?
[14:31] <ogra_> you should know how it waqs given to you
[14:32] <sniperjo__> well i have all the files nessasary to make an sd card
[14:32] <sniperjo__> they use the code sorcery arm
[14:34] <ogra_> sure, that doesnt matter
[14:34] <ogra_> well, if you have a kernel tree (likely a tarball) you need to unpack it
[14:35] <sniperjo__> i just downloaded the newest g++ lite from their site
[14:37] <ogra_> you are not on ubuntu ?
[14:38] <sniperjo__> i am
[14:39] <ogra_> well, then use the ubuntu gcc
[14:39] <ogra_> dont fiddle with an unpacked compiler
[14:39] <sniperjo__> ok, so could you tell me how ?
[14:39] <ogra_> apt-get install gcc-arm-linux-gnueabi ... as i said above
[14:39] <sniperjo__> yup, installed
[14:40] <ogra_> k
[14:40] <ogra_> now go to the kernel source tree
[14:40] <ogra_> run make menuconfig in there (you might need to install libncurse5-dev if it complains)
[14:40] <ogra_> then run: ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage modules
[14:41] <ogra_> and it will build a uImage and the matching modules
[14:41] <sniperjo__> what options do i want to select in the kernel config ?
[14:42] <ogra_> dunno, you need to ask a udev developer i guess
[14:42] <ogra_> signalfd is definitely needed
[14:42] <ogra_> and inotify support
[14:49] <sniperjo__> ogra_: arm… its asking me a lot of questions I'm just pressing enter for
[14:49] <ogra_> oh, wiat
[14:49] <ogra_> *wait
[14:49] <ogra_> can you boot the existing system on your device and get the running config from there (cat /proc/config.gz)
[14:50] <sniperjo__> (I've gone through about a 50 questions)
[14:50] <ogra_> using the output of that should get you a good starting config
[14:50] <ogra_> yeah, stop it
[14:50] <ogra_> you dont want that
[14:50] <sniperjo__> oh ok
[14:50] <ogra_> you need a default config to base on, else you will need to answer each and every question (and you need to answer them right)
[14:51] <ogra_> cat /proc/config.gz > my_new.config.txt
[14:51] <ogra_> that will copy the running config on your angstrom into the file my_new_config.txt
[14:52] <sniperjo__> yup ok
[14:52] <ogra_> that file you can copy to your source tree as .config
[14:52] <ogra_> (note the dot)
[14:52] <ogra_> then run make menuconfig again and it shouldnt ask anymore
[14:57] <sniperjo__> if run menuconfig it still lasks
[14:57] <ogra_> you copied the config into the right place ?
[14:58] <xranby> sniperjo__: are you using the source tree that came with your board?
[14:58] <ogra_> it usually doesnt, at least if the source is identical to the binary you run
[14:58] <sniperjo__> yup, they have same mf5
[14:58] <sniperjo__> md5*
[14:58] <ogra_> right, i was assuming you use the kernel tree of your vendor that also just runs as binary on your angstrom
[14:59] <sniperjo__> there is a file, called kernel in the files i downloaded from the manufacturers website, has the .config and the files you are talking about
[15:00] <ogra_> and a full kernel tree too ?
[15:01] <ogra_> janimo, how is mx5 looking ? final freeze is tomorrow so we should have them in shape today
[15:02] <janimo> yes, about to test the latest image
[15:02] <ogra_> great
[15:02] <ogra_> we only have tomorrow for emergencies
[15:02] <sniperjo___> is that the right kinda sounding place / file ?
[15:03] <xranby> sniperjo__: yes sounds like the right file..
[15:05] <xranby> sniperjo__: you can cross check that the Makefile contains the same kernel version as  your bopard report when running  uname -a
[15:05] <sniperjo___> if i do ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage modules, i get a bunch of warning for config : unexpected data, then i get a prompt for development of incomplete code / drivers
[15:06] <sniperjo___> angstrom is 2.6.32 i think, how do i check the make file
[15:06] <xranby> sniperjo___: try gedit Makefile
[15:06] <xranby> the version number are displayed at the top
[15:07] <janimo> sniperjo___, what is your boards config file? arch/arm/configs/xxx_defconfig
[15:07] <janimo> you need to add that in the make on first run
[15:07] <janimo> so ..... make XXX_defconfig
[15:07] <janimo> then uImage
[15:08] <ogra_> that shouldnt be needed if .config is there and he uses the right tree
[15:08] <sniperjo___> the make file came with the files that make the SD so its  the same
[15:08] <sniperjo___> 2.6.32
[15:10] <ogra_> and that mateches *exactly* the output of uname -r on your angstrom ?
[15:11] <sniperjo___> arm the manual has stuff in about make omap3_tsuanami_defconfig
[15:11] <sniperjo___> the manual is http://www.technexion.com/index.php/support-center/downloads/ti-cpu-modules/tao-3530/549-tao-3530-userguide-0953/download
[15:11] <ogra_> does your kernel tree have that in the config dir ?
[15:12] <ogra_> find . -name omap3_tsuanami_defconfig
[15:12] <ogra_> run that in your tree
[15:12] <ogra_> if its there, use it as janimo described above
[15:14] <sniperjo___> it does
[15:15] <ogra_> well, then try: make omap3_tsuanami_defconfig
[15:15] <ogra_> and see if it still asks
[15:17] <sniperjo___> OK config written
[15:17] <ogra_> well, now find out what the missing options are that cause your error i guess googlong will give you some hints
[15:17] <ogra_> *googling
[15:18] <ogra_> then find them in menuconfig and set them to the right values
[15:18] <sniperjo___> what error ? this is like looking for a needle in a haystack when i don't even know which planet its located on
[15:18] <ogra_> the error you posted with your first line in here today :)
[15:19] <sniperjo___> ogra_:  that was with the oneiric core
[15:19] <ogra_> which you want to get running or not ?
[15:19] <sniperjo___> yes
[15:20] <sniperjo___> i just want anything ubuntu > lucid !
[15:20] <ogra_> so, google for the error messaged in connection with kernel and udev
[15:20] <ogra_> *message
[15:20] <ogra_> and see if you can find what config options it needs
[15:20] <ogra_> then set these and build the kernel
[15:20]  * ogra_ needs to go mow the lawn ... back later
[15:21] <xranby> ogra_: have a good oneiric freeze day
[15:21] <sniperjo___> well.. my error comes up as the first result on patebin....
[15:21] <sniperjo___> noooooooo
[15:21] <ogra_> xranby, oh, i'm not finishig my day yet :) just needs to do someting that doesnt involve sitting my butt flat
[15:22] <sniperjo___> i will pay someone to spoon feed me the information on how to compile lucid or better on my board!
[15:22] <sniperjo___> i think I'm on the verge of slitting my writs
[15:29] <sniperjo___> nice to see know ones motivated by money, so who wants to help me without !!!
[15:32] <xranby> sniperjo___: we are trying our best to help you with all practcall questions..  i think you are the only one here with a tsunami board so you are the only one who can test when it work
[15:32] <xranby> sniperjo___: if you have a lot of error messages in front of you try paste them all into http://paste.ubuntu.com
[15:32] <xranby> it will makes us able to give you better hints what to do
[15:33] <xranby> sniperjo___: and if you get it working, try post what you did into a blog to let other users with a tsunami board know about it
[15:35] <xranby> sniperjo___: my best reccomendation are that *you* should try describe to someone else how to solve this...  by doing so you will sort your mind and get a better understanding how all the different parts relates
[15:35] <xranby> sniperjo___: “If you want to learn something, read about it.   If you want to understand something, write about it.  If you want to  master something, teach it.” ~     Yogi Bhajan
[15:37] <sniperjo___> xranby:  i have been doing both for the last week, week and a half
[15:37] <xranby> sniperjo___: excellent
[15:37] <sniperjo___> xranby: but i haven't succesded
[15:38] <xranby> you are making progress
[15:38] <gildean> sniperjo___: i don't see how this doesn't answer your questions mostly: http://www.linsys.fr/index.php/en/whitepapers/linux-lab/start-tsunami
[15:38] <gildean> just use the toolchain ogra_ adviced
[15:45] <sniperjo___> gildean: thanks ill have a look at that.
[15:49] <gildean> sniperjo___: it took you over a week to get to that information which i googled in a few seconds?
[15:49] <gildean> first you should learn how to google better :D
[15:50] <sniperjo___> gildean:  good facetious comment, but i have to different boards from the same manufacture, just so happens that i was concentrating on getting the other one up and running, but i gave up
[15:51] <gildean> just joking, don't take it too seriously
[15:52] <sniperjo___> its pretty hard not to when you've been trying something so hard for so long
[15:52] <sniperjo___> but if whatever you posted works…. i will forgive eyou … :P
[15:52] <gildean> :D
[15:52] <GrueMaster> Sometimes, finding the right query for google can be harder than figuring out how to fix something on your own.
[15:53] <ogra_> ++
[15:53] <GrueMaster> I know, I have spent days trying to find IPv6 test suites for Linux.
[15:53] <ogra_> GrueMaster, is there anything you have on your mind we urgently need to get done before final freeze ? we ahve a bit more thna 24h
[15:53] <GrueMaster> (and please, don't send me more links to whitepapers).
[15:53] <ogra_> geez, my typing sucks
[15:54]  * ogra_ only has TI icon, slideshow in oem-config and the partman bit on his mind
[15:54] <GrueMaster> ogra_: Nothing stands out so far.
[15:54] <GrueMaster> When is the Ti icon going to be added?
[15:55] <ogra_> GrueMaster, its there (always was) but the favorites handling changed
[15:55] <GrueMaster> Ah.
[15:55] <ogra_> GrueMaster, i'll work on that tonight/tomorrow
[15:55] <ogra_> seems its all d-conf now that gconf is done and indeed everything works different
[15:56] <ogra_> s/done/gone/
[15:56] <ppisati> guys, did anyone try the new omap4 kernel?
[15:56] <ppisati> rsalveti: ^^
[15:56] <GrueMaster> which one?
[15:56] <ppisati> i would like to pull today
[15:56] <GrueMaster> I've been doing SRU catchup.
[15:57] <ppisati> GrueMaster: http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.10_armel.deb
[15:57] <ppisati> it has 4460 support
[15:57] <GrueMaster> I have no board, but can make sure you didn't break existing stuff.  :P
[15:58] <ogra_> yeah, regression testing on that one is most important
[15:58] <ndec> ppisati: what did you use for this kernel? which branch?
[15:58] <ogra_> if 4460 doesnt work there wont be kittens dieing
[15:59] <prpplague> ogra_: just no beer and chips
[15:59] <ogra_> 8would be annoying to not have 4460 support, but would be worse to break existing pandas)
[15:59] <ppisati> ndec: TI BSP update: kernel-tilt/tilt-3.0-nodspvideo1 @ d2fe6284bb37abd542524b17f17cf9208db767c2
[15:59] <prpplague> ogra_: i am more concerned with the ES2.3 omap4430 based A4 board
[15:59] <prpplague> ogra_: did the EDID patch for the pullups get merged?
[16:00] <ogra_> prpplague, we tested that long ago i think
[16:00] <GrueMaster> A4????
[16:00] <ndec> sebjan: ^^^
[16:00] <GrueMaster> I "just" got an A3 last week.
[16:00] <ogra_> GrueMaster, iirc allison tested that
[16:00] <GrueMaster> I got her board.
[16:00] <ogra_> davidm reported it
[16:00] <ogra_> oh, i thought that was an A4
[16:00] <GrueMaster> A3
[16:00] <ogra_> prpplague, well, if we get no HW we cant test much :)
[16:01] <ogra_> send us HW :)
[16:01] <prpplague> ogra_: ok, i'll check with nipuna on this
[16:01] <prpplague> ogra_: i just assumed you had pulled the info
[16:01] <ogra_> i think ndec is after getting us 4460, not sure if A4 is on his list
[16:01] <ogra_> we didnt discuss A4 in the weekly calls
[16:03] <davidm> we were supposed to be getting 2 4460's but none have showed up yet
[16:03] <sebjan> ppisati: I was about to send you an email about that topic: kernel upgrade
[16:03] <ogra_> davidm, and A4 ?
[16:03] <ogra_> (its actually the first time i hear about A4)
[16:03] <davidm> Have not found any A4's but would want some to test with
[16:03] <GrueMaster> prpplague: Is there any significant changes in A4 that require software changes?  At this point it is probably too late to fix.
[16:03] <davidm> I've never heard of an A4 to date
[16:03]  * ppisati still has an A1
[16:03] <ndec> sebjan: ppisati is not using the branch with the linaro-3.0 stuff...
[16:03] <janimo> A$ the rpocessor in the iphone/ipad?
[16:04] <janimo> A4
[16:04] <sebjan> ppisati: we have tested this Andy's branch: tilt-linux-linaro-3.0 (de3104d9972327578baf63d6778b3cbd064aef22)
[16:04] <janimo> oh,m probably panda revision, nevermind
[16:04] <ogra_> janimo, yeah, they switched to TI now, not trusting their own CPUs anymore
[16:04] <ppisati> sebjan: but that's the linaro kernel
[16:04] <ogra_> :P
[16:04] <prpplague> GrueMaster: two major items, the silicon id needs to be added and the hmdi EDID signals have pullups that need to be disabled
[16:04] <ppisati> sebjan: we use vanilla + tilt
[16:04] <ndec> if that were true ;-)
[16:04] <ogra_> hehe
[16:04] <sebjan> ppisati: no, it's Linaro base kernel + TI patches
[16:04] <janimo> ogra_, http://en.wikipedia.org/wiki/Apple_A4 :)
[16:05] <ogra_> janimo, i know :)
[16:05] <janimo> ok
[16:05] <ogra_> i was just sarcastic ...
[16:05] <janimo> cortex a8+pvr too
[16:05] <ppisati> sebjan: yep, that's what i meant: linaro + tilt
[16:05] <ogra_> (a bit)
[16:05] <ppisati> sebjan: but for ubuntu we use vanilla + tilt
[16:05] <sebjan> ppisati: I though this is what you wanted for ubuntu in fact
[16:06] <ppisati> never used linaro-based kernel
[16:06] <janimo> possibly a lot of new 4460s go the the kindle fire production, ENOTENOUGH for developers
[16:06] <prpplague> ndec: just sent you an email regarding the ES2.3 omap4430
[16:06] <prpplague> ndec: any idea if the required items have been merged into the ubuntu release?
[16:07] <sebjan> ppisati: ok, I am confused, this is not what I remember we were supposed to use
[16:07] <prpplague> GrueMaster / ogra_  got a url i can browse the kernel release?
[16:07] <janimo> the mx5 bootup/installer is very slooooow
[16:08] <ogra_> ppisati, ^^ can you point prpplague to the current ti tree we use ?
[16:08] <GrueMaster> ppisati: Can you supply prpplague with a kernel url?
[16:08] <ppisati> sebjan: all the oneiric/omap4 kernels are based off vanilla + tilt stuff (agreen kept a branch just for this) + ubuntu sauce
[16:10] <ppisati> sebjan: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=summary - check the ti-omap4 branch
[16:10] <sebjan> ppisati: right I know, but I though it was while waiting for the linaro integrated version (with all other features)
[16:10] <ppisati> prpplague: here is the new kernel
[16:10] <ppisati> prpplague: http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.10_armel.deb
[16:11] <ppisati> prpplague: and here is the src code http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=summary ti-omap4-next
[16:11] <ppisati> sebjan: for oneiric? not really AFAIK
[16:12] <ppisati> sebjan: btw tomorrow is final freeze (kernel freeze was some weeks ago)
[16:12] <ppisati> sebjan: so...
[16:12] <ppisati> sebjan: perhaps someone from linaro wanted to manatin a linaro/ubuntu omap4 kernel
[16:12] <ppisati> *mantain
[16:13]  * ogra_ doubts that
[16:13] <ogra_> usually linaro isnt intrested in our kernels beyond comparing to theirs
[16:13] <ppisati> ok
[16:13] <ppisati> but were you aware of any switch to linaro kernel for O/omap4?
[16:13] <ogra_> no
[16:13] <ppisati> ok
[16:13] <ppisati> so we are in sync :)
[16:13] <ogra_> wont happen
[16:14] <ogra_> unless they change their support model
[16:14] <ogra_> (and security model)
[16:14] <ogra_> which i think wont happen within the next few releases
[16:15] <sebjan> ppisati: ok, so I'll have to test your kernel now
[16:15] <sebjan> ppisati: + I need to check your pvr module name, and you may need 2 additional patches for that
[16:16] <ogra_> i think rsalveti prepared all that stuff already (but better check twice)
[16:16] <ppisati> sebjan: no prob, send it to me
[16:16] <rsalveti> all needed patches are at the tilt tree already
[16:16] <rsalveti> ppisati: sorry, will test your kernel deb in a few
[16:16]  * ogra_ thought so
[16:17] <rsalveti> we have a critical bug at the linaro side noew
[16:17] <ogra_> yeah, display issues
[16:18] <sebjan> rsalveti: yes, but which tilt tree :) that's the question
[16:18] <ppisati> no prob, i'll still be around for... 6 hours? more or less
[16:18] <GrueMaster> prpplague: According to http://omappedia.org/wiki/PandaBoard_Revisions#Rev_A4_.28LATEST.29 A4 is identical to A3 except ES2.3 Silicon.  If there are board changes as well, how will they be identified, if the board ID hasn't changed?
[16:18] <rsalveti> sebjan: the tilt-linux-3.0
[16:19] <prpplague> GrueMaster: there are no board changes, it is all ES2.3 related
[16:19] <prpplague> looks like rsalveti has gotten the correct support added
[16:19] <GrueMaster> I thought you said there were HDMI EDID changes?
[16:19] <prpplague> GrueMaster: inside the silicon
[16:20] <prpplague> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=commit;h=58b36b7ce571c5b5cd6b8bc6b29f45eccc7a5f34
[16:20] <sebjan> rsalveti: this branch does not exist. Do you mean tilt-linux-linaro-3.0, or tilt-3.0-nodspvideo1?
[16:21] <rsalveti> sebjan: sorry, tilt-linux-linaro-3.0
[16:22] <sebjan> rsalveti: right, this is the branch I tested so far, but this is not the branch that is beeing integrated into the Ubuntu kernel
[16:22] <sebjan> the tilt-3.0-nodspvideo1 is being used (which does not include the linaro tree merge)
[16:28] <prpplague> GrueMaster / ogra_ looks like the support for es2.3 a4 pandaboards should be good
[16:28] <prpplague> i'll clone a copy and test
[16:29] <GrueMaster> ppisati: Testing your linux-image-3.0.0-1205-omap4_3.0.0-1205.10_armel.deb kernel now.  This has the A4 & 4460 fixes, right?
[16:30] <prpplague> GrueMaster: yes according to ppisati
[16:30] <ppisati> GrueMaster: yep
[16:30] <prpplague> GrueMaster:  this is the primary one of concern http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=commit;h=58b36b7ce571c5b5cd6b8bc6b29f45eccc7a5f34
[16:47] <GrueMaster> ppisati: On bug 855969, the audio part is because the alsa driver (kernel) renamed the analog hardware device from SDP4430 to Panda.  Do we want to change the kernel or the alsaucm files?  Kernel would (in my opinion) be easier.
[16:47] <ubot2> Launchpad bug 855969 in linux-ti-omap4 "excessive messaging in dmesg by kernel on omap4" [Undecided,Fix committed] https://launchpad.net/bugs/855969
[16:49] <rsalveti> GrueMaster: at the ubuntu-leb we changed the alsaucm files already, but at this point just not updating the kernel code is probably easier
[16:50] <GrueMaster> So, how come no one updated the bug with this info?
[16:51] <rsalveti> because this was done monday/yesterday
[16:51] <rsalveti> and we still didn't get everything working for the release
[16:51] <rsalveti> I added a comment at the no sound support for omap4 bug
[16:51] <rsalveti> saying that this changed
[16:54] <ndec> ppisati: ogra_: i think we have always said we would use the tilt kernel for ubuntu. what you are using right now is 3.0 + omap patches but it's missing the linaro-3.0 branch. that's what sebjan meant earlier.
[16:54] <ndec> linaro and us are using the tilt-linux-linaro-3.0 branch
[16:55] <rsalveti> that was what I thought too
[16:55] <ogra_> didnt paolo say we use tilt above ?
[16:55] <ndec> that's what we discussed many times in our weekly ;-)
[16:56] <ndec> ogra_: there are 2 main branches. titl and titl-linaro
[16:56] <ogra_> ah
[16:56] <ppisati> yep, we use tilt
[16:56] <ppisati> TI landing tree
[16:56] <ppisati> not the tilt + linaro kernel
[16:56] <ndec> it's probably too late now... but you should have used tilt-linaro...
[16:56] <ppisati> GrueMaster: is it something we can fix after the upload? i would like to pull req before end of day
[16:57] <GrueMaster> After the upload?  You mean after release?
[16:57] <ogra_> ndec, especially since tilt+linaro doesnt work atm
[16:57] <ndec> ppisati: you will need couple of patches from sebjan to revert the DRM driver name in the kernel. or the GFX packages won't work.
[16:57] <rsalveti> tilt+linaro does work
[16:57] <ppisati> ndec: since O/omap4 kernel hit our archive we always used vanilla + tilt + ubuntu sauce
[16:57] <ndec> what does not work?
[16:57] <rsalveti> is the one we use at the lebs
[16:57] <ogra_> rsalveti, you got the DVI issue fixed ?
[16:57] <ppisati> we had many discussions about it in the past
[16:58] <rsalveti> ogra_: which issue?
[16:58] <ogra_> rsalveti> we have a critical bug at the linaro side noew
[16:58] <ppisati> i even have an email i sent to agreen back in... june? july?
[16:58] <ppisati> where i told him we were using vanilla + tilt
[16:58] <ndec> ppisati: yes. it's just your definition of tilt that was not correct
[16:58] <rsalveti> ogra_: oh, that's the sound issue, not related with dvi
[16:58] <ppisati> ah ok then...
[16:58] <ogra_> ah, i only saw that displays dont work anymore
[16:58] <ndec> rsalveti: what issue with sound?
[16:58] <ogra_> during the day in #linaro
[16:59] <ogra_> ndec, device was renamed
[16:59] <rsalveti> ndec: packaging issue, we can't generate hwpacks anymore
[16:59] <rsalveti> but I'm fixing that
[16:59] <ogra_> oh, something totally different
[16:59] <rsalveti> yup
[16:59]  * ogra_ better shuts up
[16:59] <ndec> which device? where?
[16:59] <ogra_> ndec, the asla device
[16:59] <ndec> rsalveti: btw awesome work on cross building kernel + dkms ;-)
[17:00] <ndec> jcrigby: thanks for that ^^^
[17:00] <rsalveti> ndec: kuddos to jcrigby
[17:00] <ndec> ditto!
[17:00] <ndec> do you think it's upstreamable?
[17:00] <ogra_> "SDP4430" vs "Panda" for the alsa device
[17:00] <rsalveti> he even fixed another annoying issue for systemtap
[17:00] <ndec> even better...
[17:00] <rsalveti> now you just need to install the kernel debug package and it just works :-)
[17:01] <ndec> we tried dkms earlier, not systemtap yet
[17:01] <rsalveti> ndec: it should be, maybe we can put it at ppisati last respin
[17:02] <ppisati> actually the kernel freeze was some time ago, but it _seems_ we can still have an upload like this before tomorrow
[17:03] <ppisati> but fix can still go in before releae
[17:03] <ppisati> so if you can't make it today, we can do it later
[17:37] <GrueMaster> ogra_: bug 779410
[17:37] <ubot2> Launchpad bug 779410 in flash-kernel "package initramfs-tools 0.98.8ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Confirmed] https://launchpad.net/bugs/779410
[17:38] <ogra_> that really doesnt state it happens every time (and to be honest i have nevber seen it)
[17:39] <GrueMaster> It isn't an everytime occurance, but it is very high on some of my SD cards.  Higher on some than on others.
[17:40] <ogra_> well, if a sync fixes it we should have the in the pipe as a last resort fix, but should still investigate aa real fix
[17:40] <ogra_> i cant reproduce it here ... but would suggest an upload with an lsof in the code before the umount so we get logs about whats open
[17:41] <ogra_> and then find out why thats the cas
[17:41] <ogra_> e
[17:41] <infinity> I see no reason to upload for that.
[17:41] <ogra_> well, if its reliably reproducable there doesnt need to be an upload indeed
[17:41] <infinity> If Tobin has cards he can reliably reproduce this on, give him a hacked-up f-k to play with.
[17:41] <ogra_> right
[17:41] <GrueMaster> sigh.  3rd time through ubiquity on this particualr SD card.
[17:41] <GrueMaster> Checking logs now.
[17:41] <infinity> And if no one can reliably reproduce it, a debug upload 1 day before final freeze won't help anyone.
[17:42] <ogra_> well, if its serious enough we can have twn other uploads
[17:42] <ogra_> *ten
[17:42] <infinity> Yes, but not debug code.  Please.
[17:42] <GrueMaster> Sorry, I have been too busy this cycle to test daily desktop images.
[17:42] <infinity> The archive is not a test bed.
[17:42] <ogra_> yeah
[17:43] <ogra_> GrueMaster, nobody is blaming you for anything
[17:43] <ogra_> i know that bug since it exists, i even discussed it with skaet before
[17:43] <GrueMaster> Yea, but if I don't do it, it doesn't happen.
[17:44] <ogra_> and was under the impression its not reliably reproducable nor that it happens often actually
[17:44] <ogra_> reather blame me for not taking it serious enough before excusing missing tests
[17:45] <ogra_> *excusing for
[17:48] <GrueMaster> Yea for useless log output.  I see absolutely no usefull information from ubiquity as to why it keeps restarting.
[17:51] <GrueMaster> Like this from oem-config.log:  (oem-config:13199): Gdk-WARNING **: oem-config: Fatal IO error 0 (Success) on X server :0.
[17:51]  * GrueMaster never knew success was a fatal error.
[17:53] <ogra_> i think thats actually after X died
[17:53] <ogra_> the real error would be before somewhere
[17:54] <ogra_> if it would be in that log
[17:54] <GrueMaster> The rest of the log shows a ton of dbus errors.
[17:54] <GrueMaster> But that hasn't changed in a long time.
[17:55] <ogra_> yeah, its more likely you will find info in syslog i think
[17:56] <GrueMaster> I'm scrolling through it now.
[17:58] <GrueMaster> AHA!
[17:58]  * ogra_ is all ears
[17:58] <GrueMaster> http://paste.ubuntu.com/698627/
[18:01] <ogra_> GrueMaster, well, add an lsof to flash-kernel before the umount $TEMPFS
[18:01] <ogra_> err
[18:01] <ogra_> TMPMOUNT
[18:03] <ogra_> probably redirect to some file so it doesnt spill into syslog
[18:05] <infinity> lsof takes just long enough to start that it fixes the race. :P
[18:05] <infinity> Which is why I suspect sync appears to fix it too.
[18:06] <GrueMaster> That would be my guess.
[18:06] <infinity> (I can reproduce it in a loop here without lsof, but with it, no issues)
[18:07] <infinity> Whatever.  Path of least resistance for now is just to sync(1) before both umounts.  I'll try that in a loop of a few thousand and see if it helps.
[18:07] <ogra_> lets add a sleep 1
[18:07] <ogra_> :)
[18:07] <infinity> Time to kill an SD card.
[18:11] <infinity> set -e; for i in `seq 1 1000`; do flash-kernel; done
[18:11] <infinity> ^-- We'll call that good enough?
[18:11] <ogra_> argh
[18:11] <ogra_> thats evil
[18:11] <infinity> I weep for my poor SD card.
[18:11] <ogra_> yeah
[18:11] <ogra_> expense it
[18:12] <GrueMaster> Pfft.  They're cheap.
[18:12] <infinity> This one wasn't.    Boom.
[18:15] <ogra_> at that point the partition should already be labeled in a way it doesnt get mounted
[18:16] <ogra_> so it shouldnt automount on the installed system
[18:16] <infinity> Oh, this would be because we haven't fixed jasper to change the label yet. :P
[18:16] <infinity> Or hadn't on the system I'm testing on.
[18:16] <ogra_> yeah
[18:16] <ogra_> thats the main reason for the label :)
[18:17] <infinity> Is that fixed now?
[18:17]  * ogra_ checks
[18:17] <infinity> I'd say no.
[18:17] <infinity> Since the latest change in bzr is my GROWROOT fix.
[18:17] <infinity> Why that's in all-caps, I don't know.  I need coffee.
[18:18] <ogra_> heh
[18:18] <ogra_> infinity, janimo worked on that but mx5 got in the way i think
[18:21]  * ogra_ gets some icecream
[18:21] <infinity> I'll fix the label thing today, then.
[18:21] <ogra_> thx
[18:22] <ogra_> shouldnt be to hard, ask janimo thogh, he probably has some code already
[18:22] <infinity> I think he got sidetracked by shiny.
[18:22] <ogra_> i know he looked into mtools stuff for it
[18:22] <ogra_> yep
[18:22] <infinity> But it's easy to set a label.
[18:23] <ogra_> well, it needs hook additions for mtools etc
[18:23]  * GrueMaster tests that theory.
[18:23] <ogra_> and possibly an mtoolsrc
[18:23] <ogra_> in the initrd
[18:24] <GrueMaster> Any way the partition can be labeled at image creation time?
[18:24] <infinity> Yes, we did that, and Oliver told us we were bad people.   Right.  :(
[18:25] <GrueMaster> Forgot that whole arguement.
[18:25] <ogra_> i didnt say you were bad people !
[18:25] <ogra_> just mildly bad
[18:29] <infinity> -rwxr-xr-x 1 root root 51560 2011-08-20 14:36 /sbin/dosfslabel
[18:29] <infinity> -rwxr-xr-x 1 root root 27472 2011-08-20 14:36 /sbin/mkdosfs
[18:29] <infinity> Can someone explain to me why it takes more code to change a label than to create the filesystem? :P
[18:29] <ogra_> hahaha
[18:30] <GrueMaster> If the label is the cause, that would mean gvfs is running during oem-config.  Why would that need to be running?
[18:30] <infinity> I'm not sure the label is the cause during oem-config.  I'm just suspecting it could be causing a race here that allows me to see the bug.
[18:31] <infinity> Or, rather, to see the race and work around it. :P
[18:31] <infinity> I intend to make f-k happy on this system first, then fix the label, not the other way around.
[18:31] <ogra_> ++
[18:31] <GrueMaster> Well, I am currently testing that theory.  Will know in a few minutes.
[18:32] <ogra_> gvfs should definitely not run in ubiquity-dm
[18:32]  * infinity does a test loop with s/sync && umount/umount -l/
[18:32] <ogra_> might be though that it uses gnome-session for panel and the applets and it could be that gnome-session by default starts gvfs regardless
[18:33] <infinity> If lazy works consistently, it's probably the more elegant solution for whatever races might bite us here.
[18:33] <ogra_> yes
[18:34] <infinity> T/win 48
[18:34] <GrueMaster> sigh.  Label ENOFIX.
[18:35] <infinity> Yeah.  Didn't think it would.  But it needs fixing anyway. :P
[18:35] <ogra_> did you use the right label ?
[18:35] <ogra_> :)
[18:35] <ogra_> just to make sure
[18:35] <GrueMaster> SERVICEV001
[18:35] <ogra_> k
[18:35] <GrueMaster> It made it disappear on my desktop.
[18:35] <ogra_> yep
[18:36] <ogra_> udev has that name hardcoded
[18:36] <ogra_> err
[18:36] <ogra_> udisks but in a udev rule
[18:36] <infinity> Lazy seems to be doing the trick.
[18:36] <GrueMaster> And syslog shows the same tmpmount busy error.
[18:36] <ogra_> yeah
[18:37] <ogra_> i dont think gvfs is the issue here
[18:37] <ogra_> (and it seriously shouldnt run at all)
[18:37] <GrueMaster> Oddly enough, I can reliably reproduce this issue on the SD cards given to us at the Dallas rally.
[18:37] <ogra_> the cheapo but fast ones ?
[18:38] <GrueMaster> Yea.  The red 16G micro center ones.
[18:38]  * ogra_ needs to find his, i'll test with it tomorrow
[18:39] <infinity> lLazy was good for 20 tries in a row, going for the longer loop and a smoke.
[18:39] <ogra_> actually i need to call it a day to not be killed with a spoon by susie who waits with dinner ...
[18:39] <ogra_> i'll do the TI icon stuff tomorrow and should beyond that have spare cycles if there is anything pressing left
[18:39] <infinity> Indeed.  Go avoid spoon death.
[18:39] <ogra_> so if there is anything leave me a ping or mail
[18:40]  * ogra_ waves
[18:45] <GrueMaster> Looking at jasper, I notice all of the logging lines (...>>${LOG} ) begin with $MYECHO, which means they go through plymouth.  Shouldn't they just be "echo ...>>${LOG}"?
[18:46] <infinity> MYECHO isn't plymouth if we don't have it installed.
[18:46] <infinity> MYECHO="echo "
[18:46] <infinity> if [ -x /bin/plymouth ] && plymouth --ping; then MYECHO="plymouth message --text="
[18:46] <infinity> fi
[18:47] <infinity> Oh, wait.  Stuff for the log is in MYECHO?  Where?
[18:47] <GrueMaster> Look further down at lines 83,84.
[18:47] <infinity> Ahh, yes.
[18:48] <infinity> That probably wants a tee or something.
[18:48] <infinity> If busybox has tee.
[18:48] <infinity> But I'm not going to mangle any of that today.
[18:48] <infinity> This thing's fragile enough as it is. :P
[18:49] <GrueMaster> 83 should be a $MYECHO.  Any line that ends with >>${LOG} should be just an echo, otherwise they will not show up in the logfile.
[18:50] <GrueMaster> I think ogra_ did a s/echo/$MYECHO/g when he added plymouth support.
[18:50] <infinity> Probably.
[18:51] <infinity> Still, should replace it all with a tee function and just have the log reflect the console.
[18:52] <GrueMaster> Tee won't work if pushing out to plymouth.
[18:52] <infinity> I said a tee function, not tee itself.
[18:52] <infinity> Something to multiplex between log and console/plymouth.
[18:53] <infinity> Not terribly tough.
[18:53] <infinity> But for now, I'll just fix some oopses.
[18:54] <infinity> Only found two anyway.
[18:56] <GrueMaster> Ugh.  I keep taking a screenshot of this ugly oem-config screen, and keep blasting the SD before saving it off.  sigh.
[18:59] <GrueMaster> Testing to see if adding sync to flash-kernel fixes this issue.  I know it isn't a clean fix, but for now...
[19:00] <GrueMaster> And since I can reliably reproduce this (6 for 6 times so far) on this SD, I can always revert to test a better fix.
[19:03] <infinity> I've been testing lazy instead, if you'd like to test that.
[19:04] <infinity> s/umount/umount -l/ to both umounts in f-k.
[19:05] <infinity> A few hundred into my test, and I haven't been able to race it.
[19:06] <GrueMaster> My fix doesn't show the error in the syslog anymore, but oem-config still fails.  Not sure why.  Back to combing useless output.
[19:11] <janimo> infinity, ah dosfslabel. Seems much saner than using mtools
[19:11] <janimo> did not know about it
[19:12] <infinity> Yeah, already fixed.
[19:13] <infinity> Well, when I do a round of testing here and commit.
[19:15] <GrueMaster> infinity: Could this be it?  syslog: Sep 28 12:00:18 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
[19:15] <infinity> Depends on if it's retrying.  But also, WTF.
[19:15] <infinity> The only thing talking to and/or locking the debconf DB should be ubiquity itself.
[19:15] <GrueMaster> Repeated 5 times according to the next line.
[19:16] <infinity> Are these fresh installs, or are you restarting ubiquity after a failed attempt?
[19:16] <GrueMaster> Reflashing SD before trying something new.
[19:17] <GrueMaster> When oem-config reappears, I switch to alt-F1 and ctrl-alt-del.
[19:19] <GrueMaster> I wish ubiquity would just log to its own file.  having it output to syslog is very messy.
[19:25] <GrueMaster> sigh.  Guess I start yet again and enable oem-config debug.
[19:25] <GrueMaster> After lunch.
[19:26] <GrueMaster> Gaaah!  Forgot to save the screenshot off the SD before reflashing...again.  sigh.
[19:37] <infinity> Ugh.  One small bathroom break, and I've completely lost my train of thought.
[19:41] <GrueMaster> Kind of a pisser, isn't it?  :P
[19:41] <infinity> Yeah.  I need to stop this getting old business.
[19:42]  * infinity breaks from ARM stuff to do some release managling and clear his head.
[19:46]  * GrueMaster takes yet another screenshot.  sigh.
[19:53] <skaet> ogra_,  can you confirm,  ac100 and mx5 are both to be considered community projects, with no official support, and you'll be the signoff?
[19:53]  * skaet is doing some manifest scrubbing.
[19:53] <ppisati> rsalveti: did you test the kernel? if not, it's here: http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.11_armel.deb
[19:55] <infinity> skaet: That sounds right to me.
[19:56] <skaet> thanks infinity,  I'll go with that for now then.
[20:16] <rsalveti> ppisati: not yet, but will test now, we just fixed the issue we were having at linaro today
[20:17] <ppisati> rsalveti: ok, no prob
[20:17] <ppisati> rsalveti: i'm here
[20:46] <infinity> Sweet mother of creepy gah.  I haven't done a fresh install on a machine with a webcam since that ubiquity changes.  It turns it on and offers to take my picture during install?
[20:46] <infinity> That's just wrong.
[20:47] <infinity> (On the flipside, "hey, the ac100 webcam works")
[20:49] <GrueMaster> Heh.
[20:53] <davidm> skaet, you are correct on ac100 and imx5x no support, considered to be community
[20:54] <infinity> Oh, balls.  ac100 needs the same fix I gave omap and mx5 two days ago.
[20:54] <gildean> at least the ac100 community is quite active
[20:56] <skaet> davidm,  thanks.
[20:58] <davidm> skaet, trying to pay attention as I can today
[20:58] <GrueMaster> infinity: So, making oem-config start with --debug only succedes in generating 10x the logging of useless info.  As an added bonus, oem-config now crashes, butthat info must be confidential as there is no sign of it crashing in syslog, dmesg, oem-config.log, installer/dm or anywhere else I look.
[21:01]  * GrueMaster is tempted to just file a critical bug against ubiquity, attach all the logs, and let the installer dev's figure out the whole mess.
[21:01] <infinity> I wish I could reproduce it...
[21:01] <infinity> Though I haven
[21:01] <infinity> Err.
[21:01] <infinity> I haven't reinstalled my Panda today, so maybe a surprise is in store.
[21:02] <infinity> The ac100 went flawlessly though (except for my needing to give it oem-config-gtk)
[21:10] <ppisati> rsalveti: i
[21:10] <ppisati> 'm leaving
[21:10] <ppisati> can you give it a boot?
[21:10] <rsalveti> ppisati: slacker :P
[21:10] <rsalveti> ppisati: do you need to send the pull request today?
[21:11] <ppisati> yep
[21:11] <ppisati> tomorrow is final freeze
[21:11] <rsalveti> great, give me 30 min
[21:11] <ppisati> ok
[21:11] <rsalveti> ppisati: we'll also need a FFe for u-boot-linaro
[21:11] <rsalveti> ogra_: jcrigby: ^
[21:11] <rsalveti> for 4460 support, as I said before
[21:12] <GrueMaster> ppisati: If it helps, I had booted it on my system earlier today (before I got sucked into daily image hell).
[21:12] <ppisati> GrueMaster: panda Ax?
[21:12] <rsalveti> if it booted fine at 4430 is already a start
[21:12] <GrueMaster> A3
[21:12] <ppisati> yep, but we are pull requesting for 4460
[21:12] <ppisati> without it, i'm not sending the req
[21:13] <GrueMaster> Right.  I just wanted to make sure nothing got broken in between.  :P
[21:13] <ppisati> yep
[21:13] <ppisati> thanks for testing
[21:13] <GrueMaster> rsalveti: Will the next u-boot fix ES2.0 support?
[21:13] <rsalveti> GrueMaster: yes
[21:14] <GrueMaster> excellent.
[21:15] <ndec|home> ppisati: i think you need the pull request even without 4460. since we are fixing some graphics and MM stuff as well.
[21:15] <rsalveti> ppisati: can you point me the git tree for this deb?
[21:16] <ppisati> rsalveti: wait
[21:17] <ppisati> rsalveti: git://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git ti-omap4
[21:17] <rsalveti> ppisati: thanks
[21:17] <ppisati> and here is the deb
[21:17] <ppisati> http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.11_armel.deb
[21:19] <Gottox> hi there :)
[21:19] <jcrigby> rsalveti, so u-boot for this is 2011.09.2 which has been tested with Linaro for a few days
[21:19] <jcrigby> ?
[21:19] <rsalveti> jcrigby: yes, latest one we're also using
[21:20] <jcrigby> ok, do I wait for a confirmed status ffe?
[21:20] <rsalveti> guess we can use the other FFe bug we have around already
[21:20] <rsalveti> jcrigby: yes, I'll comment on that bug
[21:21] <jcrigby> ok, just going to say someone important needs to set status to confirmed:)
[21:21] <Gottox> I get an error when using rootstock: http://pastebin.com/cx03qteT
[21:21] <rsalveti> jcrigby: yes :-)
[21:22] <rsalveti> GrueMaster: can you help us testing pxe with this latest u-boot?
[21:22] <rsalveti> jcrigby tested already, but would be good to check with it first
[21:22] <GrueMaster> Sure, I guess.  What platforms?  Just panda?
[21:23] <rsalveti> GrueMaster: https://launchpad.net/~linaro-maintainers/+archive/overlay/+files/u-boot-linaro-omap4-panda_2011.09%2B5353%2B35%2B201109262044~natty1_armel.deb
[21:23] <rsalveti> in theory there's usb support at xM too, but we didn't test it yet
[21:23] <rsalveti> wget https://launchpad.net/~linaro-maintainers/+archive/overlay/+files/u-boot-linaro-omap3-beagle_2011.09%2B5353%2B35%2B201109262044~natty1_armel.deb
[21:28] <rsalveti> jcrigby: GrueMaster: ppisati: bug 851974
[21:28] <ubot2> Launchpad bug 851974 in u-boot-linaro "FFe: u-boot-linaro 11.09, misc fixes for new silicon and boards" [Undecided,New] https://launchpad.net/bugs/851974
[21:29] <rsalveti> GrueMaster: please let us know when you're able to test these packages, making sure PXE is still working is the most important thing
[21:29] <rsalveti> once the test is done I'll request the release team to review it
[21:29] <GrueMaster> On it now.
[21:29] <infinity> Well, 1000 passes of flash-kernel with lazy umounting, I'll call that good.
[21:30] <GrueMaster> infinity: Good.  Now see why oem-config is recycling on the daily omap4.
[21:31] <infinity> Booting that in a bit.
[21:31] <GrueMaster> rsalveti: jcrigby  What on pxe has changed in this u-boot?
[21:31] <infinity> Well, flashing it now.
[21:32] <jcrigby> GrueMaster, it should be identical
[21:32] <GrueMaster> Ok, so just a no-frills sanity check then.  Got it.
[21:33] <jcrigby> GrueMaster, make sure the naming of uuid/macaddr based downloads is not broken
[21:34] <rsalveti> GrueMaster: yeah, just to check if we didn't break anything
[21:34] <GrueMaster> ok.  I'll throw it into the pool.
[21:39] <GrueMaster> jcrigby: spl: error reading image u-boot.img, err - -1
[21:39] <GrueMaster> What happened to using u-boot.bin?
[21:41] <GrueMaster> This will break our images if it doesn't support u-boot.bin.
[21:41] <rsalveti> GrueMaster: in theory it should support it same way as before
[21:42] <rsalveti> let me wait jcrigby to answer that
[21:42] <rsalveti> GrueMaster: did you replace both MLO and u-boot.bin?
[21:43] <GrueMaster> My process is to reformat mmcblk0p1, copy MLO & u-boot.bin (in that order) and reboot.  Everything else it pulls from tftp.
[21:43] <rsalveti> GrueMaster: great
[21:45] <jcrigby> rsalveti, I knew something was wrong
[21:46] <GrueMaster> It's the day before final freeze.  What wouldn't be wrong?
[21:46] <GrueMaster> :P
[21:46] <jcrigby> I reverted the .bin support in 09 before I found that the real problem was the spl size issue
[21:46] <rsalveti> jcrigby: :-)
[21:47] <jcrigby> but now that the spl size issue is fixed the .bin support can be put back in
[21:47] <GrueMaster> Why the switch to img in the first place?
[21:47] <jcrigby> the new spl loads .img by default
[21:47] <jcrigby> it could load a uImage forexample
[21:48] <jcrigby> u-boot upstream sometimes forgets about backward compatibility
[21:48] <jcrigby> at least on arm platforms
[21:48] <GrueMaster> Well, at least it matches the hardware.  :P
[21:49] <jcrigby> ok, I'm needed at a school meeting with my kids right now
[21:49] <jcrigby> when I get back can I push a fix to ppa
[21:49] <jcrigby> then test
[21:49] <jcrigby> then push to archive if ppa test works out ok?
[21:51] <jcrigby> bbl
[21:52] <GrueMaster> Also, no tftp/pxe support on beagleXM.  usb start initiallizes the usb, but tftpboot reports no network devices.
[21:53]  * GrueMaster takes a break for a bit.
[21:53] <rsalveti> GrueMaster: ok, thanks
[21:53] <rsalveti> jcrigby: will provide a new u-boot for GrueMaster while you're away
[21:53] <rsalveti> with this fix
[21:58] <rsalveti> GrueMaster: http://people.linaro.org/~rsalveti/u-boot/
[21:58] <rsalveti> the same one from the package I sent + u-boot.bin compatibility
[22:03] <GrueMaster> Bah.  Broken.
[22:03] <GrueMaster> At least it loads uboot.bin now.
[22:04] <GrueMaster> Hmm.  Doesn't like my pxelinux.cfg
[22:05] <GrueMaster> Let me double check on another system.
[22:08] <GrueMaster> rsalveti: The old version on http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/omap4/netboot/ works fine with my pxelinux.cfg.  This one does not.
[22:09] <rsalveti> hm, then it could be a bug at the pxe implementation
[22:09] <rsalveti> GrueMaster: what error are you getting?
[22:10] <GrueMaster> One sec.
[22:12] <GrueMaster> I get "Ignoring malformed menu command:  label" then dumped to u-boot prompt.  The message is the same on the working version, but it goes forward ok.
[22:12] <GrueMaster> My pxelinux.cfg is http://paste.ubuntu.com/698765/
[22:22] <rsalveti> hm, ok, need to check the changes between both versions
[22:23] <rsalveti> and why this ignoring message
[22:24] <GrueMaster> The ignoring message could be my config.  It has been eons (2001) since I did pxelinux stuff.
[22:34] <GrueMaster> Well, I fixed the label error in my config, but it still fails to run.  I now get this:
[22:34] <GrueMaster> Bytes transferred = 740 (2e4 hex)
[22:34] <GrueMaster> Config file found
[22:34] <GrueMaster> And a prompt.
[22:36] <rsalveti> GrueMaster: and you paste your new config? going to give it a try here
[22:37] <rsalveti> GrueMaster: ppisati kernel worked fine here at my 4460 es1.1
[22:37] <GrueMaster> http://paste.ubuntu.com/698777/
[22:37] <rsalveti> but he's not on-line anymore, let me sms him
[22:39] <GrueMaster> It is 00:38 his time.
[22:39] <GrueMaster> You told him 30 minutes, 90 minutes ago.
[22:39] <GrueMaster> oops.
[22:46] <rsalveti> would help if he said he was going to leave :-)
[22:46] <GrueMaster> [14:10:20] <ppisati> rsalveti: i
[22:46] <GrueMaster> [14:10:32] <ppisati> 'm leaving
[22:46] <GrueMaster> like that?
[22:47] <rsalveti> hm, where, didn't see it
[22:47] <rsalveti> I think I just saw 'i' and that was it
[22:47] <rsalveti> :-)
[22:47] <GrueMaster> Just before you said:  [14:10:42] <rsalveti> ppisati: slacker :P
[22:48] <GrueMaster> That was just before we got into this u-boot testing.
[22:49] <GrueMaster> It's all in the scrollback.  :P
[22:49] <rsalveti> oh, but that was almost 2 hours ago
[22:49] <GrueMaster> At any rate, I need to break for a bit.  My eyes are gettng buggy.
[22:50] <rsalveti> yeah, release is still killing me
[22:50] <GrueMaster> Same here.  I am severely bogged down by issues in the desktop image that apparently didn't get looked at since I filed them...In Alpha.
[22:51] <rsalveti> heehe... fun
[22:59] <rsalveti> GrueMaster: yeah, pxe boot does nothing
[23:03] <rsalveti> hm, weird, it works fine with my pxe config
[23:06] <rsalveti> hm, but got: ERROR: Did not find a cmdline Flattened Device Tree
[23:10] <jhobbs> rsalveti: is fdt_addr set in your env?
[23:11] <rsalveti> jhobbs: yes
[23:12] <rsalveti> jhobbs: GrueMaster: without a default entry pxe boot does nothing
[23:12] <rsalveti> is it really required?
[23:13] <rsalveti> GrueMaster: http://paste.ubuntu.com/698795/
[23:13] <rsalveti> GrueMaster: works only when I set the default argument
[23:14] <rsalveti> let me compare u-boot-linaro 11.08 and 11.09, at least the pxe patches
[23:16] <rsalveti> hm, 11.09 is using a new patchset
[23:18] <rsalveti> jhobbs: when removing fdt_addr it worked fine
[23:19] <jhobbs> do you have a fdt blob at fdt_addr?
[23:19] <rsalveti> no, I'm not loading it
[23:19] <rsalveti> I was trying an menu option that didn't load the dt file
[23:20] <rsalveti> but as fdt_addr was set at my env, I could not boot it
[23:20] <jhobbs> i'm not sure what menu you're referring to there, the pxe code doesn't load fdt's itself
[23:20] <GrueMaster> rsalveti: It worked on the old release, and it matches https://help.ubuntu.com/community/PXEInstallServer fairly closely.
[23:21] <rsalveti> GrueMaster: yup, this is probably a bug
[23:21] <rsalveti> jhobbs: fdt_addr is always set at our u-boot
[23:22] <rsalveti> but we don't always need a blob
[23:22] <rsalveti> that's why at the cases we are not loading it, it fails
[23:23] <jhobbs> i see - the pxe code assumes that if fdt_addr is defined a fdt blob is being used and tells bootm that
[23:29] <jhobbs> it could be smarter and check that something is actually present there
[23:30] <rsalveti> yeah
[23:31] <rsalveti> jhobbs: any idea why without a 'default' entry pxe boot does nothing?
[23:31] <rsalveti> probably a bug at the parsing code
[23:31] <rsalveti> wasn't the case at the previous patch set
[23:34] <jhobbs> rsalveti, i'm not sure - i will check
[23:34] <jhobbs> what behavior were you seeing with the last patch set?
[23:35] <rsalveti> jhobbs: http://paste.ubuntu.com/698795/ example of a pxeconfig file
[23:35] <rsalveti> this works fine
[23:35] <rsalveti> if we remove the first line, the default entry, pxe boot gets me back to the prompt
[23:35] <rsalveti> without saying a word
[23:37] <rsalveti> jhobbs: http://paste.ubuntu.com/698802/
[23:40] <jhobbs> ok, i'm building to test right now
[23:52] <rsalveti> menu_create is returning NULL
[23:53] <jhobbs> hmm what i'm seeing is that it's trying to boot the default label but there is no default label specified
[23:54] <jhobbs> so menu_get_choice is returning -ENOENT
[23:56] <jhobbs> http://paste.ubuntu.com/698810/
[23:56] <jhobbs> whitespace will be messed up but that should get you that error message
[23:57] <rsalveti> jhobbs: menu_create gets called with cfg->title == NULL
[23:57] <rsalveti> then it returns NULL at menu_create
[23:57] <rsalveti> because it'll try to call malloc with sizeof null
[23:57] <rsalveti> let me check
[23:58] <rsalveti> >> menu_create:372
[23:58] <rsalveti> title: <NULL>, timeout: 0, prompt: 0
[23:58] <rsalveti> >> destroy_pxe_menu:1196
[23:59] <rsalveti> hm, doesn't seems to be the issue