**** BEGIN LOGGING AT Mon Feb 20 03:00:00 2012 Feb 20 10:54:40 SHR: 03shr-devel 07buildhistory * r264816b6dd21 10/packages/armv7a-vfp-neon-oe-linux-gnueabi/qt4-x11-free/qt4-x11-free-dbg/latest: Build 201202201031 of shr 20120220 for machine nokia900 on shr-chroot Feb 20 11:51:31 why writing a password generator as a shell script can be a bad idea: http://tech.slashdot.org/comments.pl?sid=2679771&cid=39091343 Feb 20 11:54:17 nice Feb 20 12:16:48 SHR: 03Martin.Jansa 07shr-chroot * r941ff90dfb2c 10/ (254 files in 26 dirs): system upgrade Feb 20 12:45:05 SHR: 03Martin.Jansa 07shr-chroot * r4b3f754ef2f3 10/ (18 files in 8 dirs): bitbake: upgrade and drop patches which are upstream now Feb 20 13:35:11 shr on n900 dead? Feb 20 13:36:44 why? Feb 20 13:38:40 just asking. is there any progress then? freesmartphone.org wiki doesn't show any change in support of n900. Feb 20 13:39:44 there is only a few devs.. so it's slower but not dead Feb 20 13:41:13 ok, thanks. Feb 20 13:42:05 about resticted user login, does this work in shr? Feb 20 13:52:34 such patience Feb 20 15:01:26 it's a wiki, what could one expect :) Feb 20 15:01:33 (up-to-date information - rarely) Feb 20 15:53:07 Project shr-core-om-gta02-shr-image build #90: SUCCESS in 49 min: http://norman-schleicher.de/jenkins/job/shr-core-om-gta02-shr-image/90/ Feb 20 16:03:44 Project shr-core-om-gta02-feed build #32: SUCCESS in 10 min: http://norman-schleicher.de/jenkins/job/shr-core-om-gta02-feed/32/ Feb 20 16:07:35 SHR: 03shr-devel 07buildhistory * r29866c493245 10/packages/armv7a-vfp-neon-oe-linux-gnueabi/webkit-gtk/ (46 files in 46 dirs): Build 201202201545 of shr 20120220 for machine nokia900 on shr-chroot Feb 20 16:18:20 Project shr-core-om-gta02-aurora-image build #29: SUCCESS in 14 min: http://norman-schleicher.de/jenkins/job/shr-core-om-gta02-aurora-image/29/ Feb 20 17:14:13 Project shr-core-nokia900-shr-image build #68: SUCCESS in 55 min: http://norman-schleicher.de/jenkins/job/shr-core-nokia900-shr-image/68/ Feb 20 17:37:04 Project shr-core-nokia900-feed build #26: SUCCESS in 22 min: http://norman-schleicher.de/jenkins/job/shr-core-nokia900-feed/26/ Feb 20 18:05:08 Project shr-core-nokia900-aurora-image build #26: SUCCESS in 28 min: http://norman-schleicher.de/jenkins/job/shr-core-nokia900-aurora-image/26/ Feb 20 18:25:18 PaulFertser: ping Feb 20 18:26:10 lindi-: ping Feb 20 18:27:19 DocScrutinizer: pong Feb 20 18:38:52 DocScrutinizer: pong Feb 20 18:39:21 lindi-: you seen my rant about thumb? Feb 20 18:39:52 DocScrutinizer: did not understand it Feb 20 18:40:21 you mustn't use thumb code on N900 Feb 20 18:40:30 at least with stock kernel Feb 20 18:40:47 probably with any kernel (though the jury is still out on that) Feb 20 18:41:40 DocScrutinizer: why would I use n900? :/ Feb 20 18:42:13 I'm an openmoko user :) Feb 20 19:19:15 It seemed to me you and GNUtoo-desktop were discussing something thumb related. So I felt like sharing the info that thumb is broken on N900 Feb 20 19:19:38 and possibly other OMAP3430 et al devices as well Feb 20 19:19:53 DocScrutinizer, you mean at the hardware level? Feb 20 19:19:59 yes Feb 20 19:20:02 ok Feb 20 19:20:16 silicon erratum Feb 20 19:20:21 the thumb we were discussing affect principally the om-gta02 Feb 20 19:20:22 chip borked Feb 20 19:20:28 yes I understand Feb 20 19:20:37 some chips have broken NEON for instance Feb 20 19:20:38 like some imx Feb 20 19:20:52 early revs tough Feb 20 19:20:59 it can be detected by the kernel Feb 20 19:21:13 by reading the cpu rev Feb 20 19:22:35 there's a workaround for it, by simply setting a bit (flash-cache-on-context-switch or whatnot) - alas that bit gets locked as soon as bootloader does some of that nasty HS shit Feb 20 19:22:56 ok Feb 20 19:23:24 I haven't completely wrapped my head around it Feb 20 19:25:52 flush* Feb 20 19:39:47 SHR: 03shr-devel 07buildhistory * rd99768419192 10/packages/ (764 files in 764 dirs): Build 201202202038 of shr 20120220 for machine nokia900 on shr-chroot Feb 20 19:57:41 GNUtoo-desktop, ping Feb 20 19:58:20 VQuickSilver, pong Feb 20 19:58:38 GNUtoo-desktop, good news I think, 2012-02-20T19:57:09.309176Z [DEBUG] QualcommHtcModem <>: Already in status FSO_GSM_MODEM_STATUS_ALIVE_REGISTERED, not advancing Feb 20 19:58:51 seems like it's connected Feb 20 19:59:21 wow Feb 20 19:59:24 indeed Feb 20 19:59:51 GNUtoo-desktop, I can read the modem info and the signal strength from settings also Feb 20 20:00:00 ok Feb 20 20:00:00 the network name etc... Feb 20 20:00:05 wow nice Feb 20 20:00:29 GNUtoo-desktop, but when I try to launch phone app or contacts it doesn't work Feb 20 20:00:40 ah? Feb 20 20:01:25 I don't know it simply doesn't work Feb 20 20:01:34 2012-02-20T20:00:30.001859Z [CRITICAL] phoneuid : GLib : ALSA: No control named 'Speaker Playback Volume' found - Sound state: 0 control type: 0 Feb 20 20:01:47 I have lots of this on Xsession.log Feb 20 20:01:58 and Feb 20 20:02:02 CRI<2546>: eina_iterator.c:98 eina_iterator_free() *** Eina Magic Check Failed !!! Feb 20 20:02:02 Input handle pointer is NULL ! Feb 20 20:02:02 *** NAUGHTY PROGRAMMER!!! Feb 20 20:02:02 *** SPANK SPANK SPANK!!! Feb 20 20:02:02 *** Now go fix your code. Tut tut tut! Feb 20 20:02:11 maybe someone needs to be spanked? lol Feb 20 20:09:42 ah ok Feb 20 20:09:46 try without the GUI Feb 20 20:10:12 because your real error seem this one: Feb 20 20:10:21 phoneuid : GLib : ALSA: No control named 'Speaker Playback Volume' found - Sound state: 0 control type: 0 Feb 20 20:10:31 it's just phoneuid that doens't find the correct alsa state Feb 20 20:10:42 you can put no alsa routing also Feb 20 20:10:45 in fsodeviced.conf Feb 20 20:19:21 guess is caused by this: Feb 20 20:19:25 [fsodevice.player_alsa] Feb 20 20:19:25 [fsodevice.router_alsa] Feb 20 20:19:25 [fsodevice.audio] Feb 20 20:19:25 player_type = alsa Feb 20 20:19:25 router_type = alsa Feb 20 20:19:43 what should I do? comment the lines? Feb 20 20:31:34 VQuickSilver, yes Feb 20 20:31:40 VQuickSilver, no Feb 20 20:31:45 you shouldn't comment Feb 20 20:31:51 you should do that instead: Feb 20 20:32:38 player_type = none Feb 20 20:32:39 router_type = none Feb 20 20:35:57 VQuickSilver, do you have alsa or the qualcomm DSP thing? Feb 20 20:36:02 or both? Feb 20 20:39:04 hi lindi- Feb 20 20:39:15 GNUtoo|laptop: hi Feb 20 20:39:32 I'll install libc-dbg Feb 20 20:39:42 and try to make a better trace Feb 20 20:40:37 just loop "si" and "x/i $pc" until it sigills Feb 20 20:43:41 ok Feb 20 20:43:43 SHR: 03GNUtoo 07meta-smartphone * r5e7a9684a31f 10/meta-osmocombb/recipes-osmocombb/osmoconbb/osmocom.inc: meta-osmocombb: update osmocombb and libosmocore SRCREV Feb 20 20:43:53 but I already did that yesterday: Feb 20 20:43:57 http://www.pastie.org/private/6qazrf8o2q3i0o7vc0c10w Feb 20 20:45:53 is more infos needed? Feb 20 20:46:02 like mapping between C source code and assembly Feb 20 20:46:04 ? Feb 20 20:46:05 I guess so Feb 20 20:46:25 that's why I said that I need to install libc-dbg on target rootfs Feb 20 20:46:45 so I've to recreate an image since opkg also segfault Feb 20 21:25:14 GNUtoo-desktop: are you using nexti or stepi here? Feb 20 21:25:39 GNUtoo-desktop, I have alsa I think, aplay -D hw:0 file.wav works, but only with some wav files, with others it doesn't work Feb 20 21:25:53 GNUtoo-desktop: and is this some kind of "x/45i $pc" or why is is printing so many lines? Feb 20 21:26:25 lindi-, I think stepi Feb 20 21:26:45 lindi-, yes it's x/45i $pc Feb 20 21:27:04 aplay -L Feb 20 21:27:04 null Feb 20 21:27:04 Discard all samples (playback) or generate zero samples (capture) Feb 20 21:27:04 default:CARD=msmaudio Feb 20 21:27:04 msm-audio, Feb 20 21:27:05 Default Audio Device Feb 20 21:27:13 GNUtoo-desktop: when you are at 0x401bf6ac: what does the memory at $r12 + 2404 contain? Feb 20 21:27:28 lindi-, it was last night Feb 20 21:27:39 but I looked that up Feb 20 21:27:43 let me look Feb 20 21:29:32 I can't find it anymore Feb 20 21:29:40 but it had an address inside Feb 20 21:30:36 and replacing $pc by that address + the immediate thing printed the thumb instructions Feb 20 21:31:17 GNUtoo-desktop: it should not have an address Feb 20 21:31:28 let me retry Feb 20 21:32:23 GNUtoo-desktop: it should have ((unsigned int)&calloc) | 0x1 Feb 20 21:32:38 GNUtoo-desktop: the lowest bit should be set so that it switches to thumb mode Feb 20 21:32:50 ok Feb 20 21:34:07 GNUtoo-desktop, uhm still the same error, maybe is related to this bug http://shr-project.org/trac/ticket/1584 Feb 20 21:35:03 GNUtoo-desktop: hmm, it works only for armv5t and above Feb 20 21:35:04 the critical error, which stopped the application, was a missing config file for om-gta04 in libphone-ui. Feb 20 21:35:18 GNUtoo-desktop: how was the code built? Feb 20 21:35:34 so you could add the config file in /etc/libphoneuid.conf or smoething like that Feb 20 21:35:40 GNUtoo-desktop: was -march=armv4t used? Feb 20 21:35:42 lindi-, using gold linker Feb 20 21:35:44 GNUtoo-desktop, ok Feb 20 21:35:53 lindi-, I'll look one second Feb 20 21:37:43 lindi-, I'm at => 0x401d86ac: ldr pc, [r12, #2404]! ; 0x964 Feb 20 21:38:15 http://www.pastie.org/private/co6sbmawg3miyyddfnequg Feb 20 21:38:30 GNUtoo-desktop: x/4a $r12 + 2404 Feb 20 21:39:07 0x402f3010: 0x7cf65 0x401d8684 0x401d8684 0x401d8684 Feb 20 21:39:12 I need some more iterations Feb 20 21:39:14 it seems Feb 20 21:39:27 I'll continue stepi Feb 20 21:39:41 => 0x7cfc4 : adds r0, r5, #0 Feb 20 21:39:43 strange Feb 20 21:39:49 ah right Feb 20 21:39:50 sorry Feb 20 21:39:51 GNUtoo-desktop: ahh, I'm off by one Feb 20 21:40:08 ok Feb 20 21:41:29 GNUtoo-desktop: so stepi does not execute the first instruction of calloc at all? Feb 20 21:42:04 if I do one more stepi it dies Feb 20 21:42:21 so maybe it does but there is a trap Feb 20 21:42:35 yes there is Feb 20 21:42:38 I didn't saw it Feb 20 21:42:51 http://www.pastie.org/private/vsrvy0wlc8gqrtqgpy5tg Feb 20 21:43:14 GNUtoo-desktop: please don't use /45, it's way too much :) Feb 20 21:43:19 ok lol Feb 20 21:43:26 difficult to make any sense Feb 20 21:44:28 GNUtoo-desktop: when you are at ldr and execute stepi it should not crash yet Feb 20 21:44:59 GNUtoo-desktop: are you sure it is doing this? Feb 20 21:46:57 GNUtoo|laptop, it works, I did my first call from dialer app :) Feb 20 21:48:34 http://www.pastie.org/private/8hjlfujgtibzkou6dzoxq Feb 20 21:48:50 at ldr it doesn't crash yet Feb 20 21:48:57 it's the step right after that crashes Feb 20 21:49:05 VQuickSilver, ok nice Feb 20 21:49:20 VQuickSilver, you should try to send fso + shr patches Feb 20 21:49:42 GNUtoo-desktop: how do you know? you have not executed ldr in that paste yet Feb 20 21:50:09 because it alwasys does it Feb 20 21:50:19 I did in the previous pastes Feb 20 21:50:23 should I do it again? Feb 20 21:51:06 GNUtoo-desktop: in http://www.pastie.org/private/6qazrf8o2q3i0o7vc0c10w it looks as if stepi after ldr would step to calloc+8 Feb 20 21:51:36 but it's hard to say since it does not say "stepi" anywhere since you just hit enter to execute previous command which could have been nexti too Feb 20 21:51:36 GNUtoo-desktop, yeah Feb 20 21:53:38 it's stepi Feb 20 21:53:39 http://www.pastie.org/private/rw9gyf1vwa4ikjrb7wx0ba Feb 20 21:55:22 is it just me or is pastie.org really slow at scrolling? ;;) Feb 20 21:56:14 pastie is unbearable Feb 20 21:56:35 GNUtoo-desktop: in http://www.pastie.org/private/rw9gyf1vwa4ikjrb7wx0ba you are not executing ldr at all? Feb 20 21:56:39 if it's that crap with that nightmare theme Feb 20 21:57:04 not yet Feb 20 21:57:06 should I do it Feb 20 21:57:20 GNUtoo-desktop: yes, stepi Feb 20 21:57:38 paste.dyndns.org FTW Feb 20 21:57:58 GNUtoo-desktop: also "display /3i $r12 + 2404 Feb 20 21:58:00 cat foo | netcat paste.dyndns.org 1234 Feb 20 21:58:01 * GNUtoo|laptop hides Feb 20 21:58:02 http://www.pastie.org/private/uzpiqye1xprxpmzimrxd9q Feb 20 21:58:09 (sorry for all the displays) Feb 20 21:58:15 GNUtoo-desktop: is quite confusing, the address is not supposed to contain instructions Feb 20 21:58:16 I should have undisplayed it Feb 20 21:58:33 only last part is valid Feb 20 21:58:35 after 1: Feb 20 21:58:47 1: x/3i $pc=> 0x7cfc4 : adds r0, r5, #0 0x7cfc6 : movs r1, #0 0x7cfc8 : bl 0x7c7f8 Feb 20 21:58:49 GNUtoo-desktop: horribly unreadable indeed :) Feb 20 21:58:49 that Feb 20 21:58:53 indeed Feb 20 21:58:56 sorry Feb 20 21:59:06 should I repaste? Feb 20 21:59:36 jr@halley:~> netcat paste.dyndns.org 1234 Feb 20 21:59:38 test Feb 20 21:59:39 test2 Feb 20 21:59:41 http://paste.debian.net/156967/ Feb 20 21:59:51 (^D invisible) Feb 20 22:01:13 GNUtoo-desktop: try "break *0x7cfbc", "stepi" when you are at 0x402ae6ac Feb 20 22:01:42 GNUtoo-desktop: oh and "x/4a $r12 + 2404" before that stepi too Feb 20 22:01:59 (you already did that but it'd be nice to have in the same trace Feb 20 22:05:43

