=== bjf is now known as bjf-afk [00:33] hmm. those dvi things on babbage boards. are those compatible with VGA? or do they only support digital? [01:17] asac: US Central [01:17] yeah [01:18] so with commenting out the lines [01:18] i end up with a console login ;) [01:19] and i cnanot log in because of these timestamp issues i suspect [01:19] if you paste that file i can show it you ;) [01:19] you need to edit that after "Copying Files ..." (i could change it at about 60% [01:24] * asac out [07:46] Good morning to everybody [07:47] any Ubuntu issue on ARM9, Anyka 7802L/266Mhz processor it is possible? [08:46] Mendocinox: We don't have any kernel for that, but the jaunty / 9.04 userspace should work [08:47] later ones will not [08:58] lool: thanks. the distro names 9.04 userspace? [08:58] Where can I find that? [09:04] Mendocinox: I mean Ubuntu jaunty / Ubuntu 9.04 for ARM [09:04] You can find it at http://ports.ubuntu.com/ubuntu-ports/ [09:05] Usually accessed with APT [09:07] thank you very much for your help, lool brother [12:52] ogra: so we want to try the new kernel asap i guess? who will get that in? [12:52] cooloney will care for imx51 i think [12:52] on the other front i would like to not land uboot for imx51 until we have a booting install image. ... unless we dont find what is going on [12:52] does that make sense? [12:53] yes [12:53] not saying we shouldnt work on uboot ... just not land it until we have an image that works more or less well to hand out. if we think uboot is safe to land we can just do it once we have it though [12:53] ogra: do you know when ncommander will be back? [12:53] e.g. do we need to find someone else checking dove? [12:53] yeah, i will do some scripting in my holidays on boring days :) [12:54] * ogra checks googlecal [12:54] hey ... holidays should be holy [12:54] nah [12:54] i'll be bored enough [12:55] ogra: so cooloney is imx51 ... who is dove? [12:55] and i have to read mail at least every second day ... i dont like to return from holidays having thethousands of mails waiting [12:55] ericm i think [12:55] ericmiao? [12:55] yeah [12:55] but we should probably as in #kernel to be sure [12:55] maybe he can help us? those issues dont really feel like they start in user space ;) [12:56] * ogra gets between 400 and 600 mails per day ... i wont stay away from my mailbox for more than a week [12:56] i think they are a combo of HW and toolchain [12:57] lool: status on my dove board ;)? [12:57] i want to have the switch to uboot for imx51 done in my first workweek after my holiday [12:57] yes. [12:57] (i.e. by jan. 8th) [12:57] so we can do some testbuilds before A2 freeze [12:57] i will probably do some excersizes with uboot just for fun (not really for image, but to get used to the whole procedure etc.) [12:58] yeah. [12:58] yeah [12:58] you should get yourself a beagleboard [12:58] asac: No, I worked mostly on python policy in the last two weeks [12:58] i would like to get a working install this year though [12:58] I'm starting to see the end of it [12:58] hmm [12:58] its great for exercises on uboot :) [12:58] asac: You say on ubuntu-devel@ that thumb2 improves performance, but it generally does not [12:58] or for any exercises :) [12:58] lool: thats what was said ;) [12:59] lool, it should according to arm [12:59] asac: You said "While this improves performance" [12:59] asac: And it does not [12:59] lool, and given that we have smaller binaries it must actually [12:59] i only carry forward the marketing stuff communicates [12:59] probably not noticeabled [12:59] It decreases cache pressure [12:59] But code will actually run slower [12:59] because of compression ? [13:00] No [13:00] lool: what counts is that the overall performance of the system is supposed to be better [13:00] asac: It's just FYI; I personally thought Thumb2 was faster until yesterday [13:00] lool: ok thanks ;) [13:00] i am not sure what exactly is faster/slower on the CPU level [13:00] just that what we are doing is supposed to improve performance summed up [13:00] Did someone look at how big the .kos are on armel? [13:00] du -hs `find /lib/modules/2.6.32-7-generic -type d -name crypto` => stupidly small numbers [13:01] Biggest is 852K /lib/modules/2.6.32-7-generic/kernel/crypto [13:01] lool: the problem is that all modules are copied [13:01] its a bug [13:01] (uncompressed -- don't see how that could bloat by MBs on armel) [13:01] lool: do you have some sources for your claims (not that i'm questioning you, I'm interested in this topic) [13:01] asac: What's the list of dirs? [13:01] or are you not referring to the bug? [13:01] lool: all dirs. we tracked it down [13:01] https://bugs.edge.launchpad.net/ubuntu/+source/cryptsetup/+bug/495161 [13:01] Launchpad bug 495161 in cryptsetup "initramfs cryptroot hook bloats armel initrd by adding >13M of compressed modules" [Critical,Triaged] [13:01] shenki: A Freescale guy who told me it was documented in ARM docs [13:02] shenki: Note that performance of some programs might improve if they fit in the L2 cache thanks to T2 instead of having to be read from RAM on e.g. every loop [13:02] is thumb2 realized in microcode? [13:02] shenki: But in general, without taking care of cache it's actually slower [13:02] (/me thought arm doesnt do microcode ... but has no clue to be honest) [13:02] asac: I have no idea [13:02] lool: the instruction decode slows it down? or... [13:02] shenki: I have no idea [13:03] lool: is this in comparision to 'thumb' (not v2) or ARM? [13:03] we hopefully will get some benchmarks at some point ;) [13:03] I didn't look at that ARM errata, but that guy was reasonnable and very confident on this [13:03] shenki: It's thumb2 versus arm [13:03] asac: im thinking i might re-do my tests with thumb2 vs ARMv7 :) [13:03] http://jms.id.au/wiki/TheresSomethingOnMyArm [13:03] asac, heh, we seem to have a race on the bug both duplicating each other :) [13:03] asac: there is a writeup of the tests ive done [13:03] ogra: really? [13:04] i am just posting things we find [13:04] ;) [13:04] me too [13:04] the bug seems ok to me [13:04] asac: I've read the comments on that bug already [13:04] asac: I don't know what the find outputs on armel systems [13:04] ogra: i was faster ;) [13:04] On my ubuntu install it's really small [13:04] yeah, you definately win :) [13:04] lool: the find outputs empty [13:04] thats one of the things we are investigating: [13:04] lool, see the last two comments [13:04] a) add a safety belt: dont call copy_modules_dir if archcrypto is empty [13:04] b) find out why on arm archcrypto is empty in the first place; if the find needs to be adjusted to it. [13:04] So your find returns empty [13:04] ok [13:04] right [13:05] asac: Both have to be addressed [13:05] asac, b) is easy ... there is no crypto dir at all [13:05] shenki: I asked about power usage too, but he said it was similar or identical [13:05] lool: yes. title of those is: [13:05] two things to do here: [13:05] a) [13:05] b) [13:05] root@ubuntu:/# grep SAHARA boot/config-2.6.31-601-imx51 [13:05] CONFIG_MXC_SAHARA=y [13:05] # CONFIG_MXC_SAHARA_POLL_MODE is not set [13:05] # CONFIG_MXC_SAHARA_USER_MODE is not set [13:06] the crypto stuff for imx51 is compiled in [13:06] ogra: yeah. so a) is enough ;) [13:06] no modules you could find [13:06] asac: I was suggesting to do both because you wrote here "thats one of the things we are investigating" [13:06] lool: what kind of engineer was your freescale friend? (how far down in the stack) [13:06] I thought it meant you would only do one of the two [13:06] right. sorry [13:06] no [13:06] both [13:06] shenki: *cough* [13:07] maybe it was a powerpc fanatic ;) [13:07] :) [13:07] i can only say that i can act quicker with 2 thumbs ;) rather than one cut off ;) [13:07] or the office gardener :) [13:07] shenki: Actually http://www.arm.com/products/CPUs/archi-thumb2.html shows that thumb2 is not higher performance [13:08] shenki: It's faster than *thmb 1*! [13:08] hrm. wtf did they invent thumb2 then!? [13:08] So I guess the higher performance stuff comes from thumb1 comparisons [13:08] the high level outcome of that is definitly better performance for the whole system [13:08] shenki: Well it might overall be better than ARM in some cases [13:08] if no net improvement on CPU level, size reduction is good :) [13:08] shenki: And your binaries are smaller too [13:08] yeah, cache, memory...all ins [13:08] for windows *g* [13:09] asac: You might see larger code performing *slower* though [13:09] let's say firefox for instance [13:09] chromium is 30% smaller ARM v thumb [13:09] s/ins/wins [13:09] I don't think firefox fits in cache [13:09] Anyway, /me returns to python policy stuff [13:09] no. but if size is smaller its still faster to get from mem to cpu [13:09] even if not in cache [13:10] thats my ignorant idea of this [13:11] anyway... details ;) [13:11] real life will show if this was worth it ;) [13:44] plars: do we have a bug about busted dove image? maybe we should open one? [13:45] plars: can you confirm that a lucid chroot on modern dove doesnt work at all? [13:45] asac: yes, 494831 [13:45] (to narrow down if its only kernel problem) [13:45] bug 494831 [13:45] Launchpad bug 494831 in linux-mvl-dove "Alignment trap/Unhandled fault errors on boot" [Critical,New] https://launchpad.net/bugs/494831 [13:46] plars: feel free to target such obvious release blockers for lucid [13:46] asac: will give it a try [13:46] done [13:47] ok added tags [13:47] also subscribe dmart [13:48] subscribed [13:52] asac: so do you believe that less likely to be kernel, more likely to be toolchain? [13:53] asac, do we want to duplicate Bug 494827 ? [13:53] Launchpad bug 494827 in ubiquity "Installing on babbage 3, crashed at ~98%" [Undecided,New] https://launchpad.net/bugs/494827 [14:06] ogra: yeah [14:06] plars: i dont know . i hope its either or ... and not a combination [14:06] but starting with a chroot will help checking that imo [14:07] though let me quickly replace the script in a test install and see if ubiquity actually survives [14:09] well, FSVO quickly :) [14:12] ogra: it survives [14:12] i tried it [14:12] it installs etc. [14:12] at least when commenting the lines after "Copying files..." [14:12] a full ubiquity run ? [14:12] yes [14:12] at about 60% you can change the file [14:12] and it will just succeed [14:12] well, i'll do it anyway since i want a lucid install [14:13] ogra: the install doesnt boot here. seems to be usb-storage problem though [14:13] so maybe with a different disc variant it will work [14:13] well it boots [14:13] i'll check [14:13] just doesnt start X [14:13] you end up at the console [14:13] and gdm cannot be killed/restarted without locking up the whole system [14:14] feature [14:14] i'll investigate that once i have a proper install [14:21] hmm, ubiquity doesnt really like to be re-run if it crashed once apparently [14:21] thats annoying [14:23] ogra: reusing existing partitions is broken too [14:23] so delete + create partition to workaround [14:23] i always to a full reinstall [14:24] plars: do we have a bug on that already? [14:24] hmm. [14:24] no need to delete for that [14:24] ogra: maybe your usb is busted now? [14:24] just check "use complete device" [14:24] not here ;) [14:24] i have a good karmic partition on that i want to keep [14:24] ah [14:24] until i have stacked up hardware redundancy [14:24] i have an extra disk for that [14:25] yeah [14:25] will get that too soon i guess [14:25] a well partitioned disk with separate home etc ... [14:25] asac: on what? [14:25] though i started doing my work on SATA recently [14:25] 15:23 < asac> ogra: reusing existing partitions is broken too [14:25] 15:23 < asac> so delete + create partition to workaround [14:25] so its not that important anymore [14:25] ubiquity [14:25] plars: ^^ [14:25] its partman, not ubiquity [14:26] asac: hmm... sounds familiar, like possibly something we filed a while back and got untagged because it was not specific to armel [14:26] asac: will have to search around for it [14:26] thx [14:26] ogra: yeah [14:26] also ubiquity is really really slow on arm imo [14:27] not sure what they do, but it feels not really designed for speed [14:27] similar to update-manager :) [14:27] yes, lool filed a bug for that around jaunty [14:27] still open iirc [14:27] actually i edited the hook file at about 58% [14:27] then at about 60% the change was gone [14:27] feels like it copies everything twice or something [14:27] or i didnt hit save properly [14:27] i'll replace the file while langpacks are downloaded ;) [14:28] but that doenst make the general slowness go away [14:28] its the throughput ... [14:28] grapics driver is also sucky ;) [14:28] the USB controller gets you something like 16MB/s [14:28] displaying stuff alone is really slow [14:28] yeah [14:28] could be [14:28] there is no graphics driver [14:28] but but but [14:28] its framebuffer [14:28] its also happning for things like timezone selection etc. [14:29] video killed the radio star [14:29] the driver that exists is 100% closed source [14:29] i know. [14:29] and we dont include the imx-libs package yet [14:29] is that something for restricted? [14:29] i'll push that to the archive during this cycle [14:29] hmm [14:29] ok [14:29] parts of it ... [14:29] there are binary files for video codecs [14:30] but i split the package already, look in the P3A [14:30] with imx-libs we at least have a 2D gpu API available ... [14:31] cool [14:31] will check [14:31] and a vpu for gstreamer [14:31] have to run for lunch and then prepare the release report [15:02] weird ... ubiwuity is sitting at partitoning at 5% since 20min [15:02] no errors or anything [15:05] err [15:05] so now i'm confused, i got dropped back to the partitioner step [15:16] ogra: this sounds like the usb problems I was seeing [15:17] there are no errors anywhere [15:17] ogra: I got an on screen error, and a lot of spam in dmesg though [15:17] nothing ... [15:17] dmesg is fine, installer debug log is fine [15:17] it just starts over [15:17] i rebooted now [15:18] suihkulokki: Did you manage to get your LD_PRELOAD exec() wrapper working with qemu-arm? [15:26] * ogra doesnt get it, same issue, no errors ... the same image worked fine on the same hardware yesterday [15:27] JamieBennett: can you check if there is more to add to weekly summary? [15:27] https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid [15:27] its also extremely slow [15:28] sigh, what is that [15:29] ogra: there are bugs with usb imo [15:29] asac, no errors at all [15:29] lool: yeah, I have even a nice demo ready [15:29] and after the first try the disk was properly partitioned [15:29] now I just need to get it uploaded somewhere with a readme [15:29] ogra: yes. repartitioning is a problme [15:30] did you unmount it before starting ubiquity? [15:30] nope [15:30] yo uneed to do that [15:30] i never had to do that [15:30] and i would expect any errors to show up in any log files [15:30] right [15:30] suihkulokki: Cool! may I help? [15:30] i think its a regression, but we seem to have big bugs on resetting usb devices/ports [15:30] i see the partitioning steps in the logs and in dmesg [15:31] suihkulokki: It looks like it's something I definitely want to use instead of the static binary [15:31] and they finish properly [15:31] ogra: for me ubiquity crashed [15:31] suihkulokki: Do you have a name for it? [15:31] and UI stayed up [15:31] so you didnt see it [15:31] then ubiquity jumps back to the partitioner [15:31] think it forked a process that crashed and then waits for ever fo rthat to end [15:31] no [15:31] suihkulokki: Perhaps in qemu itself? [15:31] i can even watch the slideshow while it hangs at 5% [15:32] until it gets me back to the partitioner [15:32] where i then see that it properly formatted and partitioned [15:32] good. cant you then continue? [15:32] oh reusing existing partitions definitly crashes ubiquitiy ;) [15:32] yes, to get into the same loop [15:32] ogra: try advanced. [15:32] remove partition, add new ... continue [15:32] thats what i used [15:32] and it worked [15:32] i *dont* reuse existing partitions [15:32] lool: will you be arount in ~2h ? [15:33] bit busy atm [15:33] i click "use entire disk" [15:33] ogra: well. still just try that. if that works we can have someone else gather the details for the bug [15:33] i did the exact same thing three or four times yesterday [15:33] ogra: dont use that. maybe thats broken ;) [15:33] and it worked flawless [15:33] hmm [15:33] well. ;) [15:33] maybe reboot and try again ;)? [15:33] i did that two times already [15:33] suihkulokki: Yes [15:34] ogra: then try what i suggested. use advanced [15:34] ;) [15:34] Well I might leave a bit at that time, but worst case leave a message here [15:34] i'm using the same image (same SD even) in the exact same HW i used yesterday [15:34] going the exact same way i did yesterday [15:34] well, i'll try your suggestion [15:35] though i dont get why that issue shows up at all [15:35] especially without *any* error messages [15:35] * ogra reboots [15:35] asac, i agree though that if its in that state everything gets unusable slow [15:36] as for the name, it is called croco atm [15:36] W: Bizarre Error - File size is not what the server reported 65872 1 [15:36] Tss [15:38] not tried on ubuntu, but I think croco too is affected by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/452175 [15:38] Launchpad bug 452175 in bash "Random segfaults when using ld.so explicitly to start a program" [Medium,Confirmed] [15:39] Never seen that one yet [15:40] suihkulokki: The loop doesn't segfault for me (on amd64) [15:41] while :; do /lib64/ld-linux-x86-64.so.2 /bin/bash -c '/usr/bin/which apt-get'; done [15:41] Ah right it's noted in the bug that amd64 works [15:49] sigh [15:49] so i zeroed out the disk ... [15:49] same issue [15:54] yes. not sure. i had tons of issues with partman [15:54] only way it worked was to remove a partition manually, add it then [15:54] i will do another install i guess [15:55] ogra: how can i make an install image out of a converted boot image without needing to put everything on it? [15:56] is there a trick or should i just do a fresh dd ? [15:56] do a fresh dd [15:56] you would need to manually replace the initrd and change the cmdline [15:56] to get the casper bits [15:57] k [15:57] funny is that the led on my usb key flashes madly [15:58] if i wouldnt knoe better i'd say its copying [15:58] *know [16:01] ogra: would it be easy for you to check whether its ok with the old kernel? [16:01] ha ! [16:01] this time it moved on [16:02] see ;) [16:02] formatting just took ages [16:02] be patient ;) [16:02] it has never been that slow [16:02] and i use the same USB key for all my test installs since jaunty [16:02] ok doing an install on a SD card now [16:02] since the ext4 issues feel liks usb related [16:03] also i want a fixed hwclock :/ [16:06] * ogra has no hwclock probs [16:06] just give up your resistance to ethernet cables ;) [16:07] use reiser4 *g* [16:08] haha [16:08] nework manager works great ;) [16:08] just not on livecd before X [16:15] oho ! [16:15] write error on swap device [16:15] i guess thats my issue [16:16] its spilling the console but doesnt show up in any log [16:17] * ogra suspects compcache is broken [16:24] oh my [16:28] hmm, calling swapoff -a wasnt so clever it seems [17:00] ogra: so my test install is now at apt stage ;) [17:00] (test install on SD as usb was broken) [17:01] as USB ? [17:01] usb-storage big thing that is [17:01] oh, as usb was broken ... [17:01] * ogra read SD as usb :) [17:01] hehe [17:01] no [17:01] well, there is definately something wonky with swap [17:02] but i couldnt find out if its compcache or the swap device on disk [17:02] the latter would explain your usb issues though [17:02] (that you have to unmount etc) [17:02] and also the slowness [17:05] ogra: swap might be related to the usb prob [17:06] but not 100% sure [17:06]