[Dev] [CM10] Fixing in call audio bug for CM10

Search This thread
By:
Advanced…
T

tmsiqueira

Member
May 28, 2009
32
5
Campinas
Hello,

I didn't find this question: if only the mutex correct the problem, why the new partition/bootloader don't have the same problem?

Thks

Sent from my GT-P7500 using xda app-developers app
 
pengus77

pengus77

Recognized Developer
Mar 10, 2011
2,140
22,971
Penguins' Republic of Antarctica
tmsiqueira said:
Hello,

I didn't find this question: if only the mutex correct the problem, why the new partition/bootloader don't have the same problem?

Thks

Sent from my GT-P7500 using xda app-developers app
Click to expand...
Click to collapse

I've been looking into it for quite a while now and still i can't really pinpoint the reason. Also, on the old bl the audio crackles on boot/reboot, while it doesn't on the new one (at least on my phone using the latest cm10 available on the old bl). And considering that it crackles before loading the kernel, i suspect there's something in the bl itself that pre-initializes the hardware but i'm still quite far from the answer...
 
wfd

wfd

Senior Member
Mar 22, 2011
341
708
Togliatti
pengus77 said:
I've been looking into it for quite a while now and still i can't really pinpoint the reason. Also, on the old bl the audio crackles on boot/reboot, while it doesn't on the new one (at least on my phone using the latest cm10 available on the old bl). And considering that it crackles before loading the kernel, i suspect there's something in the bl itself that pre-initializes the hardware but i'm still quite far from the answer...
Click to expand...
Click to collapse

And the one thing else: with old bootloader we have a slow charge bug, but on new bootloader there is no such problem. Tested on pengus77 cm10 build, and I builded cm10.1 for new BL with fully stock official cm kernel (except a couple of necessary changes) and there is no slow charge, everythig fast and smooth.
 
  • Like
Reactions: kukharski and -SONNY-
tr@p

tr@p

Senior Member
Jun 18, 2010
832
950
Zagreb
wfd said:
And the one thing else: with old bootloader we have a slow charge bug, but on new bootloader there is no such problem. Tested on pengus77 cm10 build, and I builded cm10.1 for new BL with fully stock official cm kernel (except a couple of necessary changes) and there is no slow charge, everythig fast and smooth.
Click to expand...
Click to collapse

Yeah, that's another good reason to stick with new bootloader for now.
 
Morutimeru

Morutimeru

Senior Member
Feb 26, 2009
161
39
OPPO Find X3
meh~ can someone tell me how to build a kernel for the su660 with marsgod fix and the wifi fix by pengus? I'm using the kernel that marsgod built but it drains the battery super fast :(
 
aldyu

aldyu

Senior Member
Jun 21, 2012
653
181
Hi marsgod, maybe you can do your magic again for the slow charging bug in old bl? :fingers-crossed:
God bless...
 
pengus77

pengus77

Recognized Developer
Mar 10, 2011
2,140
22,971
Penguins' Republic of Antarctica
aldyu said:
Hi marsgod, maybe you can do your magic again for the slow charging bug in old bl? :fingers-crossed:
God bless...
Click to expand...
Click to collapse

Slow charging is partially fixed in my kernel already. The bootloader-compat code was forcing muic to stick with usb mode only and wasn't routing the charging logic to the maxim chip. Now it's ok-ish and the behaviour is the same for old and new bootloader. You can check the code changes on my github.
 
R

rajdoll

Senior Member
Feb 16, 2013
172
41
I'm not sure about the New bootloader as I never tried it but I can confirm that for me (PA-08-kk-112 old bootloader), there is almost 2 times the time difference between charging in CM7 and PA. But if I use start-charging-while-phone-off technique then it is same as CM7. This is just for info, if I'm missing something then help is welcome.
 
aldyu

aldyu

Senior Member
Jun 21, 2012
653
181
pengus77 said:
Slow charging is partially fixed in my kernel already. The bootloader-compat code was forcing muic to stick with usb mode only and wasn't routing the charging logic to the maxim chip. Now it's ok-ish and the behaviour is the same for old and new bootloader. You can check the code changes on my github.
Click to expand...
Click to collapse

