/srv/irclogs.ubuntu.com/2009/07/16/#ubuntu-arm.txt

mcasadevalllool, mesa built successfully in launchpad-buildd on babbage 203:21
mcasadevalllool, I believe I can officially say argh03:21
Sarvatt10 hours mcasadevall?04:17
mcasadevallBuild needed 03:44:36, 1393092k disk space04:18
mcasadevallNope04:18
mcasadevallSOmething has got seriously wrong on the actual buildds ...04:18
Sarvattahh was like 12:30 my time when we were talking about it so thought it might have actually taken the 10+ hours04:19
loolmcasadevall: Could you bring this up with IS?09:17
ograhmm, doesnt look if i gained much with more ram for debootstraps second stage ... its simply the lack of CPU making it slow09:56
ograhmm, ok, the unpacking surely is faster10:08
ograwow, locale-gen is gotten a lot faster10:37
ograreal51m49.350s10:40
ograuser48m31.682s10:40
ograsys0m21.285s10:40
ogranot to bad for an ubuntu-minimal10:40
* ogra comments all the swap stuff and runs it again10:41
ograreal51m9.016s11:37
ograuser47m42.963s11:37
ograsys0m22.133s11:37
ograhmm, no significant difference11:37
ograso guess i'll leave the swap part in but dont add the ugly bits that make it be used *before* debootstrap runs11:38
ograsince that requires to unpack busybox-static in the choot before switching to VM to have swapon available before a system exists11:39
ogrameh /me wants a --to-the-rim option for dd so it only fills a file up to the max available space on the target device11:47
loologra: What's the status of the banshee bug?11:57
ogradyfet, is looking into it atm11:58
loologra: Why are you assigned?11:58
looldyfet: hey what's the status of the banshee bug?11:59
ograshould i reassign ?11:59
loologra: What do you think?12:00
ograwell, i felt responsible for it even though dyfet looks into it atm12:00
loologra: If you're responsible for it, could you please give me a more detailed status update?  There's nothing in the bug12:07
loolI don't know what's being investigated, what are the current results etc.12:07
loolThe fact that dyfet is looking into it is mentionned nowhere12:08
ograwell, i asked dyfet to take a look and pointed him to the vorbis error12:08
loologra: When was that?12:09
loologra: Could you please document that in the bug itself?12:09
ograthat was two days ago, i'll add info to the bug12:10
loologra: Thanks12:11
loologra: What about the debian-cd specs (subarches and mx51 changes); will this happen for Alpha 3?12:11
ograi'd really like to have a prototype but without the HW its not that easy to work out a uboot layout12:12
loologra: Did you test Uboot on the lange?12:14
loologra: I don't think the subarch changes need any hardware though12:15
loologra: Are the Uboot packages ready?12:15
ograi tested the binary image we had12:15
ograbut that didnt work12:15
loolOk12:15
ograwas waiting until NCommander has his binary through NEW12:15
loolSo it's in NEW? good12:15
ograhe told me tue. its sitting there12:15
loologra: So what about the armel -> armel+mx51 changes?12:16
* ogra sighs ... calling cleanup on 0 1 2 3 9 11 13 15 has intresting sideeffects12:16
ogralool, i want to have uboot-install separately12:17
loolYes?12:17
ograso i'm blocking on the layout as i mentioned above12:17
loolWell you could rename the script first12:17
loolThat makes room for the Marvell stuff in parallel12:17
ogragrmbl, why is cleanup called multiple times now12:18
ogralool, ok, i'll do the renaming this week12:18
loolOk thanks12:19
* ogra slaps forhead12:37
* ogra removes "exit 0" from the end of cleanup() and goes to a corner to cry12:37
ogragrmbl now it doesnt exit properly12:45
* ogra curses, it was all working before12:46
* ogra re-adds the cleanup acll at the end of the script 12:47
ogratrapping on 0 is simeply not working right12:48
=== cbrake_away is now known as cbrake
kod-ehi all13:24
looldyfet: Hey when you come up, could you update the banshee bug with your findings?14:06
loologra: trap 0 works fine for me   :-)14:06
dyfetlool: yes...but I dont have update yet...I was fighting hw part of yesterday to get karmic setup on it :)14:07
ogralool, i have massive probs with all the traps here14:07
ograif i trap out of run_vm it essentially does nothing14:08
ograwell, it prints the "Cleaning up..." but exists immediately14:08
ograeverywhere else trapping works fine14:11
ograwell, thats not actually right, trapping works in run_vm if the vm actually runs but not while wget runs or the vm is just starting up14:12
Sarvattso is marvell support going to be kept in karmic?14:12
ograkept ?14:13
ograits being added14:13
Sarvattah, new kernel flavor? i just meant the armv5, didn't know if it was going to go v6 or v7 only during karmic14:14
ograit will be v614:14
Sarvattoh wow, i should have read up more on sheeva14:15
loolSarvatt: Right, Sheeva wont work14:17
loolSarvatt: We didn't support any marvell flavour last cycle14:17
loolI find it unfortunate that we're not supporting v5, but we're targetting high end ARMv7 netbooks/hardware so it makes sense to rip the benefits of the new instructions14:18
ogralool, swap stuff pushed btw, feel free to edit away14:19
* ogra builds a desktop image to see how swap affects it14:23
rjune_wrkMorning ogra14:24
ogragrmpf, why does it die now14:24
ograhmm, swapsizes above 1G seem to be no good idea14:24
Sarvatti'm so confused, marvell says "It contains advanced three-level branch prediction, a variable stage pipeline, and an integrated memory controller, providing unmatched high-end performance and low-power requirements. Compliant with the Cortex A8, Sheeva also supports both the ARMv6 and ARMv7 instruction sets, making it the world's first dual ARM ISA compatible CPU." but the docs for the sheevaplug say its a Sheeva 88SV131 ARM v5TE Pro14:33
Sarvattcessor Core with MMU and L1/L2 Cache14:33
ograthe docs are right14:34
Sarvattso moral of the story is, if i buy one make a copy of the archive now before things move to armv6? :D14:41
suihkulokkithe moral of the story is to switch to debian \o/14:41
suihkulokkiSarvatt: marvell is saying that sales stuff that they can produce ARMv6/ARMv7 cpu's based on sheeva tehnology, but their current cores are are ARMv514:42
suihkulokkis/sales stuff that//14:44
Sarvattyeah for armv5 i guess thats the best option, i really would like to get a v7 to play with instead but the sheevaplug looks like a better option for me for the price right now vs a beagleboard and i'm starting to get convinced other platforms arent going to come out anytime soon at a decent price :D14:46
loologra: Hmm you seem to assume all vars aren't set in the env15:15
loologra: You should be init-ing things like SWAPFILE or NOSWAP15:15
ograwith ="" ?15:16
ograhmm15:16
ograthats a lot of extra empty lines ...15:16
loolThey are not "extra"15:16
ograheh15:16
ograyeah15:16
ograi'll add them15:16
loologra: Since the script is so young you could still consider set -U15:16
rjune_wrkwhat does set -U do?15:17
loolsorry set -u15:17
loolrjune_wrk: It errors out if you use an undefined var in an expansion15:17
rjune_wrkAhhh15:17
rjune_wrkIOW, a very good habit.15:17
loolA bit hard to retrofit in some pieces of code15:18
rjune_wrkI believe that.15:18
Sarvattogra: what cpu was rootstock (well qemu-arm) using by default before the cortex-a8 change?15:18
ograSarvatt, the default versatile one15:19
ograit didnt specify -cpu before15:19
ograarm926 i belive15:20
Sarvattguess it uses "any" if you dont specifiy?15:20
Sarvattah15:20
Sarvattits just nuts how much faster it is doing the second stage in a chroot in the android qemu (like 5 minutes there)15:22
ograwhat cpu is that ?15:22
ogra(specifically at what speed does it run)15:22
ograi havent gotten qemu to do more than 200MHz here15:23
ogra(on arm)15:23
Sarvattchecking, battery about to die brb15:30
Sarvatthttp://sarvatt.com/downloads/emulator.txt15:40
ograBogoMIPS: 736.2215:41
Sarvattthats on my faster pc that took almost 5 hours with rootstock the other day, will check what it is on the one i just built it on in a sec (atom cpu) :D15:41
SarvattBogoMIPS: 85.4015:43
ograright, thats a bit of a differentce15:43
ogra*difference15:43
Sarvattits QEMU PC emulator version 0.8.215:43
Sarvattbut it builds fast on this 85 bogo mips one which is the weird part15:44
ogrado you see the cpu speed in dmesg ?15:44
ograi'd really love to speed up debootstrap ... the rest runs totally fine, but the --second-stage processing is awful15:46
Sarvatthttp://sarvatt.com/downloads/emu-dmesg.txt15:46
Sarvattsorry, I had 512mb memory when I did it15:47
ograhmm15:48
Sarvattonly 96 in that dmesg15:48
ograright, that means their qemu is hacked up i guess15:48
Sarvattyeah it is quite alot, thats why they havent upgraded it since theres so many changes against the old version15:49
Sarvatthttp://android.git.kernel.org/?p=platform/external/qemu.git;a=summary15:51
Sarvattdoesn't help they do most of the development in a private perforce vcs and just import it in batches every now and then15:52
ograyeah15:53
ogranot very clean15:53
* ogra rolls a qemu with lool's 512M patch and checks if that changes anything15:53
ograi was trying to add a gig of swap today, but that didnt make any speed difference15:54
ogra(using awful hacks that added the swapspace before debootstrap runs)15:55
loolSarvatt: Oh Google also patches qemu for 512MB of RAM?  interesting15:57
Sarvattthey have a custom platform that allows it I think?15:58
Sarvattnot using versatile15:58
ograah15:58
ogralool, did you notics any speed improvement with your patch15:59
loologra: For what?16:00
ograqemu debootstrapping16:00
loolI didn't load qemu with heavy workloads, so no16:00
ograah16:00
loolI don't think 256M or 512M make any difference for a debootstrap16:00
ograit might make a difference to the dpkg database processing16:01
ograit hangs endelss in the preprocessing in rootstock16:01
ogra*endless16:01
Sarvattneat, XenARM has a paravirtualized goldfish platform from android qemu16:03
ogralool, hmm, your qemu patch doesnt work if applied against our package it seems :/16:34
ograDEBUG registered size=10000000 SDRAM at 0x0 with offset (nil)16:34
ograNot enough memory (requested_size = 268435456, max memory = 268435456)16:34
ograhmm, there seems to be a bunch of stuff missing in the patch16:49
ogralool, do you remember against which 0.10 version you made the qemu patches ?17:09
ograhrm, i suspect we apply some patch that breaks it17:22
loologra: Against tip17:31
ograoh, i thought you did it against 0.10.x17:31
loologra: No, it wont work against 0.1017:31
ograyes, i see that17:32
loolmemory management was redone and didn't allow for split memory banks in <= 0.10.x17:32
ograaaahh17:32
loologra: Is it you or NCommander working on the gnome-keyring bug?17:43
ograon my list17:44
loolNCommander: hey when do you usually roll the wiki page for next meeting?17:44
ograi need some more deskspace for the B1 though17:44
loolNCommander: I'd like to add a couple of topics early in the agenda17:44
ogralool, i think he does it 10mins before the meeting :P17:44
loolNCommander: Ah it would be cool if you could roll the pages now; otherwise I can send you topics by email17:53
NCommanderlool, I'll roll it a little later today (I usually do it a day or two after the meeting)18:08
NCommanderlool, just shoot me an email and I'll amend the pages18:09
* NCommander has to add somethinge sel as well18:09
* ogra wasnt aware NCommander speaks french 18:13
loolNCommander: sent18:15
* ogra just remembered that sel is salt in french :)18:15
* NCommander knows no human language expect English18:16
ogralol18:16
ograpartially at least :)18:16
NCommander*grumble*18:17
ograwow, the tip qemu just trashed my filesystem in the image completely18:17
NCommandero____o;18:17
* ogra takes another img ... 18:18
ograafter the last two days i have plenty of them18:18
ogra/etc/init.d/rc: line 74: /etc/default/rcS: No such file or directory18:18
ograerror: '/etc/init.d/rc' exited outside the expected code flow.18:18
ograinit: rc-sysinit main process (379) terminated with status 118:18
Sarvattwow yeah i'm doing a second stage in 256mb ram and its alot slower18:18
ogrageeez18:18
NCommandero]______-o;18:18
* ogra sees no difference with 512M in qemu yet18:21
ograstill sitting there ... doesnt move18:25
ograbut i wasnt really expecting a difference through more ram18:25
ograthat would have shown with the swap this morning already18:26
Sarvatti have the gui up this time too though, thats eating alot of the cpu time. 13% phone 11% alarm clock 9% google apps 21% dpkg kernel time 7% user 34% debootstrap user 14% kernel18:27
ograwell, you are bootstrapping from a running system18:28
ogratahts a bit different anyway18:28
Sarvatthmm 141mb ram inactive, really doesnt need more ram.. its quite nice how in depth the android debugger is for profiling18:33
Sarvattahhh i think the android environment tries to keep 50% ram free18:35
mcasadevalllool, ogra, 13563 mcasadev  20   0  372m 367m   64 R 69.6 72.9   7:14.26 lzma18:45
mcasadevallLooks like lzma is sucking down the machine's resources18:45
mcasadevalland is paging out18:45
NCommanderwait a tick18:49
NCommandernever mind18:49
loolmcasadevall / NCommander: You said yesterday it was working fine?!19:08
NCommanderlool, on my boards, I didn't build on rimu19:08
NCommanderlool, but the build passed on both rimu w/ dpkg-buildpackage, and under launchpad-buildd on my B219:08
loolSo on rimu it's slow but on our boards it's not19:08
NCommanderlool, it passed though, 4 hours, no hang19:08
NCommander(the build took 3:40 on my boards)19:08
lool4 hours is about the same you got and shorter than on the buildds19:08
NCommanderRight19:08
loolNCommander: Chase IS to see what is different?19:09
NCommanderlool, infinity just went WTF when I told him it passed19:09
NCommandersince it shouldn't19:09
NCommanderrimu is setup the same way as the buildds expect access permissions, and it doesn't have launchpad-buildd19:09
=== bizkut-miau is now known as bizkut
=== cbrake is now known as cbrake_away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!