DanaG | mountall: Plymouth command failed | 07:19 |
---|---|---|
DanaG | ... repeated about 1000 times. | 07:20 |
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:23 |
amitk | I hate it too, first this I disable is plymouth | 07:24 |
amitk | s/this/thing | 07:24 |
=== hrw|gone is now known as hrw | ||
hrw | morning | 07:58 |
DanaG | Nice thing: watchdog. | 08:01 |
DanaG | Makes it so that omapdss reboot crash makes it still reboot anyway, instead of just dying. | 08:01 |
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:13 |
saeed | ogra: ping | 08:27 |
ogra | hey saeed | 08:27 |
saeed | hey ogra | 08:28 |
saeed | the uboot on dove takes too long time to read the kernel image and initrd | 08:28 |
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:29 |
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:30 |
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:31 |
ogra | i think USB is scanned first, so using that should speed up the probing | 08:32 |
saeed | I installed from USB | 08:32 |
ogra | hmm, then the probing shouldnt have any effect i think | 08:33 |
* ogra looks at the script | 08:33 | |
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:34 |
ogra | http://paste.ubuntu.com/420270/ | 08:35 |
ogra | hmm, the script seems to scan all devices regardless | 08:35 |
saeed | right know I don't have a problem with the scan process of the uboot | 08:36 |
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:37 | |
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:38 |
saeed | do you know about a method for allocating the kenrel and initrd images so they can be contiguous on the hard drive | 08:39 |
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:40 | |
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:42 |
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:43 |
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:44 |
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:45 |
* ogra has no dove hardware to actually test or confirm anything sadly | 08:46 | |
saeed | ogra: see http://paste.ubuntu.com/420275/ | 08:46 |
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:47 |
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:48 |
saeed | ogra: are you talking about installation process? | 08:49 |
ogra | saeed, no, about your serial capture | 08:50 |
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:51 |
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:52 |
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:53 |
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:54 |
ogra | which is nonsense and wastes a lot of time | 08:55 |
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:56 |
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:57 |
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:58 |
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" | 08:59 |
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:00 |
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:01 |
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:02 |
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:03 |
ericm | ogra, only if it returns different value depending on how many storage devices are attached | 09:04 |
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:05 |
ericm | saeed, right - the most time consuming thing is "usb start" | 09:06 |
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:07 |
ericm | or introducing the keyboard (USB/HID) support in u-boot, which is super fantastic :-) | 09:08 |
saeed | ericm: thats is not straightforward | 09:09 |
ericm | saeed, I'm joking :-) | 09:09 |
saeed | :) | 09:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:18 |
ericm | saeed, let me re-upload my local version | 09:19 |
saeed | ok | 09:19 |
ericm | saeed, try again | 09:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
saeed | ericm: if your swap on usb, then the resume will not be done earlier, and it should work | 09:31 |
ericm | saeed, why is that - resume will not be done earlier? | 09:33 |
saeed | ericm: because usb disk get discovered only at later point | 09:35 |
ericm | saeed, the difference is that - one is done in rootfs_initcall() , the other is done in early user space | 09:36 |
DanaG | how are you even supposed to wake an omap (beagle)? | 09:41 |
saeed | ericm: sotware_resume is done from late_initcall | 09:41 |
saeed | ericm: both methods should work | 09:42 |
ericm | saeed, I expect so ... but the initramfs version just doesn't work :-( | 09:42 |
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:49 |
ericm | saeed, I was able to resume with "resume=" I can confirm that | 09:50 |
saeed | you meam the early resume, no the initramfs resume, right? | 09:51 |
* saeed brb | 09:51 | |
ogra | ndec, im blazed ! (just had fedex here) :) | 09:59 |
ndec | ogra: congrats!!! | 09:59 |
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:00 |
ndec | ogra: i am sure you will want to see it running, even before lucid ;-) | 10:02 |
ogra | heh, indeed | 10:02 |
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:03 |
ogra | amitk, you know my porsche, dont you ? http://people.canonical.com/~ogra/2CAF65BCd01.jpg | 10:07 |
=== james_w`` is now known as james_w | ||
amitk | i do, seen it in barcelona i think | 10:07 |
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:08 |
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:09 |
ogra | amitk, hmm, so it seems we have issues with compcache on omap | 10:12 |
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:13 |
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:17 |
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:18 |
lool | ogra: Ok, nm, just confusion | 10:19 |
ericm | ogra, amitk, or you guys have spare one that I borrow at UDS? | 10:20 |
lool | ericm: Did the kexec issue affect dove? | 10:24 |
ericm | lool, not dove specific | 10:26 |
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:27 |
* ericm be right back | 10:28 | |
lool | ericm, cooloney: Is one of you sending this bug upstream in kexec-tools? | 10:35 |
cooloney | lool: oh, i think ericm is working on this | 10:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:44 |
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:45 |
ogra | i think the latter one breaks in worse ways than at the time it was reported | 10:46 |
NCommander | ~~~~A;2~ | 11:02 |
NCommander | sorry, cat | 11:04 |
NCommander | saeed: ogra_cmpc: uboots abaility to be scripted is incredibly poor | 11:04 |
saeed | NCommander: hey | 11:06 |
NCommander | saeed: hola | 11:06 |
saeed | are you talking about adding the if "usb start" | 11:07 |
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:08 |
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:09 |
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:11 |
saeed | NCommander: yes, I agree | 11:12 |
NCommander | ericm: maybe for 10.10, but dove ends with 10.04 :-/ | 11:12 |
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:14 |
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:15 |
saeed | it could be unoptimized ext2 implementation | 11:16 |
NCommander | saeed: that could be it | 11:16 |
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:17 |
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:18 |
NCommander | saeed: huh? | 11:19 |
saeed | I mean to write the kernel image on /dev/sda1, then uboot will load the image from sector 63 | 11:20 |
saeed | without fs | 11:21 |
lool | ericm, cooloney: Sorry, kept crashing hard a couple of times; will look into kexec-tools | 11:21 |
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:22 |
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:23 | |
ericm | lool, no problem | 11:24 |
* cwillu_at_work grumbles about usplash not building from source | 11:59 | |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
amitk | cwillu_at_work: indeed :) | 12:07 |
saeed | dmart: I just got Segmentation fault | 12:08 |
dmart | saeed: cool, that's what I wanted to hear :) Thanks for testing | 12:08 |
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:09 |
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:10 |
cwillu_at_work | lool, adding -marm to CFLAGS in debian/rules didn't affect it | 12:14 |
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:17 |
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:20 |
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:21 |
dmart | aH | 12:22 |
dmart | We seem to be trying to build x86 inline asm here... | 12:22 |
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:23 |
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:24 |
cwillu_at_work | so, wrong backend? | 12:25 |
* 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:26 |
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:27 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 | |
ogra_cmpc | in the buildlog it seems to ignore svgalib and only build bogl | 12:35 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
ogra_cmpc | i thought they preferred splashy anyway | 12:44 |
cwillu_at_work | well it's in universe | 12:44 |
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:45 |
cwillu_at_work | <3 | 12:47 |
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:16 |
ericm | lool, ok - you updated on LP? | 13:21 |
lool | ericm: Yes | 13:22 |
ericm | lool, I'll take a look | 13:22 |
lool | ericm: https://launchpad.net/~canonical-arm-dev/+archive/marvell-dove-public/+build/1702324 | 13:23 |
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:24 |
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:25 |
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:27 |
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:28 |
lool | I dont see these commits in our master tree at least (from which versatile is built) | 13:29 |
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:30 |
ericm | lool, but yeah - this is common and should go into master instead | 13:31 |
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:33 |
NCommander | saeed: eggonlea you around? | 13:35 |
saeed | NCommander: yep | 13:35 |
asac | saeed: see msg | 13:35 |
asac | or talk to NCommander ;) | 13:35 |
lool | ericm: Could you help track / test it in other kernels? | 13:36 |
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:37 |
ericm | lool, guess I need a beagleboard somewhere | 13:38 |
lool | ericm: You should get one | 13:39 |
lool | ericm: There are plenty of people here to test in the mean time | 13:39 |
asac | lool: so assign to amitk? or ericm? | 13:43 |
asac | and yes, its on SRU radar as its now targetted ;) | 13:43 |
asac | feel a bit reluctant about fixing this in linux in SRU ... is that a safe patch`across the board? | 13:44 |
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:45 |
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:46 |
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:47 |
* 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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
ericm | asac, sure - just assign amitk then, I'll let him know this | 13:53 |
=== ogra_ is now known as ogra | ||
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:03 |
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:04 |
amitk | *on | 14:05 |
lool | amitk: But you dont review the linux patches for the other trees? | 14:05 |
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:06 |
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:07 |
lool | amitk: I wish there would be some process to ensure we do fix issues in all trees :-/ | 14:08 |
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:10 |
ogra | amitk, you forgot "different flavours of beer/wine" | 14:12 |
amitk | :) | 14:13 |
hrw | btw - is there a list of ubuntu/arm sessions for uds-m? | 14:14 |
ogra | hrw, not yet, lool is a slacker ! | 14:14 |
* 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:15 |
ogra | NCommander, how is gphoto doing ? already uploaded to the queue ? | 14:17 |
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:19 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
NCommander | dmart: well, if you want to rule out hardware, my shell on BBG 2.5 or Dove stands | 14:34 |
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:35 |
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:36 |
ogra | asac, my patch adds a 0 to /dev/fb (or XorA's patch now, since he committed it to the bug) | 14:37 |
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:39 |
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:40 |
lool | ericm: Can you test with zImage? | 14:42 |
ericm | lool, ok | 14:42 |
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:43 |
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:44 |
* 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:45 |
ericm | lool, both vmlinuz and converted vmlinux worked | 14:53 |
ericm | the converted vmlinux has no decompressing, which should be slightly faster | 14:54 |
* ericm needs some sleep | 14:57 | |
=== jmcgee|gone is now known as jmcgee | ||
lool | ericm: Cool | 15:21 |
lool | ericm: So we can push these kexec patches it seems | 15:22 |
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? | 15:59 |
lool | ericm: Pushed the pacakge to lucid; pending approval | 16:01 |
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:02 |
lool | mopdenacker: In theory they do, but apparently compcache support breaks this; ogra has the details | 16:03 |
ogra | right | 16:07 |
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:08 |
ogra | you should see compcache with swapon -s | 16:09 |
ogra | well, ramzswap | 16:09 |
ogra | though we still saw malloc errors with that setup | 16:11 |
ogra | the next image will not use compcache at all anymore | 16:11 |
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:12 |
mopdenacker | ogra: thanks! Hope we will manage to make ramzswap work in the next release. That sounds attractive. | 16:13 |
ogra | we will | 16:13 |
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:14 |
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:15 |
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:16 |
* 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:17 |
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:18 |
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:19 |
ogra | cwillu_at_work, yeah, i guess smoothstone would disagree about the joke part :) | 16:20 |
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:22 |
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:25 |
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:26 |
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:27 |
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:28 |
saeed | NCommander, ogra | 16:42 |
ogra | here | 16:42 |
saeed | the slow read from sata seems to happen only on dove | 16:42 |
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:43 |
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:44 |
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:47 |
ogra | relatively new ones | 16:50 |
ogra | i need to look up the versions | 16:50 |
ogra | 2009.01 for imx51 | 16:50 |
ogra | omap is 2010.3 (plus some omap specific git checkout) | 16:53 |
NCommander | saeed: I know filesystem support in u-boot has been vastly expanded since 1.3.4 | 16:57 |
saeed | mm | 16:58 |
saeed | I don't recall that this issue occured in early uboot versions of dove, do you? | 16:58 |
NCommander | saeed: although it would be a downright pain to port a newer u-boot to Dove, won't it :-/ | 16:59 |
NCommander | saeed: I remember the speed sucking from day 1 unfortunately. Its possibly gotten worse just because our initramfs grew | 17:00 |
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:03 |
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 |
=== JaMa is now known as JaMa|GoNe | ||
Martyn | ogra : Yep. | 17:04 |
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:06 |
saeed | NCommander: please make sure Li know about it | 17:07 |
NCommander | saeed: will do, just happens our timezone skew really really sucks | 17:08 |
GrueMaster | lrg: Ping. I was told you are working on alsa bits for freescale and marvell. | 17:34 |
NCommander | argh | 17:39 |
* Martyn is twiddling with the tegra2 | 17:40 | |
=== XorA is now known as XorA|gone | ||
hrw | which image gives x11 on beagleboard? | 17:43 |
persia | hrw: have you tried either of the omap netbook variants? | 17:55 |
hrw | only when it did not support usb | 17:58 |
persia | Well, either try again, or use an image you know works, and install some desktop environment (e.g. apt-get install ^ubuntu-netbook) | 17:59 |
hrw | desktop rebooot time | 18:03 |
hrw | /nick/ | 18:03 |
lrg | GrueMaster: yes | 18:13 |
GrueMaster | If you get a chance, do you think you could enable jack detection? | 18:13 |
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:14 |
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:15 |
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:16 |
GrueMaster | But if I get time, I'll look into it. Thanks. | 18:17 |
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:21 |
=== hrw is now known as hrw|gone | ||
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:22 |
lrg | GrueMaster: well we are at 2.6.34-rc5 atm, so I'd say another few weeks | 18:23 |
GrueMaster | Ok. I can probably work on it late next week. | 18:24 |
GrueMaster | This could be interesting. I've worked on HD Audio side of alsa before, but not the SOC or AC'97 stuff. | 18:28 |
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:30 |
persia | Well, kinda. | 18:31 |
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 | 18:32 |
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:00 |
* GrueMaster stopped using Redhat after 7.2 | 19:24 | |
GrueMaster | (before they said there was no future in Desktop Linux). | 19:24 |
hrw|gone | I use Debian since 1999 | 20:19 |
jc_ | hi | 22:09 |
persia | Hey. | 22:09 |
jc_ | so is apple going to buy arm or not? | 22:10 |
jc_ | i hope it doesn't stiffle any dev on ubuntu and arm.... | 22:11 |
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:12 |
* 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:13 | |
videorechner | Mhm I like the idea, mac minis with arm cortex a9 MP, low power consumption and ubuntu can still be installed | 22:54 |
persia | Maybe. There's issues related to that specific implementation of GPT in lucid, although they may be fixed in the future. | 22:59 |
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:13 |
sveinse | Is there any here now who happens to have worked with JTAG against TI OMAP? | 23:19 |
persia | Anyone know if there is an existing bug number for both desktop-webmail and evolution being on ubuntu-netbook/armel ? | 23:22 |
=== jmcgee is now known as jmcgee|gone |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!