I already applied your commit but the bug is still there. It's only 1 line of code right? By bootloader-compat code, are you referring to the patch by wkpark which still needed together with that commit?

Sent from my LG-P990
 
Freakthis08

Freakthis08

Senior Member
May 18, 2012
71
19
Minneapolis
Hi there!

First, I know I'm in the wrong forum for my device. I have the LG P999, but when I was searching for a problem I was having with my phone this thread was a big hit for me and I'm hoping to get some direction on how to fix my error. I attached a SS and a radio logcat of my problem.

Here is my problem (and I'm not fully sure if it's a problem or my OCD making me fix something that's looks REALLY wrong either way,)

I'm getting the error lge-ril: GET_NEIGHBORING_CELL_IDS; request function not defined and it's being almost spammed throughout the log. along with REQUEST_GET_NEIGHBORING_CELL_IDS error: com.android.internal.telephony.CommandExecption: GENERIC_FAILURE

Any guidance or help will let my nerves relax. Thank you!

EDIT:
ROM: CM7 March 01 2013
Kernel Maz's latest kernel http://xdaforums.com/showthread.php?t=2125818
 

Attachments

  • Radio_alogcat.2013-07-16.txt
    57.2 KB · Views: 2
Last edited:
You must log in or register to reply here.

Similar threads

temasek
[CM7][UNOFFICIAL][NOV10] temasek's UNOFFICIAL BUILD 135.4 - FINAL RELEASE
Replies
10K
Views
2M
reggiexp
reggiexp
pengus77
[KERNEL][stable: M1 (2.6.39.4) - exp: Alpha 31 (3.1.10)] Kowalski Kernel
Replies
9K
Views
2M
RepurposedPotential
RepurposedPotential
pengus77
[ROM] [2013-05-14] CM10 "Look Ma! No Hands!" Edition
Replies
4K
Views
677K
oneearleft
oneearleft
tonyp
[ROM][old|newbl] CM10.1 - tonyp - T-Build 05
Replies
3K
Views
1M
G
GuestD2211
vadonka
  • Poll
[CM7/MIUI Kernel][AUG21]CM7-ETaNa v2.6.32.59
Replies
6K
Views
1M
oneearleft
oneearleft

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 99
    M
    marsgod
    The call issue of CM10 ROMs is present for some people. There will be a trouble when making a call each other could not hear voice or the other side would only hear big noise.
    If you reboot the phone once a day (e.g. at the morning) it usually won't occur during the whole day, sometimes it will not fix the problem by reboot.

    I checked the offical V30C and V28G radio logcat , and found it is differnet to the CM10 radio logcat.

    you can verify this by
    Code: 
     adb logcat -b radio

    when making a call.

    The offical V28G logcat radio is something like this:
    Code: 
    D/GSM     (  351): [getVoiceMailNumber] isNetworkRoaming: false
D/PHONE   (  351): VM: PhoneSubInfo.getVoiceMailNUmber: 
D/GSM     (  351): isTwoDigitShortCode
D/GSM     (  351): dialing w/ mmi 'null'...
D/GSM     (  351): [GSMConn] acquireWakeLock
D/RILJ    (  351): [0162]> DIAL
D/RILC    (   88): [0162]> DIAL (num=88888888,clir=0)
D/RILC    (   88): [0162]< DIAL
D/RILJ    (  351): [0162]< DIAL 
D/RILC    (   88): [UNSL]< RIL_UNSOL_LGE_XCALLSTAT {1,2}
D/RILC    (   88): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 
D/RILJ    (  351): [UNSL]< LGE_XCALLSTAT
D/RILJ    (  351): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED
D/RILJ    (  351): [0163]> LGE_SET_CPATH 3
D/RILC    (   88): [0163]> RIL_REQUEST_LGE_SET_CPATH (3)
D/RILJ    (  351): [0164]> LGE_SET_CPATH 1
D/RILC    (   88): [0164]> RIL_REQUEST_LGE_SET_CPATH (1)
D/RILC    (   88): [0163]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0163]< LGE_SET_CPATH 
D/RILC    (   88): [0164]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0164]< LGE_SET_CPATH 
D/RILJ    (  351): [0165]> GET_CURRENT_CALLS
D/RILC    (   88): [0165]> GET_CURRENT_CALLS 
D/RILC    (   88): [0166]> GET_CURRENT_CALLS 
D/RILC    (   88): [0165]< GET_CURRENT_CALLS {[id=1,DIALING,toa=129,norm,mo,als=0,voc,noevp,88888888,cli=0,name='(null)',0}
D/RILJ    (  351): [0165]< GET_CURRENT_CALLS  [id=1,DIALING,toa=129,norm,mo,0,voc,noevp,,cli=1,,0] 
D/RILC    (   88): [0166]< GET_CURRENT_CALLS {[id=1,DIALING,toa=129,norm,mo,als=0,voc,noevp,88888888,cli=0,name='(null)',0}
D/RILJ    (  351): [0166]< GET_CURRENT_CALLS  [id=1,DIALING,toa=129,norm,mo,0,voc,noevp,,cli=1,,0] 
D/RILJ    (  351): [0167]> LGE_SET_CPATH 8
D/RILC    (   88): [0167]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILJ    (  351): [0168]> LGE_SET_CPATH 8
D/RILC    (   88): [0168]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILC    (   88): [0167]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0167]< LGE_SET_CPATH 
D/RILJ    (  351): [0168]< LGE_SET_CPATH 
D/RILJ    (  351): [0169]> LGE_SET_CPATH 8
D/RILC    (   88): [0169]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILC    (   88): [0169]< RIL_REQUEST_LGE_SET_CPATH
D/RILC    (   88): [0170]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILC    (   88): [0170]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0170]< LGE_SET_CPATH 
D/RILC    (   88): [UNSL]< RIL_UNSOL_LGE_XCALLSTAT {1,3}
D/RILJ    (  351): [UNSL]< LGE_XCALLSTAT
D/RILC    (   88): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 
D/RILJ    (  351): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED
D/RILC    (   88): [UNSL]< RIL_UNSOL_LGE_XCALLSTAT {1,3}
D/RILC    (   88): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 
D/RILJ    (  351): [0171]> GET_CURRENT_CALLS
D/RILJ    (  351): [UNSL]< LGE_XCALLSTAT
D/RILC    (   88): [0171]> GET_CURRENT_CALLS 
D/RILJ    (  351): [0172]> GET_CURRENT_CALLS
D/RILC    (   88): [0172]> GET_CURRENT_CALLS 
D/RILC    (   88): [0171]< GET_CURRENT_CALLS {[id=1,ALERTING,toa=129,norm,mo,als=0,voc,noevp,88888888,cli=0,name='(null)',0}
D/RILJ    (  351): [0171]< GET_CURRENT_CALLS  [id=1,ALERTING,toa=129,norm,mo,0,voc,noevp,,cli=1,,0] 
D/RILC    (   88): [0172]< GET_CURRENT_CALLS {[id=1,ALERTING,toa=129,norm,mo,als=0,voc,noevp,88888888,cli=0,name='(null)',0}
D/RILJ    (  351): [0172]< GET_CURRENT_CALLS  [id=1,ALERTING,toa=129,norm,mo,0,voc,noevp,,cli=1,,0] 
D/RILJ    (  351): [0173]> LGE_SET_CPATH 8
D/RILC    (   88): [0173]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILC    (   88): [0173]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0173]< LGE_SET_CPATH 
D/RILC    (   88): [UNSL]< RIL_UNSOL_LGE_XCALLSTAT {1,7}
D/RILJ    (  351): [UNSL]< LGE_XCALLSTAT
D/RILC    (   88): [UNSL]< RIL_UNSOL_LGE_XCALLSTAT {1,0}
D/RILC    (   88): [UNSL]< RIL_UNSOL_LGE_COLP {88888888,type=129,subaddr=,satype=-1, alpha=}
D/RILC    (   88): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 
D/RILJ    (  351): [UNSL]< LGE_XCALLSTAT
D/RILJ    (  351): [UNSL]< LGE_COLP COLP { number: 88888888, type: 129, subaddr:, satype: -1, alpha:  }
D/RILJ    (  351): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED
D/RILJ    (  351): [0174]> GET_CURRENT_CALLS
D/RILC    (   88): [0174]> GET_CURRENT_CALLS 
D/RILC    (   88): [0174]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=129,norm,mo,als=0,voc,noevp,88888888,cli=0,name='(null)',0}
D/RILJ    (  351): [0175]> LGE_SET_CPATH 8
D/RILJ    (  351): [0174]< GET_CURRENT_CALLS  [id=1,ACTIVE,toa=129,norm,mo,0,voc,noevp,,cli=1,,0] 
D/RILC    (   88): [0175]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILC    (   88): [0175]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0175]< LGE_SET_CPATH 
D/RILJ    (  351): [0176]> LGE_SET_CPATH 8
D/RILC    (   88): [0176]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILC    (   88): [0176]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0176]< LGE_SET_CPATH 
D/RILC    (   88): [UNSL]< UNSOL_SIGNAL_STRENGTH {[signalStrength=18,bitErrorRate=-1,                CDMA_SS.dbm=-1,CDMA_SSecio=-1,                EVDO_SS.dbm=-1,EVDO_SS.ecio=-1,                EVDO_SS.signalNoiseRatio=-1,                LTE_SS.signalStrength=-1,LTE_SS.rsrp=-1,LTE_SS.rsrq=-1,                LTE_SS.rssnr=-1,LTE_SS.cqi=-1]}
D/RILJ    (  351): [0177]> LGE_HANG_UP_CALL
D/RILC    (   88): [0177]> RIL_REQUEST_LGE_HANG_UP_CALL 
D/RILC    (   88): [0177]< RIL_REQUEST_LGE_HANG_UP_CALL
D/RILJ    (  351): [0177]< LGE_HANG_UP_CALL 
D/RILJ    (  351): [0178]> GET_CURRENT_CALLS
D/RILC    (   88): [0178]> GET_CURRENT_CALLS 
D/RILC    (   88): [0178]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=129,norm,mo,als=0,voc,noevp,88888888,cli=0,name='(null)',0}
D/RILJ    (  351): [0178]< GET_CURRENT_CALLS  [id=1,ACTIVE,toa=129,norm,mo,0,voc,noevp,,cli=1,,0] 
D/RILJ    (  351): [0179]> LGE_SET_CPATH 8
D/RILC    (   88): [0179]> RIL_REQUEST_LGE_SET_CPATH (8)
D/RILC    (   88): [0179]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0179]< LGE_SET_CPATH 
D/RILC    (   88): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 
D/RILJ    (  351): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED
D/RILC    (   88): [UNSL]< RIL_UNSOL_LGE_XCALLSTAT {1,6}
D/RILC    (   88): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED 
D/RILJ    (  351): [UNSL]< LGE_XCALLSTAT
D/RILJ    (  351): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED
D/RILJ    (  351): [0180]> GET_CURRENT_CALLS
D/RILC    (   88): [0180]> GET_CURRENT_CALLS 
D/RILJ    (  351): [0181]> GET_CURRENT_CALLS
D/RILC    (   88): [0181]> GET_CURRENT_CALLS 
D/RILC    (   88): [0180]< GET_CURRENT_CALLS }
D/RILJ    (  351): [0180]< GET_CURRENT_CALLS  
D/RILC    (   88): [0181]< GET_CURRENT_CALLS }
D/RILJ    (  351): [0181]< GET_CURRENT_CALLS  
D/RILJ    (  351): [0182]> LGE_SET_CPATH 0
D/RILC    (   88): [0182]> RIL_REQUEST_LGE_SET_CPATH (0)
D/RILC    (   88): [0182]< RIL_REQUEST_LGE_SET_CPATH
D/RILJ    (  351): [0182]< LGE_SET_CPATH 
D/RILC    (   88): [UNSL]< UNSOL_SIGNAL_STRENGTH {[signalStrength=19,bitErrorRate=-1,                CDMA_SS.dbm=-1,CDMA_SSecio=-1,                EVDO_SS.dbm=-1,EVDO_SS.ecio=-1,                EVDO_SS.signalNoiseRatio=-1,                LTE_SS.signalStrength=-1,LTE_SS.rsrp=-1,LTE_SS.rsrq=-1,                LTE_SS.rssnr=-1,LTE_SS.cqi=-1]}

    As you can see,
    1. when the call start, the ril send
    LGE_SET_CPATH 3
    LGE_SET_CPATH 1 (if you make the call via headset, it will be LGE_SET_CPATH 2)
    2. during the call session, the ril send
    LGE_SET_CPATH 8
    3. after ending the call , the ril send
    LGE_SET_CPATH 0

    so, I make a fix for the LGEInfineon.java(thank rmcc provide the original code, if I didn't remenber wrong...), try to simulate this command sequence in it(not very accu, but I think it will be OK).
    you can put this file in your source tree “device/lge/star-common/ril/telephony/java/com/android/internal/telephony”, then rebuild the CM10 source.
    Hope this can fix the CM10 call bug.

    PS: lipisak built a CM10 here: http://xdaforums.com/showpost.php?p=34672614&postcount=47
    [WARNING]: I am not sure whether this fix will fix the audio bug or not, so it is a DEV test....


    2012/11/27:
    Another found : In V30C lge-ril.so, it used /dev/block/mmcblk0p5 as a datastorge for write_nvidia function, which will write IMEI, SWV, SWOV, INFO in it. But as CM partitions definition, /dev/block/mmcblk0p5 is used as boot.img....... I am not sure it will cause problem or not. But a dirty fix of lge-ril.so, which will use a hexeditor modified the binary code, would workaround this.
    If in your logcat -b radio found these: write IMEI ok, write IMEI ng. write SWV ok, write SWV ng, write SWOV ok, write SWOV ng, write INFO ok, write INFO ng. then your boot.img would be corrupted.[Thank wkpark pointed out that In V30C, /dev/block/mmcblk0p5 is /misc not /data/ve, /dev/block/mmcblk0p10 is the /data/ve in V30C]

    2012/11/29:
    Fix MSC partition problem[PLEASE NOTE: THIS ASSUME YOU USE THE OLD GB BOOTLOADER & PARTITION, not OFFICIAL BOOTLOADER & PARTITION]
    1. use the attached liblgeril.so, this is a quick fix in binary : mmcblk0p5=>mmcblk0p3
    2. modified your kernel source code arch/arm/mach-tegra/lge/star/include/lge/board-star-nv.h
    Code: 
    #ifdef CONFIG_CM_BOOTLOADER_COMPAT
#define LGE_NVDATA_PARTITION                    "/dev/block/mmcblk0p3"
#else
#define LGE_NVDATA_PARTITION                    "/dev/block/mmcblk0p5"
#endif
    then recompile your kernel.
    3. fix init.rc. modify the rild group id:
    Code: 
    group radio cache inet misc audio sdcard_rw log system media_rw
    4. fix uevent.tegra.rc, add a line at bottom:
    Code: 
    /dev/block/mmcblk0p3      0660   system     radio

    2012/12/04:
    Found a temp fix for this, when you encounter the call bug, just reboot into recovery, do nothing, reboot. This will fix the phone for a while..

    2012/12/07:
    By compare linux 3.6.9 kernel source to V30C kernel source code, I found that the V30C kernel source wm8994.c has some bugs in it. There are a copy/paste bug and many "switch" "case" "break" mismatch bugs. I made a patch file to fix this. Goto your kernel source sound/soc/codes, input patch wm8994.c < wm8994.diff

    2012/12/25:
    Another fix for audio problem:
    During the wm8994 suspend/resume , it use a unsafe version of read/write registers. I just modify the code , use a mutex lock protect version of register read/write.
    Hope this can make some help.

    https://github.com/marsgod/lge-kernel-star/commit/02fab112d1dc63387b4474fbcf99e7bb9d617236

    I guess when an incoming call trigger, the wm8994 resume, it will take a long time 'restore' the wm8994 registers(because it use the I2C interface), if this process were interrupted by another read/write wm8994 attemp, it will cause problem.

    2012/12/29:
    Based on above patch, I built two kernel for P990 & SU660, as the attached files. Please have a try.
    Just use CWM flash these zip files. The zip file will only update your kernel & modules, there is NO need make a factory reset or clean your cache/data.

    EDIT: for P990 kernel , please check http://xdaforums.com/showpost.php?p=36032539&postcount=661
    View
    38
    M
    marsgod
    marsgod said:
    Another fix for audio problem:

    During the wm8994 suspend/resume , it use a unsafe version of read/write registers. I just modify the code , use a mutex lock protect version of register read/write.
    Hope this can make some help.

    https://github.com/marsgod/lge-kernel-star/commit/02fab112d1dc63387b4474fbcf99e7bb9d617236
    Click to expand...
    Click to collapse

    After a week's testing, I got NO call bug.
    Kernel developers can safely apply this patch.
    Hope this can merge into official kernel release.
    View
    35
    tonyp
    tonyp
    Allright, here's the kernel zip:
    http://goo.im/devs/tonyp/P990-stuff/JB/P990-oldBL-testkernel-tonyp-20121229.zip
    This is for the old BL of course. As I'm on the new one this is untested, please provide feedback.

    It does include the new fix by marsgod and the wifi fixes by pengus77 - apart from that it's arcee's CM10 kernel.
    All credits to them.

    Regarding the callbug - you need to wait at least two days before you should post "no callbugs".
    If you do have one post right away.
    View
    20
    M
    marsgod
    x_justin said:
    Yes me too, it's obviously not a baseband problem because it even doesn't matter whether you're using SU660 BB's or the P990 ones.

    Isn't it that calling and beïng called work as follows:

    - phone.apk sends a request to the RIL (pick up when beïng called or DIAL when call)
    - RIL sends request to baseband
    - Baseband commands with the carrier: picks up the line or dials a number
    - Baseband receives sync back from carier, like 'connected'
    - Baseband sends this back to the RIL
    - RIL sends this back to phone.apk or directly into the kernel, I don't know

    Then 3 cases are posible:
    - Both sending audio and receiving audio works
    - Receiving audio works, sending (mic) doesn't work
    - Receivind audio works, sending is highly distorted and noisy

    So there are some options left:
    1: Kernel contains driver parts of the SU660 which aren't supported by P990. doesn't sound plausible, because excellent calling is also possible sometimes.
    2: SU660 has two mics, one for noise cancelling and one for calling (just a guess, p990 has only one mic, SU660... dont know), RIL requests the kernel to activate mic, but wrong mic is beïng activated so only the noise cancel mic is working (but there is no noise canceling mic) hmm not really plausible, just guessing.

    I don't know if i'm right, but I just want to figure out all options.
    Click to expand...
    Click to collapse

    Thank man, I think there maybe some other possible reasons:
    1. The official ROM used a unlock bootloader, and difference partition table. Some RIL or audio part will try to communicate with bootloader or check partition's saved values...I found that lge-ril.so try to save info in its MSC partition, and this is call mmcblk0p5 in official partion, but mmcblk0p3 in CM10 partition.
    2. rild service started up with group media_rw , but CM10 rild startup without this permission.it will cause the rild access MSC partition fail.
    3.wm8994 codec has some strange audio path config , and you can see this in dmesg, a audio path config fail. I think at run time, after some days , the wm8994 codec will work wrong when you making a call. It just "connect " wrong audio path to your baseband.
    4. some other reasons, such as the ram_console use a physical address 0x17800000 save reserved buffer, maybe this will corrupt some other apps (maybe RIL?)

    BTW, I used a SU660, the CM10 call bug still exist, so it is not just a SU660/P990 difference. I am testing some new fixes in my phone, made some calls and found no bug now, still testing..........
    View
    20
    M
    marsgod
    2012/12/29:
    Based on above patch, I built two kernel for P990 & SU660, as the attached files. Please have a try.
    Just use CWM flash these zip files. The zip file will only update your kernel & modules, there is NO need make a factory reset or clean your cache/data.

    Please feedback after 7 days or when you encounter a call bug.

    (please check the first post for download the zip files)
    View

New posts