search

diepquynh / android_device_samsung_scx30g2-common

Common device repository for Samsung devices with Spreadtrum SC7730SE (SC7731 - scx30g2) platform
2 stars 8 forks source link

RIL problems #1

Open enriquezmark36 opened 6 years ago

enriquezmark36 commented 6 years ago

Hello again, I'm trying to build cm 13.0 for kanas (core 2, SM-G355H) using this source as a reference.

First of all thank you if you decide to read this.

How do you make the ril work without failing? The ril works on dual sim but later on, the phone will reboot. From the last_kmsg file, it is hinted that modemd is responsible:

<0>[   76.533472]  [2:         modemd:  241] 
<0>[   76.533541]  [2:         modemd:  241] [c2] sc8830_machine_restart (h, (null))

Then I tried compiling modemd from source that does not reboot (like the one I'm using) or trigger a kernel panic (like the one from stock). I got these messages from main buffer of logcat.

07-02 15:48:25.204  3182  3205 D         : RIL_onMultiClientUnsolicitedResponse:
07-02 15:48:25.204  3182  3205 E         : unsupported multiclient unsolicited response code 1009
07-02 15:48:25.481   213   221 D MODEMD  : buf=W Modem Assert in file PS/layer1/wlayer1/drv/rfic/sr3130/src/drv_rf_nv_sr3130_calibration_wcdma.c at line 2666 exp=PS Assert! info=[]W Modem Assert in file PS/layer1/wlayer1/drv/rfic/sr3130/src/drv_rf_nv_sr3130_calibration_wcdma.c at line 2666 exp=PS Asser
07-02 15:48:25.485   213   221 D MODEMD  : modem assert happen
07-02 15:48:25.485   213   221 E MODEMD  : Info all the sock clients that modem is assert/hangup
07-02 15:48:25.485   213   221 E MODEMD  : client_fd[0]=6
07-02 15:48:25.486   213   221 E MODEMD  : write 256 bytes to client_fd[0]:6
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[1]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[2]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[3]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[4]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[5]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[6]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[7]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[8]=-1
07-02 15:48:25.486   213   221 E MODEMD  : client_fd[9]=-1
07-02 15:48:25.486   213   221 D MODEMD  : modem reset is not enabled , will not reset
07-02 15:48:25.486   213   221 D MODEMD  : detect_sipc_modem: wait for modem assert/hangup event ...
07-02 15:48:25.486   213   221 D MODEMD  : buf=t! info=[]
07-02 15:48:25.486   213   221 D MODEMD  : detect_sipc_modem: wait for modem assert/hangup event ...
07-02 15:48:25.489   229   697 D audio_hw_primary: modem_monitor: W Modem Assert in file PS/layer1/wlayer1/drv/rfic/sr3130/src/drv_rf_nv_sr3130_calibration_wcdma.c at line 2666 exp=PS Assert! info=[]W Modem Assert in file PS/layer1/wlayer1/drv/rfic/sr3130/src/drv_rf_nv_sr3130_calibration_wcdma.c at line 2666 exp=PS Asser
07-02 15:48:25.490   229   697 D audio_hw_primary: modem asserted1 W Modem Assert in file PS/layer1/wlayer1/drv/rfic/sr3130/src/drv_rf_nv_sr3130_calibration_wcdma.c at line 2666 exp=PS Assert! info=[]W Modem Assert in file PS/layer1/wlayer1/drv/rfic/sr3130/src/drv_rf_nv_sr3130_calibration_wcdma.c at line 2666 exp=PS Asser

and radio buffer:

07-02 15:48:22.645  3184  3184 D DefaultPhoneNotifier: notifySignalStrength: mRegistry=com.android.internal.telephony.ITelephonyRegistry$Stub$Proxy@71b8a43 ss=SignalStrength: 17 99 -120 -160 -120 -1 -1 99 2147483647 2147483647 2147483647 2147483647 2147483647 gsm|lte sender=Handler (com.android.internal.telephony.gsm.GSMPhone) {45c6653}
07-02 15:48:23.921  3182  3205 D use-Rlog/RLOG-AT: [w] Channel0: AT< +CSQ: 15,99
07-02 15:48:23.922  3182  3205 D use-Rlog/RLOG-AT: [w] Channel0: AT< +CSQ: 15,99
07-02 15:48:23.922  3182  3205 D use-Rlog/RLOG-AT: [w] Channel0: AT< +SPSCSQ: 15,99,1
07-02 15:48:23.922  3182  3205 D use-Rlog/RLOG-RILC: [w] [UNSL]< UNSOL_SIGNAL_STRENGTH {[signalStrength=14,bitErrorRate=99,                CDMA_SS.dbm=-1,CDMA_SSecio=-1,                EVDO_SS.dbm=-1,EVDO_SS.ecio=-1,                EVDO_SS.signalNoiseRatio=-1,                LTE_SS.signalStrength=99,LTE_SS.rsrp=2147483647,LTE_SS.rsrq=2147483647,                LTE_SS.rssnr=2147483647,LTE_SS.cqi=2147483647]}
07-02 15:48:23.923  3184  3184 D DefaultPhoneNotifier: notifySignalStrength: mRegistry=com.android.internal.telephony.ITelephonyRegistry$Stub$Proxy@71b8a43 ss=SignalStrength: 17 99 -120 -160 -120 -1 -1 99 2147483647 2147483647 2147483647 2147483647 2147483647 gsm|lte sender=Handler (com.android.internal.telephony.gsm.GSMPhone) {45c6653}
07-02 15:48:25.204  3182  3205 D use-Rlog/RLOG-AT: [w] Channel0: AT< +CSQ: 15,99
07-02 15:48:25.204  3182  3205 D use-Rlog/RLOG-AT: [w] Channel0: AT< +CSQ: 15,99
07-02 15:48:25.204  3182  3205 D use-Rlog/RLOG-AT: [w] Channel0: AT< +SPSCSQ: 15,99,1
07-02 15:48:25.205  3182  3205 D use-Rlog/RLOG-RILC: [w] [UNSL]< UNSOL_SIGNAL_STRENGTH {[signalStrength=14,bitErrorRate=99,                CDMA_SS.dbm=-1,CDMA_SSecio=-1,                EVDO_SS.dbm=-1,EVDO_SS.ecio=-1,                EVDO_SS.signalNoiseRatio=-1,                LTE_SS.signalStrength=99,LTE_SS.rsrp=2147483647,LTE_SS.rsrq=2147483647,                LTE_SS.rssnr=2147483647,LTE_SS.cqi=2147483647]}
07-02 15:48:25.206  3184  3184 D DefaultPhoneNotifier: notifySignalStrength: mRegistry=com.android.internal.telephony.ITelephonyRegistry$Stub$Proxy@71b8a43 ss=SignalStrength: 17 99 -120 -160 -120 -1 -1 99 2147483647 2147483647 2147483647 2147483647 2147483647 gsm|lte sender=Handler (com.android.internal.telephony.gsm.GSMPhone) {45c6653}
07-02 15:48:31.940  3184  4973 D SubscriptionController: [getActiveSubIdList] simInfoSet=[0=1, 1=2]
07-02 15:48:31.941  3184  4973 D SubscriptionController: [getActiveSubIdList] X subIdArr.length=2
07-02 15:48:31.954  3184  3196 D SubscriptionController: [getActiveSubIdList] simInfoSet=[0=1, 1=2]
07-02 15:48:31.954  3184  3196 D SubscriptionController: [getActiveSubIdList] X subIdArr.length=2
07-02 15:48:31.964  3184  4974 D SubscriptionController: [getActiveSubIdList] simInfoSet=[0=1, 1=2]
07-02 15:48:31.965  3184  4974 D SubscriptionController: [getActiveSubIdList] X subIdArr.length=2
07-02 15:48:31.969  3184  3369 D SubscriptionController: [getActiveSubIdList] simInfoSet=[0=1, 1=2]
07-02 15:48:31.969  3184  3369 D SubscriptionController: [getActiveSubIdList] X subIdArr.length=2
07-02 15:49:35.943  3184  4974 D SubscriptionController: [getActiveSubIdList] simInfoSet=[0=1, 1=2]
07-02 15:49:35.944  3184  4974 D SubscriptionController: [getActiveSubIdList] X subIdArr.length=2
07-02 15:49:35.954  3184  4973 D SubscriptionController: [getActiveSubIdList] simInfoSet=[0=1, 1=2]
07-02 15:49:35.954  3184  4973 D SubscriptionController: [getActiveSubIdList] X subIdArr.length=2
07-02 15:49:35.966  3184  3196 D SubscriptionController: [getActiveSubIdList] simInfoSet=[0=1, 1=2]
07-02 15:49:35.966  3184  3196 D SubscriptionController: [getActiveSubIdList] X subIdArr.length=2

Also I'm curious about these two lines in build.prop/system.prop (which I copied from stock):

persist.sys.sprd.modemreset=0
persist.sys.sprd.wcnreset=1

No Idea what it is or what it does.

P.S. I tried getting the dmesg log but it is always spammed by PM, cpufreq_scx35, "BUG: using smp_processor_id() in preem", and register dumps. I think I was wrong about RILJ being the culprit but right now I have a weird feeling that it's the NVRAM's fault.

diepquynh commented 6 years ago

Nah it's not anything but out of memory for modem (seems not related eh?) If kanas support device tree in kernel then I suggest picking this commit: https://github.com/remilia15/android_kernel_samsung_core33g/commit/699735934faf62d996fba08a36e7c561e5f577c4#diff-d6194c68fcc7e79bb57401be603cb1cc

Or else, remove refnotify binary from vendor blobs list. This one is from 4PDA users suggestion

enriquezmark36 commented 6 years ago

Okay, will try.

enriquezmark36 commented 6 years ago

@remilia15, wait would this remove about 4 MB of usable ram? 4MB is not that large to be concerned about but just asking. Also, arch/arm/boot/dts/sprd-scx35.dtsi doesn't exist in the kernel tree so this is not applicable. Though, I think I know the code that determines the size of allocation.

diepquynh commented 6 years ago

Yes it takes more 4MB of physical memory for modem

enriquezmark36 commented 6 years ago

Welp, there's no dts files anywhere ....

diepquynh commented 6 years ago

Could you try the second solution I mentioned above?

enriquezmark36 commented 6 years ago

Do you mean to remove the refnotify from the vendor blobs to let the refnotify binary build from source? Or just simply removing it from the whole rom?

diepquynh commented 6 years ago

Just simply remove it. Source-built RIL-related thing will never work for us, unless you have assembly knowledge to edit those sources

enriquezmark36 commented 6 years ago

Ahh wait, I'm currently testing the first idea.

enriquezmark36 commented 6 years ago

This might take some time. @remilia15 , is there any trigger for this? To test this I usually have wait at least about 3 hours until I see the error.

diepquynh commented 6 years ago

You'll see when it losts RIL signals I have to wait too, and it took me very long time finding real solution for this

enriquezmark36 commented 6 years ago

So, I tried removing the refnotify binary and the signal lasted for about 4 hours. The error is the same but with different assert line: MODEMD : buf=W Modem Assert in file PS/layer1/wlayer1/wl1c/src/wl1c_xdsp.c at line 1959 exp=PS Assert! info=[]W Modem Assert in file PS/layer1/wlayer1/wl1c/src/wl1c_xdsp.c at line 1959 exp=PS Assert! info=[] Then, I added the refnotify back and proceeded adding about 5 MB of ram (from 33 MB to 38 MB) for the modem and it lasted for about 10 hours and 26 minutes.

It really seems that this is a memory problem, or a leak on the firmware. I don't have much ideas anymore rather than downgrading the firmware or trying the libs directory from ih24n69's lollipop device tree. I guess time to rebuild the rom or downgrade the firmware or whichever comes first.

EDIT: I didn't timed the ril signals. I just computed it from uptime and the radio logcat timestamps.

enriquezmark36 commented 6 years ago

@remilia15 , even a modem firmware down/crossgrade still causes the failure. That's it; I have no more significant ideas to try... EDIT: Actually, this is the shortest one. It took about an hour and 24 mins.

diepquynh commented 6 years ago

Seems you need to dig sprd_cproc source code XD

enriquezmark36 commented 6 years ago

What's that? Also, about the firmware, newer updates bring no changes to the modem since their md5 checksums did not change.

EDIT: Aww, it allows to interface with the modem located at drivers/misc/sprd_cproc.

enriquezmark36 commented 6 years ago

I didn't get anything from cproc. The status file in /proc/cpw/ says that it is still running even when it is blocked. Is it possible though to let modemd reset the entire radio hardware when this assertion fails?

EDIT: It IS possible to reset the modem, but it is a hassle (since the downtime can last at most a minute). So, it can only be considered as a workaround. But wow, at least thank you for a workaround. EDIT3: @remilia15, is these trails in the radio logcat kinda OK? I mean there's a lot of these messages repeated every second? I mean there's no LTE support and there's LTE_SS.signalStrength=99.

7-03 21:27:31.153  3692  3729 D use-Rlog/RLOG-AT: [w] Channel3: AT< +CSQ: 18,99
07-03 21:27:31.153  3692  3729 D use-Rlog/RLOG-AT: [w] Channel3: AT< +CSQ: 18,99
07-03 21:27:31.153  3692  3729 D use-Rlog/RLOG-AT: [w] Channel3: AT< +SPSCSQ: 18,99,1
07-03 21:27:31.154  3692  3729 D use-Rlog/RLOG-RILC: [w] [UNSL]< UNSOL_SIGNAL_STRENGTH {[signalStrength=14,bitErrorRate=99,                CDMA_SS.dbm=-1,CDMA_SSecio=-1,                EVDO_SS.dbm=-1,EVDO_SS.ecio=-1,                EVDO_SS.signalNoiseRatio=-1,                LTE_SS.signalStrength=99,LTE_SS.rsrp=2147483647,LTE_SS.rsrq=2147483647,                LTE_SS.rssnr=2147483647,LTE_SS.cqi=2147483647]}
07-03 21:27:31.155  3489  3489 D DefaultPhoneNotifier: notifySignalStrength: mRegistry=com.android.internal.telephony.ITelephonyRegistry$Stub$Proxy@f54c7f3 ss=SignalStrength: 17 99 -120 -160 -120 -1 -1 99 2147483647 2147483647 2147483647 2147483647 2147483647 gsm|lte sender=Handler (com.android.internal.telephony.gsm.GSMPhone) {55715fe}
enriquezmark36 commented 6 years ago

Sorry again but may I ask again what does this: remilia15/android_kernel_samsung_core33g@6997359#diff-d6194c68fcc7e79bb57401be603cb1cc does? I think I've re-done it correctly but it still fails after some 16 hours to 17 hours of operation. I wonder if its doomed to be reset after some period of time.

diepquynh commented 6 years ago

which line is it? My browser somehow can't navigate to the specified path lol

enriquezmark36 commented 6 years ago

ay, I've copied the wrong one: https://github.com/remilia15/android_kernel_samsung_core33g/commit/699735934faf62d996fba08a36e7c561e5f577c4#diff-d6194c68fcc7e79bb57401be603cb1cc

The dts file doesn't exist so I tried finding the definitions.

diepquynh commented 6 years ago

Still the same :x

enriquezmark36 commented 6 years ago

What still the same? I don't think I got the right image of it. The commit I've made is on this: https://github.com/enriquezmark36/android_kernel_samsung_kanas/commit/7808fe39b38c380ae2dbf3ba42c603ef85b9b629

enriquezmark36 commented 6 years ago

What happens when you click on the link?

diepquynh commented 6 years ago

It loads on the head of the page Normally if there's a #diff-commit-id then it should navigate to the specified file

Btw update: My users are still experiencing reboots somehow. I'll need to dig this harder

enriquezmark36 commented 6 years ago

Maybe, just maybe its because the commit only touched a single file?

Sigh Well, thank God this only fails on dsds but not on single sim. The best workaround I've seen and am currently using is to reset the modem every time it fails. Time to go back to single sim, hahahaha.

TBH, I really haven't tested dsds on his lollipop build long enough or at least longer than 17 hours.

enriquezmark36 commented 6 years ago

Quick question, does this commit https://github.com/remilia15/android_kernel_samsung_core33g/commit/699735934faf62d996fba08a36e7c561e5f577c4#diff-5cfeca591c31a02f16a1650ebea1566fR585 produces a message failed to alloc smem from gen pool on early boot up (even before init starts)?

diepquynh commented 6 years ago

No, it shouldn't

enriquezmark36 commented 6 years ago

Thank you, so that explains it... I'm still investigating the assert error on my device, and what's worst is that one test take more than a half of a day :)

