[07:19] <DanaG> mountall: Plymouth command failed
[07:20] <DanaG> ... repeated about 1000 times.
[07:23] <amitk> DanaG: are you using LVM?
[07:23] <DanaG> Nope.
[07:23] <DanaG> And I do dislike how plymouth refuses to show splash if a serial console is present.
[07:23] <amitk> yeah, that is a known plymouth bug
[07:24] <amitk> I hate it too, first this I disable is plymouth
[07:24] <amitk> s/this/thing
[07:58] <hrw> morning
[08:01] <DanaG> Nice thing: watchdog.
[08:01] <DanaG> Makes it so that omapdss reboot crash makes it still reboot anyway, instead of just dying.
[08:13] <sveinse> I'm about to do some kernel debugging on ARM target. Do you know of an decent GUI for gdb (-arm) which can run on host?
[08:27] <saeed> ogra: ping
[08:27] <ogra> hey saeed
[08:28] <saeed> hey ogra
[08:28] <saeed> the uboot on dove takes too long time to read the kernel image and initrd
[08:29] <saeed> the uboot sata driver is optimized (using DMA, upt to 128 sectors requests)
[08:29] <ogra> hmm, sounds like a case for ericm and NCommander
[08:29] <saeed> it looks to me that for some reason those files are too mush scattered on the disk
[08:30] <ogra> which installer is that ? GUI or text mode ? (the files live in different subdirs in either one)
[08:30] <saeed> GUI
[08:30] <saeed> the files under /boot/ dir
[08:30] <ogra> so the live in /casper/uI*
[08:31] <ogra> no, the live installer holds uImage and uInitrd in the /casper dir
[08:31] <ogra> though i know NCommander worte a rather complex uboot script that scans all devices before loading, do you install from USB or SD card ?
[08:32] <ogra> i think USB is scanned first, so using that should speed up the probing
[08:32] <saeed> I installed from USB
[08:33] <ogra> hmm, then the probing shouldnt have any effect i think
[08:33]  * ogra looks at the script
[08:34] <saeed> ogra: I problem that I notice is that when the script reads the images from the hdd, the read process takes too much time, maybe 10 seconds just to read ~3MB image
[08:35] <ogra> http://paste.ubuntu.com/420270/
[08:35] <ogra> hmm, the script seems to scan all devices regardless
[08:36] <saeed> right know I don't have a problem with the scan process of the uboot
[08:37] <saeed> the thing is that it takes too much time to read from sata hdd
[08:37] <ericm> saeed, still I guess it's a sata drive issue, as usb loading is pretty fast
[08:37] <ericm> either booting from /casper/ or any other image I wrote later to the USB disk
[08:37]  * ogra wonders where ${fs} ${interface} and ${device} come from for the first if in that script
[08:38] <ericm> I believe scatter status is no better from usb disk perspective
[08:38] <saeed> ericm: yes
[08:38] <ericm> maybe other part of u-boot introduces some delays?
[08:38] <saeed> I think also with ssd that won't be an issue
[08:38] <ogra> saeed, oh, you were talking about post-install ?
[08:38] <ogra> sorry, i didnt get that
[08:38] <saeed> ogra: yes
[08:39] <saeed> do you know about a method for allocating the kenrel and initrd images so they can be contiguous on the hard drive
[08:40] <ogra> oh, wait, the same script is used in inistalled systems
[08:40] <saeed> yes
[08:40]  * ogra looks at the flash-kernel source
[08:42] <ogra> and it definately initializes USB and IDE first, probes USB fat, then USB ext2 and only *then* switches to probe IDE fat and *last* it probes IDE ext2
[08:43] <ogra> imho the order is totally wrong here if we always expect the install to live on IDE ext2 it should be the other way round
[08:43] <ogra> so that gets probed first
[08:43] <ogra> have you monitored a boot in serial console to see what uboot actually does ?
[08:44] <ericm> ogra, saeed is seeking a way to contiguously write uImage and uInitrdto the hard drive
[08:44] <ogra> ericm, right, but still we use several seconds before the loading even starts
[08:44] <ericm> saeed, I guess the kernel strategy to write out a file (if not interrupted) is to write it as contiguously as possible
[08:45] <ericm> ogra, yeah - but that's something we can fix maybe, the loading speed of uImage/uInitrd binary - only Marvell can fix that :-)
[08:45] <ogra> its likely an additional issue i see here but it might cost valuable extra time in the boot
[08:45] <saeed> orga: yes ,I think the first "if" will be taken here
[08:46]  * ogra has no dove hardware to actually test or confirm anything sadly
[08:46] <saeed> ogra: see http://paste.ubuntu.com/420275/
[08:47] <ogra> yeah, line 1-41 are pointless on an installed system
[08:47] <ogra> (apart from initializing IDE actually)
[08:47] <ericm> saeed, the first part of the script is actually within u-boot
[08:47] <ericm> to look for a boot.scr
[08:48] <ogra> ericm, look at the paste
[08:48] <ogra> it scans everything before doing any load
[08:48] <ericm> ogra, yeah I'm looking
[08:48] <ericm> ogra, I guess we could move ide to first place as that's mostly used
[08:48] <saeed> ogra: why do you think the IDE is re-initialized?
[08:48] <ericm> installation is less frequently happening
[08:49] <saeed> ogra: are you talking about installation process?
[08:50] <ogra> saeed, no, about your serial capture
[08:51] <ogra> saeed, line 18-41 in your paste clearly show that the full script is executed before anything gets loaded at all
[08:51] <ogra> ericm, there is no difference between the installation boot.scr and the boot.scr after installation, they are identical
[08:52] <saeed> ogra: this the uboot default boot command
[08:52] <ogra> which costs a lot of extra scan time for nonexisting USB
[08:52] <ericm> ogra, I'm not talking about the installation boot.scr, I mean the u-boot builtin boot.scr
[08:52] <ogra> ericm, they appear to be identical
[08:53] <ericm> ogra, right so the improvement can be done to both version
[08:53] <ogra> the builtin boot.scr should bail out the moment it doesnt find USB
[08:53] <ogra> (as the installation one should)
[08:53] <ericm> ogra, right - and the builtin boot.scr should scan ide first as that's more commonly used
[08:53] <ogra> instead of trying to probe vfat and then ext2 additionally
[08:54] <ogra> ericm, no, then you cant install
[08:54] <ericm> ogra, ah well - that's the problem
[08:54] <ogra> it *should* check for USB ... but if it doesnt find a device it shouldnt try to fatload/ext2load
[08:54]  * ericm feels stumped
[08:54] <ericm> ogra, that's correct
[08:54] <ogra> currently it goes on trying to load stuff from a nonexisting device
[08:55] <ogra> which is nonsense and wastes a lot of time
[08:56] <saeed> ogra: if you need the uboot from usb disk if connected, then the flow is ok
[08:56] <ogra> saeed, it shouldnt try to load if there is no device
[08:57] <saeed> ogra: but maybe the sata disk connected, and it have proken kernel
[08:57] <saeed> broken
[08:57] <ericm> saeed, which means if "usb reset" returns failure, "fatload/ext2load" can be skipped
[08:58] <saeed> ericm: does usb reset fails if no usb device is connected?
[08:58] <ericm> ogra, ah - it seems fatload/ext2load combines the probing and reading all together unless you have a way to separate them into two commands
[08:58] <ogra> yes
[08:58] <ericm> saeed, nope
[08:58] <ogra> (though its "usb start"
[08:58] <ericm> saeed, sorry I over looked
[08:59] <ericm> ogra, yeah it is usb start and it takes a lot time for unknown reason, ide reset is fast enough
[08:59] <ogra> you could have something like  "if usb start; fatload/ext2load .... fi"
[09:00] <ogra> so it will not try to load if there is no usb device
[09:00] <ericm> ogra, but we are not sure if the current implementation of "usb start" returns what
[09:00] <ogra> test it :)
[09:00] <ogra> (i dont have the HW )
[09:00] <ericm> ogra, hope it's returning the number of usb storage devices found
[09:01] <ogra> well, the hush shell "if" will look if it exits 0 or nonzero
[09:01] <ogra> no matter what it returns
[09:01] <ogra> if usb start; .... fi should work fine as a wrapper for the load commands here
[09:02] <ogra> the prob with the existing script is that it is one big loop
[09:02] <ogra> it should be split into multiple conditional loops instead
[09:02] <ericm> ogra, it doesn't work with a quick test, we may need to modify "usb start" to return 0 if there are any storage devices, otherwise non-zero
[09:03] <ogra> if test -n usb start; then ... fi
[09:03] <ogra> try that
[09:03] <ericm> usb reset seems to return a true condition here whether a usb disk is plugged or not
[09:03] <ogra> err, hmm
[09:03] <ogra> -n wont help
[09:03] <ogra> but you should be able to use test properly here
[09:04] <ericm> ogra, only if it returns different value depending on how many storage devices are attached
[09:05] <saeed> ogra: usb start taked 5 seconds, and accessing usb does't take noticable time if no device found
[09:05] <ericm> ogra, and the "usb start" is really slow, which should be avoided during normal running (but then we need a way to tell uboot it's in installation mode and run 'usb start')
[09:06] <ericm> saeed, right - the most time consuming thing is "usb start"
[09:07] <ericm> but the problem is we don't do this automatically and everytime, installation isn't possible unless we tell u-boot explicitly
[09:07] <saeed> guys, I think that should be handled in productions systems, for example, the user shoud press on some button so the uboot will try boot from usb
[09:07] <ericm> like F12 in IBM thinkpad to tell BIOS to boot from CDROM
[09:07] <ericm> saeed, exactly what I'm thinking
[09:07] <ogra> saeed, ++
[09:07] <ericm> the problem is that: there is only the power button :-)
[09:07] <ericm> or the reset button ??
[09:08] <ericm> or introducing the keyboard (USB/HID) support in u-boot, which is super fantastic :-)
[09:09] <saeed> ericm: thats is not straightforward
[09:09] <ericm> saeed, I'm joking :-)
[09:09] <saeed> :)
[09:10] <ericm> saeed, a kexec -based soft loader, though, may really be helpful to solve this issue
[09:10] <ericm> esp. kexec seems rather stable on dove
[09:10] <saeed> yes
[09:10] <ericm> and it's loading uImage/uInitrd quick enough
[09:11] <saeed> ericm: yesterday I tried to use it, but it didn't work
[09:11] <saeed> the next boot the system complains that it can't find the initrd on address 0
[09:11] <saeed> where does the kexec allocate the initrd?
[09:12] <ericm> saeed, ah well - that's because you are still using the old kexec binary
[09:12] <ericm> which needs to be patched (a single line though)
[09:12] <saeed> mmm
[09:12] <ogra> ericm, if we have kbd support we only need to add framebuffer !
[09:12] <ericm> the uImage will decompress itself into some place in initrd, by placing initrd far away behind, it can be solved
[09:12] <ericm> ogra, that's right
[09:13] <saeed> can I just update it ?
[09:13] <ericm> saeed, it's not in repo yet, wait
[09:13] <ericm> saeed, check http://people.canonical.com/~ycmiao/kexec/, copy kexec and kdump to overwirte the original copioes
[09:18] <saeed> ericm: it didn't work!
[09:18] <ericm> saeed, .....
[09:18] <saeed> # kexec  --version kexec-tools: 2.0.1-git released 13th August 2009
[09:19] <ericm> saeed, let me re-upload my local version
[09:19] <saeed> ok
[09:20] <ericm> saeed, try again
[09:21] <ericm> saeed, btw bug 509006 - hibernation resuming failure, I was able to track that to swsusp_arch_resume() where when restoring pages on "restore_pblist", it caused data abort
[09:21] <ubot4> Launchpad bug 509006 in linux-mvl-dove (Ubuntu Lucid) (and 1 other project) "[dove] hibernation failed to resume (affects: 4) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/509006
[09:22] <saeed> ericm: kexec works, thanks alot
[09:22] <ericm> saeed, no problem
[09:22] <ogra> ericm, now get it working on omap and imx51 and we can actually make use of it :)
[09:23] <ericm> ogra, it should be working - but you remind me to put the patch to lp, which I should have done long time ago
[09:23]  * ericm is a slack
[09:23] <ogra> afaik kexec on imx51 breaks a bunch of currently working stuff
[09:24] <cooloney> ogra: really?
[09:24] <ogra> i cant remember what exactly but i think cooloney said suspend/resume
[09:24] <cooloney> kexec breaks many things?
[09:24] <ogra> oh, cooloney there are you :)
[09:24] <ogra> didnt you say it broke suspend ?
[09:25] <cooloney> ogra: hehe, actually, i did not found the root cause of the suspend/resume regression
[09:25] <ogra> iirc that was before you fiddled with fec
[09:25] <cooloney> ogra: it should be ok after the kexec patches
[09:25] <ogra> and suspend worked before you added the kexec patch
[09:25] <saeed> ericm: the fact that the system hangs at swsusp_arch_resume() doens't necessarly mean that the it's a kernel bug
[09:25] <ogra> ok, then i misunderstood
[09:26] <cooloney> ogra: and one patch fixed the suspend/resume issue from jk, who introduce that regression in the leds bug fixing
[09:26] <ogra> yeah
[09:26] <ogra> i remember that one
[09:26] <cooloney> then after that, the candidate should be me my fec driver
[09:26] <ogra> yup
[09:26] <cooloney> now i fixed that, it can suspend,
[09:26] <cooloney> but cannot resuem
[09:27] <cooloney> currently, my babbage board was dead totally,
[09:27] <cooloney> it cannot power on now
[09:27] <ogra> cooloney, btw, what became of the regulator disaster with your board ?
[09:27] <ogra> ah
[09:27] <ogra> snap
[09:27] <cooloney> ogra: i think i will fix them soon
[09:28] <ericm> saeed, yeah - but it's really weird that if hibernation resume is done earlier then it works all right
[09:28] <cooloney> ogra: the report from plars about the regulator testing kernel is reasonable
[09:28] <ericm> saeed, basically the initramfs does the resume by writing to /sys/power/resume and trigger the hibernation resume explicitly
[09:31] <saeed> ericm: if your swap on usb, then the resume will not be done earlier, and it should work
[09:33] <ericm> saeed, why is that - resume will not be done earlier?
[09:35] <saeed> ericm: because usb disk get discovered only at later point
[09:36] <ericm> saeed, the difference is that - one is done in rootfs_initcall() , the other is done in early user space
[09:41] <DanaG> how are you even supposed to wake an omap (beagle)?
[09:41] <saeed> ericm: sotware_resume is done from late_initcall
[09:42] <saeed> ericm: both methods should work
[09:42] <ericm> saeed, I expect so ... but the initramfs version just doesn't work :-(
[09:49] <saeed> ericm: iirc, beta2 succeeded to resume from initramfs, when resume= added to command line. can you please try that version?
[09:49] <saeed> you don't need to install it, you can try the usb live
[09:50] <ericm> saeed, I was able to resume with "resume=" I can confirm that
[09:51] <saeed> you meam the early resume, no the initramfs resume, right?
[09:51]  * saeed brb
[09:59] <ogra> ndec, im blazed ! (just had fedex here) :)
[09:59] <ndec> ogra: congrats!!!
[10:00] <ogra> its sooo sexy !
[10:00] <ndec> ogra: later today, I need to give you instructions to get the right kernel...
[10:00]  * ogra will put it under his pillow at night :)
[10:00] <ndec> ogra: but I am a little busy for now
[10:00] <ogra> yeah, no urgence before lucid anyway
[10:00] <amitk> ogra: just don't slobber all over it :)
[10:00] <ogra> i need to concentrate on the beagle image
[10:00] <ogra> amitk, hard to do :)
[10:02] <ndec> ogra: i am sure you will want to see it running, even before lucid ;-)
[10:02] <ogra> heh, indeed
[10:03] <ogra> ndec, what i love most is that it has the same color as one of my porsches ... how did you guys know that ? :)
[10:03] <amitk> show off!
[10:03] <ogra> nice bordeaux red :)
[10:07] <ogra> amitk, you know my porsche, dont you ? http://people.canonical.com/~ogra/2CAF65BCd01.jpg
[10:07] <amitk> i do, seen it in barcelona i think
[10:08] <ogra> (though thats the one sitting in the garage, i drive another one atm)
[10:08]  * amitk is so confused about UDS'
[10:08] <ogra> no, the one ion barcelona was the more powerful one :)
[10:08] <ogra> it'll take me to brussels too this time ... and its more loke firengine red
[10:08]  * ericm wonders how many porsche ogra has
[10:08] <ogra> ericm, two
[10:09] <ogra> which gets me regular stress with my GF :)
[10:09] <amitk> ericm: as I said - show-off :)
[10:09] <ericm> amitk, yeah indeed
[10:12] <ogra> amitk, hmm, so it seems we have issues with compcache on omap
[10:13] <ogra> if i swapoff and remove the two compcache modules my install finishes properly
[10:13] <ogra> if i dont, i end up with stuff like http://paste.ubuntu.com/419902/ in dmesg
[10:17] <ericm> ogra, amitk, possible to get a beagle and get it reimbursed? I'm thinking about getting another arm-v7 SoC for testing purpose
[10:17] <lool> ogra: Hey
[10:17] <lool> ogra: Did you reproduce the qemu-maemo beagleboard issue yesterday?
[10:17] <ogra> lool, what issue ?
[10:17] <lool> ogra: The kernel hang after uncompressing linux
[10:18] <ogra> no, i dont have qemu-maemo here, still fighting with the compcache issue on the netbook image
[10:18] <amitk> lool: the link you sent was regarding fw_setenv
[10:18] <lool> amitk: was not?
[10:19] <lool> ogra: Ok, nm, just confusion
[10:20] <ericm> ogra, amitk, or you guys have spare one that I borrow at UDS?
[10:24] <lool> ericm: Did the kexec issue affect dove?
[10:26] <ericm> lool, not dove specific
[10:27] <ericm> saeed, weird - JTAG stops at data abort when restoring page at 0x81044000 (with a copy at 0x98f00000), I'm seeing no speciality of this specific page
[10:27] <ericm> the weirdest thing is data abort happens in the middle of page restoring, which is unusual
[10:28]  * ericm be right back
[10:35] <lool> ericm, cooloney: Is one of you sending this bug upstream in kexec-tools?
[10:37] <cooloney> lool: oh, i think ericm is working on this
[10:38] <DanaG> oh yeah, random thing: I get spew of "Mountall: Plymouth Command Failed" at boot.
[10:38] <DanaG> It uses 100% of one cpu core on the HOST system when watching the serial console.
[10:38] <lool> Gah dpatch
[10:39] <lool> DanaG: strace it
[10:39] <lool> DanaG: might be https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/567964 ?
[10:39] <ubot4> Launchpad bug 567964 in mountall (Ubuntu) "mountall keeps on running (affects: 2) (heat: 12)" [Medium,Confirmed]
[10:39] <lool> just hit this this morning on my laptop myself
[10:39] <DanaG> How do I strace it during boot?
[10:39] <lool> DanaG: It's only during boot?
[10:39] <DanaG> Yeah.
[10:39] <DanaG> And it stops spewing after a while.
[10:39] <lool> DanaG: Ok; what's your image?
[10:40] <DanaG> Or perhaps it's spewing just after boot.
[10:40] <DanaG> Image as in file system, or as in picture?  Since I'm using serial console, it gives me no splash screen.
[10:40] <DanaG> Same thing happens on my host system (AMT serial console).
[10:41] <DanaG> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/557161
[10:41] <ubot4> Launchpad bug 557161 in mountall (Ubuntu) "mountall: Plymouth command failed (dup-of: 559761)" [Undecided,Confirmed]
[10:41] <ubot4> Launchpad bug 559761 in mountall (Ubuntu Lucid) (and 1 other project) "mountall needs to flush plymouth message queue before emitting upstart events (affects: 26) (dups: 2) (heat: 152)" [High,Fix committed]
[10:41] <DanaG> anyway, bedtime now.
[10:42] <DanaG> I commented on a bug about "no splash as soon as console= is present", as well.
[10:42] <DanaG> Thu Apr 22 02:42:15 PDT 2010
[10:44] <ogra> it could also be bug 563618
[10:44] <ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[10:45] <ogra> in combination with bug 516825
[10:45] <ubot4> Launchpad bug 516825 in plymouth (Ubuntu) "plymouth doesnt show any splash as soon as a console= commandline option is used on boot (affects: 2)" [Medium,Fix released] https://launchpad.net/bugs/516825
[10:46] <ogra> i think the latter one breaks in worse ways than at the time it was reported
[11:02] <NCommander> ~~~~A;2~
[11:04] <NCommander> sorry, cat
[11:04] <NCommander> saeed: ogra_cmpc: uboots abaility to be scripted is incredibly poor
[11:06] <saeed> NCommander: hey
[11:06] <NCommander> saeed: hola
[11:07] <saeed> are you talking about adding the if "usb start"
[11:08] <NCommander> saeed: theres no way to check if usb sstart ran successfully or not; it returns no error code nor is there a way to see how many devices were found
[11:08] <NCommander> saeed: I'd like to add such functionality as part of an optimization if I ever got the time, but the biggest holdup is just raw read speed
[11:09] <saeed> NCommander: anyway, I don't think that it will save a noticable time
[11:09] <saeed> NCommander: what do you mean by the raw read speed?
[11:11] <ericm> NCommander, since kexec is now available - we might want to speed up the softloader project
[11:11] <NCommander> saeed: if you look at the boot time, 10-20 seconds are just spent at ext2load ide
[11:12] <saeed> NCommander: yes, I agree
[11:12] <NCommander> ericm: maybe for 10.10, but dove ends with 10.04 :-/
[11:14] <saeed> NCommander: mayeb defrag of the boot partition could help
[11:14] <NCommander> saeed: hasn't beofre. the issue seems to be a lack of DMA on reading from SATA
[11:14] <NCommander> saeed: but I haven't looked at the code extensively to confirm
[11:14] <saeed> NCommander: the uboot ide driver is ok
[11:15] <NCommander> saeed: then I have no explination on the speed
[11:15] <saeed> just try "ide read 0x2000000 0 0x10000" and you will see that it completes very fast
[11:15] <saeed> the ide driver support DMA and requests up to 128 sectors (64K)
[11:16] <saeed> it could be unoptimized ext2 implementation
[11:16] <NCommander> saeed: that could be it
[11:17] <NCommander> saeed: the question is what can be done about it?
[11:17] <saeed> NCommander: I've had ssd disk, and the uboot read of images was fast
[11:18] <NCommander> saeed: not so much here, when I used a sata ssd, it wasn't much of a speed improvement
[11:18] <saeed> mabye writing the images are row date on known partition :)
[11:19] <NCommander> saeed: huh?
[11:20] <saeed> I mean to write the kernel image on /dev/sda1, then uboot will load the image from sector 63
[11:21] <saeed> without fs
[11:21] <lool> ericm, cooloney: Sorry, kept crashing hard a couple of times; will look into kexec-tools
[11:22] <ogra> stop crashing !Q
[11:22] <NCommander> saeed: we do tha tfor imx51, but its too late/difficult to change the behavior now for 10.04
[11:22] <NCommander> saeed: with a little luck, softbootloader will materialized for 10.10 and we'll have a GRUB like booting experience
[11:23] <ogra> well, there is also change that we actually get grub proted to ARM
[11:23] <ogra> *chance
[11:23]  * ogra still has that on this plate to make sure the grub guys get the HW they need
[11:24] <ericm> lool, no problem
[11:59]  * cwillu_at_work grumbles about usplash not building from source
[12:00] <lool> cwillu_at_work: Seriously?
[12:00] <lool> cwillu_at_work: What's the error?
[12:00] <cwillu_at_work> sec
[12:00] <cwillu_at_work> it's an asm constraint thingie
[12:01] <lool> cwillu_at_work: I dont see it on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi at least
[12:01] <cwillu_at_work> in the svgalib included
[12:01] <lool> ah on arm
[12:01] <lool> indeed we dont test rebuild armel ATM
[12:01] <dmart> lool, asac, ogra: can anyone with a dove do a quick test for me?
[12:01] <lool> dmart: I dont have one
[12:01] <dmart> Relates to bug 567956
[12:01] <ubot4> Launchpad bug 567956 in linux-fsl-imx51 (Ubuntu) "ARM: Incorrect prefetch abort handling can cause a spin instead of SIGSEGV (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/567956
[12:01] <hrw> saeed: what is 'softloader project'?
[12:02] <lool> saeed ^ dmart is looking for testers with dove hardware
[12:02] <lool> hrw: mukluk
[12:02] <cwillu_at_work> lool, did you still want the error message?
[12:02] <lool> hrw: https://launchpad.net/mukluk
[12:02] <lool> cwillu_at_work: Yes, file a bug actually
[12:03] <lool> cwillu_at_work: we have some binaries available for it https://launchpad.net/ubuntu/+source/usplash/0.5.51 but it's not rebuilt with latest toolchain
[12:03] <cwillu_at_work> lool, .../usplash-0.5.49/src/libvga.h:275(and294): error: impossible constraint in 'asm'
[12:03] <dmart> saeed: would you be able to do a qkick test for me?
[12:03] <lool> cwillu_at_work: Probably a thumb2 porting issue
[12:03] <lool> cwillu_at_work: Please do file a bug with the log
[12:03] <cwillu_at_work> lool, ya, I can't use the binaries;  I'm trying to hack out the /dev/.initramfs
[12:03] <lool> cwillu_at_work: thing is, we moved to plymouth and usplash is now in universe, so wasn't on our radar
[12:03] <saeed> dmart: hey
[12:03] <lool> it's pretty much being phased out I'm afraid
[12:04] <cwillu_at_work> lool, this is in karmic still, but ya
[12:04] <dmart> saeed: Hi there
[12:04] <lool> cwillu_at_work: Quick fix: try building with -marm in CFLAGS
[12:04] <saeed> dmard: sure which test
[12:04] <hrw> lool: like kexecboot from OE guys
[12:04] <cwillu_at_work> if lucid would install in qemu, I'd be on it already :)
[12:04] <lool> hrw: eh
[12:04] <cwillu_at_work> k, I'll give that a shot
[12:04] <dmart> saeed: I added the test case in bug 567956
[12:04] <ubot4> Launchpad bug 567956 in linux-fsl-imx51 (Ubuntu) "ARM: Incorrect prefetch abort handling can cause a spin instead of SIGSEGV (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/567956
[12:04] <lool> hrw: like other existing bootloaders, yes
[12:04] <dmart> saeed: you're running 2.6.32, yes?
[12:04] <lool> hrw: google for it and you should find a spec for it where this was discussed
[12:04] <saeed> yes
[12:04] <cwillu_at_work> ugh; how do I file a bug without using ubuntu-bug again?
[12:05] <amitk> cwillu_at_work: ubuntu-bug <package-name>
[12:05] <dmart> If you can try the test case, you should get a segfault, indicating that the bug isn't present in the dove kernel
[12:05] <cwillu_at_work> amitk, your reading comprehension leaves something to be desired :p
[12:05] <hrw> ok
[12:07] <amitk> cwillu_at_work: indeed :)
[12:08] <saeed> dmart: I just got Segmentation fault
[12:08] <dmart> saeed: cool, that's what I wanted to hear :)  Thanks for testing
[12:09] <cwillu_at_work> https://bugs.launchpad.net/ubuntu/+source/<packagename>/+filebug?no-redirect
[12:09] <saeed> dmart: the "ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7" is applied into my kernel
[12:09] <dmart> saeed: I think it was merged into mailline 2.6.32
[12:10] <dmart> ...so that's what I expected
[12:10] <saeed> I see
[12:10] <dmart> Just wanted to make sure
[12:10] <dmart> thanks
[12:14] <cwillu_at_work> lool, adding -marm to CFLAGS in debian/rules didn't affect it
[12:17] <cwillu_at_work> lool, https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/568337
[12:17] <ubot4> Launchpad bug 568337 in usplash (Ubuntu) "usplash fails to build from source (armel, karmic) (affects: 1)" [Undecided,New]
[12:20] <dmart> cwillu_at_work: can you add gcc version details to your bug report?  A source snippet of the relevant lines might be handy, but I expect the source won't change that rapidly...
[12:21] <cwillu_at_work> done
[12:21] <dmart> Thanks
[12:21] <dmart> Out of curiosity, are vga.c, libvga.h applicable to arm at all?
[12:22] <dmart> aH
[12:22] <dmart> We seem to be trying to build x86 inline asm here...
[12:23] <dmart> http://pastebin.ubuntu.com/420366/
[12:23] <NCommander> dmart: what do you need tested on dove?
[12:23] <dmart> NCommander: it's OK, saeed did it already
[12:23] <NCommander> dmart: oh good
[12:24] <dmart> cwillu_at_work: Maybe there's some wrong config or #ifdefs somewhere, or perhaps we shouldn't build those files on ARM--- normally graphics means X or framebuffer or nothing
[12:25] <cwillu_at_work> so, wrong backend?
[12:26]  * ogra_cmpc finds all that a bit weird, we definately shipped usplash on arm in karmic 
[12:26] <ogra_cmpc> in both platforms
[12:26] <cwillu_at_work> yep, I'm using it right now
[12:27] <ogra_cmpc> i dont get why you cant recompile it then
[12:27] <ogra_cmpc> since it definatly built successfully in the archive back then
[12:29] <ogra_cmpc> i think it also should default to use bogl on arm, weird that it chooses vgalib
[12:29] <cwillu_at_work> debian/rules doesn't make any reference to bogl
[12:29] <cwillu_at_work> what is bogl?
[12:29] <ogra_cmpc> the other backend
[12:30] <cwillu_at_work> ...work via? :p
[12:30] <ogra_cmpc> no idea, i would have to dig in the code, i think plain framebuffer
[12:30] <cwillu_at_work> okay; trying to rebuild against that
[12:31] <ogra_cmpc> https://edge.launchpad.net/ubuntu/karmic/armel/usplash all karmic versions built
[12:31] <lool> dmart: You could check the build log for the version in lucid
[12:31] <lool> dmart: (of usplash)
[12:32] <lool> dmart: ISTR we're using the fb backend of usplash to draw; there's an embedded svgalib IIRC
[12:32] <ogra_cmpc> the last lucid build was before we changed the toolchain defaults though https://edge.launchpad.net/ubuntu/+source/usplash/0.5.51/+build/1373831
[12:33] <ogra_cmpc> but if you use a karmic toolchain that shouldnt matter
[12:33] <lool> ogra_cmpc: Yes, but it shows which files were built
[12:33]  * cwillu_at_work points out that the error is in the embedded svgalib
[12:35] <ogra_cmpc> in the buildlog it seems to ignore svgalib and only build bogl
[12:37] <cwillu_at_work> build completed with BACKEND="bogl"
[12:37] <ogra_cmpc> right
[12:37] <ogra_cmpc> but the package should select that automatically based on the arch
[12:38] <lool> cwillu_at_work: You build the package with dpkg-buildpackage, right?
[12:38] <lool> Not ./configure + make etc.
[12:38] <cwillu_at_work> lool, debian/rules binary
[12:38] <ogra_cmpc> hmm
[12:38] <lool> cwillu_at_work: That changes CFLAGS/LDFLAGS, but I wouldn't expect a big difference
[12:39] <cwillu_at_work> debian/rules has a check for i386 amd64 lpia, which sets BACKEND = "BACKEND=svga"
[12:39] <cwillu_at_work> the other branch sets it to BACKEND =
[12:39] <lool> ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),i386 amd64 lpia)) BACKEND = "BACKEND=svga"
[12:39] <lool> else BACKEND =
[12:39] <lool> cwillu_at_work: ack
[12:39] <lool> endif
[12:40] <cwillu_at_work> lool, and for the crowning touch:  when I set backend to bogl, I did it in the i386/amd64/lpia branch, _not_ the else
[12:40] <cwillu_at_work> and that built successfully
[12:40] <lool> cwillu_at_work: So it should just build the bogl code on armel, not svga
[12:40] <cwillu_at_work> ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),i386 amd64 lpia)) BACKEND = "BACKEND=bogl"
[12:40] <cwillu_at_work> is what I changed it to
[12:41] <lool> GAH
[12:41] <lool> nothing sets DEB_HOST_ARCH
[12:41] <ogra_cmpc> heh
[12:41] <lool> cwillu_at_work: You should REALLY use dpkg-buildpackage!
[12:41] <lool> cwillu_at_work: The bug is that the rules don't set DEB_HOST_ARCH properly, but dpkg-buildpackage always sets them
[12:42] <cwillu_at_work> so it's a lintian'ish thing
[12:42] <lool> It's a packaging bug, but one which will only affect people running debian/rules binary  :-)
[12:42] <cwillu_at_work> well, now you know :p
[12:43] <ogra_cmpc> and which it unlikely to be fixed at all ... since usplash will vanish
[12:43] <cwillu_at_work> it's disappearing from debian too?
[12:43]  * ogra_cmpc doubts anyone will put any time in that package
[12:43] <ogra_cmpc> debian uses it ?
[12:44] <ogra_cmpc> i thought they preferred splashy anyway
[12:44] <cwillu_at_work> well it's in universe
[12:45] <cwillu_at_work> it's not native to ubuntu is it
[12:45] <lool> cwillu_at_work: Pushed to bzr
[12:45] <ogra_cmpc> it was
[12:45] <lool> cwillu_at_work: Ubuntu is the upstream
[12:45] <ogra_cmpc> not sure if they pulled it into debian or not
[12:45] <lool> hence the abuse of native packaging
[12:45] <lool> It's definitely pulled in Debian
[12:45] <cwillu_at_work> ah, k
[12:45] <ogra_cmpc> ah
[12:45] <lool> for the same reason, it wont affect Debian too hard
[12:45] <lool> anyway, fixed
[12:47] <cwillu_at_work> <3
[13:16] <lool> ericm: I pushed a test package; would love if you could answer to the questions I asked on the bug
[13:16] <lool> as to have a test case documented by someone else than me
[13:21] <ericm> lool, ok - you updated on LP?
[13:22] <lool> ericm: Yes
[13:22] <ericm> lool, I'll take a look
[13:23] <lool> ericm: https://launchpad.net/~canonical-arm-dev/+archive/marvell-dove-public/+build/1702324
[13:24] <ericm> lool, ok - guess I could download the deb directly instead of adding the ppa to my dove
[13:24] <lool> ericm: Yes
[13:24] <lool> that's why I pointed you at this URL, and also because the PPA publishing might take up to 20 minutes
[13:25] <ericm> lool, no problem, I'll give it a run and update the LP
[13:25] <ericm> versatile & beagleboard, I'm afraid there are several kernel patches needed
[13:27] <ericm> https://bugs.launchpad.net/adana/+bug/517841
[13:27] <ubot4> ericm: Error: Bug #517841 is private.
[13:27] <lool> ericm: These didn't make it to the kernel?
[13:28] <lool> These are from March
[13:28] <ericm> lool, not in .32 I guess
[13:28] <ericm> lool, but should be sitting there if versatile&beagle kernel are built from latest
[13:28] <lool> What prevented them from being merged into our various ARM trees!?
[13:29] <lool> I dont see these commits in our master tree at least (from which versatile is built)
[13:30] <lool> nor in ti-omap, which is -33 based
[13:30] <ericm> lool, that's the problem, we are currently maintaining different branches for different ARM SoC so these patches do just get into each other branch
[13:30] <ericm> s/do/don't
[13:30] <lool> ericm: I've seen patches from master propagate into the other trees though
[13:31] <ericm> lool, but yeah - this is common and should go into master instead
[13:33] <lool> ericm: Do you mind if I make the bug public and affecting Ubuntu arm kernel branches?
[13:33] <lool> except fsl-imx51 which has the fixes of course
[13:33] <lool> in fact mvl-dove has them as well
[13:33] <lool> so linux-ti-omap and linux
[13:33] <ericm> lool, no problem, it should have been made public
[13:35] <NCommander> saeed: eggonlea you around?
[13:35] <saeed> NCommander: yep
[13:35] <asac> saeed: see msg
[13:35] <asac> or talk to NCommander ;)
[13:36] <lool> ericm: Could you help track / test it in other kernels?
[13:37] <ericm> lool, no problem
[13:37] <lool> asac: Would you put that on your SRU radar as well?
[13:37] <lool> will flag as stable updates candiates
[13:37] <lool> ericm: it's confirmed as needed for versatile and omap, right?
[13:37] <ericm> lool, btw - current kexec-tools has support for uImage right?
[13:37] <asac> lool: which?
[13:37] <lool> ericm: Dunno
[13:37] <lool> ericm: never tried uimage
[13:37] <asac> (sorry on call ... didnt read backlog)
[13:37] <lool> ericm: let me know :)
[13:37] <lool> asac: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/517841
[13:37] <ubot4> Launchpad bug 517841 in linux-ti-omap (Ubuntu) (and 2 other projects) "KEXEC support broken (affects: 2) (dups: 1)" [Undecided,New]
[13:37] <ericm> lool, we do need that for versatile and omap
[13:37] <lool> ericm: Ok thanks
[13:38] <ericm> lool, guess I need a beagleboard somewhere
[13:39] <lool> ericm: You should get one
[13:39] <lool> ericm: There are plenty of people here to test in the mean time
[13:43] <asac> lool: so assign to amitk? or ericm?
[13:43] <asac> and yes, its on SRU radar as its now targetted ;)
[13:44] <asac> feel a bit reluctant about fixing this in linux in SRU ... is that a safe patch`across the board?
[13:45] <ericm> asac, I think we should make the kexec work back into master - so every ARM branch will have it once rebased
[13:45] <ericm> including OMAP
[13:45] <asac> ericm: can you change your patch attachments to text/plain? my browser doesnt like text/x-diff ;)
[13:45] <asac> (not importnat)
[13:45] <asac> ericm: yes, but will this patch be good enough for lucid SRU? i see this for maverick for sure
[13:46] <ericm> asac, I was originally sending attachments in text/plain, but later found the checkbox that "The Attachment is a patch", I cannot resist to leave it unchecked :-)
[13:46] <ericm> asac, I don't think so, we don't have any existing user land stuffs, -M is a go as we move to soft bootloader
[13:47] <asac> ericm: heh. the patch i edited didnt hav that checkbox checked ;)
[13:47] <ericm> that really depends how quick NCommander is able to come up with it, NCommander ?! :-)
[13:47] <asac> still it was text/x-diff ... but i will survive
[13:48]  * NCommander reads backscroll
[13:48] <ericm> asac, .... yeah I know, with pain
[13:48] <ericm> NCommander, are we bringing forward the soft bootloader to -M?
[13:48] <asac> ericm: TBD
[13:48] <NCommander> ericm: softbootloader has working prototype. It might actually land for 10.10 at this point as kernel support landed for imx51 and dove
[13:48] <NCommander> ericm: we'll have yet another UDS session on it
[13:49] <ericm> NCommander, cool
[13:49] <NCommander> I mean, it won't be UDS without an ARM softbootloader session
[13:49] <asac> NCommander: we will have? i dont think one is scheduled and given that we had a bunch already, do you really think we need a session?
[13:49] <ericm> NCommander, hehe :-)
[13:49] <NCommander> asac: its traditional!
[13:49]  * ericm lol
[13:49] <asac> right. lets break traditions this cycle and get it actually done instead ;)
[13:49] <asac> rather than the tradition to just talk ;)
[13:49] <NCommander> asac: ouch.
[13:50] <ericm> NCommander, no worry - I'll see if I can help on that if I have time
[13:50] <ericm> :-)
[13:50] <NCommander> ericm: time is something that is always in short supply I find.
[13:50] <asac> ericm: so you cannot test kexec without a softbooloader? is that what you meant by being blocked on NCommander ?
[13:51] <ericm> asac, no I can test kexec with kexec-tools, that's fine
[13:51] <ericm> asac, I'm not blocked
[13:51] <ericm> NCommander, indeed
[13:52] <asac> ericm: great ;)
[13:52] <asac> ericm: so can we aim for an sru for linux-omap for lucid, but keep the "linux" fix for m?
[13:53] <ericm> asac, sure - just assign amitk then, I'll let him know this
[14:03] <ericm> lool, it's weird - I'm seeing no uImage support in kexec-tools source but the binary in the package does support uImage loading
[14:03] <ericm> lool, can you point me a URL for the source or bzr branch name?
[14:04] <ericm> for the exact package you built
[14:04] <lool> ericm: apt-get source kexec-tools will always give it to you; it might be in a patch in debian/patches/
[14:04] <lool> ericm: bzr branch lp:ubuntu/kexec-tools will give you the history of package uploads
[14:04] <amitk> lool: fsl and mvl are or different kernel version in lucid (re: propagating from master)
[14:05] <amitk> *on
[14:05] <lool> amitk: But you dont review the linux patches for the other trees?
[14:06] <amitk> lool: we try, but given the number of patches it is very hard to keep up.
[14:06] <lool> amitk: Ah I thought there was some kind of process to ensure no patch is lost
[14:06] <amitk> lool: you live in a perfect world :)
[14:07] <lool> amitk: Eh, I'm assuming you folks are reaching for the sky!!  ;-)
[14:07] <amitk> different people working on each of the branches, different deadlines, etc.
[14:08] <lool> amitk: I wish there would be some process to ensure we do fix issues in all trees   :-/
[14:10] <amitk> lool: if you come up with something, that will scale across different kernel versions, release deadlines, kernel configs, debian packaging, different people, different time for branching, I am sure we're all interested in following it.
[14:10] <amitk> :)
[14:12] <ogra> amitk, you forgot "different flavours of beer/wine"
[14:13] <amitk> :)
[14:14] <hrw> btw - is there a list of ubuntu/arm sessions for uds-m?
[14:14] <ogra> hrw, not yet, lool is a slacker !
[14:15]  * ogra hides
[14:15] <lool> hrw: an out of date one is public
[14:15] <lool> but we kind of suck on this front ATM
[14:17] <ogra> NCommander, how is gphoto doing ? already uploaded to the queue ?
[14:19] <dmart> asac: I see there's a fix committed for the firefox scrollbar bug now.  Did you get anywhere working out which object is getting miscompiled?
[14:24] <asac> dmart: far away from finding the module. i wanted to first see which optimization causes this
[14:24] <asac> dmart: but that dropped off the radar a bit because building everything -Os didnt evn build and then i got dragged into other stuff.
[14:25] <dmart> OK.  Well, let me know if you get any ideas ;)  if there is a miscompile somewhere it'd be good to track it down
[14:25] <asac> dmart: my opinion is that its probably not good to test non default optimizations in firefox
[14:25] <asac> dmart: its kinda understandable that none -O2 has issues
[14:25] <dmart> Do you think it may be a firefox issue instead?
[14:25] <asac> if we want to get toolchain stabilized for other optimizations we should think about starting with base packages and then work up
[14:26] <dmart> Yeah, I guess
[14:26] <asac> dmart: hard to say. given that we dont see it anywhere else, i doubt it
[14:26] <asac> also it goes away with -O2 and goes away when doiung a debug build
[14:26] <asac> so far only the mozila mix of different optimizations for different subtrees triggers it
[14:26] <asac> they use -O3, -Os and -O2 mix
[14:27] <dmart> interesting... there shouldn't be any ABI issues
[14:27] <asac> its not ABI i would think. it doesnt crash and is stable
[14:27] <dmart> well, don't worry about it right now, I guess
[14:27] <asac> just something with math is broken ;) ... my guess
[14:27] <NCommander> ogra: it should be in the queue, I haven't seen a reject or accept email
[14:28] <dmart> NCommander: I retried the OOo build on babbage3+lucid and got the same failure as before:
[14:28] <dmart> ../unxlngr.pro/bin/makedepend: symbol lookup error: ../unxlngr.pro/bin/makedepend: undefined symbol: cppsetup
[14:28] <dmart> any thoughts?
[14:28] <NCommander> dmart: er, that looks like a new one
[14:28] <NCommander> dmart: but my gut reaction is: OOo sucks?
[14:28] <dmart> The build always falls over this way, I haven't been able to get it any further for at least the last week or so...
[14:29] <NCommander> dmart: how are you building?
[14:29] <dmart> debian/rules build
[14:29] <dmart> But dpkg-buildpackage -B produced the same result previously
[14:29] <NCommander> dmart: odd ... that should work. It works on Dove I think
[14:29] <NCommander> dmart: i thought OOO was fully built though
[14:30] <dmart> Yes, that's why I'm confused.
[14:30] <NCommander> dmart: does it do it in a pbuilder instance?
[14:30] <dmart> This build was with the -marm workaround turned off, but I get the same failure either way.
[14:30] <dmart> This is not using pbuilder, just a manual build
[14:30] <lool> ericm: Please let me know when you test the kexec package and update the bug with a test case!  :-)
[14:31] <NCommander> dmart: it possible something in the build environment is breaking OOo. a clean chroot may be the way to go
[14:31] <ogra> NCommander, great !
[14:31] <lool> ericm: I see the test case actually now
[14:32] <ogra> asac, do you still plan to work on xserver-video-omapfb ? else i'll just upload the quick fix
[14:32] <dmart> NCommander: guess so.  I have the build-deps up to date, but it's a huge fs--- something else might be causing problems
[14:32] <ericm> lool, it doesn't actually have a test case indeed as you now see :)
[14:32] <asac> ogra: is archive open again?
[14:32] <ogra> asac, will open soon
[14:32] <ericm> lool, the binary from the package actually works
[14:32] <ogra> i think steve is in last stages for RC
[14:32] <NCommander> dmart: I can kick a build, or give you a shell on a Dove board
[14:33] <ericm> weird thing is it looks to me no uImage is supported yet it does work with uImage
[14:33] <NCommander> ogra: its there: https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
[14:33] <asac> ogra: your patch is probably ready and tested?
[14:33] <dmart> NCommander: it's not urgent.  Basically I wanted a build tree demonstrating the build-time segfault so I can poke at it.  Probably best if I try and reproduce it myself
[14:33] <asac> ogra: give me 3 hours ... if i dont give anything by then to test etc. go ahead
[14:34] <NCommander> dmart: well, if you want to rule out hardware, my shell on BBG 2.5 or Dove stands
[14:35] <dmart> Do we know whether it builds on dove?  It could be worth firing off a build there if not
[14:35] <NCommander> dmart: it should with -marm, thats where I did all my test builds.
[14:35] <lool> ericm: Which binary?
[14:35] <dmart> I mean with -mthumb
[14:36] <lool> ericm: the kexec one?  Cool
[14:36] <NCommander> dmart: no, it segfaults
[14:36] <dmart> Ah right, so it's not buildd-specific...
[14:36] <ericm> lool, wait - let me make sure I'm using the correct binary first, will get back to you later
[14:36] <dmart> A shell could be useful, though I won't be working on it right now.  I'll ping you later if I need access to something.
[14:37] <ogra> asac, my patch adds a 0 to /dev/fb (or XorA's patch now, since he committed it to the bug)
[14:39] <ericm> lool, it doesn't work - we may need to add uImage into kexec-tools
[14:39] <ericm> lool, or we may generate a kernel package with zImage or even vmlinux
[14:39] <ericm> NCommander, why don't we preserve zImage after flash-kernel?
[14:40] <NCommander> ericm: we do /boot/vmlinuz-*
[14:40] <ericm> /boot/vmlinuz-* == zImage?
[14:40] <NCommander> ericm: yeah
[14:40] <ericm> NCommander, got you
[14:40] <NCommander> that's why its vmlinuz
[14:40] <NCommander> decompressed images are traditional vmlinux
[14:42] <lool> ericm: Can you test with zImage?
[14:42] <ericm> lool, ok
[14:43] <lool> ericm: I think I saw the same as you did: vmlinuz doesn't work but vmlinux does
[14:43] <lool> ericm: I converted the file with a helper I wrote here
[14:43] <lool> http://people.canonical.com/~lool/vmlinuz-to-vmlinux
[14:44] <asac> ogra: well. go ahead ... i turned out to be busy most of the rest of the day ;)
[14:44] <NCommander> dmart: do you have IPv6 by any chance? :-)
[14:45]  * ericm is seeing mountall: Plymouth command failed printed out like crazy
[14:45] <dmart> NCommander: probably not...
[14:45] <NCommander> dmart: sudo apt-get install miredo will setup IPv6 over UDP. Then you can SSH into my boards if you need them
[14:45] <ogra> asac, ok, will do
[14:45]  * dmart makes a note
[14:45] <ericm> lool, vmlinuz seems all right
[14:53] <ericm> lool, both vmlinuz and converted vmlinux worked
[14:54] <ericm> the converted vmlinux has no decompressing, which should be slightly faster
[14:57]  * ericm needs some sleep
[15:21] <lool> ericm: Cool
[15:22] <lool> ericm: So we can push these kexec patches it seems
[15:59] <mopdenacker> Hi, I'm booting my Beagle with the LL image on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ . However, because of the "only-ubiquity" boot option, it doesn't start the live CD but directly the Ubiquity installer. Bug or feature?
[16:01] <lool> ericm: Pushed the pacakge to lucid; pending approval
[16:02] <lool> mopdenacker: that's intended
[16:02] <lool> ogra: ^
[16:02] <mopdenacker> It could be a bug because the Beagle has enough RAM to run the live CD (at least my rev C2). Could it be made for Rev A and B boards? Did they have 128 MB?
[16:03] <lool> mopdenacker: In theory they do, but apparently compcache support breaks this; ogra has the details
[16:07] <ogra> right
[16:08] <mopdenacker> lool: thanks! I don't see compcache in the kernel messages though...
[16:08] <ogra> compcache has issues on the beagle we couldnt solve anymore so it still causes OOM
[16:08] <mopdenacker> Ah, right.
[16:09] <ogra> you should see compcache with swapon -s
[16:09] <ogra> well, ramzswap
[16:11] <ogra> though we still saw malloc errors with that setup
[16:11] <ogra> the next image will not use compcache at all anymore
[16:12] <ogra> i just committed a fix and a new image build should happen as soon as initramfs-tools is in the archive
[16:12] <ogra> mopdenacker, i would suggest to use the netinst image though thats the text installer indeed
[16:13] <mopdenacker> ogra: thanks! Hope we will manage to make ramzswap work in the next release. That sounds attractive.
[16:13] <ogra> we will
[16:14] <ogra> the prob is (i suspect) that we use an old compcache implementation that was originally written for 2.6.28 ...
[16:14] <mopdenacker> Cool!
[16:14] <ogra> with 2.6.33 a rewrite entered staging but that requires a changed userspce handling
[16:15] <ogra> the omap image came in very very late in the cycle, so we couldnt rewrite the userspce bits in time and just took the old implementation
[16:15] <ogra> which is likely causing the different issues we see
[16:15] <ogra> for 10.10 we'll have a lot more time to make everything smooth and sort out all bugs
[16:16] <mopdenacker> Great, that's good to know that everything should be all right with mainline.
[16:16] <plars> mopdenacker: I've had some success installing from the netbook image by removing the swap on ramzswap0 and unloading ramzswap and xvmalloc, but certainly the d-i based image is going to be a more memory friendly install
[16:16] <cwillu_at_work> but what will I run on my arm-based server then?
[16:17]  * cwillu_at_work demands perfection from his lts
[16:17] <ogra> cwillu_at_work, the ubuntu-server image
[16:17] <ogra> cwillu_at_work, http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/
[16:18] <cwillu_at_work> "<ogra> for 10.10 we'll have a lot more time to make everything smooth and sort out all bugs"
[16:18] <ogra> oh
[16:18] <ogra> heh
[16:18] <cwillu_at_work> and then I was kinda making fun of the concept of using an arm board as a server
[16:18] <cwillu_at_work> despite the fact that I'm actually in that business :p
[16:19] <mopdenacker> Is there documentation for installing 10.04 on the Beagle besides the http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ page? I'd like to help writing doc about this.
[16:20] <ogra> cwillu_at_work, yeah, i guess smoothstone would disagree about the joke part :)
[16:22] <mopdenacker> ogra, thanks for the tip for ubuntu-server! I plan to use it on my IGEPv2 board, with a home made kernel. That's a perfect board for a home server.
[16:22] <ogra> indeed
[16:25] <mopdenacker> Back to the Beagle install, my board doesn't automatically load the boot.scr file, while it did with someone else's board. Probably because I have my own U-boot in NAND flash.
[16:25] <mopdenacker> The documentation should tell which U-boot image to download and how to install it in NAND.
[16:26] <mopdenacker> That's why I propose to write this doc if it doesn't exist yet (I already have all the instructions).
[16:26] <cwillu_at_work> mopdenacker, the documentation should tell you which distribution to use, and how to install it
[16:27] <ogra> https://wiki.ubuntu.com/ARM/BeagleNetInstall
[16:27] <ogra> mopdenacker, ^^^
[16:27] <mopdenacker> cwillu_at_work: right! Do you know if such documentation exists somewhere, or should I create it?
[16:27] <mopdenacker> ogra: great, many thanks!
[16:27] <ogra> beyond that i'll create a page on the ubuntu wiki explaining how to get the ubuntu uboot-omap package, extract it and flash it to NAND
[16:28] <ogra> but if you already have *something* in NAND the above should get you going
[16:28] <ogra> (will work with all ubuntu images, they all use the same boot.scr (just different cmdlines))
[16:42] <saeed> NCommander, ogra
[16:42] <ogra> here
[16:42] <saeed> the slow read from sata seems to happen only on dove
[16:43] <saeed> I tried to read the same file on another arm board and it was fast
[16:43] <ogra> hmm, uboot issue ?
[16:43] <saeed> I'll check the boot
[16:43] <saeed> yes
[16:43] <ogra> seems a lot boards have issues with ext2 support in uboot
[16:44] <NCommander> hey saeed
[16:44] <saeed> which boards?
[16:44] <NCommander> saeed: if thats the case, we can look at using vfat over ext2 for the next release cycle of Dove, but when I tried fat, it wasn't much better
[16:44] <NCommander> saeed: vfat is also vey fragile :-/
[16:47] <ogra> saeed, omap beagle definately ...
[16:47] <ogra> saeed, and i had probs on imx51 too but we dont use uboot there
[16:47] <ogra> just when testing it
[16:47] <saeed> which uboot version?
[16:50] <ogra> relatively new ones
[16:50] <ogra> i need to look up the versions
[16:50] <ogra> 2009.01 for imx51
[16:53] <ogra> omap is 2010.3 (plus some omap specific git checkout)
[16:57] <NCommander> saeed: I know filesystem support in u-boot has been vastly expanded since 1.3.4
[16:58] <saeed> mm
[16:58] <saeed> I don't recall that this issue occured in early uboot versions of dove, do you?
[16:59] <NCommander> saeed: although it would be a downright pain to port a newer u-boot to Dove, won't it :-/
[17:00] <NCommander> saeed: I remember the speed sucking from day 1 unfortunately. Its possibly gotten worse just because our initramfs grew
[17:03] <Martyn> Oh boy
[17:03] <Martyn> Today is ARM rumor central ...
[17:03] <Martyn> Apple aquiring ARM?  Pffft .. neer
[17:03] <Martyn> never
[17:03] <ogra> Martyn, sure, you ddidnt hear that ?
[17:03] <Martyn> The industry wouldn't -let- that happen ...
[17:03] <ogra> will happen right after smoothstone aquired apple
[17:03] <Martyn> Freescale, Marvell, and others have direct stake in ARM .. and they would lose out if Apple locked out the industry
[17:04] <Martyn> So, I think it's just that .. speculation, rumor, driven by Apple's purchase of intrinsity .. no way would they spend >20% of their cash reserves
[17:04] <Martyn> ogra : Yep.
[17:06] <ogra> my suspicion is that they wanted to have something up against google buying Agnilux so they spread that roumor
[17:06] <NCommander> saeed: BTW, it seems the newest gstreamer-plugins-marvell we got FTBFS :-/
[17:06] <Martyn> maybe
[17:07] <saeed> NCommander: please make sure Li know about it
[17:08] <NCommander> saeed: will do, just happens our timezone skew really really sucks
[17:34] <GrueMaster> lrg: Ping.  I was told you are working on alsa bits for freescale and marvell.
[17:39] <NCommander> argh
[17:40]  * Martyn is twiddling with the tegra2
[17:43] <hrw> which image gives x11 on beagleboard?
[17:55] <persia> hrw: have you tried either of the omap netbook variants?
[17:58] <hrw> only when it did not support usb
[17:59] <persia> Well, either try again, or use an image you know works, and install some desktop environment (e.g. apt-get install ^ubuntu-netbook)
[18:03] <hrw> desktop rebooot time
[18:03] <hrw> /nick/
[18:13] <lrg> GrueMaster: yes
[18:13] <GrueMaster> If you get a chance, do you think you could enable jack detection?
[18:14] <GrueMaster> Not critical for Lucid, but would be nice to have,
[18:14] <lrg> GrueMaster: on which platform ?
[18:14] <GrueMaster> babbage 3 and dove.
[18:15] <lrg> I have niether
[18:15] <lrg> it's simple to add
[18:15] <lrg> grep for jack in sound/soc
[18:15] <lrg> there are quite a few examples
[18:16] <GrueMaster> Ok, that's what I thought.
[18:16] <GrueMaster> Thanks.
[18:16] <lrg> and there is still time before the next merge window :)
[18:16] <GrueMaster> It would have to go into an sru release.
[18:17] <GrueMaster> But if I get time, I'll look into it.  Thanks.
[18:21] <persia> GrueMaster: lrg: If it's only nice-to-have for lucid, it's still best to get it done, and pushed in this merge window, so that when the kernel team pulls for maverick, it's already there.
[18:22] <lrg> persia: I agree, although I have not free time for implementation, but I will review and upstream if GrueMaster can provide a patch.
[18:22] <GrueMaster> What is the time window?  I have a convention I am leaving for tomorrow, and won't be back until Monday.
[18:23] <lrg> GrueMaster: well we are at 2.6.34-rc5 atm, so I'd say another few weeks
[18:24] <GrueMaster> Ok.  I can probably work on it late next week.
[18:28] <GrueMaster> This could be interesting.  I've worked on HD Audio side of alsa before, but not the SOC or AC'97 stuff.
[18:30] <Martyn> plus one of the whole points of the new LTS system, is that it allows for real kernel updates
[18:30] <Martyn> which is a nice changed policy
[18:31] <persia> Well, kinda.
[18:32] <persia> There's issues with that, and how far it can go,etc.
[18:32] <persia> We'll see how it works, but *don't* expect that new upstream kernel releases will all magically drop into 10.04.x
[19:00] <Martyn> persia : That it was accepted at /all/ is a good thing
[19:00] <Martyn> because LTS releases are few and far between, they must be able to update and roll with the times
[19:24]  * GrueMaster stopped using Redhat after 7.2
[19:24] <GrueMaster> (before they said there was no future in Desktop Linux).
[20:19] <hrw|gone> I use Debian since 1999
[22:09] <jc_> hi
[22:09] <persia> Hey.
[22:10] <jc_> so is apple going to buy arm or not?
[22:11] <jc_> i hope it doesn't stiffle any dev on ubuntu and arm....
[22:12] <DanaG> Frankly, I don't trust Apple.
[22:12] <DanaG> \][p
[22:12] <DanaG> [iuaA-]
[22:12] <DanaG> P-P
[22:12] <DanaG> er
[22:12] <DanaG> sorry, wiping keyboard.\
[22:13]  * persia suspects there are better forums for speculation
[22:13] <DanaG> though P-P looks like a funky smiley.
[22:13]  * persia also suspects that it's unlikely that corporate ownership will significantly affect the ISA in the short term.
[22:54] <videorechner> Mhm I like the idea, mac minis with arm cortex a9 MP, low power consumption and ubuntu can still be installed
[22:59] <persia> Maybe.  There's issues related to that specific implementation of GPT in lucid, although they may be fixed in the future.
[23:13] <asac> bug 561874
[23:13] <ubot4> Launchpad bug 561874 in f-spot (Ubuntu) "NULL Reference exception in F-Spot (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/561874
[23:19] <sveinse> Is there any here now who happens to have worked with JTAG against TI OMAP?
[23:22] <persia> Anyone know if there is an existing bug number for both desktop-webmail and evolution being on ubuntu-netbook/armel ?