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