Oh yeah, may I ask how different is android 7.1 from android 6?

diepquynh commented 6 years ago

By different you mean source or something?

enriquezmark36 commented 6 years ago

Yep, I meant the source. Although I am plenty satisfied with my home built rom of android 6, I think i should try working on android 7.1 and see how far I could go before school starts again.

diepquynh commented 6 years ago

For kernel, you need to pick binder, seccomp and selinux commits. seccomp is needed for codecs stuff (and you know what binder and selinux do)

For device sources, not much different from MM, except fixing crappy bugs like camera, RIL (I'm sure these are easy if you know C++ and java stuffs). N needs legacy HAL1 impl for camera, as we're using prebuilt camera blobs that use HAL1 impl, so you need to define TARGET_HAS_LEGACY_CAMERA_HAL1 to get it working

Well maybe those are what I could remember. You can check my device trees as reference then XD

enriquezmark36 commented 6 years ago

Sorry for late reply and also thanks for that. But, isn't sdcardfs needed from the kernel too?

enriquezmark36 commented 6 years ago

I dunno if I could use your scx35-common repository since that really helped a lot. Though I have to override some flags here and there because the device doesn't use a dt image. And, I have to modify it's Android.mk file to let 'kanas' in. Despite all of that, I was able to run Android 7.1. Thank you very much for that.

Still the problem with dual sim persists but with the workaround it became almost invisible or was it because I reboot my device often. It seems a new problem surfaced although it's not serious.

There's a battery drain problem concerning the RILJ wakelock. Any idea what it could be?

PS. Is it really that hard to swipe unlock the lockscreen in android 7.1?

diepquynh commented 6 years ago

That wakelock could be caused by the RAF configuration on N, and since, we have to use static RAF for that or wakelocks or couldn't switch preferred network type

And yeah, you can use my repo. It's open-source right? And it's free also xD

About lockscreen, maybe it's the touch driver bug

enriquezmark36 commented 6 years ago

Thanks, I'll investigate these later. Also, what I mean about your repo is that this line in Android.mk ifneq ($(filter grandprimeve3g coreprimeve3g core33g,$(TARGET_DEVICE)),) I'm currently having an internal debate whether I should be using this or not, or should I just copy everything from your repo instead to avoid the Android.mk file... hmm?

Ay, there's also that issue regarding the sim toolkit that always says "check operator services" despite sending 3 successful requests.

enriquezmark36 commented 6 years ago

Can I ask you a side question about Bluetooth? Did you experience some failure in nougat that falls along the lines? I can't pair any bluetooth device. bt_hci : command_timed_out hci layer timeout waiting for response to a command. opcode: 0xc12

diepquynh commented 6 years ago

No, I haven't

enriquezmark36 commented 6 years ago

Thanks, sorry to bother you. It was my fault not paying attention on what I am typing in the BoardConfig.mk file. A single character does make a lot of difference, hehehe.

enriquezmark36 commented 6 years ago

It's working now on Nougat, even the emergency cell broadcasts work. Then I tried Oreo, still using your scx35-common repo, my custom kernel from 2016 (of course with different config file, lol), and did hex-editing libraries in the my device's vendor repo.

But, rild crashes with this line: CANNOT LINK EXECUTABLE "/vendor/bin/hw/rild": cannot locate symbol "ril_service_name" referenced by "/system/vendor/bin/hw/rild"...'

Wasn't this supposed to be part of the shim lib? Or did Oreo really did an upheaval of the entire ril API? It could be both?

diepquynh commented 6 years ago

ril_service_name isn't in our SHIM tho, but you can shim it manually Weird here, O rild isn't supposed to give that missing symbol. Are you using prebuilt libril?

enriquezmark36 commented 6 years ago

I am using the prebuilt libril, why though? Maybe, I'll try to use the O's libril after solving the weird TWRP 3.0.2 error: This package is for device kanas; this is a . Yep it's just a dot. Guess I'll need to build a newer one...

diepquynh commented 6 years ago

O ditched RIL sockets, so prebuilt libril and rild is totally useless. You have to build your own libril with fixes for Sammy

I suggest using my latest lineage-15.1 branch of hardware_sprd and device_scx35-common, or build your own using LOS' hardware_samsung repo's ril for required hacks for Samsung RIL

enriquezmark36 commented 6 years ago

Oh, that's why the frameworks/opt/telephony patch cannot be not used anymore.

Thanks for the advice, but I'm already using your hardware_sprd and device_scx35-common repos since it just works and also to avoid duplicated labor. I'll try to rearrange the Makefiles to use the source-built RIL, tomorrow. Again, much thanks for your repos and to those who've contributed!