**** BEGIN LOGGING AT Tue Sep 11 02:59:58 2012 Sep 11 06:22:21 SHR: 03Martin.Jansa 07shr-makefile * r4f1970dd4d29 10/conf/layers.txt: layers.txt: bump bitbake rev Sep 11 07:11:08 SHR: 03Martin.Jansa 07shr-chroot * rb30c9d36c081 10/ (868 files in 69 dirs): system upgrade Sep 11 07:26:08 morning Sep 11 07:26:28 hi ! Sep 11 07:31:10 morphis: ping Sep 11 07:34:58 progress :) progress ! I get warning slowpath and then schedule while atomic (boot proceed but not everything works) with a new fiq handler based on a sample on so Sep 11 07:35:12 excellent. which hardware are you working on again? Sep 11 07:35:32 gta02 currently (it is the sole user of the c fiq handler code :) Sep 11 07:35:41 ah, right Sep 11 07:35:52 i'm afraid i have no idea about the current state of mainline quality Sep 11 07:36:03 which tree are you basing on? Sep 11 07:36:22 shr linux-openmoko 2.6.39 Sep 11 07:36:42 with preempt enabled + collect statistics Sep 11 07:36:52 and iosched cfq Sep 11 07:47:10 prahal2: are you trying to upstream stuff or just fix the audio lag issue you mentioned? Sep 11 07:51:05 for upstreaming there is 3.5 branch by GNUtoo and some patches went up from that Sep 11 07:57:15 would be nice if he could add comments to http://wiki.openmoko.org/wiki/Kernel/Upstreaming Sep 11 07:58:34 lindi-: at that point audio lag is on hold ... I am spending some time learning fiq implementation Sep 11 07:59:02 though this fiq c handler code is not upstreamed at all Sep 11 07:59:56 prahal2: yeah that page lists the fiq c patch Sep 11 08:02:39 though as I am still learning arm assembly I took a whole block of code from stack overflow and adapted it . it works very well now Sep 11 08:03:59 in fact the issue I have is that the fiq c handler calls gpio request (add a spinlock) which trigger the slowpath this in an interrupt context and there seems to be a schedule which I have not yet tracked down Sep 11 08:05:10 so the issue was there ... the most intriguing is that it never triggered with the defconfig (there is a bug report on debian bts but I bet they also used a non default shr defconfig Sep 11 08:06:38 the main issue I have is copyright ... so I would better share my understanding of the fix than spoil other fellows Sep 11 08:07:34 I tried it as I was at the point were I thought this was a lost cause Sep 11 08:12:31 so I have to either sort out the stackoverflow policy . This was also a fiq handler for the linux kernel Sep 11 08:15:48 what I focusing on is to fix the underlying issue uncovered (the gpio request -> slow path -> schedule while atomic -> bq27x00 stuck Sep 11 08:19:27 I bet I could explain the way to fix the c fiq handler to anyone knowing arm assembly , half of the implementation I have is mine : the plumber work . The only peculiarity of the "upstream" patch is the stack handling . Sep 11 08:21:34 prahal2: hmm Sep 11 08:22:06 I think I have read the fiq code at least once Sep 11 08:22:14 and I do know ARM assembly Sep 11 08:51:32 http://prahal.homelinux.net/~prahal/gta02/fiq/ab.c.txt the thing in are what I took as is Sep 11 08:51:57 ie removed Sep 11 08:52:10 lindi-: ^ :) Sep 11 08:54:29 with preempt you will now have a nice warning then bug with proper backtrace instead of data aborted bad mode 0 and a backtrace about the kernel context (instead of fiq one) Sep 11 08:55:06 this is __fiq_c_handler Sep 11 08:57:02 the change to use start and end globals I took from arch/arm/mach-omap1/ams-delta-fiq.c Sep 11 08:57:10 upstream code Sep 11 08:57:12 hmm Sep 11 08:57:23 need to have lunch now... Sep 11 09:49:42 while cleaning I made a typo : in set_fiq_c_handler "unsigned int fiqhandler_length = &fiq_end - fiq_start;" should be "unsigned int fiqhandler_length = &fiq_end - &fiq_start;" Sep 11 09:59:27 he did not left any contact infos on stackov ... Sep 11 11:16:25 SHR: 03Martin.Jansa 07opimd-utils * rc77597eb7247 10/opimd-dates: adapt to API change in r59160 s/homogenous/homogeneous/g Sep 11 11:17:33 SHR: 03Martin.Jansa 07meta-smartphone * r0d06894d031a 10/meta-shr/recipes-shr/3rdparty/ (3 files in 2 dirs): ecalc: adapt to new EFL api Sep 11 11:17:33 SHR: 03Martin.Jansa 07meta-smartphone * r044746730a60 10/meta-fso/recipes-freesmartphone/freesmartphone/opimd-utils_git.bb: opimd-utils: bump SRCREV to adapt to new EFL api Sep 11 11:17:34 SHR: 03Martin.Jansa 07meta-smartphone * r783e32ff7c89 10/meta-shr/recipes-shr/3rdparty/ (4 files in 2 dirs): ecalc: replace local patches with SRCREV bump Sep 11 11:25:13 SHR: 03Martin.Jansa 07meta-smartphone * r097883cdf7a4 10/meta-shr/recipes-shr/3rdparty/ (4 files in 2 dirs): ecalc: replace local patches with SRCREV bump Sep 11 11:30:45 I removed a leftover disable preempt around the handler from my tests ... the schedule while atomic issue is gone . Still the gpio fails in warn slowpath Sep 11 11:35:07 SHR: 03Martin.Jansa 07meta-smartphone * r2496dddafe71 10/meta-shr/recipes-shr/3rdparty/ecalc_git.bb: ecalc: add PV Sep 11 12:23:12 SHR: 03Martin.Jansa 07meta-smartphone * rc46b4690efd7 10/meta-shr/recipes-shr/3rdparty/ecalc_git.bb: ecalc: bump PE for upgrade path Sep 11 12:35:48 http://www.alsa-project.org/main/index.php/Changes_v1.0.25_v1.0.26 >>alsaloop: Improve xrun_sync - fill missing playback samples<< Sep 11 13:24:24 lindi : I am making an attempt at redoing the assembly without temporary stack and temp registry array. If it succeed there will be nothing left from so code Sep 11 14:31:34 SHR: 03shr-devel 07buildhistory * r6b22edfd25f0 10/ (67 files in 67 dirs): packages: Build 201209111608 of shr 20120911 for machine nokia900 on opmbuild Sep 11 15:24:25 SHR: 03shr-devel 07buildhistory * r2ca61a384d38 10/packages/om_gta04-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201209111642 of shr 20120911 for machine om-gta04 on opmbuild Sep 11 16:11:04 SHR: 03shr-devel 07buildhistory * rba550034f2fd 10/packages/crespo-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201209111800 of shr 20120911 for machine crespo on opmbuild Sep 11 16:32:08 SHR: 03shr-devel 07buildhistory * rbc00ed8d9450 10/packages/tuna-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201209111821 of shr 20120911 for machine tuna on opmbuild Sep 11 17:03:33 SHR: 03shr-devel 07buildhistory * r417598442c26 10/packages/ (59 files in 59 dirs): packages: Build 201209111842 of shr 20120911 for machine om-gta02 on opmbuild Sep 11 17:04:52 I did not manage to fix the fiq c handler another way , ie without resorting to allocate a new stack in asm .. Sep 11 17:05:32 by the way did you know about the gnu fiq c handler ? I have not read the code yet but it is quite complete (includes facilities) Sep 11 17:06:45 there is also http://www.pabr.org/pxarc/doc/pxarc.en.html Sep 11 17:14:32 and the amstrad implementation that is already upstream Sep 11 17:16:02 hum no the later has a handler in asm Sep 11 17:17:21 though use a C interrupt handler and buffer to get the results Sep 11 17:30:36 the fiq handler looked good in its early incarnation but became weird after a while (looking at history) . Ie the fp = sp = ... the position of the __jump_to_isr :/ Sep 11 17:32:32 hum me misunderstanding the code .. it is in fact fp = sp = __jump_to_isr + 256 in latest 2.6.39.4 **** ENDING LOGGING AT Wed Sep 12 02:59:58 2012