**** BEGIN LOGGING AT Sun Feb 26 02:59:59 2012
Feb 26 03:26:27 <CIA-112> SHR: 03shr-devel 07buildhistory * rcab68d1bbaf5 10/ (39 files in 29 dirs): Build 201202260207 of shr 20120226 for machine palmpre on opmbuild
Feb 26 06:04:30 <CIA-112> SHR: 03shr-devel 07buildhistory * r21fe622ab8fe 10/ (39 files in 29 dirs): Build 201202260441 of shr 20120226 for machine palmpre2 on opmbuild
Feb 26 08:08:23 <CIA-112> SHR: 03Martin.Jansa 07meta-smartphone * r6556b3888a9d 10/meta-palm/recipes-efl/efl/evas.inc: meta-palm: no need to keep it here, neon is disabled for armv7a in meta-efl
Feb 26 08:08:26 <CIA-112> SHR: 03Martin.Jansa 07meta-smartphone * r2a43a5ae0c29 10/meta-palm/conf/layer.conf: meta-palm: add ecore->tslib to SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS as out tslib changes doesn't change ABI
Feb 26 08:08:56 <CIA-112> SHR: 03Martin.Jansa 07libphone-ui-shr * r57a1358c6666 10/src/view/ (4 files): view: move from elm_pager to elm_naviframe
Feb 26 08:11:00 <CIA-112> SHR: 03Martin.Jansa 07meta-smartphone * ra6b82dbbc017 10/meta-shr/recipes-shr/shr/libphone-ui-shr_git.bb: libphone-ui-shr: upgrade SRCREV for new EFL support
Feb 26 09:00:26 <CIA-112> SHR: 03Martin.Jansa 07shr-chroot * re8e6ffea18fe 10/ (1158 files in 85 dirs): system upgrade
Feb 26 09:00:36 <CIA-112> SHR: 03Martin.Jansa 07shr-chroot * r1ac8aa12ae47 10/ (33 files in 7 dirs): bitbake upgrade
Feb 26 09:01:19 <CIA-112> SHR: 03shr-devel 07buildhistory * r0ab60c741952 10/ (43 files in 30 dirs): Build 201202260714 of shr 20120226 for machine crespo on opmbuild
Feb 26 11:35:33 <CIA-112> SHR: 03shr-devel 07buildhistory * r667b154c7e31 10/packages/ (523 files in 523 dirs): Build 201202261016 of shr 20120226 for machine om-gta02 on opmbuild
Feb 26 13:22:01 * DocScrutinizer moos
Feb 26 13:22:52 * PaulFertser says nya
Feb 26 14:41:19 <GNUtoo|laptop> hi lindi- 
Feb 26 14:41:41 <lindi-> GNUtoo|laptop: hi
Feb 26 14:41:53 <GNUtoo|laptop> lindi-, I forgot to tell you that there are patches for pol_putchar and poll_getchar for samsung serial driver in mainline
Feb 26 14:42:02 <GNUtoo|laptop> http://article.gmane.org/gmane.linux.kernel.samsung-soc/9684
Feb 26 14:42:09 <GNUtoo|laptop> and this patch work
Feb 26 14:42:32 <GNUtoo|laptop> http://www.pastie.org/private/dswdlba1rirycquidxwqw
Feb 26 14:42:48 <lindi-> GNUtoo|laptop: did you test kgdb?
Feb 26 14:43:33 <lindi-> GNUtoo|laptop: apparently so?
Feb 26 14:43:35 <GNUtoo|laptop> indeed that's what I did
Feb 26 14:44:04 <GNUtoo|laptop> do you have kgdb already?
Feb 26 14:47:39 <lindi-> GNUtoo|laptop: never used actually
Feb 26 14:47:58 <lindi-> GNUtoo|laptop: are you debugging some specific bug in that backtrace?
Feb 26 14:48:13 <GNUtoo|laptop> yes I am
Feb 26 14:48:26 <GNUtoo|laptop> (gdb) p map.format
Feb 26 14:48:26 <GNUtoo|laptop> Cannot access memory at address 0x37386d8b
Feb 26 14:48:27 <GNUtoo|laptop> that bug
Feb 26 14:48:42 <lindi-> GNUtoo|laptop: does it have a number?
Feb 26 14:48:47 <GNUtoo|laptop> no
Feb 26 14:48:57 <GNUtoo|laptop> I find bugs and send patches upstream
Feb 26 14:49:01 <lindi-> GNUtoo|laptop: can you open one please? ;)
Feb 26 14:49:16 <GNUtoo|laptop> it's a bug present only within linux-next
Feb 26 14:49:20 <lindi-> ok
Feb 26 14:49:22 <lindi-> so not in 2.6.39
Feb 26 14:49:24 <GNUtoo|laptop> no
Feb 26 15:59:02 <GNUtoo|laptop> hi DocScrutinizer 
Feb 26 15:59:14 <DocScrutinizer> hi GNUtoo|laptop 
Feb 26 15:59:27 <DocScrutinizer> how's living?
Feb 26 15:59:29 <GNUtoo|laptop> is the CoDEC connected trough SPI? 
Feb 26 15:59:31 <GNUtoo|laptop> nice
Feb 26 15:59:39 <GNUtoo|laptop> *CODEC
Feb 26 15:59:46 <DocScrutinizer> where?
Feb 26 15:59:50 <GNUtoo|laptop> I see pins like SDA SCL on datasheet of om-gta02
Feb 26 15:59:57 <GNUtoo|laptop> is that SPI?
Feb 26 16:00:02 <DocScrutinizer> mhm, then that's it
Feb 26 16:00:22 <GNUtoo|laptop> let me look
Feb 26 16:00:32 <DocScrutinizer> I have to check whether it's SPI or IIS
Feb 26 16:00:45 <GNUtoo|laptop> second page
Feb 26 16:00:47 <DocScrutinizer> always mixing up the two
Feb 26 16:00:49 <GNUtoo|laptop> can it be both?
Feb 26 16:01:03 <GNUtoo|laptop> there are IIS stuff named on the page 2
Feb 26 16:01:21 <larsc> it's i2c...
Feb 26 16:01:34 <GNUtoo|laptop> ok
Feb 26 16:01:51 <larsc> and i2s for the pcm data
Feb 26 16:01:56 <GNUtoo|laptop> ok
Feb 26 16:02:35 <GNUtoo|laptop> so SPI is not used in the gta02 for the CODEC
Feb 26 16:02:36 <GNUtoo|laptop> ok
Feb 26 16:02:42 <GNUtoo|laptop> because I've a problem with the driver
Feb 26 16:02:44 <GNUtoo|laptop> it panics
Feb 26 16:02:53 <DocScrutinizer> http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus  http://en.wikipedia.org/wiki/I2c  http://en.wikipedia.org/wiki/I2s
Feb 26 16:03:04 <GNUtoo|laptop> I know a bit the 3
Feb 26 16:03:08 <GNUtoo|laptop> but a bit only
Feb 26 16:03:16 <larsc> well, wm8753_i2c_probe should init regmap too, shouldn't it?
Feb 26 16:03:23 <GNUtoo|laptop> I know i2s is used to transport audio in some codecs
Feb 26 16:03:33 <GNUtoo|laptop> and spi for controlling it
Feb 26 16:03:36 <DocScrutinizer> same here I guess
Feb 26 16:03:48 <DocScrutinizer> and wolfson control is via I2C
Feb 26 16:03:57 <GNUtoo|laptop> and I already used SPI for a BIOS chip 
Feb 26 16:03:59 <GNUtoo|laptop> but that's all
Feb 26 16:04:00 <GNUtoo|laptop> ok
Feb 26 16:04:01 <DocScrutinizer> or rather, the 3 wire variant
Feb 26 16:04:30 <larsc> there is no 3wire i2c variant
Feb 26 16:04:37 <GNUtoo|laptop> I'll tap wm8753_i2c_probe
Feb 26 16:05:47 <DocScrutinizer> *sigh*
Feb 26 16:06:27 <GNUtoo|laptop> ?
Feb 26 16:06:34 <GNUtoo|laptop> did I say something wrong
Feb 26 16:07:59 <larsc> no, i did
Feb 26 16:08:03 <GNUtoo|laptop> ok
Feb 26 16:08:30 <DocScrutinizer> ooops, 2-wire
Feb 26 16:08:55 <DocScrutinizer> /home/jr/Documents/OpenMoko/varaha_docs/docs/by_component/wm8753/WM8753_Rev3.4.pdf
Feb 26 16:09:14 <DocScrutinizer> CONTROL INTERFACE TIMING – 3-WIRE MODE ..................................................... 15
Feb 26 16:09:15 <DocScrutinizer> CONTROL INTERFACE TIMING – 2-WIRE MODE ..................................................... 16
Feb 26 16:09:29 <GNUtoo|laptop> ok
Feb 26 16:09:50 <DocScrutinizer> means you can't read back from WM8753 registers
Feb 26 16:10:23 <GNUtoo|laptop> ah?
Feb 26 16:10:35 <larsc> GNUtoo|laptop: don't listen to him
Feb 26 16:10:39 <GNUtoo|laptop> I don't know the regmap at all
Feb 26 16:11:13 <larsc> the wm8753 is connected via I2C and you can write and read registers
Feb 26 16:11:21 <DocScrutinizer> BS
Feb 26 16:12:01 <DocScrutinizer> you "read" registers from shadow buffer in kernel driver
Feb 26 16:13:04 <larsc> while that is true, you can still read the real hw registers
Feb 26 16:17:06 <GNUtoo|laptop> ouch
Feb 26 16:17:13 <GNUtoo|laptop> it seem a scheduler bug but I'm not sure
Feb 26 16:17:16 <DocScrutinizer> larsc: http://people.openmoko.org/joerg/schematics/GTA02/Schematics_Freerunner-GTA02_A5-A7cumulative_public_RC0.pdf  p.6, you got connected to U3001(WM8753):  U3001:47(SDCLK) and U3001:46(SDIN). Where is SDOUT you'd need for reading from chip?
Feb 26 16:18:48 <larsc> DocScrutinizer: again. it's connected via i2c
Feb 26 16:18:59 <larsc> i2c is a bi-directional bus
Feb 26 16:19:55 <GNUtoo|laptop> hmmm
Feb 26 16:19:56 <GNUtoo|laptop> http://www.pastie.org/private/dr1jrdkpx9wrcytx19eeg
Feb 26 16:20:41 <DocScrutinizer> larsc: umm, you're right
Feb 26 16:20:55 <GNUtoo|laptop> basically I start to put a breakpoint at wm8753_i2c_probe
Feb 26 16:21:14 <GNUtoo|laptop> it but i2c_probe doesn't finish
Feb 26 16:21:28 <DocScrutinizer> but still I recall Andy explaining to me in all epic length ("doesn't work!! you XXX") that we can't read data from WM8753
Feb 26 16:21:34 <GNUtoo|laptop> and the wm8753_probe start to run
Feb 26 16:21:37 <GNUtoo|laptop> is that possible
Feb 26 16:21:57 <GNUtoo|laptop> or am I wrong somewhere?
Feb 26 16:24:18 <larsc> GNUtoo|laptop: if it does not finish, the codec shouldn't be registered and wm8753_probe shouldn't be called
Feb 26 16:24:36 <GNUtoo|laptop> hmmm
Feb 26 16:24:42 <GNUtoo|laptop> strange then
Feb 26 16:25:08 <GNUtoo|laptop> because I was with stepi and at some point boom, the kernel panic arrived
Feb 26 16:26:14 <GNUtoo|laptop> do you see something wrong in my kgdb session?
Feb 26 16:32:48 <DocScrutinizer> larsc: from wm8753 DS: >> The control interface of the WM8753L is a write only interface. However setting register bit READEN *in* *3-wire mode* will allow a status word to be read from the device.<<
Feb 26 16:34:35 <larsc> DocScrutinizer: yes, i guess you are right in this case. but this is not an issue i2c per se
Feb 26 16:34:39 <DocScrutinizer> larsc: so, AIUI, while wm8753 is connected via bidir I2C (2wire) bus, it doesn't support read of any register except status register. And even status register read is supported only in 3-wire mode, not for I2C
Feb 26 16:35:00 <larsc> GNUtoo|laptop: the address of map looks a bit strange. map=0x37386d77
Feb 26 16:35:40 <GNUtoo|laptop> ok
Feb 26 16:35:50 <GNUtoo|laptop> indeed it points nowhere
Feb 26 16:36:46 <larsc> GNUtoo|laptop: can you print map in regmap_init?
Feb 26 16:36:55 <GNUtoo|laptop> ok
Feb 26 16:37:17 <GNUtoo|laptop> let me do it
Feb 26 16:38:06 <DocScrutinizer> larsc: I never said it's a I2C-per-se issue. I said we're operating WM8753 in 2-wire mode and that forbids reding *anything* from it
Feb 26 16:39:23 <DocScrutinizer> of course I messed up things a bit when you challenged me on *why* it's like that, 
Feb 26 16:39:25 <larsc> ok, then I misunderstood you
Feb 26 16:39:49 <DocScrutinizer> of course 3-wire is no I2C
Feb 26 16:40:02 <DocScrutinizer> and of course I2C is bidir
Feb 26 16:40:30 <DocScrutinizer> but for reading from wolfson we'd need a connected SDOUT and that's all I remembered
Feb 26 16:41:13 <DocScrutinizer> dude, it's like 3 years ago I last time looked into it
Feb 26 16:41:54 <GNUtoo|laptop> larsc, I've DEBUG_INFO compiled in and it says:
Feb 26 16:42:16 <GNUtoo|laptop> value has been optimized out
Feb 26 16:42:19 <GNUtoo|laptop> when printing map
Feb 26 16:43:02 <larsc> :/ can you add a printk?
Feb 26 16:43:12 <GNUtoo|laptop> I'll do
Feb 26 16:44:16 <GNUtoo|laptop> what infos do you want on map exactly?
Feb 26 16:44:19 <GNUtoo|laptop> it's content?
Feb 26 16:44:22 <GNUtoo|laptop> or it's address?
Feb 26 16:45:16 <larsc> the address
Feb 26 16:45:21 <GNUtoo|laptop> ok
Feb 26 16:47:12 <larsc> are you using modules?
Feb 26 16:48:47 <GNUtoo|laptop> no
Feb 26 16:55:01 <GNUtoo|laptop> hmmm
Feb 26 16:55:04 <GNUtoo|laptop> it prints it 2 times
Feb 26 16:55:31 <larsc> the pcf50633 also uses regmap
Feb 26 16:55:32 <GNUtoo|laptop> one right after i2c:
Feb 26 16:55:51 <GNUtoo|laptop> ok
Feb 26 16:55:55 <GNUtoo|laptop> the right one is that one:
Feb 26 16:55:56 <GNUtoo|laptop> [    0.985000] DBG: map: 0xc78c4500 
Feb 26 16:56:18 <larsc> yes, that address looks good
Feb 26 16:56:24 <GNUtoo|laptop> ok
Feb 26 16:56:57 <GNUtoo|laptop> why does it do that then: [    0.990000] Unable to handle kernel paging request at virtual address 37386d9b
Feb 26 16:56:59 <GNUtoo|laptop> strange
Feb 26 16:57:48 <GNUtoo|laptop> with [    1.000000] [<c01ccbc0>] (regmap_get_val_bytes+0xc/0x30) from [<c0243e98>] (snd_soc_codec_set_cache_io+0x9c/0xcc)
Feb 26 16:57:57 <larsc> because 37386d9b is not a good address
Feb 26 16:58:04 <GNUtoo|laptop> yes I know that
Feb 26 16:58:09 <GNUtoo|laptop> I'll refrase
Feb 26 16:58:15 <larsc> try to find out where wm8753->regmap gets messed up
Feb 26 16:58:21 <GNUtoo|laptop> where does 37386d9b comes from?
Feb 26 16:58:24 <GNUtoo|laptop> that's the question
Feb 26 16:58:37 <GNUtoo|laptop> ok
Feb 26 16:58:46 <larsc> and also check that the wm8753 in wm8753_i2c_probe and wm8753_probe have the same address
Feb 26 16:58:51 <GNUtoo|laptop> is there something in gdb that permit to monitor that struct value?
Feb 26 16:59:03 <GNUtoo|laptop> they do
Feb 26 16:59:07 <GNUtoo|laptop> it's the wrong address 
Feb 26 16:59:21 <GNUtoo|laptop> if I remember well
Feb 26 16:59:23 <GNUtoo|laptop> let me re-check
Feb 26 17:03:11 <GNUtoo|laptop> no different addresses
Feb 26 17:03:50 <GNUtoo|laptop> http://www.pastie.org/private/pbtswfdlanxd57g1nl2q
Feb 26 17:04:20 <GNUtoo|laptop> let me look at the code
Feb 26 17:04:33 <GNUtoo|laptop> I think I did a mistake while pasting wm8753
Feb 26 17:08:32 <GNUtoo|laptop> 0xc02d4354	1644		kfree(wm8753);
Feb 26 17:08:33 <GNUtoo|laptop> hmmm
Feb 26 17:08:41 <GNUtoo|laptop> err_regmap:
Feb 26 17:09:52 <GNUtoo|laptop>                 dev_err(&i2c->dev, "Failed to register CODEC: %d\n", ret);
Feb 26 17:11:40 <larsc> what's the value of ret?
Feb 26 17:11:48 <GNUtoo|laptop> that's what I'm looking
Feb 26 17:11:57 <GNUtoo|laptop> *that's what I want to get
Feb 26 17:13:13 <GNUtoo|laptop> againt obtimized out
Feb 26 17:13:18 <GNUtoo|laptop> I'll print with printk
Feb 26 17:13:27 <GNUtoo|laptop> or better
Feb 26 17:13:33 <GNUtoo|laptop> it should print it already
Feb 26 17:13:46 <larsc> yes
Feb 26 17:13:49 <GNUtoo|laptop> I guess there is only one serial port in om-gta02
Feb 26 17:14:10 <larsc> oh....
Feb 26 17:14:19 <larsc> i see the error
Feb 26 17:14:27 <larsc> pretty obvious actually
Feb 26 17:14:30 <GNUtoo|laptop> ok
Feb 26 17:14:54 <GNUtoo|laptop> the .codec_name were changed by me btw
Feb 26 17:15:26 <larsc> http://pastebin.com/SfE1PEXx
Feb 26 17:15:53 <GNUtoo|laptop> ohhh
Feb 26 17:15:55 <GNUtoo|laptop> lol
Feb 26 17:16:03 <GNUtoo|laptop> I'll try it
Feb 26 17:16:19 <GNUtoo|laptop> but then how do I send it upstream if it works?
Feb 26 17:16:33 <GNUtoo|laptop> should I include your signed-off-by?
Feb 26 17:16:40 <GNUtoo|laptop> or you as author and me as tester?
Feb 26 17:17:00 <larsc> no. just send it with you as the author
Feb 26 17:17:08 <larsc> keeps things simple
Feb 26 17:17:42 <larsc> make sure to mention the commit witch broke it (391d9e4e5).
Feb 26 17:17:43 <GNUtoo|laptop> ok
Feb 26 17:17:49 <GNUtoo|laptop> ok
Feb 26 17:17:55 <GNUtoo|laptop> I'll mention you helped me?
Feb 26 17:18:03 <larsc> if you want to
Feb 26 17:18:20 <GNUtoo|laptop> thanks a lot
Feb 26 17:18:25 <GNUtoo|laptop> let me try it now
Feb 26 17:19:22 <GNUtoo|laptop> wow it works
Feb 26 17:25:17 <larsc> for bonus points also send a patch converting the driver to devm_kzalloc
Feb 26 17:25:36 <GNUtoo|laptop> ok I'll try not to forget that
Feb 26 17:25:57 <Alex[sp3dev]> omg
Feb 26 17:26:55 <Alex[sp3dev]> nice, everything is now getting tied to devices (dev_err, this kzalloc). didn't know about kzalloc, though. thanks for a tip ;)
Feb 26 17:27:55 <Alex[sp3dev]> my crazy dream is to have a compiled language with ruby syntax and haskell type inference for kernel programming
Feb 26 17:30:56 <larsc> crazy dream indeed ;)
Feb 26 17:32:18 <larsc> did you know that there is module which allows you to write kernel drivers in haskell?
Feb 26 17:34:15 <Alex[sp3dev]> larsc: i do know. my dream is to write all code in a haskell or ML-like language with type inference, strict type checking and (mostly) immutable data structures. but I have not yet studied parsing/compilation ;)
Feb 26 17:35:01 <Alex[sp3dev]> while this can save you from null pointers, this will, of course not save you from hardware crashing due to wrong settings/misconfigured power etc
Feb 26 17:49:02 <CIA-112> SHR: 03shr-devel 07buildhistory * r8cf0c2215e83 10/ (489 files in 480 dirs): Build 201202261304 of shr 20120226 for machine om-gta04 on opmbuild
Feb 26 19:32:09 <CIA-112> SHR: 03shr-devel 07buildhistory * r1ba3c48a70d9 10/ (19 files in 10 dirs): Build 201202261859 of shr 20120226 for machine nokia900 on opmbuild
Feb 26 19:36:04 <GNUtoo|laptop> Alex[sp3dev], hi do you have any idea on how to debug when the phone freeze because of an interrupt issue?
Feb 26 19:36:08 <GNUtoo|laptop> like for crespo
Feb 26 19:36:11 <GNUtoo|laptop> with wifi
Feb 26 19:36:45 <Alex[sp3dev]> GNUtoo|laptop: ramconsole
Feb 26 19:36:51 <GNUtoo|laptop> ok
Feb 26 19:37:02 <GNUtoo|laptop> do you know how to use it, what address to put in?
Feb 26 19:37:27 <Alex[sp3dev]> basically, if we're speaking of android ramconsole, you just reboot and do cat /proc/last_kmsg
Feb 26 19:37:37 <GNUtoo|laptop> ok
Feb 26 19:37:53 <GNUtoo|laptop> nothing to setup like memory address like in the old times then
Feb 26 19:38:12 <GNUtoo|laptop> in the old times you had to setup the address and size in the kernel parameters
Feb 26 19:38:24 <Alex[sp3dev]> you can still setup address via platform data
Feb 26 19:38:34 <GNUtoo|laptop> ok
Feb 26 19:40:40 <PaulFertser> GNUtoo|laptop: have you seen http://lindi.iki.fi/lindi/openmoko/crash/README ?
Feb 26 19:41:50 <GNUtoo|laptop> yes of course
Feb 26 19:41:54 <GNUtoo|laptop> but I've no QI for crespo
Feb 26 19:42:38 <PaulFertser> GNUtoo|laptop: but you can probably reuse the idea i mean.
Feb 26 19:42:43 <GNUtoo|laptop> ok
Feb 26 19:42:56 <PaulFertser> It looks like it gives the ultimate way to debug such things.
Feb 26 19:43:05 <PaulFertser> Way more better than obtaining an old dmesg.
Feb 26 19:43:15 <GNUtoo|laptop> yes
Feb 26 19:43:23 <GNUtoo|laptop> but I've a proprietary bootloader on that device
Feb 26 19:43:30 <GNUtoo|laptop> porting a free one requires bricking it
Feb 26 19:43:36 <GNUtoo|laptop> and then unbricking it
Feb 26 19:43:45 <lindi-> PaulFertser: you still don't get register contents with that unfortunately
Feb 26 19:43:59 <GNUtoo|laptop> basically it seems(not sure) that the bootrom checks NAND first
Feb 26 19:45:03 <PaulFertser> lindi-: preserving register contents would be nice but seems to be impossible (if the kernel really hanged and was rebooted by the hardware watchdog)...
Feb 26 19:45:15 <lindi-> PaulFertser: yep
Feb 26 20:01:31 <GNUtoo|laptop> Alex[sp3dev], what if it prints nothing?
Feb 26 20:03:04 <JaMa> multimachine builds finally efficient :)
Feb 26 20:03:48 <Alex[sp3dev]> GNUtoo|laptop: then you probably placed it to the area where it gets erased on boot. or you have not enabled it at all
Feb 26 20:04:27 <Alex[sp3dev]> but if you have uart, it should not just die silently
Feb 26 20:06:09 <GNUtoo|laptop> it does even with the uart
Feb 26 20:06:25 <GNUtoo|laptop> I didn't try ramconsole yet
Feb 26 20:06:34 <GNUtoo|laptop> but I really wonder what it would print
Feb 26 20:06:39 <GNUtoo|laptop> I mean it's interrupt stuff
Feb 26 20:06:44 <GNUtoo|laptop> maybe the best is to try
Feb 26 20:08:49 <morgner> hi! when building shr there are several versions of openssl, that are built. how do i enforce linking an other package against a speciffic version of openssl?
Feb 26 20:10:14 <morgner> (i patched one version of openssl, which adds new library functions. an other program, that uses these functions gets a linker-error althought nm shows that the new functions are included in libcrypto)
Feb 26 20:12:04 <GNUtoo|laptop> JaMa, ^^^
Feb 26 20:12:47 <JaMa> morgner: only one version is always built
Feb 26 20:13:06 <JaMa> morgner: and you need to set PREFERRED_VERSION if you want different version than default one
Feb 26 20:20:34 <morgner> ic. you're right, libcrypto.so appears several times, but only in one version. all of them contain my changes. linking fails anyway. i even tried EXTRA_OECONF += 'OPENSSL_LIBS="-L${STAGING_DIR_TARGET}/lib/ -lcrypto"' in the recipe with no effect...
Feb 26 20:27:55 <GNUtoo|laptop> Alex[sp3dev], what should I add to cmdline?
Feb 26 20:30:54 <Alex[sp3dev]> GNUtoo|laptop: use platform_device http://pastebin.com/sL5aWC8f just think of a proper start/end
Feb 26 20:31:35 <GNUtoo|laptop> it's enabled automatically?
Feb 26 20:31:49 <Alex[sp3dev]> sorry, not size, but end should be in resources
Feb 26 20:31:59 <GNUtoo|laptop> I think I should have it
Feb 26 20:32:02 <Alex[sp3dev]> no, it is not enabled. add it to the platform devices in your board
Feb 26 20:32:06 <GNUtoo|laptop> ok
Feb 26 20:33:19 <GNUtoo|laptop> it's in the board file
Feb 26 20:33:24 <GNUtoo|laptop> 1M is reserved for it
Feb 26 20:34:33 <GNUtoo|laptop> and there is no ifdef arround
Feb 26 20:36:13 <GNUtoo|laptop> seem to work by default
Feb 26 20:36:16 <GNUtoo|laptop> I'll try it then
Feb 26 20:56:17 <GNUtoo|laptop> [    0.038708] ram_console: no valid data in buffer (sig = 0x00000000)
Feb 26 20:57:16 <GNUtoo|laptop> maybe I need a reboot watchdog?
Feb 26 20:59:04 <Alex[sp3dev]> you need to move ramconsole to a place where it won't get erased
Feb 26 20:59:22 <GNUtoo|laptop> it get erased because I remove the battery after the crash
Feb 26 20:59:41 <GNUtoo|laptop> else usually it doesn't get erased
Feb 26 20:59:51 <Alex[sp3dev]> well
Feb 26 21:00:04 <Alex[sp3dev]> try holding power key until it shuts down. may or may not help
Feb 26 21:01:05 <GNUtoo|laptop> doesn't help but kernel hacking menu could help
Feb 26 21:01:07 <GNUtoo|laptop> hung task
Feb 26 21:01:12 <GNUtoo|laptop> etc...
Feb 26 21:02:11 <GNUtoo|laptop> detect hard and soft lockup
Feb 26 21:02:20 <GNUtoo|laptop> and panic reboot on such things
Feb 26 21:14:19 <CIA-112> SHR: 03shr-devel 07buildhistory * r8369a7ee3f7e 10/ (17 files in 8 dirs): Build 201202262042 of shr 20120226 for machine palmpre on opmbuild
Feb 26 21:26:09 <GNUtoo|laptop> Alex[sp3dev], just like I tought:
Feb 26 21:26:10 <GNUtoo|laptop> http://www.pastie.org/private/1u5kq7gzkzsenpudxrhtrg
Feb 26 21:26:12 <GNUtoo|laptop> no errors
Feb 26 21:26:34 <GNUtoo|laptop> and some time ago it was the same with serial: no errors
Feb 26 21:27:27 <Alex[sp3dev]> GNUtoo|laptop: you mean, it works fine after you enabled debugging?
Feb 26 21:27:54 <GNUtoo|laptop> no
Feb 26 21:28:01 <GNUtoo|laptop> I mean it doesn't produce any errors
Feb 26 21:28:04 <GNUtoo|laptop> it just freeze
Feb 26 21:28:21 <GNUtoo|laptop> I cannot get a lot
Feb 26 21:28:25 <GNUtoo|laptop> because there is nothing to print
Feb 26 21:28:33 <GNUtoo|laptop> only interupt storm or something like that
Feb 26 21:28:37 <GNUtoo|laptop> that blocks the phone
Feb 26 21:28:46 <GNUtoo|laptop> it's related to the second function of sdio
Feb 26 21:28:54 <GNUtoo|laptop> if I remove the dummy interupt handler it works
Feb 26 21:29:02 <GNUtoo|laptop> and maybe the interupt should be masked
Feb 26 21:29:05 <GNUtoo|laptop> or something like that
Feb 26 21:29:08 <GNUtoo|laptop> or disabled even
Feb 26 21:29:11 <GNUtoo|laptop> if possible
Feb 26 21:29:17 <Alex[sp3dev]> if it works, why do you not just remove the handler?
Feb 26 21:29:19 <GNUtoo|laptop> instead of using a dummy interrupt handler
Feb 26 21:29:35 <GNUtoo|laptop> it's a possibility however it comes at a very high price:
Feb 26 21:29:41 <GNUtoo|laptop> the phone become slow as hell
Feb 26 21:29:51 <GNUtoo|laptop> and the dmesg is spammed with no handler message
Feb 26 21:30:00 <Alex[sp3dev]> well, first off. are you using bcm80211 or bcm4329 driver?
Feb 26 21:30:17 <GNUtoo|laptop> brcm80211/brcmfmac
Feb 26 21:30:42 <Alex[sp3dev]> dunno. works fine for me. both on tegra w/chromium kernel 2.6.38 and sgs2 with 3.2 linaro
Feb 26 21:31:01 <Alex[sp3dev]> have you updated bcm80211 to the latest from vanilla?
Feb 26 21:31:17 <GNUtoo|laptop> not exactly, last compat-wireless
Feb 26 21:31:20 <GNUtoo|laptop> so lastest possible
Feb 26 21:36:51 <GNUtoo|laptop> and each time I try a new one it ends up the same
Feb 26 21:36:57 <GNUtoo|laptop> no logs + freeze 
Feb 26 21:37:13 <GNUtoo|laptop> freeze means the phone doesn't react anymore to any kind of events
Feb 26 21:37:15 <GNUtoo|laptop> no ssh
Feb 26 21:37:19 <GNUtoo|laptop> no touchscreen etc...
Feb 26 21:37:24 <GNUtoo|laptop> no serial
Feb 26 21:58:25 <CIA-112> SHR: 03Martin.Jansa 07meta-smartphone * r7f887d078398 10/ (8 files in 5 dirs): Quoting fixes
Feb 26 22:32:21 <CIA-112> SHR: 03Martin.Jansa 07meta-smartphone * r104c02959052 10/meta-shr/conf/distro/shr.conf: meta-shr: try to disable gold for armv4
Feb 26 22:40:05 <CIA-112> SHR: 03Martin.Jansa 07shr-chroot * r462908fba348 10/ (15 files in 8 dirs): bitbake: add patch for caching fix
Feb 26 22:40:06 <CIA-112> SHR: 03Martin.Jansa 07shr-chroot * r11d2706d42b5 10/ (15 files in 8 dirs): bitbake: add patch for strict quotes
Feb 26 22:40:06 <CIA-112> SHR: 03Martin.Jansa 07shr-chroot * ra7785d78de51 10/ (12 files in 5 dirs): bitbake upgrade
Feb 26 22:45:07 <GNUtoo|laptop> JaMa|Off, hi
Feb 26 22:45:33 <GNUtoo|laptop> JaMa|Off, still nothing for a patch that fixes gold issues?
Feb 26 22:45:45 <GNUtoo|laptop> because I must also work on reverting to 2.6.34
Feb 26 22:47:29 <lindi-> GNUtoo|laptop: isn't an obvious fix to use bfd?
Feb 26 22:47:45 <GNUtoo|laptop> I don't want to recompile everything from scratch
Feb 26 22:47:55 <GNUtoo|laptop> that's what we'll do anyway if the patch timesout
Feb 26 22:48:02 <GNUtoo|laptop> and I may have to recompile from scratch anyway
Feb 26 22:53:02 <CIA-112> SHR: 03shr-devel 07buildhistory * r7d5722fb5785 10/ (17 files in 8 dirs): Build 201202262224 of shr 20120226 for machine palmpre2 on opmbuild
Feb 26 23:26:59 <GNUtoo|laptop> Alex[sp3dev], I guess you're out of ideas?
Feb 26 23:28:44 <Alex[sp3dev]> GNUtoo|laptop: more or less so. you should probably enable full debug in bcm80211 (either there was a cmdline switch or you can hack the header)
Feb 26 23:32:04 <GNUtoo|laptop> yes hack with the header
Feb 26 23:46:04 <GNUtoo|laptop> else I could just use bcm4329
Feb 26 23:46:11 <GNUtoo|laptop> with -DCSCAN removed
Feb 26 23:46:28 <GNUtoo|laptop> and adapted for compiling with -DCSCAN removed
Feb 26 23:47:05 <GNUtoo|laptop> and scanning with iwlist eth0 scan essid ""
Feb 26 23:52:16 <GNUtoo|laptop> I'll do both
Feb 26 23:52:25 <GNUtoo|laptop> the hack on bcm4329 is done and seem to work
Feb 27 01:48:13 <CIA-112> SHR: 03shr-devel 07buildhistory * rd82c7044b392 10/ (156 files in 146 dirs): Build 201202270001 of shr 20120226 for machine crespo on opmbuild
**** ENDING LOGGING AT Mon Feb 27 02:59:58 2012