| === ApOgEE__ is now known as ApOgEE | ||
| persia | Noisi: Hey. Did you not get an answer about your mysqlclient question yesterday? | 09:47 |
|---|---|---|
| Noisi | only go to #sql , but i got no answer there | 09:49 |
| persia | Bother. | 09:50 |
| persia | Sorry I didn't answer you then: I ended up falling asleep. | 09:50 |
| persia | So my memory is that you had a cross-compile environment but you wanted to try binaries without needing to compile them, is that correct? | 09:50 |
| mikeul | ogra, it looks like you made all the necessary changes to RootfsFromScratch that we discussed yesterday. | 09:54 |
| ogra | mikeul, yes, sorry, i didnt want users to run into problems | 09:54 |
| mikeul | no problem, that makes sense. | 09:54 |
| mikeul | I'll just have to find another problem I guess. | 09:55 |
| persia | mikeul: What kind of problem do you like? | 09:56 |
| mikeul | I'm not really looking for problems, they usually find me. | 09:57 |
| persia | OK. I usually have a reserve of issues available if you're looking for something :) | 09:59 |
| persia | Also, we're having a mini-sprint on Thumb2 porting in about an hour, if you'd like to participate. | 10:00 |
| asac | o/ | 10:58 |
| ogra | hmm, all languages are gone from our images again | 10:59 |
| ogra | that wasnt the plan :/ | 10:59 |
| ogra | * Languages: es xh pt de fr bn | 11:01 |
| ogra | * language-pack-${Languages} [i386 amd64 powerpc] | 11:01 |
| ogra | oh, sigh | 11:01 |
| dyfet | hmm...yea... | 11:01 |
| ogra | StevenK, ^^^ can you change that post freeze ? | 11:02 |
| asac | ok ... X is crashing badly on me :/ | 11:03 |
| asac | on x86 luckily ;) | 11:03 |
| ogra | on armel or x86 ? | 11:03 |
| ogra | ah | 11:04 |
| ogra | in what way ? | 11:04 |
| asac | i hit ctrl+enter -> boom | 11:04 |
| asac | but only sometimes | 11:04 |
| ogra | weird | 11:04 |
| * asac upgrades and hopes there was a fix | 11:04 | |
| dmart | Hi guys | 11:05 |
| ogra | hrm, a rootstock build of ubuntu-netbook hangs reliably in "unpacking iso-codes" | 11:05 |
| asac | hey dmart | 11:05 |
| * ogra wonders why that is | 11:05 | |
| ogra | hi dmart | 11:05 |
| dmart | Hi there, sorry I'm late--- got sucked into a discussion about gdb | 11:06 |
| asac | ogra: did we figure why ooo is pulled in for us now? | 11:06 |
| ogra | all fixed and gone :) | 11:06 |
| asac | cooool | 11:06 |
| ogra | seems someone added language-support-$lang for all languages and all arches above | 11:06 |
| ogra | the -support packages pull in thesaurus and packages that in turn pull in oo.o | 11:07 |
| asac | hmm | 11:07 |
| lool | dmart: You mean you hanged in a discussion with gdb | 11:07 |
| ogra | usually we only have -pack and -pack-gnome | 11:07 |
| asac | lol | 11:07 |
| dmart | lool: ? | 11:08 |
| lool | dmart: hanging... gdb... | 11:08 |
| lool | oh well | 11:08 |
| dmart | lool: well, segfaulting | 11:08 |
| * lool tried to do silly jokes | 11:08 | |
| lool | I suspect asac has pity for my jokes | 11:08 |
| * dmart was slow on the uptake | 11:09 | |
| dmart | Anyone ready to take a look at https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList | 11:09 |
| dyfet | we can step you through it... | 11:09 |
| asac | so ... | 11:10 |
| asac | i think it would be time to add a column for the current status there | 11:10 |
| asac | or move all the fixed/invalid bugs to a separate table | 11:10 |
| lool | Just drop them? | 11:10 |
| lool | There's wiki history, we don't need to clutter the page for fixed bugs do we | 11:11 |
| asac | not sure | 11:11 |
| lool | dmart: Got blocked on the gcc atomic builtins qemu changes by their ppc maintainer who objects to using them in general, and for ppc in particular; need to redo the patch to only use these for arm/thumb :-( | 11:11 |
| asac | having a page that shows what was done isnt that bad either | 11:12 |
| asac | are there instructions how to do that without gcc atomics? ... /me checks | 11:12 |
| dmart | I added some info on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto | 11:13 |
| dmart | Still a bit high-level, but better than nothing (hopefully) | 11:14 |
| lool | << On ARMv7, there is a DMB instruction which performs this operation. There is also an MCR p15, ... operation which is backwards-compatible the earlier architecture versions. >> | 11:14 |
| lool | Frankly, I much prefer getting the code to use atomic builtins in, even if only for arm/thumb in my case | 11:14 |
| dmart | If you use the atomics, you shouldn't need to use these low-level barriers. | 11:15 |
| dmart | ...which are obviously totally arch-specific and non-portable. | 11:15 |
| lool | I think it would help portability to use them by default, but apparently the ppc qemu maintainer prefers holding to comments from 2005 to judge of their usefulness | 11:15 |
| dmart | Did you understand why the qemu guys were resistant>? | 11:15 |
| lool | dmart: Yeah we're on the same line | 11:15 |
| lool | dmart: No; let me find the thred | 11:15 |
| lool | http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01142.html | 11:16 |
| dmart | Also, it's easier to write buggy atomics code than almost any other sort of code... so the KISS principle definitely applies ;) | 11:16 |
| lool | I checked with another qemu maintainer what he thought of it, and that's the person who suggested I should ask for benchmarks | 11:16 |
| lool | dmart: I'm also pretty sure the code is getting abused in the case of qemu | 11:17 |
| dmart | What are atomics used for in qemu anyway? | 11:17 |
| lool | Heck, I could have proposed a patch to use pthread mutxes, that would have been fun | 11:17 |
| lool | dmart: locks | 11:17 |
| lool | Which actually sucks | 11:17 |
| StevenK | ogra: That's a silly change, sigh | 11:17 |
| dmart | Does qemu use multithreading to emulate high-level processes, or something? | 11:18 |
| ogra | StevenK, yeah, agreed | 11:18 |
| lool | dmart: Hmm good question, it can emulate two CPUs though | 11:18 |
| lool | I suppose that's only possible with threading or multiple processes, but suspect they use something closer to threading to share memory | 11:18 |
| lool | (it actually uses multiple hosts CPUs when emulating multiple guests CPUs) | 11:19 |
| dmart | Right. Well, you can certainly implement fast spinlocks using exclusives and barriers if it's really needed, but that's probably in issue to worry about when the spinlocks are found to be a bottleneck? | 11:19 |
| lool | dmart: Interestingly, the gcc atomics doc recommends not to use them for spinlocks | 11:19 |
| dmart | Really, I missed that | 11:20 |
| asac | to not use what? the gcc built ins | 11:20 |
| * dmart looks | 11:20 | |
| asac | ? | 11:20 |
| lool | Hmm actually I can't find that reference any more | 11:20 |
| asac | ;) | 11:20 |
| dmart | Certainly you should use __sync_lock_* for spinlocks (and not the other funcs) | 11:20 |
| asac | lool: he seems to be fine to use those for thumb2 ... so whats the problem? | 11:21 |
| lool | dmart: Sorry, got confused by this comment http://sourceware.org/ml/libc-alpha/2005-06/msg00132.html | 11:21 |
| dmart | They (can) have reduced barriers which make them less of an overhead. | 11:21 |
| lool | dmart: ack, that's what I used | 11:22 |
| lool | dmart: There's no technical problem here, it's mostly politics | 11:22 |
| lool | the ppc maintainer didn't even say which part of the 2005 discussion he was referring to | 11:22 |
| asac | right. | 11:22 |
| asac | but do we care about ppc | 11:22 |
| lool | i.e. performance, should be in libc or whatever | 11:22 |
| asac | they seem to be fine if we submit that for arm | 11:22 |
| dmart | Not sure about the comment there--- certainly if you try to take a spinlock and find it's contended, then you can't just loop, because the kernel does not know to schedule the lock holder. | 11:22 |
| lool | asac: Yes, only choice I have for that bug | 11:22 |
| asac | i dont see that beging a problem | 11:23 |
| asac | if folks are happy with their current ppc solution etc. | 11:23 |
| dmart | You need to do a thread yield (and even that's inefficient--- the kernel still doesn't know what to schedule next) | 11:23 |
| asac | then let them keep that | 11:23 |
| dmart | If we can use the GCC atomics for arm as a first step, that's probably the best approach. They can be optimised later if this looks like a significant benefit. | 11:24 |
| dmart | This is certainly no worse than arch-specific implementations in general. | 11:24 |
| lool | I wonder whether they would accept a configure flag to use them | 11:25 |
| dmart | #ifdef __arm__ ? | 11:25 |
| lool | I was thinking #ifdef ppc, use_gcc_atomics=no | 11:26 |
| lool | :-) | 11:26 |
| lool | Anyway, it's politics; I will eventually sort it out with upstream | 11:26 |
| dmart | Maybe. The other arches might have a view on this though. | 11:26 |
| lool | there's no complexity here | 11:26 |
| dmart | ok | 11:26 |
| lool | I wanted to share the discussion with you because of the comments on gcc atomics | 11:26 |
| dmart | Sure, that's useful, thanks. | 11:26 |
| dmart | The main reason for emphasising the atomics is we want to quickly port to an implementation which works with v7 and Thumb-2, without everyone needing to understand the low-level details (which make my brain hurt a bit ;) ) | 11:27 |
| dmart | But anything can be optimised in the future | 11:28 |
| dmart | ... | 11:28 |
| dmart | asac, all: Should we review through the status of items on https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList ? | 11:29 |
| dmart | We should identify unfixed or blocked packages. | 11:29 |
| asac | yes | 11:29 |
| asac | so erlang | 11:29 |
| asac | is TODO | 11:30 |
| asac | and gmp still | 11:30 |
| asac | dyfet: ^^ | 11:30 |
| asac | we already discussed gmp last time, so we dont need to do that | 11:30 |
| asac | not sure if we want to go through ffmpeg | 11:30 |
| asac | maybe that would make sense | 11:31 |
| persia | erlang has code-generation. As does parrot. That might be an interesting set of topics. | 11:31 |
| asac | libmad is another candidate | 11:31 |
| dmart | ffmpeg has optimised assembler, but that was already dealt with | 11:31 |
| asac | ffmpeg is done? | 11:31 |
| asac | oh right | 11:31 |
| asac | its in the last column | 11:32 |
| dmart | It would be good to note on this page whenever something is resolved | 11:32 |
| asac | 12:10 < asac> i think it would be time to add a column for the current status there | 11:32 |
| asac | 12:10 < asac> or move all the fixed/invalid bugs to a separate table | 11:32 |
| asac | so yes | 11:33 |
| dmart | Would it make sense to trawl quickly through the issues with bugs raised to classify them? | 11:33 |
| dmart | I can add a resolved column | 11:33 |
| asac | yes | 11:33 |
| asac | ok i can cancel my edit | 11:33 |
| dmart | Oh, ok | 11:33 |
| asac | either you say which packages are still not resolved | 11:33 |
| asac | or the other way around ;) | 11:33 |
| dmart | Shall we work through? Probably won't take long. | 11:33 |
| asac | ok boost* | 11:34 |
| asac | is done | 11:34 |
| * asac updates the wiki if thats ok | 11:34 | |
| dmart | ok, if you want | 11:34 |
| asac | cacao-source? | 11:34 |
| asac | thats still open | 11:34 |
| dmart | hang on | 11:34 |
| asac | bugwise | 11:34 |
| persia | cacao was recently removed in Debian. Do we need it? | 11:34 |
| dmart | boost1.38 is not resolved, what happened to that? | 11:34 |
| persia | Should have been dropped from the archive. | 11:35 |
| dmart | Also, the boost1.41 source package was not changed (or this isn't documented in the bug) | 11:35 |
| asac | dmart: its not in the archive anymore | 11:35 |
| asac | https://edge.launchpad.net/ubuntu/+source/boost1.41/+changelog | 11:35 |
| asac | boost is fixed | 11:35 |
| asac | except 1.38 ... but thats not in the archive anymore (too old) | 11:36 |
| dyfet | 38 was dropped, 40/41 was patched | 11:36 |
| dmart | Ah, ok, I didn't scroll far enough up the bug. | 11:36 |
| dmart | asac, can you note those? | 11:36 |
| asac | yes | 11:36 |
| asac | already done ;) | 11:36 |
| dmart | ok, thanks! | 11:37 |
| === DavidBz is now known as berco | ||
| asac | djvulibre | 11:37 |
| asac | -> done (we checked that last week and evven added a safety belt) | 11:37 |
| asac | erlang | 11:37 |
| asac | -> not done | 11:37 |
| asac | evolution-data-server -> done | 11:37 |
| asac | ffmpeg resolved | 11:38 |
| asac | gcc-4.4 -> was never considered an issue, e.g. is probably right ( | 11:39 |
| dmart | gcc-4.4 is under continuous maintenance, so we can mark that an not needing specific action here. | 11:39 |
| asac | ack | 11:39 |
| asac | glib2.0 -> done (atomics by dmart ;)) | 11:39 |
| dmart | hmmm, I remember now | 11:39 |
| asac | gmp -> not yet done ... discussed last time; dyfet is on it and i was told he bumped prioritiy now | 11:40 |
| dyfet | there is an upstream issue with configure tests... | 11:40 |
| asac | for glib? | 11:40 |
| dyfet | gmp | 11:40 |
| asac | ah | 11:40 |
| dmart | politics or technical? ;) | 11:40 |
| dyfet | yeah... | 11:41 |
| dyfet | they want never to do try_compile tests, and use the tripplet to identify archs only... | 11:41 |
| asac | they are dumb ;) | 11:41 |
| dyfet | of course armv7/thumb2 is still "arm" as far as target arch's go... | 11:41 |
| asac | try_compile isnt that bad | 11:41 |
| asac | try_run is bad | 11:41 |
| dmart | Hmmm, that only works on x86 where the triplet identifes the arch version... | 11:41 |
| dyfet | a bit like lool's issue in qemu ;) | 11:41 |
| asac | i dont see that we can do it without try_compile, can we? | 11:42 |
| dmart | Just checking the GCC version number might be considered adequate. But try_compile felt more reliable... | 11:43 |
| asac | i agree with dmart | 11:43 |
| dyfet | me too | 11:43 |
| asac | dmart: what version number is lower bound? | 11:43 |
| asac | 4.1.0? | 11:43 |
| dmart | I'm assuming lucid GCC is the bound (i.e. 4.4.3) | 11:43 |
| dmart | This is not quite true, but it's a reasonable approximation | 11:44 |
| asac | hmm | 11:44 |
| asac | anyway. | 11:44 |
| asac | i think we can use try_compile and just patch it | 11:44 |
| asac | push it to debian | 11:44 |
| asac | and let democracy decide at some point | 11:44 |
| asac | most likely other distros will pick it up too and then upstream is alone ;) | 11:45 |
| dmart | (by "reasonable approximation" I mean "safe approximation") | 11:45 |
| dyfet | okay | 11:45 |
| dmart | You might also run nm on libgcc.a. But there's no guarantee the functions won't turn fully into builtins in the future... | 11:45 |
| asac | dyfet: lets just get the work done first and then care about politics | 11:46 |
| asac | also CC me on upstream discussion ;) | 11:46 |
| dyfet | well, we need to know in this case if we are thumb2 or not otherwise we break debian on armv4, etc... | 11:46 |
| dyfet | so try_compile seems the safest way by far | 11:46 |
| asac_ | right | 11:46 |
| asac_ | reconnect ;) | 11:46 |
| dmart | ok, so gmp is in progress | 11:47 |
| asac_ | dyfet: so you have the patch? | 11:47 |
| dyfet | I did not do a try_compile patch, but I can do so quickly after the sprint | 11:47 |
| asac_ | give it to me ... also forward me upstream discussion you had so far ... so i can poke them too ;) | 11:47 |
| asac_ | ok | 11:47 |
| asac_ | seems gmp will be fixed today | 11:47 |
| asac_ | i think the next two are all not-for-us (klibc, libgc) | 11:48 |
| asac_ | then we have libmad | 11:48 |
| asac_ | which isnt fixed | 11:48 |
| asac_ | and llvm | 11:49 |
| asac_ | both not fixed | 11:49 |
| dmart | Who is handling klibc? | 11:49 |
| asac_ | dmart: i thought it was toolchain/kernel folks | 11:49 |
| asac_ | actually i thought there are no real issues there. | 11:50 |
| * asac_ grabs the filtered files | 11:50 | |
| dmart | ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S: mov pc, lr | 11:51 |
| dmart | ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S: mov pc, lr | 11:51 |
| dmart | ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S: mov pc, lr | 11:51 |
| dmart | ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:1: mov pc, r3 | 11:51 |
| dmart | ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S: mov pc, lr | 11:51 |
| dmart | ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S: mov pc, lr | 11:51 |
| dmart | I'd need to look at the source package to see whether that matters. | 11:51 |
| asac | yeah | 11:52 |
| asac | i think it matters | 11:52 |
| dmart | Probably we should raise a bug on this one. | 11:53 |
| asac | we should use BX lr | 11:53 |
| asac | unless i am mistaken ;) | 11:53 |
| asac | dmart: right | 11:53 |
| dmart | Yes... though I also see #ifndef __thumb__ ... #ifdef __thumb__ ; I don't know which one is actually built | 11:54 |
| dmart | (in setjmp.S) | 11:54 |
| asac | hmm | 11:55 |
| asac | bug 527720 | 11:55 |
| ubot4 | Launchpad bug 527720 in klibc (Ubuntu) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527720 | 11:55 |
| asac_ | dmart: even for thumb it uses #else /* __thumb__ */ | 11:57 |
| asac_ | mov pc, lr | 11:57 |
| asac_ | line 78 | 11:57 |
| dmart | Yes, that's probably bad (actually, worse than using it in ARM) | 11:58 |
| asac_ | feels like its safe to use bx lr there | 11:58 |
| dmart | Probably yes. I'm wondering whether anyone builds this for Thumb-1 | 11:59 |
| dmart | duh | 11:59 |
| dmart | that doesn't matter, ignore me ;) | 11:59 |
| asac_ | mov pc, r3 | 11:59 |
| asac_ | thats just bx r3? | 11:59 |
| asac_ | dmart: ? | 11:59 |
| persia | Yes. | 12:00 |
| dmart | Providing r3 is derived from a return address | 12:00 |
| dmart | (I think that's the case here) | 12:00 |
| saeed | latest lucid-netbook-armel+dove doesn't aultomatically login, any idea which user&password should I use? | 12:00 |
| asac_ | ok let me do the patch then | 12:00 |
| lool | saeed: ubuntu no password | 12:00 |
| persia | dmart: Why wouldn't bx r3 work for an arbitrary branch address? | 12:00 |
| saeed | lool: thanks | 12:01 |
| dmart | persia: generally, yes. But if the address is detemined by some arithmetic or something the thumb bit (0) might not be set correctly | 12:01 |
| persia | Aha. Thanks for the explanation. | 12:02 |
| asac_ | http://launchpadlibrarian.net/39762158/klibc-thumb.patch | 12:02 |
| asac_ | attached to bug 527720 | 12:02 |
| ubot4 | Launchpad bug 527720 in klibc (Ubuntu Lucid) (and 1 other project) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [High,Triaged] https://launchpad.net/bugs/527720 | 12:03 |
| dmart | We still need to check this code isn't built with -marm | 12:03 |
| * dmart greps for -marm | 12:04 | |
| dmart | not found, probably OK | 12:04 |
| dmart | ... | 12:04 |
| asac_ | dmart: the patch only touched ifdef __thumb__ | 12:04 |
| dmart | Ah, actually there is a problem | 12:04 |
| asac_ | so it should be safe even if we build with -marm ;) | 12:05 |
| asac_ | dmart: what problem ? | 12:05 |
| dmart | The assembler always defaults to ARM | 12:05 |
| asac_ | right | 12:05 |
| asac_ | so we build with arm here ;) | 12:05 |
| asac_ | but we could build with __thumb__ now | 12:05 |
| asac_ | using this fix | 12:06 |
| dmart | This is preprocessed assembler, to __thumb__ will be defined (by the GCC defaults) | 12:06 |
| dmart | *so | 12:06 |
| dmart | So I think we're OK | 12:06 |
| dmart | Actually the functions will get assembled as Thumb because they both have the .thumb_func firective. | 12:06 |
| dmart | *directive | 12:06 |
| dmart | So this is probably fine. | 12:07 |
| asac | ok | 12:07 |
| asac | so ... i think we are set with this patch? | 12:07 |
| * asac thinks someone should try that out | 12:07 | |
| dmart | vfork.S needs patching too | 12:07 |
| asac | dmart: i patched that ;) | 12:08 |
| asac | check the patch | 12:08 |
| asac | 13:02 < asac_> http://launchpadlibrarian.net/39762158/klibc-thumb.patch | 12:08 |
| asac | oh | 12:08 |
| asac | i even failed ;) | 12:08 |
| dmart | -er- I mean setjmp.S needs patching | 12:09 |
| asac | yes | 12:09 |
| asac | i just failed to produce a patch ;) | 12:10 |
| asac | new patch attached | 12:10 |
| asac | http://launchpadlibrarian.net/39762270/klibc-thumb.patch | 12:10 |
| dmart | Yes I think that looks OK. | 12:10 |
| persia | Um, not all the changes in vfork.S from the first patch appear in the second patch. | 12:11 |
| asac_ | persia: ? | 12:11 |
| dmart | I think the second half of the first patch is a headerless non-unified diff of setjmp.S (or something) | 12:11 |
| asac_ | persia: forget the first patch ... not sure why it was busted | 12:11 |
| asac_ | right ... what dmart said | 12:11 |
| asac_ | i am sure i had >> for the second part | 12:12 |
| asac_ | but apparently i missed -u | 12:12 |
| * dmart is just making it up really | 12:12 | |
| persia | Ah. | 12:12 |
| persia | Yes, that does look right (if confusing) | 12:12 |
| asac_ | so lets continue (i marked it as "has patch" in table | 12:13 |
| asac_ | libgc is next | 12:13 |
| asac_ | that one is doko business | 12:13 |
| asac_ | doko: fixed in 6.8-1.2ubuntu1 | 12:13 |
| asac_ | so now to libmad | 12:14 |
| asac_ | what are the hits? | 12:14 |
| * asac_ checks filtered files | 12:14 | |
| dmart | Looks like an attempt to address an inline data or jump table -- should be a simple fix | 12:15 |
| dmart | ./libmad-0.15.1b/imdct_l_arm.S: add r2, pc, #(imdct36_long_karray-.-8) | 12:15 |
| * asac_ looks at porting page | 12:15 | |
| asac_ | so just adr r2, pc ? | 12:16 |
| asac_ | hmm | 12:16 |
| asac_ | nope | 12:16 |
| asac_ | adr r2, imdct36_long_karray-.-8 | 12:16 |
| asac_ | err | 12:16 |
| asac_ | adr r2, imdct36_long_karray | 12:16 |
| dmart | The trouble is that the pc is a bit unpredictable depending on the code alignment | 12:16 |
| persia | And this is likely to be an alignment issue, right? | 12:17 |
| dmart | Search the porting page for "getting the address of local data in the text section" | 12:17 |
| asac_ | right | 12:17 |
| asac_ | i think we already discussed that last week ... and i remembered that adr is the right way ;) | 12:17 |
| dmart | Looking at it though, I don't know what the data is doing in .text | 12:18 |
| dmart | Maybe it would be better to push it into .rodata | 12:18 |
| dmart | (it's not code) | 12:18 |
| asac_ | #define K14 0x0cb19346 | 12:19 |
| asac_ | if thats used it means we have preprocessed assembler? | 12:19 |
| asac_ | e.g. we can use #ifdef __thumb__ ? | 12:19 |
| dmart | This is really a cleanup change, so we probably don't even need that: we just want to switch from a less portable to a more portable way of addressing the data. | 12:20 |
| asac_ | are we sure the data isnt modified? | 12:21 |
| dmart | I don't think it will be. It's in .text which is not usually made writable | 12:21 |
| dmart | My guess is this is a table of precomputed data to speed up the imdct calculation. | 12:22 |
| asac_ | right | 12:22 |
| dmart | The simplest option is to leave it where it is and use adr to address it. | 12:22 |
| asac_ | heh ;) | 12:23 |
| asac_ | would be interested in how to do it with rodata though too | 12:23 |
| asac_ | anyway let me do the patch ... one moment | 12:23 |
| asac_ | oh .. adr is #ifdef __thumb__ or > armv4t ? | 12:24 |
| asac_ | dmart: ? | 12:24 |
| dmart | I suggest no #ifdef. adr really is the same instruction (just via a pseudo op which makes sure it's really correct) | 12:24 |
| dmart | Oh, hang on a minute... this code is built as ARM (as default behaviour again) | 12:25 |
| dmart | I suggest to do the adr patch anyway; it's cleaner | 12:25 |
| asac_ | yeah | 12:26 |
| dmart | Or if you want we could try building it in Thumb with | 12:26 |
| asac_ | ok | 12:26 |
| asac_ | one sec | 12:26 |
| dmart | #ifdef __thumb__ | 12:26 |
| dmart | .code 16 | 12:26 |
| dmart | #endif | 12:26 |
| asac_ | .code 16? | 12:26 |
| dmart | (Or .thumb, it's a synonym) | 12:26 |
| asac_ | ah | 12:26 |
| asac_ | let me first do the adr patch | 12:26 |
| asac_ | dmart: adr exists since a certain gcc/assembler version or what? | 12:27 |
| dmart | I'll work on the other, since I did not explain myself well... | 12:27 |
| asac_ | http://pastebin.com/M6V3aqiW | 12:27 |
| asac_ | that would be the libmad adr patch | 12:27 |
| asac_ | ;) | 12:27 |
| asac_ | let me attach that to the bug unless you shout | 12:28 |
| dmart | asac_: I think adr has been there for a long time; unless someone is using really ancient tools it should work | 12:28 |
| asac_ | yeah | 12:28 |
| asac_ | cool | 12:29 |
| asac_ | ok attached | 12:29 |
| asac_ | next is llvm | 12:30 |
| * asac_ goes and greps | 12:30 | |
| asac_ | hmm. that seems to be more extensive ;) | 12:30 |
| dmart | There is an ongoing bug thread conversation for this one. Basically, the jumping in/out of JITted is not interworking aware. | 12:30 |
| asac_ | http://paste.ubuntu.com/383646/ | 12:30 |
| asac_ | :/ | 12:31 |
| asac_ | ok ... so is on the poirting page what to do for this kind of jump in/out from arm to thumb and vv. | 12:31 |
| asac_ | ? | 12:31 |
| dmart | I think so; I pointed Xerxes Rånby at this, but I haven't had feedback yet. | 12:32 |
| dmart | Probably modifications are only needed in a few places, but it will take someone familiar with llvm to know where | 12:32 |
| asac_ | hmm | 12:33 |
| dmart | Probably best to label this as under discussion for now. | 12:34 |
| dmart | Do we know the priority of llvm? Does much depend on it? | 12:34 |
| asac_ | so | 12:35 |
| asac_ | needs investigation; potential code gen; doko: only used in openjdk-6-jre-zero when using shark | 12:35 |
| asac_ | thats the comment | 12:35 |
| asac_ | doko seems to think its ok | 12:35 |
| asac_ | oh | 12:35 |
| asac_ | well not sure if one can interpret that out of the comment | 12:35 |
| dmart | I think it's not used for openjdk-6 by default (some separate, Thumb EE based JIT is now contributed) | 12:36 |
| dmart | ...in openjdk-6 | 12:36 |
| asac_ | according to our table llvm has zero rdepends | 12:36 |
| asac_ | (priority) | 12:36 |
| asac_ | i think we can move on and come back to llvm later | 12:38 |
| asac_ | mono ... i have the cherry pick staged on my disk | 12:38 |
| asac_ | the one we discussed the other day ... besides that we found to be fine? | 12:39 |
| asac_ | or still "needs more investigation" ? | 12:39 |
| dmart | I can't remember the discussion now... was there interworking stuff to fix (in addition to the atomics)? | 12:41 |
| asac | dmart: we had discussion in #mono ... with vargez ... from what i recall we found one more patch | 12:42 |
| asac | but besides from that the outcome was that it should be ok wrt to interworking | 12:42 |
| dmart | oh yeah, I'd forgotten that was about the same topic... yes I agree | 12:42 |
| asac | i have that patch locally ... waiting for a3 freeze to be lifted | 12:42 |
| asac | that hd isnt wired up, so i can show it right now | 12:43 |
| dmart | OK, I'm happy to wait :) | 12:45 |
| dmart | Next package? | 12:45 |
| asac_ | 15:43 < dmart> <vargaz>Ihttp://lists.ximian.com/pipermail/mono-patches/2010-February/166945.html | 12:46 |
| asac_ | thats the patch ;) | 12:46 |
| asac_ | yes | 12:46 |
| asac_ | bug 514232 | 12:46 |
| ubot4 | Launchpad bug 514232 in newlib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514232 | 12:46 |
| asac_ | " investigate if its used - affected code is on places like crt0.S where it may not be a problem (dmart)" | 12:46 |
| * asac_ apt-get source newlib | 12:47 | |
| asac_ | dmart: why do you think its not used? | 12:48 |
| asac_ | oh | 12:48 |
| asac_ | seems that it uses ifdef _-thumb__ | 12:48 |
| asac_ | like: | 12:48 |
| asac_ | #if defined(__thumb__) || defined(__thumb2__) blx r3 | 12:48 |
| asac_ | #else mov lr, pc mov pc, r3 | 12:48 |
| asac_ | #endif | 12:48 |
| asac_ | .LC24: | 12:48 |
| asac_ | in ./libgloss/arm/crt0.S for example | 12:48 |
| asac_ | so ./libgloss/arm/crt0.S definitly is fine ... checked all uses of mov | 12:48 |
| dmart | Yes, this package generally looks like Thumb-2 was thought about by someone. | 12:49 |
| asac_ | then we have ./libgloss/arm/redboot-crt0.S: ... which probably is marm | 12:49 |
| asac_ | but even that has thumb ifdefs | 12:49 |
| asac_ | so ... cool. lets scratch it | 12:49 |
| * asac_ marks it invalid and drops comment in bug | 12:49 | |
| dmart | OK | 12:50 |
| asac_ | next is ocaml | 12:50 |
| asac_ | bug 514235 | 12:50 |
| ubot4 | Launchpad bug 514235 in ocaml (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] https://launchpad.net/bugs/514235 | 12:50 |
| asac_ | i marked that as invalid already | 12:50 |
| asac_ | so the assembly isnt used it seems | 12:51 |
| asac_ | i think i checkd build system and also even added bogus code to the asembly that would trigger a build failure ... to no result | 12:51 |
| dmart | ok | 12:51 |
| ogra | did you note that a full new ocaml eneterd from debian yesterday ? | 12:51 |
| ogra | *entered | 12:51 |
| asac_ | ogra: new upstream? | 12:51 |
| ogra | bug #526073 | 12:52 |
| * ogra checks | 12:52 | |
| ubot4 | Launchpad bug 526073 in xstr (Ubuntu) (and 51 other projects) "[OCaml 3.11.2 transition][round 3/6] Please rebuild packages involved in OCaml transition (universe) (affects: 1)" [Undecided,Fix released] https://launchpad.net/bugs/526073 | 12:52 |
| asac_ | they do a transition during freeze? | 12:52 |
| asac_ | thtas annoying | 12:52 |
| ogra | ah | 12:53 |
| ogra | its the same ocaml | 12:53 |
| asac_ | ok ;) | 12:53 |
| ogra | just the depending packages | 12:53 |
| persia | Please check with sgnb about that. | 12:53 |
| ogra | sorry for the noise :) | 12:53 |
| persia | It's on hold right now. james_w is expecting to do the next round of syncs once the freeze lifts. | 12:53 |
| asac_ | ocaml-3.11.2$ find | xargs grep arm.S | 12:53 |
| asac_ | ./asmrun/arm.S:/* $Id: arm.S 8823 2008-02-29 14:21:22Z doligez $ */ | 12:53 |
| asac_ | so there is no match for that arm.S file that has the code | 12:54 |
| asac_ | not sure if i am missing something | 12:54 |
| ogra | oh, wait, i'm wrong | 12:54 |
| ogra | a new ocaml came in of feb 15th | 12:54 |
| ogra | silly version numbers | 12:54 |
| persia | And the transition is in process, and the transition team is working to make sure it builds on armel. | 12:54 |
| asac_ | dmart: do you see any way that arm.S could be used in that project? | 12:54 |
| ogra | 3.11.1-2 to 3.11.2-1 | 12:54 |
| asac_ | persia: they do thumb2 porting ;)? i doubt that | 12:55 |
| asac_ | most stuff doesnt fail to build | 12:55 |
| ogra | well, i think the new ocaml at least deserves a new grep run on the new package | 12:55 |
| asac_ | i did now | 12:56 |
| persia | asac_: They are testing against qemu-arm-static and lool's qemu, so they should notice breakage as well. | 12:56 |
| asac_ | also i did the last run last week | 12:56 |
| dmart | I guess so. Probably there has been no change relevant to us... | 12:56 |
| ogra | i think its unlikely something changed but you never know | 12:56 |
| asac_ | the grep above is from the current lucid | 12:56 |
| asac_ | 13:53 < asac_> ocaml-3.11.2$ find | xargs grep arm.S | 12:56 |
| asac_ | 13:53 < asac_> ./asmrun/arm.S:/* $Id: arm.S 8823 2008-02-29 14:21:22Z doligez $ */ | 12:56 |
| asac_ | ok ... moving on. | 12:56 |
| asac_ | openssl | 12:56 |
| asac_ | we didnt create a bug for that because: | 12:56 |
| asac_ | "seems ok - only armv4 files affected - verify that those are not used for modern arm " | 12:56 |
| asac_ | so we should double check that now to scratch it forever | 12:57 |
| * asac_ apt-get source openssl | 12:57 | |
| === hrw|gone is now known as hrw | ||
| asac_ | we have a .pl file with assembly :) ... | 12:57 |
| asac_ | ./openssl-0.9.8k/crypto/aes/asm/aes-armv4.pl:movpc,lr@ return | 12:58 |
| asac_ | i think that file is used | 12:58 |
| asac_ | there is no other arm file in aes/asm | 12:59 |
| * asac_ looks at build log | 12:59 | |
| asac_ | https://edge.launchpad.net/ubuntu/+source/openssl/0.9.8k-7ubuntu6/+build/1492868 | 12:59 |
| asac_ | http://launchpadlibrarian.net/38924017/buildlog_ubuntu-lucid-armel.openssl_0.9.8k-7ubuntu6_FULLYBUILT.txt.gz | 12:59 |
| asac_ | hmm ... dont see that armv4 is used somewhere | 13:00 |
| asac_ | http://paste.ubuntu.com/383659/ | 13:00 |
| asac_ | thats the grep | 13:00 |
| asac_ | any idea how those .pl files are used in that build system? | 13:01 |
| asac_ | next one would be pixman | 13:04 |
| asac_ | bug 514237 | 13:04 |
| ubot4 | Launchpad bug 514237 in pixman (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] https://launchpad.net/bugs/514237 | 13:04 |
| asac_ | seems i marked it as invalid | 13:04 |
| asac_ | "Checked this. Its a false positive. the mov isn't used in combination with pc etc. ... the only use of it is in a ifdef _MSC_VER block ... e.g. windows only." | 13:05 |
| asac_ | so its a MS thing | 13:05 |
| asac_ | dmart: ^^ | 13:05 |
| asac_ | ? | 13:05 |
| dmart | I think so; pixman is actively developed against Thumb-2 anyway I think. | 13:05 |
| asac_ | postgresql-8.4 -> is fixed in bzr or even uploaded in archive already | 13:06 |
| asac_ | was just atomics | 13:06 |
| asac_ | qemu-kvm -> not sure ... bug 514252 | 13:06 |
| ubot4 | Launchpad bug 514252 in qemu-kvm (Ubuntu) "[arm] (might) need porting to thumb2 (affects: 1)" [Low,In progress] https://launchpad.net/bugs/514252 | 13:06 |
| asac_ | lool: ? | 13:06 |
| ogra | i think lool is on that ? | 13:06 |
| asac_ | did you do the swp atomics? | 13:06 |
| asac_ | or do you need help? or is this the issue we talked about above? | 13:07 |
| asac_ | ok seems it has a patch | 13:07 |
| asac_ | http://launchpadlibrarian.net/39067738/0001-Detect-and-use-GCC-atomic-builtins-for-locking.patch | 13:07 |
| asac_ | lool: planning to upload that? | 13:07 |
| dmart | ^^ For openssl, some nasty hacks are used to enable compatibility with interworking, but the hacks look like they should work | 13:07 |
| asac_ | dmart: do you understand the .pl files and how they are used? | 13:08 |
| asac_ | lool: qemu-kvm just uses atomics for resetlock and testandset ? | 13:08 |
| asac_ | or is the patch just a first revision? | 13:09 |
| persia | The .pl files for openssl are neither used in the build system nor installed int he package, and there seems to be a sufficiently comprehensive test suite that we'd notice an issue. | 13:10 |
| asac_ | persia: we wont notice mov.*pc style things unless we are using smp afaiu | 13:10 |
| asac_ | we could add some bogus syntax stuff and see if it causes some failure | 13:11 |
| persia | Ugh, so we'd have to run the test suite on SMP to know if it's an issue? | 13:11 |
| asac_ | no ... we have to read the code ;) | 13:11 |
| asac_ | and find out if its run | 13:11 |
| asac_ | if its run its an issue ... if not, its not | 13:11 |
| dmart | The mov pc issues will show up independently of SMP | 13:12 |
| asac_ | dmart: how will it show up? | 13:12 |
| dmart | crashes | 13:12 |
| dmart | The issue for SMP is the atomics | 13:12 |
| asac_ | hmm ok | 13:12 |
| persia | Then I'm *really* confident that openssl is just fine. | 13:12 |
| asac_ | isnt openssl testsuite run during build? | 13:12 |
| persia | That's a massive test suite. | 13:12 |
| asac_ | yeah | 13:12 |
| asac_ | so its not run? /me would think security would be damn hard about having that enabled | 13:13 |
| dmart | openssl looks OK to me (if a bit nasty) | 13:13 |
| asac_ | dmart: where do you see the nasty bits? (just for education) | 13:13 |
| persia | asac_: It is run during build, and it succeeded in http://launchpadlibrarian.net/38924017/buildlog_ubuntu-lucid-armel.openssl_0.9.8k-7ubuntu6_FULLYBUILT.txt.gz for all four runs. | 13:13 |
| asac_ | like you said there was interworking ... where do you spot that? | 13:13 |
| asac_ | persia: nice | 13:13 |
| asac_ | so yeah. openssl is off our list then | 13:13 |
| asac_ | postgres is covered, qemu-kvm seems to be in progress (lets wait for lool) | 13:14 |
| asac_ | next would be qt4-x11 | 13:14 |
| asac_ | is commented to have a webkit copy | 13:14 |
| asac_ | webkit is invalid i found: bug 490371 | 13:14 |
| ubot4 | Launchpad bug 490371 in qt4-x11 (Ubuntu) "Atomic operations not safe for ARMv7,Thumb-2 and multicore (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/490371 | 13:14 |
| asac_ | bug 514255 | 13:14 |
| ubot4 | Launchpad bug 514255 in webkit (Ubuntu) "[arm] needs porting to thumb2 (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/514255 | 13:14 |
| asac_ | ok so webkit part is invalid (we can check that when we come to webkit) | 13:14 |
| asac_ | and qt4-x11 needs atomics | 13:14 |
| asac_ | though odd that it builds | 13:15 |
| asac_ | NCommander: qt4-x11 builds? | 13:15 |
| asac_ | NCommander: e.g. is bug 490371 a none issue? | 13:15 |
| asac_ | "In debian/rules Set DEB_HOST_ARCH and DEB_HOST_ARCH_OS. Configure with "-arch armv6" option on ARM" | 13:16 |
| asac_ | seems its built using armv6? | 13:16 |
| * asac_ waits for qt4-x11 sources to arrive | 13:16 | |
| ogra | i think there was a bug cjwatson worked on | 13:16 |
| ogra | which he could only solve by switching to v6 | 13:16 |
| asac_ | from v5? | 13:17 |
| asac_ | or v7? | 13:17 |
| ogra | from using the default (v7) | 13:17 |
| dmart | I think this uses LDREX/STREX, if building for ARMv6. Originally the build system did not recognise ARMv7 and fell back to the older SWP code causing ftbfs | 13:17 |
| dmart | This was since bodged to lie to the build system about the architecture version so the v6 code is used, IIRC | 13:18 |
| asac_ | oh | 13:18 |
| asac_ | right | 13:18 |
| asac_ | so we might want to fix the build system | 13:18 |
| asac_ | or leave it as it is | 13:18 |
| asac_ | NCommander: can you fix the buildsystem of qt4-x11 to understand v7? | 13:18 |
| NCommander | asac_: its on my TODO behind OOo | 13:19 |
| asac_ | NCommander: arent you idle all the time witing for ooo to build? | 13:19 |
| NCommander | asac_: no, because i don't do full builds | 13:19 |
| asac_ | NCommander: also i think that ooo is not higher priority than thumb2 ... its same priority | 13:19 |
| * NCommander just rebuilds the libraries I need, and wait at most 30 minutes for a full rebuild | 13:19 | |
| ogra | qt4-x11 (4:4.6.0-1ubuntu2) lucid; urgency=low | 13:19 |
| ogra | * Make libqt4-dev depend on libx11-dev | 13:19 |
| ogra | * In debian/rules Set DEB_HOST_ARCH and DEB_HOST_ARCH_OS. Configure with "-arch armv6" option on ARM | 13:19 |
| ogra | -- Jonathan Riddell < jriddell@ubuntu.com> Tue, 08 Dec 2009 13:30:39 +0000 | 13:19 |
| ogra | there we go | 13:19 |
| NCommander | asac_: I was informed otherwise by davidm | 13:19 |
| asac_ | NCommander: but you wait 30 minutes ;) | 13:20 |
| dmart | asac_, NCommander: we should probably note down qt4-x11 for a SMP safety review | 13:20 |
| asac_ | you can surely work on something ;) | 13:20 |
| asac_ | anywway | 13:20 |
| asac_ | dmart: wouldnt that show up in our greps? | 13:20 |
| * ogra goes to look for Riddell | 13:20 | |
| NCommander | dmart: if you have a few minutes, can you help me grok the C++ ABI? | 13:21 |
| * NCommander has found where OOo blows up | 13:21 | |
| asac_ | ok i have a call in 10 ... so i think we are over | 13:21 |
| asac_ | we are down to four packages or so | 13:21 |
| dmart | Not really - this is about whether barriers are used correctly. It's mainly an issue for packages which have their own hand-crafted atomics using the ARMv6+ primitives (LDREX/STREX) where SMP may not have been fully tested | 13:21 |
| asac_ | out of which most are fixed | 13:21 |
| asac_ | dmart: oh ok | 13:21 |
| asac_ | so anything using ldrex etc. is subject to review | 13:22 |
| dmart | Ideally | 13:22 |
| asac_ | but afaik we grepped for ldrex | 13:22 |
| dmart | Oh, yes. | 13:22 |
| dmart | I mean grep can't tell us if it's wrong; but it does identify what's worth looking at. | 13:22 |
| asac_ | bug 451553 | 13:23 |
| ubot4 | Launchpad bug 451553 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "Lots of errors during install on dove (affects: 2) (dups: 1)" [Medium,Confirmed] https://launchpad.net/bugs/451553 | 13:23 |
| asac_ | dmart: right. thats what i meant | 13:23 |
| dmart | I forgot we grepped for that too | 13:23 |
| dmart | ok, I guess we are pretty much done | 13:24 |
| dmart | Unless people have questions | 13:24 |
| asac_ | the rest is: thunderbird -> fixed | 13:25 |
| asac_ | upx-ucl -> i think in invalidated that | 13:25 |
| asac_ | bug 514254 | 13:25 |
| ubot4 | Launchpad bug 514254 in upx-ucl (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514254 | 13:25 |
| asac_ | oh no ;) | 13:25 |
| asac_ | but webkit: | 13:25 |
| asac_ | bug 514255 | 13:25 |
| ubot4 | Launchpad bug 514255 in webkit (Ubuntu) "[arm] needs porting to thumb2 (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/514255 | 13:25 |
| asac_ | bug 514257 | 13:25 |
| ubot4 | Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514257 | 13:25 |
| asac_ | so upx-ucl and xine-lib are still todo for main/important | 13:26 |
| asac_ | and the qt4-x11 smp review | 13:26 |
| asac_ | wiki page should be more or less up-to-date | 13:26 |
| asac_ | ok me prepares for a call ;) | 13:26 |
| dmart | OK, thanks | 13:26 |
| NCommander | dmart: if your around in about an hour, I need to pick your brain on unwind tables, and the fun of ARM C++ exception handling :-) | 13:26 |
| asac_ | thanks dmart for your time again | 13:27 |
| ogra | <ogra> Riddell, in qt4-x11 4:4.6.0-1ubuntu2 you set -arch armv6, do you remember the reason for that ? | 13:27 |
| ogra | <Riddell> I did? | 13:27 |
| ogra | <Riddell> where? | 13:27 |
| asac_ | and everyone else ;) | 13:27 |
| ogra | <cjwatson> ogra: I do, it was because there was a specific armv6 implementation of some bits | 13:27 |
| ogra | * sabdfl hat die Verbindung getrennt (Read error: No route to host) | 13:27 |
| ogra | <cjwatson> the default was arm, and wasn't good for armv7 | 13:27 |
| ogra | * sabdfl (~sabdfl@ubuntu/member/sabdfl) hat #ubuntu-devel betreten | 13:27 |
| asac_ | bug 509006 | 13:27 |
| dmart | NCommander: Not something I know too much about, but I'll see if I can draft in someone else | 13:27 |
| ogra | <ogra> do you remember if it was assembler ? | 13:27 |
| ubot4 | Launchpad bug 509006 in linux-mvl-dove (Ubuntu) "[dove] hibernation failed to resume (affects: 1)" [High,Confirmed] https://launchpad.net/bugs/509006 | 13:27 |
| ogra | <cjwatson> the armv6 code doesn't handle multicore, but is otherwise much better than what was there before | 13:27 |
| ogra | <cjwatson> yes | 13:27 |
| armin76 | spam | 13:27 |
| asac_ | ogra: ... cant you paste tsuch huge pastes in pastebin? | 13:28 |
| NCommander | dmart: that would be useful | 13:28 |
| asac_ | bug 509006 | 13:28 |
| asac_ | bug 451635 | 13:28 |
| ogra | asac_, ah, come on ... 10 lines ... | 13:28 |
| ubot4 | Launchpad bug 451635 in alsa-driver (Ubuntu Karmic) (and 1 other project) "Sound not working on dove Y1 board (affects: 1)" [Medium,New] https://launchpad.net/bugs/451635 | 13:28 |
| asac_ | bug 452156 | 13:28 |
| ubot4 | Launchpad bug 452156 in linux-mvl-dove (Ubuntu) (and 1 other project) ""Write-error on swap-device" while installing Ubuntu (affects: 1)" [Undecided,New] https://launchpad.net/bugs/452156 | 13:28 |
| ogra | but yes, i'll do in the future | 13:28 |
| asac_ | bug 451553 | 13:28 |
| ubot4 | Launchpad bug 451553 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "Lots of errors during install on dove (affects: 2) (dups: 1)" [Medium,Confirmed] https://launchpad.net/bugs/451553 | 13:28 |
| asac_ | bug 527148 | 13:28 |
| ubot4 | Launchpad bug 527148 in linux-mvl-dove (Ubuntu) "dove fails to shutdown (affects: 2)" [Undecided,New] https://launchpad.net/bugs/527148 | 13:28 |
| asac_ | ok that were my 10 ;) | 13:28 |
| dmart | ogra: OK, I guess if "the armv6 code doesn't handle multicore" it needs looking at, so definitely add this to the SMP safety review table. | 13:31 |
| ogra | yeah | 13:31 |
| dmart | Thanks for checking | 13:33 |
| ogra | added | 13:35 |
| ogra | (if the wiki ever saves) | 13:36 |
| * dmart wonders why the wiki is so slow | 13:36 | |
| lool | asac_: I think the gcc atomics patch is uploaded already?? | 13:39 |
| lool | It still FTBFS but not due to thumb/asm | 13:39 |
| lool | dmart: Suggestions on how to fix the failure are actually welcome | 13:39 |
| lool | It's float comparisons and gcc logic | 13:40 |
| dmart | lool: which package is this? | 13:40 |
| lool | dmart: /build/buildd/qemu-kvm-0.12.2/fpu/softfloat-native.c:373: error: impossible constraint in 'asm' | 13:40 |
| lool | dmart: qemu-kvm | 13:40 |
| lool | Oh | 13:41 |
| lool | it's actually not th eplace I thought it was | 13:41 |
| lool | I was looking at the wrong function the first time | 13:41 |
| lool | dmart: http://paste.ubuntu.com/383679/ | 13:42 |
| lool | dmart: probably if defined(__arm__) && !defined(__thumb__)? | 13:42 |
| lool | dmart: what's rndd/rnddm etc.? I grepped the ARM asm reference card and the VFP one for "RN" and couldn't find it | 13:57 |
| lool | Might be some gas syntax | 13:57 |
| dmart | Hmmm, yes, I was just looking at that | 13:57 |
| dmart | I think these opcodes (and the "f" asm constraint) are probably related to the obsolete FPA architecture (which is what the netwinder fp emulator code in the kernel emulated) | 13:58 |
| dmart | This code won't work on any Ubuntu armel release | 13:58 |
| lool | can't find it in http://sourceware.org/binutils/docs/as/ARM-Opcodes.html#ARM-Opcodes | 14:00 |
| lool | dmart: Oh, so an older FPU? | 14:00 |
| dmart | Yes. Well, an older FP architecture. I'm not sure whether there was ever much silicon implementing it... | 14:00 |
| dmart | You can probably make GCC accept the code with -mfpu=fpa or something, but unless this code is being built to run inside qemu (and qemu emulates the instructions) I can't see how it's going to work... | 14:01 |
| lool | dmart: Bah, I'm wasting our time | 14:01 |
| lool | the asm was dropped upstream | 14:01 |
| dmart | ah... good thing too :) | 14:02 |
| lool | float64 float64_round_to_int( float64 a STATUS_PARAM ) | 14:02 |
| lool | { return rint(a); | 14:02 |
| lool | } | 14:02 |
| lool | (can't they just errr call rint()? :-) | 14:02 |
| ogra | probably something uses float64_round_to_int in the code ? | 14:07 |
| ogra | and they were lazy | 14:07 |
| persia | Or maybe they use this to force a cast somehow? | 14:10 |
| lool | Nah I just think it's historical | 14:10 |
| lool | rint is C99 just like qemu | 14:10 |
| dmart | NCommander: looks like our tools guys aren't available this afternoon. Would 1500 UTC tomorrow be OK for you? I can try and grab someone for then. | 14:17 |
| NCommander | dmart: that would work | 14:18 |
| dmart | ramana: Hi | 14:20 |
| dmart | NCommander: Looks like someone is available after all | 14:20 |
| dmart | Ramana has been working with some of the Ubuntu guys (doko etc.) on the tools | 14:21 |
| NCommander | hey ramana! | 14:21 |
| ramana | hi NCommander | 14:27 |
| NCommander | ramana: how goes your morning | 14:27 |
| ramana | Ncommander: Not too bad.. it's now afternoon where I'm sitting ... It's not raining and that's a plus :) | 14:28 |
| ramana | how goes yours ? | 14:29 |
| NCommander | ramana: early morning conference calls | 14:29 |
| ramana | NCommander: sounds like fun | 14:31 |
| NCommander | ramana: I'm dealing with crashing on ARM with OOo with modern toolchains, which is being caused by a direct call to __cxa_throw | 14:33 |
| ramana | ok | 14:33 |
| NCommander | ramana: it begins to unwind the stack, and then blows up with a phase2 failure | 14:35 |
| NCommander | __cxa_throw calls std::terminate | 14:35 |
| NCommander | ramana: I know there were unwind table changes between jaunty->karmic (gcc 4.3 to 4.4/glibc to eglibc) | 14:36 |
| ramana | do you know for what frame unwind_phase2 is in ? | 14:38 |
| NCommander | ramana: not sure how to get that | 14:39 |
| NCommander | I'm guessing is marked CANTUNWIND that shouldn't, or the inverse | 14:40 |
| NCommander | ramana: the stack gets completely trashed so the debugger is of limited help | 14:40 |
| ramana | can you get a backtrace from the point before it hits the throw to see what the frames are ? | 14:43 |
| NCommander | ramana: I can try. OOo does some very very strange and evil things that make debugging it extremely difficult | 14:45 |
| ramana | NCommander: The last time I tried looking at this was in September and I was stymied by not knowing enough about OOo. | 14:46 |
| NCommander | ramana: I think I need to do an entire debug build of the entire stack | 14:46 |
| NCommander | ramana: thats a multiday love affar :-/ | 14:46 |
| ramana | yes that sounds prudent to have. | 14:48 |
| NCommander | ramana: unfortunately, since I don't have a small test case for this | 14:48 |
| ramana | NCommander : Is this the standard OOo in the lucid packages or is this in your PPA ? | 14:50 |
| NCommander | ramana: I'm working upstream; saner to build | 14:50 |
| ogra | the std oo.o in lucid uses a jaunty lib that works around that bug | 14:50 |
| ramana | ok | 14:50 |
| NCommander | (although sanity in this case is extremely relatively) | 14:51 |
| NCommander | *relative | 14:51 |
| ramana | NCommander: is there any place where I or dmart could have a look at your chroot or libraries ? We can try doing some disass on the libraries / binaries ? | 14:56 |
| NCommander | ramana: I'm just using standarding ubuntu jaunty, karmic, and lucid chroots | 14:56 |
| ramana | NCommander: and the OO build tree you might have ? | 14:56 |
| dmart | Presumably that's just apt-get source? | 14:57 |
| dmart | Or are you working on something not yet in the archive? | 14:57 |
| ramana | dmart: I think NCommander is working on upstream OOo | 14:57 |
| dmart | (the bug is old though...) | 14:57 |
| asac | NCommander: can you tell ramana how to build the package without the jaunty workaround so they can see the actual problem? | 15:04 |
| asac | ogra: you said doko made packages available for you | 15:04 |
| NCommander | asac_: that won't be useful without being able to debug it | 15:04 |
| asac | that have that issue ... did doko als opush source for that? | 15:04 |
| ogra | asac, yes, on jocote in his home | 15:04 |
| ogra | not sure about the source | 15:04 |
| NCommander | ramana: you can cause the issue by going into /usr/lib/ure/lib, and replacing libgcc3_uno.so with libgcc3_uno.so.karmic | 15:04 |
| asac | NCommander: well. they want a way to reproduce. if you have a better way, then just go for that | 15:04 |
| ogra | i always only got a bunch of .so's | 15:05 |
| asac | NCommander: reproduce from source that is | 15:05 |
| NCommander | asac_: you have to build OOo then from scratch | 15:05 |
| NCommander | http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux#ccache | 15:05 |
| lool | asac: IIRC, the two binaries (really built and from jaunty) are installed in the libdir | 15:05 |
| asac | NCommander: package sounds esaier ,) | 15:06 |
| asac | debuild -b | 15:06 |
| asac | wait | 15:06 |
| asac | wait | 15:06 |
| asac | ;) | 15:06 |
| lool | asac: So the current builds of oo.o ship the borken binary in a different path | 15:06 |
| NCommander | asac_: that won't work because it won't build OOo with debugging | 15:06 |
| asac | fine if you can reproduce with upstream instrcutions | 15:06 |
| * ogra kicks and punches qemu so it has dents and wrinkles | 16:12 | |
| ogra | i dont love you anymore you darn thing !!! | 16:12 |
| * ogra goes into a corner and sulks | 16:13 | |
| alecrim | i'm with some problem to bootup a minimal ubuntu image with N810. I freezes as you can see here http://pastebin.com/41gRjZuF | 17:29 |
| alecrim | s/I/it/g | 17:29 |
| Stskeeps | jaunty? | 17:30 |
| Stskeeps | out of curiousity, got serial console | 17:30 |
| Stskeeps | ? | 17:30 |
| Stskeeps | and you are possibly running into the watchdog | 17:30 |
| alecrim | Stskeeps, I generated rootfs using this procedure : sudo rootstock --fqdn n810 --login ubuntu --password ubuntu --imagesize 500M | 17:31 |
| Stskeeps | ok, so lucid? | 17:31 |
| alecrim | Stskeeps, karmic | 17:31 |
| Stskeeps | mmk | 17:32 |
| Stskeeps | and .33 is quite experimental there | 17:32 |
| alecrim | Stskeeps, maybe the boot finished, but it does not show the serial. Old versions of ubuntu contain a /etc/inittab that I could force a login by serial, but not this one. | 17:33 |
| Stskeeps | ah | 17:33 |
| alecrim | Stskeeps, any idea? | 17:33 |
| Stskeeps | check event.d? should be tty* | 17:33 |
| alecrim | Stskeeps, thanks! I'll check it. I'll try lucid version, instead of karmic next time. let me see if I can get console | 17:34 |
| Stskeeps | no, lucid is armv7 | 17:35 |
| Stskeeps | will not work on n810 | 17:35 |
| alecrim | Stskeeps, I didn't know :( | 17:37 |
| NCommander | ramana: I've tied three babbage boards and one dove board into the OOo build | 18:05 |
| NCommander | Which shoul dget drastically cut build times down | 18:06 |
| NCommander | ^- armin76 :-) | 18:06 |
| ramana | nice :) | 18:08 |
| NCommander | ramana: the issue is I'm still not sure I'm going to get a proper backtrace | 18:10 |
| NCommander | ramana: the UNO call pulls CXX exceptions across multiple threads/processors/evil | 18:10 |
| NCommander | So even having a proper backtrace before the throw might not help | 18:11 |
| NCommander | And I'm not sure stepping into the _Unwind_* will give me anything I'm going to be able ot grok | 18:11 |
| ramana | joy | 18:11 |
| NCommander | (although I'll prepare to do a debug build of libgcc) | 18:11 |
| NCommander | ramana: is there a good way to debug the _Unwind_* functions and friends? | 18:14 |
| alecrim | Stskeeps, it's working. http://paste.ubuntu.com/383843/ | 18:15 |
| alecrim | Stskeeps, actually /etc/init/ttyS2.conf is the correct place | 18:15 |
| Stskeeps | close enough | 18:15 |
| * DanaG wonders how much power it would take to get a mere Radeon 7500 sort of horsepower in an ARM. | 18:15 | |
| DanaG | Specifically, for the sake of compiz. | 18:15 |
| Stskeeps | alecrim: does your lcd work? | 18:16 |
| alecrim | Stskeeps, it's a basic image using linux-omap latest version(2.6.33). I got serial using a special HW from Nokia | 18:17 |
| Stskeeps | ah, good | 18:18 |
| * alecrim is a privileged person | 18:18 | |
| alecrim | hehe | 18:18 |
| Stskeeps | yeah, i have one too :P | 18:18 |
| ramana | NCommander: I've never personally done this but I can dig around. | 18:19 |
| NCommander | ramana: that would help. Google hasn't told me a lot of phase2 unwinder failures except they exist | 18:20 |
| alecrim | Stskeeps, I'm gonne work to get version 2.6.33 fully working like 2.6.29 version (http://franciscoalecrim.com/blog/2010/02/05/preparing-mamona-03-sync-with-openembedded-alpha/) | 18:20 |
| Stskeeps | cool :) even with wifi and dsp? | 18:21 |
| Stskeeps | i will bookmark | 18:22 |
| Stskeeps | 2.6.33 on n8x0 would be cool | 18:23 |
| Stskeeps | you saw the release of MBX 3d drivers too? | 18:23 |
| Stskeeps | gpl kernel driver | 18:23 |
| DanaG | MBX? | 18:24 |
| Stskeeps | omap2 3d accelerator | 18:24 |
| armin76 | NCommander: cheater | 18:26 |
| NCommander | hehe | 18:26 |
| Stskeeps | alecrim: you have git tree for kernel somewhere? | 18:26 |
| Stskeeps | for your patches | 18:26 |
| NCommander | armin76: there is somethng for being able to simply throw more hardware at a problem | 18:30 |
| DanaG | what I have is the beagleboard. | 18:32 |
| ssvb | alecrim: there is user luke-jr on #maemo and #gentoo-embedded channels and he tried to do something with the latest kernels on N810 too (at least he was the last to update http://elinux.org/N800 page) | 18:33 |
| * armin76 prefers to throw NCommander at the problem and keep the hardware | 18:35 | |
| alecrim | Stskeeps, linux-omap tree. I sent patches with corrections a few weeks ago. | 18:52 |
| Stskeeps | k | 18:53 |
| * NCommander sighs | 18:59 | |
| NCommander | trying to build OOo from source is like trying to drive in reverse on I-90 from Boston to Seattle | 18:59 |
| armin76 | thats how is it on arm :) | 19:01 |
| armin76 | you should be glad you don't have to work with a marvell orion and the like | 19:01 |
| Martyn | *ugh* | 19:29 |
| Martyn | No, building oOo is rally a pain in the ass | 19:29 |
| Martyn | I'm still trying to build various MPI applications and libraries for our platform | 19:30 |
| Martyn | and it's NOT fun | 19:30 |
| Martyn | Plus I still have no work from Pegatron how the heck I can restore the image on their i.mx51 whitebox ( similar to the genesi box ) | 19:30 |
| DanaG | Pegatron as in split-off-from-ASUS? | 19:32 |
| DanaG | Pegatron sounds like an el-cheapo brand... it's a bad choice of name, in my opinion. | 19:32 |
| ojn | Martyn: just boot from external SD card. $20 of hardware saves you how many hours of work? | 19:32 |
| Martyn | ojn : It's not booting | 19:32 |
| Martyn | ojn : And I have no debug cable so I can't change the configuration of the u-boot | 19:33 |
| ojn | Martyn: if you change the switches it'll load u-boot from SD | 19:33 |
| Martyn | ah! That's new info | 19:33 |
| Martyn | 0001? | 19:33 |
| ojn | Can't remember and I'm not in Austin this week | 19:33 |
| Martyn | no worries | 19:33 |
| ojn | My offer of borrowing the debug card also holds, but I guess it's more fun to fumble in the dark. :) | 19:33 |
| Martyn | I forgot you were in the same city as me :) | 19:35 |
| Martyn | When you're back, ping me | 19:35 |
| armin76 | ojn: it is! | 19:37 |
| NCommander | Martyn: well, at least I managed to isolate the crash | 19:44 |
| NCommander | Fixing it still going to be a real trick | 19:44 |
| NCommander | Martyn: try using ooo-build, I think it will make it easier | 19:44 |
| Chocobo | Do any of you know of a good tutorial for interworking ARM and THUMB code? For example... if I have a bunch of C code I want to compile in ARM and a small ASM routine I want in ASM... what I need for compile flags | 20:24 |
| lool | Chocobo: You can get the actual architecture reference manuals from arm.com, if you register and accept the license | 20:33 |
| ogra | lool, no go with rootstock :( ... installing an ubuntu-netbook task makes qemu hang in iso-codes ... just installing iso-codes works fine though | 21:01 |
| * ogra wasted the whole day on it and is out of ideas | 21:01 | |
| === fta_ is now known as fta | ||
| |nfecteD | qemu is whacky | 21:07 |
| |nfecteD | locked up here too when i gave it too much to chew on | 21:07 |
| ogra | it wasnt for the last two releases | 21:07 |
| |nfecteD | anyway... got it to build my rootfs when i removed lxde and gde from the seed | 21:09 |
| ogra | right, minimal isnt a problem | 21:09 |
| |nfecteD | mmhmm | 21:09 |
| |nfecteD | not that the damn thing wants to boot on my beagleboard | 21:09 |
| |nfecteD | init: plymouth main process (625) terminated with status 71 | 21:09 |
| |nfecteD | and such | 21:09 |
| |nfecteD | yay | 21:09 |
| |nfecteD | guess i'll try another kernel just for hell of it | 21:12 |
| asac | dyfet: hey | 23:02 |
| asac | dyfet: so you wanted to discuss mono ;)? | 23:02 |
| * persia notes that the easiest way to get a high-end GFX card on armel is to find hardware with PCIe slots. | 23:05 | |
| dyfet | yea, I see several different issues | 23:06 |
| * persia also notes that "Pegatron is a cheap brand" is somewhat tricky to parse, as Pegatron is one of only 5-6 companies that build 96% of laptops shipped worldwide and not the one with the least market share | 23:06 | |
| asac | dyfet: so lets talk ;) | 23:15 |
| asac | dyfet: where would you start? i thought looking at the failed test cases and then understanding why the fail might be a good way to start | 23:16 |
| dyfet | I was not aware of the status of that. But I am also concerned what does it currently block building | 23:17 |
| asac | dyfet: i dont think it blocks anything from building | 23:17 |
| asac | only problem is that the runtime behaviour is borked | 23:17 |
| asac | which makes good chunk of the archive unreliable to use ... which is bad ;) | 23:17 |
| asac | luckily mono hasn't spread out that muc in the archive, but still there are apps we would like to have working ;) | 23:17 |
| dyfet | out of curiosity, have the test cases also failed in qemu arm build? | 23:26 |
| asac | havent tried to build it there yet | 23:28 |
| dyfet | because it might offer an environment for testing where people don't have hardware, if it reproduces the behavior | 23:29 |
| dyfet | while pulling down latest which tests do fail? | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!