GNUtoo-desktop: x/4a $r12 + 2404 Feb 20 22:05:43 0x402f3010: 0x7cf65 0x401d8684 0x401d8684 0x401d8684 Feb 20 22:05:56 if that is true then you should jump to beginning of malloc Feb 20 22:05:58 not calloc+8 Feb 20 22:05:59 HAX0RS Feb 20 22:06:16 ;-D Feb 20 22:06:17 and you should not get illegal instruction yet Feb 20 22:06:27 ok Feb 20 22:06:35 no illegal, no fun! Feb 20 22:08:20 (gdb) x/4a $r12 + 2404 Feb 20 22:08:20 0x40237010: 0x7cf65 0x4011c684 0x4011c684 0x4011c684 Feb 20 22:08:33 * DocScrutinizer idly ponders how long til 1st of April - would be a nice trolling for those script kiddies to tell them about all the awesome illegal instructions, and the conspiracy in all compiler and debugger folks to not allow those to the poor kids Feb 20 22:08:35 yeah, so it should be jumping to the beginning of malloc in thumb mode Feb 20 22:08:46 lol Feb 20 22:08:49 ok Feb 20 22:08:54 what should I do now? Feb 20 22:08:59 and on armv4t it will jump there in ARM mode since it ignores the lowest bit Feb 20 22:09:07 b *0x7cf65 Feb 20 22:09:20 GNUtoo-desktop: that won't make any sense :) Feb 20 22:09:21 instead of Feb 20 22:09:22 (gdb) break *0x7cfbc Feb 20 22:09:43 GNUtoo-desktop: instructions can't be at odd addresses Feb 20 22:09:50 let me look Feb 20 22:09:58 sorry Feb 20 22:10:00 indeed Feb 20 22:10:04 the value is odd because the lowest bit indicates thumb mode Feb 20 22:10:22 ah ok Feb 20 22:10:32 I didn't know that Feb 20 22:10:33 ok Feb 20 22:10:43 YAY, thumb mode \o/ Feb 20 22:10:43 ok so I do nexti now? Feb 20 22:10:55 GNUtoo-desktop: figure out what flags were given to gcc Feb 20 22:10:59 ok Feb 20 22:11:05 GNUtoo-desktop: try linking with both gold and bfd Feb 20 22:11:39 toldya, kids. There's all those 'illegal' instructions and in fact they are faster and shorter than regular arm assembler ;-P Feb 20 22:13:13 http://paste.debian.net/156972/ Feb 20 22:13:27 better: Feb 20 22:13:43 illegal instructions are instruction not documented by the manufacturer Feb 20 22:14:24 now they will think that since it's not documented they are hidding something right? Feb 20 22:14:45 but in another hand not documented in the manual means that they are not valid Feb 20 22:16:28 GNUtoo-desktop: hmm Feb 20 22:16:59 GNUtoo-desktop: afaik " -march=armv4t -mthumb -mthumb-interwork -mtune=arm920t" should ensure that it does not use "ldr pc, [foo]" but instead uses bx Feb 20 22:17:10 ok Feb 20 22:17:19 I tough ldr was valid according to the manual Feb 20 22:17:22 let me verify Feb 20 22:17:29 GNUtoo-desktop: on armv4t you can't use ldr to switch to thumb mode Feb 20 22:17:36 A processor in Thumb state can enter ARM state by executing any of the following instructions: BX, BLX, or an LDR or LDM that loads the PC.A processor in ARM state can enter Thumb state by executing any of the same instructions. Feb 20 22:18:08 maybe there are erratas? Feb 20 22:18:11 GNUtoo-desktop: we are in ARM state Feb 20 22:18:16 yes Feb 20 22:18:20 GNUtoo-desktop: " In ARMv5T and above, bit[0] of the loaded value determines whether execution Feb 20 22:18:20 continues after this branch in ARM state or in Thumb state, as though a BX (loaded_value) instruction had Feb 20 22:18:20 been executed. Feb 20 22:18:22 well, illegal or hidden instructions existed in Z80 already. No kidding Feb 20 22:18:35 DocScrutinizer, I know Feb 20 22:18:41 not in z80 exactly Feb 20 22:18:56 but in the machines that are emulated by (non-free) software such as mame Feb 20 22:18:59 GNUtoo-desktop: your quote does not work for armv4t afaik Feb 20 22:19:04 ok Feb 20 22:19:14 GNUtoo-desktop: this is A4.1.23 Feb 20 22:19:20 let me look mine Feb 20 22:19:39 of course it's a nice catch to tell those kids, all "illegal instruction" in a gdb or whatever disassembly were in fact such hidden useful instructions Feb 20 22:19:56 DDI0406C_arm_architecture_reference_manual.pdf Feb 20 22:20:03 it's not long til april's fool day Feb 20 22:20:17 lol we need to print some puffy Feb 20 22:20:30 GNUtoo-desktop: anyways, 0x402ae6ac is in libc.so Feb 20 22:20:34 GNUtoo-desktop: how was libc.so built? Feb 20 22:20:35 yes Feb 20 22:20:38 ok Feb 20 22:20:40 let me look Feb 20 22:21:07 GNUtoo-desktop: the ARM architecture manual book yes Feb 20 22:23:27 the log is huge, I'll scp + xz it on my router Feb 20 22:25:22 http://gnutoo.homelinux.org/downloads/people/lindi/log.do_compile.xz Feb 20 22:30:20 GNUtoo|laptop: ok so that has -march=armv4t -marm -mthumb-interwork -mtune=arm920t Feb 20 22:30:41 GNUtoo|laptop: then why does calloc() contain thumb code? Feb 20 22:30:46 yes I saw that Feb 20 22:30:49 no idea Feb 20 22:30:52 it's strange Feb 20 22:31:04 GNUtoo|laptop: is 0x7cfc4 also mapped from libc.so? Feb 20 22:31:44 I think it's from libc Feb 20 22:31:51 but how to check? Feb 20 22:32:02 GNUtoo|laptop: /proc/$pid/maps Feb 20 22:32:03 ah wait a second Feb 20 22:32:05 maybe not Feb 20 22:33:27 http://www.pastie.org/private/cbh0lubnn5xyinv2wnu69g Feb 20 22:33:37 hmmm Feb 20 22:33:56 so bash has its own calloc? Feb 20 22:34:05 yes Feb 20 22:34:07 in calloc.c Feb 20 22:34:11 I remember it now Feb 20 22:34:17 and bash is compiled with -mthumb Feb 20 22:34:23 ah? Feb 20 22:34:25 so the calloc contains thumb code Feb 20 22:34:32 let me look Feb 20 22:34:44 and the problem is that libc calls calloc using ldr Feb 20 22:34:50 it should use bx instead Feb 20 22:38:12 arm-oe-linux-gnueabi-gcc -march=armv4t -mthumb -mthumb-interwork Feb 20 22:38:28 GNUtoo|laptop: yeah, -mthumb Feb 20 22:38:38 bash is built with -mthumb but libc is built with -marm Feb 20 22:39:52 ok Feb 20 22:40:00 so we should build both with -mthumb? Feb 20 22:40:08 or both with -marm? Feb 20 22:40:21 GNUtoo|laptop: well, you should figure out why the interworking is not working Feb 20 22:40:30 GNUtoo|laptop: just try linking everything with ld.bfd first Feb 20 22:40:43 easier to start that way Feb 20 22:42:01 ok Feb 20 22:42:06 thanks a lot!!!!!!!!!! Feb 20 22:42:32 armv4t is not getting a lot of testing Feb 20 22:42:40 so it's very possible that you hit one of the gold bugs Feb 20 22:42:45 indeed Feb 20 22:43:23 for example chromium suffers from something similar now Feb 20 22:43:40 ok Feb 20 22:43:50 I'm doing recipes for chromium for work btw Feb 20 22:44:01 so chromium will enter oe at some point Feb 20 22:44:12 (when the recipe will be finished) Feb 20 23:21:56 toldya mixing -marm -mthumb is not a nice idea Feb 20 23:25:01 each swith between arm and thumb e.g. flushes jump prediction table AIUI Feb 20 23:30:22 DocScrutinizer: never heard about anything like that Feb 20 23:31:04 maybe that's part of the workaround for the silicon error in OMAP Feb 20 23:31:51 no omap here :/ Feb 20 23:59:51 SHR: 03shr-devel 07buildhistory * r7d1d4fbc1100 10/packages/ (525 files in 525 dirs): Build 201202202053 of shr 20120220 for machine nokia900 on shr-chroot **** ENDING LOGGING AT Tue Feb 21 02:59:58 2012