Sudden Signal Loss - Pls Help - Xiaomi Mi 9 Questions & Answers
Dear friends,
I got Mi 9 MIUI 12.0.3
These past days there are periods withing day that phone loses signal (antenna bar disappears) and then recconects within 2 seconds. It goes like that back and forth
Seems provider doesnt have issues. Also I havent removed my sim card. Only thing I can think of is MIUI update to 12.0.3
These doesnt happen all day just some periods within day.
Can you guys think of something?
Thanks!
hello, have you found a solutionn yet?
I experience similar issue, currently on crDroid 7.10, but it was also happening on Xiaomi.eu. It usually happens during commute, but sometimes also randomly. I'm using dual sim configuration, usually connected to LTE.
One time I decided to gather logs on my commute and below is the result. It seems to be some kind of problem with modem firmware in my case.
Code:
09-22 18:59:23.641 E/ (0): Fatal error on modem!
09-22 18:59:23.641 E/ (0): modem subsystem failure reason: lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE failed: .
09-22 18:59:23.641 I/subsys-restart(0): subsystem_restart_dev(): Restart sequence requested for modem, restart_level = RELATED.
09-22 18:59:23.839 I/subsys-restart(0): subsystem_shutdown(): [kworker/u17:0:29595]: Shutting down modem
NVi5 said:
I experience similar issue, currently on crDroid 7.10, but it was also happening on Xiaomi.eu. It usually happens during commute, but sometimes also randomly. I'm using dual sim configuration, usually connected to LTE.
One time I decided to gather logs on my commute and below is the result. It seems to be some kind of problem with modem firmware in my case.
Click to expand...
Click to collapse
Hello, I have exactly the same problem with POCO X3 Pro - the same logs in last_kmsg. The device does a reboot at that point. It happens only when I am using mobile data and only with one particular network provider (SIM card). If I switch to another SIM card (another telecom) or use WIFI the problem doesn't occur.
I noticed that problem in crDroid and in LineageOS 18.1. I'm not sure if it happened on stock MIUI, because I've had it for a short time. Do you know if it happens on stock? Did you find any workaround?
kamicki said:
Hello, I have exactly the same problem with POCO X3 Pro - the same logs in last_kmsg. The device does a reboot at that point. It happens only when I am using mobile data and only with one particular network provider (SIM card). If I switch to another SIM card (another telecom) or use WIFI the problem doesn't occur.
I noticed that problem in crDroid and in LineageOS 18.1. I'm not sure if it happened on stock MIUI, because I've had it for a short time. Do you know if it happens on stock? Did you find any workaround?
Click to expand...
Click to collapse
Hi, In my case it does not cause reboot, only modem is resetting causing loss of signal. I used MatLog which is provided with crDroid to gather these logs.
I'm living in Poland and using two cards. One for cards is from provider "Play", the second provider is "Orange" which I use mainly for internet. I did not try using other providers.
Recently I was talking to a friend who owns stock Mi 9T Pro, never rooted etc. He was using one sim card, but recently got himself second card from "Orange" for internet and started experiencing same issues. It seems it's more of a problem with QC modem. Mi 9 and Mi 9T Pro both use Snapdragon 855, and Poco X3 Pro uses Snapdragon 860, so I wouldn't be surprised If they used the same firmware for modem.
Still I didn't find any fix to this issue.
NVi5 said:
Hi, In my case it does not cause reboot, only modem is resetting causing loss of signal. I used MatLog which is provided with crDroid to gather these logs.
I'm living in Poland and using two cards. One for cards is from provider "Play", the second provider is "Orange" which I use mainly for internet. I did not try using other providers.
Recently I was talking to a friend who owns stock Mi 9T Pro, never rooted etc. He was using one sim card, but recently got himself second card from "Orange" for internet and started experiencing same issues. It seems it's more of a problem with QC modem. Mi 9 and Mi 9T Pro both use Snapdragon 855, and Poco X3 Pro uses Snapdragon 860, so I wouldn't be surprised If they used the same firmware for modem.
Still I didn't find any fix to this issue.
Click to expand...
Click to collapse
Poland here also. For me it happens when I use data with nju mobile (which is basically Orange). It doesn't happen when I use data on T-Mobile. I guess Orange does something different and the firmware can't handle that.
My logs are from /proc/last_kmsg from crdroid
Code:
[ 63.760409] icnss: Received early crash indication from FW
[ 65.089126] Fatal error on modem!
[ 65.089201] modem subsystem failure reason: lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE failed: .
[ 65.089339] Ramdump(ramdump_microdump_modem): No consumers. Aborting..
[ 65.190284] Kernel panic - not syncing: subsys-restart: Resetting the SoC - modem crashed.
I've just reflashed stock MIUI and will observe.
The same for me, nju mobile (orange) for me it has been for 4 months and when I drive the car the modem always restarts in the same places. I suppose it's a VoLte matter because VoLte in Orange does not work on mi9, the nju mobile operator said that the phone is not compatible. maybe Orange is combining with BTS 5g?
I have the same problem in Egypt, also dual sim on crDroid 7.10. Didn't check the logs but as far as I remember this only happened when I started to use 2 sims on the phone.
Hi all,
I may have potential workaround. The fact that @kamicki observed It only on Orange, and not on T-Mobile, got me thinking If it could be related to LTE bands. He also said in his other posts, that it was usually when he was on LTE+, while other card worked well on LTE only, this may indicate that orange is using carrier aggregation.
I downloaded "Network Signal Guru" app and in the Forcing Control menu I set preffered LTE bands to B1, B7 and B20. Keep in mind, that this app requires root to work.
Overall Orange uses 800MHz, 1800MHz, 2100MHz and 2600MHz, so that would disable one of it's carriers. After that change and testing today modem seemed to not reset anymore. I will keep testing further.
@kamicki How is your experience on stock?
@patryk0511 @Lil Geeky FYI
Let me know If you will be able to check this workaround.
NVi5 said:
Hi all,
I may have potential fix. The fact that @kamicki observed It only on Orange, and not on T-Mobile, got me thinking If it could be related to LTE bands. He also said in his other posts, that it was usually when he was on LTE+, while other card worked well on LTE only, this may indicate that orange is using carrier aggregation.
I downloaded "Network Signal Guru" app and in the Forcing Control menu I set preffered LTE bands to B1, B7 and B20. Keep in mind, that this app requires root to work.
Overall Orange uses 800MHz, 1800MHz, 2100MHz and 2600MHz, so that would disable one of it's carriers. After that change and testing today modem seemed to not reset anymore. I will keep testing further.
@kamicki How is your experience on stock?
@patryk0511 @Lil Geeky FYI
Let me know If you will be able to check this workaround.
Click to expand...
Click to collapse
Hi, so far no reboots on stock MIUI. I haven't noticed modem resets but for me on X3 Pro the issue manifested in reboots.
It still shows LTE+ in orange.
Hi guys,
I've been experiencing the same problem for a while now on my K20 Pro (Chinese Global version of Mi9T Pro), I'm also from Poland and my carrier is also Orange, what a coincidence I've reached out to @kamicki before because I stumbled upon his reply with same kernel panic messages, my symptoms are very similar to both his and @NVi5 :
1) Around a month ago I started to notice that my LTE signal would disappear completely for a few seconds, then got back up. I didn't think much of it but it became really annoying so I've decided to update from old elementalX build to a newer one,
2) After flashing new ElementalX everything seemed fine, but I've noticed random freezing and reboots, I tried flashing different firmware versions but nothing seemed to work, even switched to Syberia Project but rebooting issue persists to this day
It seems that orange is the culprit here, I'm using cellular-pro to limit bands to only what my phone supports (no B20 here), I hope to resolve this issue, otherwise I might have to switch operators...
NVi5 said:
Hi all,
I may have potential workaround. The fact that @kamicki observed It only on Orange, and not on T-Mobile, got me thinking If it could be related to LTE bands. He also said in his other posts, that it was usually when he was on LTE+, while other card worked well on LTE only, this may indicate that orange is using carrier aggregation.
I downloaded "Network Signal Guru" app and in the Forcing Control menu I set preffered LTE bands to B1, B7 and B20. Keep in mind, that this app requires root to work.
Overall Orange uses 800MHz, 1800MHz, 2100MHz and 2600MHz, so that would disable one of it's carriers. After that change and testing today modem seemed to not reset anymore. I will keep testing further.
@kamicki How is your experience on stock?
@patryk0511 @Lil Geeky FYI
Let me know If you will be able to check this workaround.
Click to expand...
Click to collapse
Hello again,
I just found a file called "mcrash_history" on MIUI. With following contents:
Code:
2021-10-27_11-27-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_19-04-08 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_18-09-23 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_18-05-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_17-35-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_17-05-39 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_15-58-25 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_09-53-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_09-42-03 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_18-03-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_07-27-34 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_06-36-48 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_06-19-19 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_06-17-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_05-05-42 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-23_16-11-43 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-23_07-55-04 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-23_07-40-25 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-22_19-21-27 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-22_18-23-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-22_07-32-19 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-20_19-44-52 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-20_19-36-18 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-19_18-32-32 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-19_18-31-12 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-19_07-55-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_18-34-34 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-53-44 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-43-16 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-11-14 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-06-29 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-17_18-22-04 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-16_13-38-06 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_16-36-07 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_16-26-58 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_08-10-16 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_08-06-36 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_07-34-33 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_13-57-48 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_13-55-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_13-49-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-53-52 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-48-41 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-34-02 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-28-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-23-02 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-09-31 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-08-41 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-05-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_09-50-29 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-11_12-15-44 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_12-14-44 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_12-10-39 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_12-09-12 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-58-50 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-56-37 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-55-45 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-54-37 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-45-21 err_inject_crash.c:403:Crash injected via Diag
2021-10-10_15-10-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-37-39 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-21-59 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-19-55 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-17-18 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-00-13 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_13-55-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_13-36-25 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_12-41-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_11-12-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_07-44-12 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_13-33-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_13-25-43 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_13-23-53 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_12-12-28 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_12-03-38 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-08_18-56-07 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-08_12-31-50 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-08_10-05-30 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
So, the modem crash still happens on a regular basis. It just doesn't reboot the phone on MIUI.
kamicki said:
Hello again,
I just found a file called "mcrash_history" on MIUI. With following contents:
Code:
2021-10-27_11-27-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_19-04-08 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_18-09-23 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_18-05-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_17-35-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_17-05-39 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_15-58-25 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_09-53-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-26_09-42-03 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_18-03-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_07-27-34 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_06-36-48 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_06-19-19 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_06-17-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-25_05-05-42 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-23_16-11-43 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-23_07-55-04 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-23_07-40-25 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-22_19-21-27 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-22_18-23-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-22_07-32-19 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-20_19-44-52 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-20_19-36-18 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-19_18-32-32 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-19_18-31-12 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-19_07-55-51 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_18-34-34 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-53-44 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-43-16 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-11-14 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-18_08-06-29 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-17_18-22-04 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-16_13-38-06 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_16-36-07 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_16-26-58 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_08-10-16 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_08-06-36 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-15_07-34-33 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_13-57-48 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_13-55-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_13-49-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-53-52 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-48-41 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-34-02 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-28-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-23-02 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-09-31 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-08-41 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_10-05-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-14_09-50-29 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-11_12-15-44 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_12-14-44 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_12-10-39 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_12-09-12 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-58-50 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-56-37 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-55-45 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-54-37 err_inject_crash.c:403:Crash injected via Diag
2021-10-11_11-45-21 err_inject_crash.c:403:Crash injected via Diag
2021-10-10_15-10-54 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-37-39 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-21-59 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-19-55 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-17-18 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_14-00-13 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_13-55-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_13-36-25 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_12-41-09 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_11-12-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-10_07-44-12 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_13-33-11 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_13-25-43 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_13-23-53 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_12-12-28 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-09_12-03-38 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-08_18-56-07 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-08_12-31-50 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
2021-10-08_10-05-30 lte_ml1_dlm_common_if.c:715:Assert (r1280_present && r1430_present) == FALSE fai
So, the modem crash still happens on a regular basis. It just doesn't reboot the phone on MIUI.
Click to expand...
Click to collapse
I think this is more of an issue with chip.
You can try to use my workaround, as it is working successfully in my case.
Hi again,
I did some testing and ultimately decided to switch my operator. So far I had ONE system crash/reboot which was not related to modem. So yeah, Orange is totally the culprit. Unfortunately NVi5's solution doesn't work on my phone for some reason, I kept getting crashes anyway. Must be related to my phone not supporting B20.
You're not facing this in orange because... In miui kernel panic doesnt cause reboot...in miui You'll find network gone for a few second and come back,while in aosp It'll just reboot......i'm a x3 pro user here...facing exactly same issue...
kamicki said:
Hi, so far no reboots on stock MIUI. I haven't noticed modem resets but for me on X3 Pro the issue manifested in reboots.
It still shows LTE+ in orange.
Click to expand...
Click to collapse
Related
[Q] Assert failed error updating to latest CM 10.1
My device is running cm-10.1-20130323-UNOFFICIAL-s6500d just fine, but when I try to install the latest I get this error: Code: Installing '/sdcard/cm-10.1-20130611-UNOFFICIAL-jena.zip'... Checking for MD5 file... I:Cannot find file /sdcard/cm-10.1-20130611-UNOFFICIAL-jena.zip.md5 Skipping MD5 check: no MD5 file found. Warning: No file_contexts script aborted: assert failed: getprop("ro.product.device") == "jena" || getprop("ro.build.product") == "jena" || getprop("ro.product.device") == "jenad" || getprop("ro.build.product") == "jenad" || getprop("ro.product.device") == "GT-S6500" || getprop("ro.build.product") == "GT-S6500" || getprop("ro.product.device") == "GT-S6500D" || getprop("ro.build.product") == "GT-S6500D" assert failed: getprop("ro.product.device") == "jena" || getprop("ro.build.product") == "jena" || getprop("ro.product.device") == "jenad" || getprop("ro.build.product") == "jenad" || getprop("ro.product.device") == "GT-S6500" || getprop("ro.build.product") == "GT-S6500" || getprop("ro.product.device") == "GT-S6500D" || getprop("ro.build.product") == "GT-S6500D" E:Error in /sdcard/cm-10.1-20130611-UNOFFICIAL-jena.zip (Status 7) Error flashing zip '/sdcard/cm-10.1-20130611-UNOFFICIAL-jena.zip' Here's my whole recovery log: gist.github.com/anonymous/cc61a5f3180940525c57 Not really sure how to debug since my first install went without a hitch. Has anyone else experienced this? What can I do to fix this problem?
:/ I have the same problem
Are you using cwm 6 build 4?
I dont know how but now i installed cm.
I suggest you to learn how to read.
You gotta have cwm 6+ Sent from my GT-S6500 using Tapatalk 2
OverkillSRB said: You gotta have cwm 6+ Sent from my GT-S6500 using Tapatalk 2 Click to expand... Click to collapse not just CWM 6+. it must be in build 4.
tekkenl0rd13 said: not just CWM 6+. it must be in build 4. Click to expand... Click to collapse Oh, didnt know that Sent from my GT-S6500 using Tapatalk 2
Go to arhive with cm now go to META-INF -> com -> google -> android -> and extract "updater-script" Open "updater-script" and search this lines Code: assert(getprop("ro.product.device") == "jena" || getprop("ro.build.product") == "jena" || getprop("ro.product.device") == "GT-S6500" || getprop("ro.build.product") == "GT-S6500" || getprop("ro.product.device") == "GT-S6500D" || getprop("ro.build.product") == "GT-S6500D" || getprop("ro.product.device") == "GT-S6500T" || getprop("ro.build.product") == "GT-S6500T"); ^ | | delelte this now copy modiffied "updater-script" to normal arhive. now "updater-script" start with Code: mount("ext4", "EMMC", "/dev/block/mmcblk0p16", "/system");
Not working rarebc said: Go to arhive with cm now go to META-INF -> com -> google -> android -> and extract "updater-script" Open "updater-script" and search this lines Code: assert(getprop("ro.product.device") == "jena" || getprop("ro.build.product") == "jena" || getprop("ro.product.device") == "GT-S6500" || getprop("ro.build.product") == "GT-S6500" || getprop("ro.product.device") == "GT-S6500D" || getprop("ro.build.product") == "GT-S6500D" || getprop("ro.product.device") == "GT-S6500T" || getprop("ro.build.product") == "GT-S6500T"); ^ | | delelte this now copy modiffied "updater-script" to normal arhive. now "updater-script" start with Code: mount("ext4", "EMMC", "/dev/block/mmcblk0p16", "/system"); Click to expand... Click to collapse Hello. Unfortunately, delete the lines did not resolve the problem. Now I got this message. Installing update ... Installation aborted.
just update cwm -_-
[Q] TWRP flashing roms: assert failed when get prop ro.device.product
Hey everyone, I have an unlocked ATT htc one. Whenever I flash any roms downloaded from this forum (international htc one), I get Code: script aborted: assert failed: getprop("ro.product.device") == "m7" || getprop("ro.build.product") == "m7" || getprop("ro.product.device") == "m7ul" || getprop("ro.build.product") == "m7ul" assert failed: getprop("ro.product.device") == "m7" || getprop("ro.build.product") == "m7" || getprop("ro.product.device") == "m7ul" || getprop("ro.build.product") == "m7ul" I have to manually remove the script line in every rom, which is really annoying. I was under the impression that att htc one is also a m7ul?? does that mean I can only flash roms especially made for m7att? thanks in advance
Error 7 TWRP ( I can not install current roms )
I can not install any current ROM, Lineage 14 - Viper OS - Ressurection 5.8.4, always gives the error 7 [Patching system unconditionally E1001: Failed to update system image. ] currently use the RR 5.8.0 android 6.0, my cell phone is the Moto G2 LTE XT1078 (THEA) image of the event> https://imgur.com/a/jRZkT
Do you have the newest TWRP? https://dl.twrp.me/thea/
yes, I tested all versions, 3.1.1-0 to 3.0.0-0, they all gave the same error
pabli24 said: Do you have the newest TWRP? https://dl.twrp.me/thea/ Click to expand... Click to collapse yes, I tested all versions, 3.1.1-0 to 3.0.0-0, they all gave the same error
Are you sure you are using one for thea? If not, then do get it from here (I am using it on my XT1072): https://dl.twrp.me/thea/twrp-3.2.1-0-thea.img.html Reboot to fastboot (shut down, then pwr+vol up for 5 seconds then release) and plug your phone to a PC with mfastboot. then execute in a copy of mfastboot the following command: mfastboot flash recovery twrp-3.2.1-0-thea.img Click to expand... Click to collapse Now take your phone and choose "Normal Powerup", then interrupt the boot and get again to fastboot, this time choose "Recovery". You should be booting TWRP right now. Now wipe /cache, /data, /storage, dalvik and /system. Now flash CyanogenMod/AOKP/Carbon/AOSPA/LineageOS or any other custom ROM (optional: flash GApps of the same Android version afterwards to get Google support) Now wipe /cache, /data and dalvik Finally, reboot to system. Not working? Make sure your bootloader is unlocked. Still not working and unlocked? Flash the stock ROM and try again.
Fixed the 7 TWRP error problem on the Moto G2 LTE XT1078? I'm having the same problem, I did not find a solution
Same problem. Managed to unlock bootloader, flash recovery, cannot flash any rom due to error 7. Any ideas?
Gupalupa123 said: I can not install any current ROM, Lineage 14 - Viper OS - Ressurection 5.8.4, always gives the error 7 [Patching system unconditionally E1001: Failed to update system image. ] currently use the RR 5.8.0 android 6.0, my cell phone is the Moto G2 LTE XT1078 (THEA) image of the event> https://imgur.com/a/jRZkT Click to expand... Click to collapse So, if you're still looking for a solution, I can give you one, but stupid... You need to download the TWRP backup for XT1068 and install it. https://forum.xda-developers.com/moto-g-2014/general/moto-g-indian-xt1068-marshmellow-6-0-t3313148 Al least the phone will work, but you'll also face some problems like laggy auto-rotation (the picture will be upside down in landscape mode) and also you'll have 2 SIM cards (XT1072 has only one sim card slot) That means we should ask someone to make a backup of stock firmware (or at least stable LineageOS firmware) and restore it with TWRP. Please, if anyone still has this phone (XT1072) on stock or any other firmware which WORKS make a backup and upload it to the internet. :good::good:IT WOULD BE REALLY COOL, BECAUSE A LOT OF PEOPLE HAVE THIS PHONE AND THEY CAN'T FLASH ANY ROM WITH ERROR 7!!!:good::good: A photo of succesfully restored device: https://photos.app.goo.gl/shNVhtpJP4x432Sm6 Thank you.
Possible solution for error 7 in my case for moto e i opened the flashable zip with winrar, go to meta-inf/com/google/android and opened update-script with notepad++ and delete the first lines, in my case i deleted these assert(getprop("ro.product.device") == "titan" || getprop("ro.build.product") == "titan" || getprop("ro.product.device") == "titan_umts" || getprop("ro.build.product") == "titan_umts" || getprop("ro.product.device") == "titan_udstv" || getprop("ro.build.product") == "titan_udstv" || getprop("ro.product.device") == "titan_umtsds" || getprop("ro.build.product") == "titan_umtsds" || getprop("ro.product.device") == "titan_retaildsds" || getprop("ro.build.product") == "titan_retaildsds" || getprop("ro.product.device") == "XT1068" || getprop("ro.build.product") == "XT1068" || getprop("ro.product.device") == "XT1064" || getprop("ro.build.product") == "XT1064" || getprop("ro.product.device") == "XT1063" || getprop("ro.build.product") == "XT1063" || getprop("ro.product.device") == "XT1069" || getprop("ro.build.product") == "XT1069" || abort("E3004: This package is for device: titan,titan_umts,titan_udstv,titan_umtsds,titan_retaildsds,XT1068,XT1064,XT1063,XT1069; this device is " + getprop("ro.product.device") + "."); assert(getprop("ro.bootloader") == "0x4882" || getprop("ro.bootloader") == "0x4883" || getprop("ro.bootloader") == "0x4886" || getprop("ro.bootloader") == "0x4887" || abort("This package supports bootloader(s): 0x4882, 0x4883, 0x4886, 0x4887; this device has bootloader " + getprop("ro.bootloader") + "."); ifelse(is_mounted("/system"), unmount("/system")); and rom is actually flashing
GuestD0668 said: in my case for moto e i opened the flashable zip with winrar, go to meta-inf/com/google/android and opened update-script with notepad++ and delete the first lines, in my case i deleted these assert(getprop("ro.product.device") == "titan" || getprop("ro.build.product") == "titan" || getprop("ro.product.device") == "titan_umts" || getprop("ro.build.product") == "titan_umts" || getprop("ro.product.device") == "titan_udstv" || getprop("ro.build.product") == "titan_udstv" || getprop("ro.product.device") == "titan_umtsds" || getprop("ro.build.product") == "titan_umtsds" || getprop("ro.product.device") == "titan_retaildsds" || getprop("ro.build.product") == "titan_retaildsds" || getprop("ro.product.device") == "XT1068" || getprop("ro.build.product") == "XT1068" || getprop("ro.product.device") == "XT1064" || getprop("ro.build.product") == "XT1064" || getprop("ro.product.device") == "XT1063" || getprop("ro.build.product") == "XT1063" || getprop("ro.product.device") == "XT1069" || getprop("ro.build.product") == "XT1069" || abort("E3004: This package is for device: titan,titan_umts,titan_udstv,titan_umtsds,titan_retaildsds,XT1068,XT1064,XT1063,XT1069; this device is " + getprop("ro.product.device") + "."); assert(getprop("ro.bootloader") == "0x4882" || getprop("ro.bootloader") == "0x4883" || getprop("ro.bootloader") == "0x4886" || getprop("ro.bootloader") == "0x4887" || abort("This package supports bootloader(s): 0x4882, 0x4883, 0x4886, 0x4887; this device has bootloader " + getprop("ro.bootloader") + "."); ifelse(is_mounted("/system"), unmount("/system")); and rom is actually flashing Click to expand... Click to collapse Nope. That's just not working for me... P.S I'm still waiting for a proper backup for XT1072 and it will help to restore this phone. So... Please, somebody make a backup!
Trouble with flashing.
Hi guys, I had installed few hours ago the LineageOS, but it really didn't fit to me, so I decided to wipe data, cache etc. and install global stable rom. First of all when I wanted to make the wipe, I got msg like "unable mount internal storage". Then I downloaded fastboot version of firmware and was going to flash it via XiaoMiFlash tool. I got this: [20:36:48 d5fafeb0]:MiFlash 2017.4.25.0 [20:36:48 d5fafeb0]:image path:C:\Users\Dżony\Desktop\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global_f413999234\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global [20:36:48 d5fafeb0]:env android path:"C:\XiaoMi\XiaoMiFlash\Source\ThirdParty\Google\Android" [20:36:48 d5fafeb0]:script :C:\Users\Dżony\Desktop\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global_f413999234\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global\flash_all.bat [20:36:48 d5fafeb0]hysical Memory Usage:1777664 Byte [20:36:48 d5fafeb0]:$fastboot -s d5fafeb0 getvar product 2>&1 | findstr /r /c:"^product: *MSM8996" || echo Missmatching image and device [20:36:48 d5fafeb0]roduct: MSM8996 [20:36:48 d5fafeb0]:$fastboot -s d5fafeb0 getvar product 2>&1 | findstr /r /c:"^product: *MSM8996" || exit /B 1 [20:36:48 d5fafeb0]roduct: MSM8996 [20:36:48 d5fafeb0]:$fastboot -s d5fafeb0 erase bk12 2>&1 [20:36:48 d5fafeb0]:erasing 'bk12'... [20:36:48 d5fafeb0]KAY [ 0.021s] [20:36:48 d5fafeb0]:finished. total time: 0.021s [20:36:48 d5fafeb0]:$if not 0 == 0 exit /B 1 [20:36:48 d5fafeb0]:$rem fastboot -s d5fafeb0 getvar soc_id 2>&1 | findstr /r /c:"^soc_id: *239" || echo Missmatching image and device in soc_id [20:36:48 d5fafeb0]:$rem fastboot -s d5fafeb0 getvar soc_id 2>&1 | findstr /r /c:"^soc_id: *239" || exit /B 1 [20:36:48 d5fafeb0]:$fastboot -s d5fafeb0 flash xbl C:\Users\Dzony\Desktop\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global_f413999234\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global\images\xbl.elf || [20:36:48 d5fafeb0]:error:error: cannot load 'C:\Users\Dzony\Desktop\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global_f413999234\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global\images\xbl.elf': No such file or directory [20:36:48 d5fafeb0]:"Flash xbl error" [20:36:48 d5fafeb0]:error:error: cannot load 'C:\Users\Dzony\Desktop\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global_f413999234\gemini_global_images_V9.2.1.0.NAAMIEK_20180117.0000.00_7.0_global\images\xbl.elf': No such file or directory [20:36:48 d5fafeb0]rocess exit. [20:36:49 d5fafeb0]:flashSuccess False [20:36:49 d5fafeb0]:isFactory False CheckCPUID False [20:36:49 d5fafeb0]:before:flashSuccess is False set IsUpdate:True set IsDone True [20:36:49 d5fafeb0]:after:flashSuccess is False set IsUpdate:false set IsDone true I don't know how to fix that. When I boot my mi5 I get stuck boot screen. Help!
TWRP: Prevent assertion error when flashing rom
Hi, I've got a Z3 Compact with TWRP 3.0.1-2 on it. As far as I can see, this is the latest version. In my build.prop, both ro.product.device and ro.build.product are set to z3c. However, the following line in an update-script still causes the flash to abort with an assertion error: (getprop("ro.product.device") == "D5803" || getprop("ro.build.product") == "D5803" || getprop("ro.product.device") == "D5833" || getprop("ro.build.product") == "D5833" || getprop("ro.product.device") == "z3c" || getprop("ro.build.product") == "z3c" || getprop("ro.product.device") == "aries" || getprop("ro.build.product") == "aries") || abort("E3004: This package is for "D5803,D5833,z3c,aries" devices this is a "" + getprop("ro.product.device") + ""."); I also tried setting ro.product.device and ro.build.product manually via adb shell and setprop. getprop on the adb shell (when in TWRP) returns the correct values. Of course, I can always unpack the ZIP, edit update-script, repack the ZIP and flash. But doing this every time is tedious and, of course, deleting the assertion somehow beats the purpose anyway. Is there a way to fix this? Does TWRP get the properties from anywhere else than /system/build.prop? Blessings, Christoph
Hey Christoph, I had the same issue. I just tried the TWRP version (3.2.1-0) of this post: https://forum.xda-developers.com/z3-compact/general/d5803-z3c-aries-twrp3-0-t3543113 (I only tried the Lineage one) and it is working again. (I'am running Carbon 6.1) (No more update-script editing \o/)