[PATCH] [Kernel] The spontaneous reboot (solution?) thread - Epic 4G Android Development

I've been getting occasional random reboots EI22, and I've seen reports in the general forum of the same.
There seem to be two main causes of reboots:
WIFI Related (bcm4329 DHD Bus Module TX Queue overflow)​The reboots always happen when WIFI is on. The system will freeze up hard for about 10-15 seconds and then just reset. The LAST_KMSG file shows 60KB of nothing but the following:
Code:
[ 5315.816399] dhd_bus_txdata: out of bus->txq !!!
[ 5315.820979] dhd_bus_txdata: out of bus->txq !!!
[ 5315.825411] dhd_bus_txdata: out of bus->txq !!!
[ 5315.829922] dhd_bus_txdata: out of bus->txq !!!
[ 5315.834499] dhd_bus_txdata: out of bus->txq !!!
[ 5315.838929] dhd_bus_txdata: out of bus->txq !!!
[ 5315.843505] dhd_bus_txdata: out of bus->txq !!!
OneDram driver related reboots​
After patching the WIFI related bugs I started to get these more often. Here is an example of the log leading up to the reboot.
Code:
[ 13.319028] [OneDRAM](dpram_write) Failed to get a Semaphore. sem:0, PHONE_ACTIVE:HIGH, fail_cnt:1
[ 13.339579] [OneDram] dpram_drop_data, head: 319, tail: 319
[ 13.351715] [OneDRAM](dpram_write) Failed to get a Semaphore. sem:0, PHONE_ACTIVE:HIGH, fail_cnt:1
[ 13.366965] [OneDram] dpram_drop_data, head: 319, tail: 319
[ 13.379178] [OneDRAM](dpram_write) Failed to get a Semaphore. sem:0, PHONE_ACTIVE:HIGH, fail_cnt:1
Another log sample from a reboot, right before it restarts...
Code:
[ 11.585629]
[ 11.585665] dpram_shutdown !!!!!!!!!!!!!!!!!!!!!
[ 11.590957]
[ 11.590986] dpram_shutdown ret : 0
[ 11.598695] Restarting system.
[ 11.600629] KERNEL:magic_number=0 CLEAR_UPLOAD_MAGIC_NUMBER
[ 11.608974] arch_reset: attempting watchdog reset
For the WIFI issue, I searched and found a set of patches on the linux driver project mailing list that address this issue.
See: http://driverdev.linuxdriverproject.org/pipermail/devel/2011-March/012948.html
After applying the patch verbatim I still got the WIFI related reboots, so I slowly pushed the TXQLEN values up until the reboots stopped. Here is the commit from my github that contains the patch that seems to have done the trick.
As for the OneDRAM related reboots, I think I may have found the solution to these too. The problem seems to have gone away when I switched the specific ARM toolchain that is mentioned in the Samsung kernel source README. Previously I was using the 4.4.x toolchain from Googles repo. Thanks to Earthbound for working with me on this one. Aside from Earthbound (he uses the recommended Codesourcery one), I don't know what toolchains others use, but I do know that I have not had one reboot in the four days since switching to the CodeSourcery toolchain.
Here is a kernel (source) with the WIFI fix that was compiled with the 2009-q3-68 toolchain. Aside from the WIFI fix, the kernel contains the following features:
root/su/busybox
init.d script support
bootanimation.zip support
overclock to 1.4/voltage control
keyboard delay fix
ext4/rfs support
CWM5/ROM Manager support (reboot bml8 recovery)
If you are having WIFI or dpram/onedram related reboots, you might want to give this kernel a try and report back.
NOTE: If you overclock or over/under volt please stop doing so if you want to test this kernel and post logs.

Interesting I'll have to try it out, thanks for this!
Sent from my SPH-D700 using XDA Premium App

Thanks for this. Just need an EI22 branch now hehe.
Sent from my Epic 4G

I've experienced a few ramdom freezes and reboots lately even when overclocked to previously stable frequencies- ever since I successful ran with 1.5ghz enabled for two minutes.
I gave this a go, and overclocked to 1.4 and my phone went into a reboot loop- the rom booted up, but would freeze and reboot shortly afterwards.
I'm stable again now after running the VC cwm zip to restore settings to 1ghz.
Is there any useful feedback I could provide? Some sort of log or something?
Sent from my secret underground bunker

I just got another reboot...same issue.
So much for that!!
This bug is defintely causing the reboots though.

mjben said:
Is there any useful feedback I could provide? Some sort of log or something?
Click to expand...
Click to collapse
The system keeps logs in /data/system/dropbox
After a reboot the file with a name like " [email protected]" will contain a copy of the last system log buffer before your phone restarted.
But like I said I just got another reboot. I ran a speedtest over wifi using the speedtest.net app just before my last two reboots so I might be onto a way of triggering the bug.

I'm going to continue working on this. I'm experimenting with larger and smaller TXQLEN values.
Right now running with a TXQLEN of 4096 instead of 2048. It may be that larger is not better; that I needed to go smaller.
I'll keep my github updated.

So how was this different then froyo? Or did the tab ever have reboots?
sent from my always aosp epic

Excellent work!
I'd jump all over this but I stopped getting them after IAP 1.0.5+.
If they start up again I will report back.

the only time i have experienced this particular reboot concerning wifi, was having wifi + 4g enabled at home after a dalvik cache wipe (where the phone starts up, 4g starts first, then wifi simultaneously gets on LAN - both icons are showing, locks up - then reboot) once it restarts, it's all ok, wifi starts first, and doesn't happen again.
(running IAP samurai 1.0.4)

darkierawr said:
Excellent work!
I'd jump all over this but I stopped getting them after IAP 1.0.5+.
If they start up again I will report back.
Click to expand...
Click to collapse
AFAIK, the Earthbound is only mucking around with frequencies and voltages in his kernel. Of course I'm basing this on the only source he has posted, which was from two or three versions of his kernel back. He hasn't posted the source for any of this new builds, so apparently he still views GPL compliance as optional.
The reboots don't happen that often. I've gone many days without a single reboot and then gotten them multiple times in one day.

SenseiSimple said:
the only time i have experienced this particular reboot concerning wifi, was having wifi + 4g enabled at home after a dalvik cache wipe (where the phone starts up, 4g starts first, then wifi simultaneously gets on LAN - both icons are showing, locks up - then reboot) once it restarts, it's all ok, wifi starts first, and doesn't happen again.
(running IAP samurai 1.0.4)
Click to expand...
Click to collapse
No 4G service for me within 40 miles, so I never turn it on, but now that you mention it the lockups I've had have seemed to happen during that split second when both 3G data and Wifi icons show up in the top bar.

toadlife said:
No 4G service for me within 40 miles, so I never turn it on, but now that you mention it the lockups I've had have seemed to happen during that split second when both 3G data and Wifi icons show up in the top bar.
Click to expand...
Click to collapse
yeah maybe something about having two sources of internet... being assigned two addresses, no idea...
earthbound is stuck on the frequency tuning, but i think it's so stable because of the trunks he started with.

SenseiSimple said:
yeah maybe something about having two sources of internet... being assigned two addresses, no idea...
earthbound is stuck on the frequency tuning, but i think it's so stable because of the trunks he started with.
Click to expand...
Click to collapse
What trunk did he start from? He's got no history in github.
I'm assuming nubecoder's since his initial kernels had nubecoders broken video recording. I took a quick look a nubecoder's tree and nothing network related is touched there.
Anyhow in the general and Q&A forums have two reports reboots with Samauri 1.04, so that kernel is definitely not immune.

toadlife said:
What trunk did he start from? He's got no history in github.
I'm assuming nubecoder's since his initial kernels had nubecoders broken video recording. I took a quick look a nubecoder's tree and nothing network related is touched there.
Anyhow in the general and Q&A forums have two reports reboots with Samauri 1.04, so that kernel is definitely not immune.
Click to expand...
Click to collapse
yeah it's not immune, as i said it's happened to me, but it's appeared to me he started picking and choosing from nubernel into rodderick's clean kernel, and as he's said in his OP for samurai, there are elements of Genocide and other forerunners.. i forgot which, he's since removed the part where he says where his mods come from... he did at one point put in a fix for wifi issues, i'm not sure if it's in relation to the same issue (i think it was a general connectivity thing).
i have a short list of todo's for a kernel and have made headway but i really have no desire to compete with the 4 (including yours) on here.

SenseiSimple said:
i have a short list of todo's for a kernel and have made headway but i really have no desire to compete with the 4 (including yours) on here.
Click to expand...
Click to collapse
We are not competing. I just want my phone to be stable. Collaboration is what makes open source work. If you have ideas on how to make our kernels better share them.

@ toad
Iv'e been using your rom for over week and the e122 modem and have not had any reboots.
I do not overclock
I use 4g when i drive in a certain area to stream pandora faster and then it connect and reconnect to 4g
Ive connected wifi and 3g at the same time for picture mail and charging to my sprint account and still no reboot

Dangg.. I had no idea ppl had random reboots on ei22.. I've not seen one.

ksmullins88 said:
Dangg.. I had no idea ppl had random reboots on ei22.. I've not seen one.
Click to expand...
Click to collapse
I just had another one. This time it was the OneDRAM driver triggering a `reboot now`
CAn anyone explain what the OneDRAM driver does?

Toad,
Running your Kernel and Clean GB I had WiFi reboots every 3 to 4 minutes. WiFi would drop and go to the router for DHCP to hand out the IP again. I figured I would give you a chance to work on it and run rooted stock for a few days before trying Clean GB again as I like it! This same issue was even worse for me with ACS ICS v4.
Running rooted stock is a different story all together! I don't get the random WiFi drops, instead I get Android reboots with the freezing that's mentioned. Things run great for awhile before I get stuck in a loop of reboots. I noticed this last time that touchwiz lost all the bar icons besides the applications drawer icon. the bar also doubled in size along with the icon. Very strange!
Anyway, I was able to drop the default home between reboots this last time. The next reboot I launched ADW instead of TW. ADW instantly crashed and offered to email a bug report, So I did. In the stack trace I see that android Package manager has died as a cause of the exception. I am not a java programmer so am at a loss here to what's really happening.
Anyway, I hope this long story may be of some help in tracking this issue down. It looks like quite a few people are having it, and I myself don't want to go back to Froyo
Cheers,
Dave
---------- Post added at 02:02 AM ---------- Previous post was at 01:53 AM ----------
Here is a copy of the stack trace I mentioned...
Stack :
=======
java.lang.RuntimeException: Package manager has died
at android.app.ContextImpl$ApplicationPackageManager.getApplicationInfo(ContextImpl.java:2062)
at android.app.ContextImpl$ApplicationPackageManager.getResourcesForApplication(ContextImpl.java:2554)
at org.adwfreak.launcher.LauncherModel.a(Unknown Source)
at org.adwfreak.launcher.LauncherModel.b(Unknown Source)
at org.adwfreak.launcher.LauncherModel.b(Unknown Source)
at org.adwfreak.launcher.LauncherModel.a(Unknown Source)
at org.adwfreak.launcher.ck.run(Unknown Source)
at java.lang.Thread.run(Thread.java:1019)
Caused by: android.os.DeadObjectException
at android.os.BinderProxy.transact(Native Method)
at android.content.pm.IPackageManager$Stub$Proxy.getApplicationInfo(IPackageManager.java:1280)
at android.app.ContextImpl$ApplicationPackageManager.getApplicationInfo(ContextImpl.java:2057)
... 7 more
Cause :
=======
java.lang.RuntimeException: Package manager has died
at android.app.ContextImpl$ApplicationPackageManager.getApplicationInfo(ContextImpl.java:2062)
at android.app.ContextImpl$ApplicationPackageManager.getResourcesForApplication(ContextImpl.java:2554)
at org.adwfreak.launcher.LauncherModel.a(Unknown Source)
at org.adwfreak.launcher.LauncherModel.b(Unknown Source)
at org.adwfreak.launcher.LauncherModel.b(Unknown Source)
at org.adwfreak.launcher.LauncherModel.a(Unknown Source)
at org.adwfreak.launcher.ck.run(Unknown Source)
at java.lang.Thread.run(Thread.java:1019)
Caused by: android.os.DeadObjectException
at android.os.BinderProxy.transact(Native Method)
at android.content.pm.IPackageManager$Stub$Proxy.getApplicationInfo(IPackageManager.java:1280)
at android.app.ContextImpl$ApplicationPackageManager.getApplicationInfo(ContextImpl.java:2057)
... 7 more
android.os.DeadObjectException
at android.os.BinderProxy.transact(Native Method)
at android.content.pm.IPackageManager$Stub$Proxy.getApplicationInfo(IPackageManager.java:1280)
at android.app.ContextImpl$ApplicationPackageManager.getApplicationInfo(ContextImpl.java:2057)
at android.app.ContextImpl$ApplicationPackageManager.getResourcesForApplication(ContextImpl.java:2554)
at org.adwfreak.launcher.LauncherModel.a(Unknown Source)
at org.adwfreak.launcher.LauncherModel.b(Unknown Source)
at org.adwfreak.launcher.LauncherModel.b(Unknown Source)
at org.adwfreak.launcher.LauncherModel.a(Unknown Source)
at org.adwfreak.launcher.ck.run(Unknown Source)
at java.lang.Thread.run(Thread.java:1019)
**** End of current Report ***

Related

[ROM-DEV] AOSP 2.0+ Hero CDMA | camera doesn't work, Google sync issues

This is a "MASTER" branch build, so it has Eclair plus some code checkins after that. Google has not released/tagged 2.0.1 (nor 2.1 for that matter) sources, so the SDK level is 5 (2.0), not 6 (2.0.1).
New 2009-12-17 build with wifi and sensors working
AOSP Hero CDMA 20091217
Changelog:
2009-12-03 build - first build that basic phone and SMS functions works
2009-12-10 build with post-2.0 updates, bluetooth turns on, but not tested yet, can enable 3G data with kluge in reply #23, pics in #21
2009-12-11 build with auto 3G enabling
2009-12-17 build with wifi and sensors working
What works:
Phone, 3G data, possibly BT, haven't tried pairing with anything yet, but it turns on, Haptic feedback, GPS, Wifi, accel/orientation/magnetic sensor
What doesn't work:
camera - not likely to work until some new proprietary binaries come out specifically for the CDMA Hero. compiling with the 1.5 libcamera.so fails, as it requires things no longer present in 2.0, but the new libcamera.so tries access devices not present in the 2.6.27 kernel. On top of that, we probably need a liboemcamera.so for the CDMA Hero, this file replaces the libqcamera.so
Googlebits: for people who have tried to use apk's to enable syncing with your Google account, the phone seems to keep syncing even when its done. I don't really know where the problem is with that at this point. If you've tried this, can you tell me where the apks are from? I tried the apks I found in chuckhriczko mod-build http://forum.xda-developers.com/showpost.php?p=5118188&postcount=29 and it has the sync problem. I haven't tried the ones from http://www.buttonclicker.com/2009/12/02/googlebits-signed_v1-1/ yet.
Please understand that I'm mainly interested in the AOSP/build from android.git.kernel.org issues, the Googlebits stuff is something I'm willing to investigate. Also, I won't be building any ROMs with the Googlebits built in, as this is an AOSP ROM w/ some tweaks to get as much of the HARDWARE working as possible. Anything beyond that is really up to the others, or yourself to figure out. Its fun to learn!
So after a reboot it just puts you back in to recovery?
You can watch the debugger to see what's going on.
(in windows) \sdk\tools\ddms.bat
Ok, got it to boot. I did not have the update-script set perms, so as soon as it booted, it failed to execute sh!
It booted, but before the home screen completely loads, com.android.phone dies (force close). I can't even get into the settings screen to do a picture for you guys
I'm not sure what to try next, use the phone.apk from CDMA 1.5/cupcake, or the one from Moto Droid.
quietcblongs said:
Ok, got it to boot. I did not have the update-script set perms, so as soon as it booted, it failed to execute sh!
It booted, but before the home screen completely loads, com.android.phone dies (force close). I can't even get into the settings screen to do a picture for you guys
I'm not sure what to try next, use the phone.apk from CDMA 1.5/cupcake, or the one from Moto Droid.
Click to expand...
Click to collapse
Give it a try, but I've had the same issues on the 2.1 dev build. Although it does boot and work, just still gets the FC's on com.android.phone.
So then what kernel does this use? 2.6.27, 29 or 31?
Its running the stock HTC 2.6.27 kernel (the only one that seems to work on our phones it seems).
I decided to rebuild AOSP after all the tweaking along the compile I did the first time around. This time, phone doesn't crash, but calendar still crashes on start (at least it doesn't try to restart over and over again).
The phone still thinks its a gsm type phone, and the odd part is that it starts up in airplane mode. I'm not sure I've ever been able to get it out of it. Turning on wifi puts it into continous reboot the phone mode, so I'm not sure whats going on there. I'm using the wlan.ko from our phone as well.
Click on the thumbs for bigger view of the pics:
Did another build, this time, with some CDMA specific settings in system.prop, and took out gsm/umts settings that were in inherited .mk files. Also took out the init.goldfish.rc.
With this build, I get CDMA related info in the phone status screen, like phone number, PRL version, etc. But it seems like the phone can't read any of that info (values are unknown), so I'm thinking of trying the libhtcril from the leaked 2.1 to see if that works. Also, turning on wifi still puts it into reboot loop.
Update:
Using the leaked 2.1 libhtc_ril got the phone working. About phone screen shows correct values for phone number, PRL version, etc. I was able to make an outbound call as well. Putting in the wlan.ko from the leaked 2.1 didnt' help in a meaningful way, instead of reboot looping, it just says can't turn on wifi. Tried turning on bluetooth, but the button just goes into that grayed out state of "turning on bluetooth.."
It might be time to upload this one and let more people give it a few (w)hacks at it.
quietcblongs said:
Did another build, this time, with some CDMA specific settings in system.prop, and took out gsm/umts settings that were in inherited .mk files. Also took out the init.goldfish.rc.
With this build, I get CDMA related info in the phone status screen, like phone number, PRL version, etc. But it seems like the phone can't read any of that info (values are unknown), so I'm thinking of trying the libhtcril from the leaked 2.1 to see if that works. Also, turning on wifi still puts it into reboot loop.
Update:
Using the leaked 2.1 libhtc_ril got the phone working. About phone screen shows correct values for phone number, PRL version, etc. I was able to make an outbound call as well. Putting in the wlan.ko from the leaked 2.1 didnt' help in a meaningful way, instead of reboot looping, it just says can't turn on wifi. Tried turning on bluetooth, but the button just goes into that grayed out state of "turning on bluetooth.."
It might be time to upload this one and let more people give it a few (w)hacks at it.
Click to expand...
Click to collapse
Yeah it looks like this is an amazing start. Good job! I'll be happy to help if you want.
ill help too can test for you
See first post
sweet!!! im gonna try and have a look at this later. lookin good though man
I was thinking of putting this on my Hero just to check out what everything looks like is it any harder to do than flashing a custom rom?
Lessthantito said:
I was thinking of putting this on my Hero just to check out what everything looks like is it any harder to do than flashing a custom rom?
Click to expand...
Click to collapse
no, just wipe data (do a nandroid backup first!), then flash.
Wonder if we will have a 2.1 built here before sprint releases it
This build doesn't have sense running does it?
No, this is vanilla android.
cant wait im down to test it out! when you do a wipe do you do a complete wipe factory reset or wipe sd partition
Joecrack305 said:
cant wait im down to test it out! when you do a wipe do you do a complete wipe factory reset or wipe sd partition
Click to expand...
Click to collapse
just factory wipe, no need to wipe your SD card.
You can also get rid of the roaming indicator by putting the following into a file named "eri.xml", and then pushing it to /data
Code:
<EriFile VersionNumber="1357" NumberOfEriEntries="1" EriFileType="1">
<CallPromptId Id="0" CallPromptText="CallPromptId0"/>
<CallPromptId Id="1" CallPromptText="CallPromptId1"/>
<CallPromptId Id="2" CallPromptText="CallPromptId2"/>
<EriInfo RoamingIndicator="128" IconIndex="1" IconMode="0" EriText="Sprint" CallPromptId="0" AlertId="0"/>
</EriFile>
quietcblongs said:
just factory wipe, no need to wipe your SD card.
You can also get rid of the roaming indicator by putting the following into a file named "eri.xml", and then pushing it to /data
Code:
<EriFile VersionNumber="1357" NumberOfEriEntries="1" EriFileType="1">
<CallPromptId Id="0" CallPromptText="CallPromptId0"/>
<CallPromptId Id="1" CallPromptText="CallPromptId1"/>
<CallPromptId Id="2" CallPromptText="CallPromptId2"/>
<EriInfo RoamingIndicator="128" IconIndex="1" IconMode="0" EriText="Sprint" CallPromptId="0" AlertId="0"/>
</EriFile>
Click to expand...
Click to collapse
Now, did we figure out whether the phone actually is roaming when it shows this? If we just remove the indicator and we are still roaming that could be a bad thing, right? I mean, I don't know how Sprint works with roaming so maybe Im completely wrong.
chuckhriczko said:
Now, did we figure out whether the phone actually is roaming when it shows this? If we just remove the indicator and we are still roaming that could be a bad thing, right? I mean, I don't know how Sprint works with roaming so maybe Im completely wrong.
Click to expand...
Click to collapse
In the AOSP code, there are un-implemented methods that are supposed to read the ERI from the phone through the vendor's RIL:
http://android.git.kernel.org/?p=pl.../internal/telephony/cdma/EriManager.java#l137
Code:
136 private void loadEriFileFromModem() {
137 // NOT IMPLEMENTED, Chipset vendor/Operator specific
138 }
139
140 /**
141 * Load the ERI file from a File System file
142 *
143 * In this case the a Phone Support Tool to update the ERI file must be provided
144 * to the Operator
145 */
146 private void loadEriFileFromFileSystem() {
147 // NOT IMPLEMENTED, Chipset vendor/Operator specific
148 }
You can see what SID the phone is registered on through adb, by doing a logcat -d -b radio and looking for registration messages with SIDs in them as well as messages like the following:
D/CDMA ( 116): [CdmaServiceStateTracker] Set CDMA Roaming Indicator to: 128.
mCdmaRoaming = false, isPrlLoaded = true. namMatch = false , IsInPrl = true, mRoamingIndicator = 128, mDefaultRoamingIndicator= 1
-------------
What I'm doing in the eri.xml file is giving the system a definition for Sprint's ERI value of 128. AOSP comes with a default/sample eri.xml that gets loaded, but it contains roam indicator values between 64-75.

[FIX WIP] Battery Drain fix for CM7 UPDATED Ver5 - Radio Update Info

This is posted over in the DHD sub-forum but I didn't find any reference to it over here... stands to reason many may not know about it.
Part of the reason we are getting such low battery life on CM7 may be due to the aic3254 chip not turning off properly when its not being used.
mad-murdock has posted a flashable zip that contains a slightly modified kernel ("just the driver for the AIC3254 dsp chip is changed") along with some DSP related stuff that addresses and corrects this issue.
I personally flashed this on top of CM Nightly 14 after doing a no-wipe (did wipe cache and dav cache of course) upgrade from Nightly 8 + audio/gps fix.
The author of this fix has said:
note: after using phone for any calls, power down is disabled again. usual voice search enables it again.
So although originally it was thought that Version 5 no longer requires Google's voice search or voice dialer to be used once after every reboot to correctly initialize the fix, as you can see, you need to use google voice services after each phone call* to correctly initialize the power management of the chip
Once you have done that, the result of entering the command:
Code:
# aic3254pd status
from terminal emulator on the phone, or:
Code:
adb shell aic3254pd status
from a command line on your PC should give you this:
Code:
Power status of aic3254 chip: OFF
Please note as of this late hour, I'm not sure how this interacts with the changes made to the Inspire 4G kernel. I realize that as of CM7 RC2 there is a Unified kernel in place that handles the audio fix automatically, I do not know if mm's kernel is using that fix or not. I was however able to call my voice mail and leave a message and successfully play it back via google voice.
Use at your own risk, don't blame me, etc etc.
Please report back and let me know both how it affects battery life and whether or not audio quality is adversely impacted.
DOWNLOAD:
Version 5 md5: f7c7b01a47266b26b8a01f2fc853cfbe mirror mirror
more information can be found over in the original thread in the DHD sub-forum
Thanks again to Mad-Murdock for his continuing hard work on this.
*Radio Update Info
Personal tests have shown that after updating the radio, the Voice search only has to be used once after the first call, not after each additional call. This works for me, but I can't guarantee it will work for everyone.
Before Updating your Radio, make sure you are BOTH Radio S-OFF and ENG S-OFF
The Radio I'm using (the Author of the fix is using it as well):
28th January 2011: Radio_12.35d.60.140f_26.06.03.24_M2 - TELUS WWE 1.84.661.1
MD5 Checksum: edc9b36f3e30b8a3aec0f8e5ebfe9484
I haven't had any battery drain with cm7...
HTC Inspire Clockwork Recovery * CM7(kang) * Eng S-Off
BelacNongaw said:
I haven't had any battery drain with cm7...
HTC Inspire Clockwork Recovery * CM7(kang) * Eng S-Off
Click to expand...
Click to collapse
For me CoreDroid on average with the screen off drains 4-8mah, CM7 build 13 is draining 15-100+ . mah
First post updated to contain fix #5
running the command returns that the chip is ON until you run the voice dialer. i used fix 5, flashed over cm7 rc2. obviously, the fix is still broken.
edit;
can verify the fix works once you do run the google voice dialer, pulling 9ma with screen off, before running the voice dialer im pulling 263ma. something is seriously wrong with this mod, glad it's been found, eagerly awaiting a working fix.
edit again;
was something changed with the wifi aswell? im getting full bars when pre-flash i was getting two. sitting in the same chair and haven't moved before during or after the update, so it's not that.
Let's get this pushed into the next nightly.
let's not push this into the nightly until we don't have to keep running google voice to make it work, please? forgetting to do that could ruin your day if you leave your charger at home. :/
fwayfarer said:
let's not push this into the nightly until we don't have to keep running google voice to make it work, please? forgetting to do that could ruin your day if you leave your charger at home. :/
Click to expand...
Click to collapse
You should read the update. #5 does not require the workaround.
What type of draws are you guys seeing? With the patch installed and airplane mode on i'm still seeing a 10mA draw, 18mA with radio on.
you should do some real world testing. do you even run the rom?
i flashed to cm7 rc2, and installed fix 5 as linked above, and running the status command in terminal reports the chip as ON until i run the voice dialer, then it reports the chip as OFF.
did you even read my post?
with the screen off, radio and wifi on i am seeing 9ma draw as reported by battery monitor widget from the market.
fwayfarer said:
you should do some real world testing. do you even run the rom?
i flashed to cm7 rc2, and installed fix 5 as linked above, and running the status command in terminal reports the chip as ON until i run the voice dialer, then it reports the chip as OFF.
did you even read my post?
with the screen off, radio and wifi on i am seeing 9ma draw as reported by battery monitor widget from the market.
Click to expand...
Click to collapse
I've been running the rom for weeks and have tested the newest patch with google voice uninstalled. It works perfectly. This is with RC2 and nightly 14.
removed......
mentalcase said:
I've been running the rom for weeks and have tested the newest patch with google voice uninstalled. It works perfectly. This is with RC2 and nightly 14.
Click to expand...
Click to collapse
welp, read the updated op. looks like voice is still needed.
fwayfarer said:
welp, read the updated op. looks like voice is still needed.
Click to expand...
Click to collapse
I'm not sure where the OP is getting their info from, but the original post over in the dhd section has not been updated and still maintains that voice apps are not needed. Also, no one has posted in that thread since 5 was released to say that there is an issue.
http://forum.xda-developers.com/showpost.php?p=11919563&postcount=1
Edit: Looks like there is an issue on some radios where the chip doesn't turn off automatically after a phone call. I've noticed that if i reboot the chip is off automatically, but after a phone call the voice dial method is needed to turn it back off or a reboot of course. We may have to flash a different radio version to get this to work.
do we know what the offending radio versions are, and what are known good versions? id like to fix this asap, i dont really want to go back to revo, but it was pretty solid compared to all these bugs with cm7.
mentalcase said:
I'm not sure where the OP is getting their info from
Click to expand...
Click to collapse
From the author of the fix. See instead of just reading the first post over there, I read the entire thread (something I would recommend to anyone before posting an uninformed comment that insinuates I don't know what I'm talking about.)
On page 11 I found this:
mad-murdock said:
note: after using phone for any calls, power down is disabled again. usual voice search enables it again.
not sure how to bypass this yet. needs further investigation tomorrow. good night
Swyped with cyanogenmod 7 powered HTC Desire HD. Excuse typos.
Click to expand...
Click to collapse
fwayfarer said:
do we know what the offending radio versions are, and what are known good versions?
Click to expand...
Click to collapse
Currently more investigation is underway, but there does not seem to be a 100% link between radio and correct functionality.
mburris said:
From the author of the fix. See instead of just reading the first post over there, I read the entire thread (something I would recommend to anyone before posting an uninformed comment that insinuates I don't know what I'm talking about.)
On page 11 I found this:
Currently more investigation is underway, but there does not seem to be a 100% link between radio and correct functionality.
Click to expand...
Click to collapse
good work! and screw that guy, he's another one of the "know it all don't tell me anything" sperglord types this forum is polluted with. looking forward to finding a radio which works!
mburris said:
Currently more investigation is underway, but there does not seem to be a 100% link between radio and correct functionality.
Click to expand...
Click to collapse
is there a reason the stock driver can't be pulled over to cm7? copyright issues? compatibility issues?
Radio Information
I have just updated my Radio to the same that the author of this fix is using: Radio_12.35d.60.140f_26.06.03.24_M2 - TELUS WWE 1.84.661.1.
After doing so, I get the following:
After powering on:
Power status of aic3254 chip: OFF
After making a phone call:
Power status of aic3254 chip: ON
After performing voice search:
Power status of aic3254 chip: OFF
After making a second call:
Power status of aic3254 chip: ON
-and about 20 seconds later-
Power status of aic3254 chip: OFF
So, after making the first call, I use voice search once, and all subsequent calls are handled correctly.
Radio info can be found in the OP.
After installing the fix, my phone starts with the aic3254 OFF, and turns on as needed, and shuts off again.
I'm getting about a 9mA draw with this fix, so I can't complain.
skroll82 said:
After installing the fix, my phone starts with the aic3254 OFF, and turns on as needed, and shuts off again.
I'm getting about a 9mA draw with this fix, so I can't complain.
Click to expand...
Click to collapse
+1.
I'm running MIUI with a CM7 kernel and installed Build #5 of the fix and it seems to be working perfectly.
After initial boot chip is off, make a call it turns on, after call it turns back off and stays off, tested with more calls and it works perfectly.
I'm letting it idle right now so I can check my battery usage but I bet it will be nice and low now

CM7 APN Issue is Fixed!

The APN issue in CM7 is finally fixed!
Check out the last few comments here - http://code.google.com/p/cyanogenmo...on Model Network Owner Summary Stars Priority
*I TAKE NO CREDIT FOR THIS*
Wow that's awesome thanks for the update
Sent from my LG-P999 using xda premium
That didn't take long to make it over here. Lol.
Seems good so far here.
Awesome news...loving my G2x more and more every day! Can I just download that boot.img and flash it to my existing ROM through ADB? I'm on EagleBlood 2.3.7 which is a CM7 variant.
pettigrew95 said:
Awesome news...loving my G2x more and more every day! Can I just download that boot.img and flash it to my existing ROM through ADB? I'm on EagleBlood 2.3.7 which is a CM7 variant.
Click to expand...
Click to collapse
It should work fine. The change appears to be in the ramdisk, so if your ROM didn't require anything odd from it, you should be fine. Last time I played with EB, it didn't do anything odd in there.
ttabbal said:
It should work fine. The change appears to be in the ramdisk, so if your ROM didn't require anything odd from it, you should be fine. Last time I played with EB, it didn't do anything odd in there.
Click to expand...
Click to collapse
Thanks going to flash now!!!
Which comment I should read. .?
Reading those comments, it doesn't appear it was "fixed" but rather "helped". It seems that certain reboots didn't shut down the radio "perfectly" and the stock OTA files had some top layer reboot switch, which would reboot the radio after a set time of being disconnected.... which CM lacked.
It is weird because I am running MIUI and I haven't had a disappearing APN in some time... although we don't have a functioning WiFi calling app (Invalid SIM). I just thought it was funny when ricardo threw out Kinteco (or whatever WiFi Calling APK is) as I have wondered why CM7 had bad APN issues when MIUI has bad WiFi Calling. I see they tried building a rom without Kinteco (?) and the issue persisted, so I don't know.
So now, resetting from the UI is the same as a hard reset (pwr + volup) and a battery pull. I think bootup will also recycle the radio so it properly turns up too.
Sweet. While I don't know if it is perfected, it looks like they are on top of it and should be cooked in nightlies within a few days.
First a2dp now apn fix.... Ricardo is a genius, everyone should buy him a beer!!
player911 said:
Reading those comments, it doesn't appear it was "fixed" but rather "helped". It seems that certain reboots didn't shut down the radio "perfectly" and the stock OTA files had some top layer reboot switch, which would reboot the radio after a set time of being disconnected.... which CM lacked.
It is weird because I am running MIUI and I haven't had a disappearing APN in some time... although we don't have a functioning WiFi calling app (Invalid SIM). I just thought it was funny when ricardo threw out Kinteco (or whatever WiFi Calling APK is) as I have wondered why CM7 had bad APN issues when MIUI has bad WiFi Calling. I see they tried building a rom without Kinteco (?) and the issue persisted, so I don't know.
So now, resetting from the UI is the same as a hard reset (pwr + volup) and a battery pull. I think bootup will also recycle the radio so it properly turns up too.
Sweet. While I don't know if it is perfected, it looks like they are on top of it and should be cooked in nightlies within a few days.
Click to expand...
Click to collapse
Actually, I don't think that's quite correct.
The change makes it so the ril-daemon shuts down earlier on reboot, to make sure the radio is stuck in a funny state when the system boots back up, hence the apn issue. Also, the only problem they were reporting still having is sometimes it happens when you come out of cwm and reboot back to android. I just looked at the changelogs on cm7 and it appears he's just patched this as well. Hard reset is not the same as the new reboot function. If you look at the code, you'll see he just added
on property:sys.shutdown.requested=1
stop ril-daemon
at the end of the shutdown sequence. A hard reboot is not the healthiest thing to do on our phone because it's a journaling file system, can create corruption. (It's very rare, but it happens.) This reboot is the same as regular, shutting down everything properly, just adding the stop command to the ril-daemon (the service that controls the radio chip, essentially).
First part of your post was correct, though (Plus, it's already in the nightlies. 165 has the stop ril-daemon on shutdown, and 166 it looks like will have it on rebooting from recovery as well.)
Ricardo is the man
Also, please be sure to keep an eye on the thread. Ricardo has been asking for various radio logcats from both Stock and CM7 ROMs. Everyone that knows how to do this (logcat -b radio) should pitch in with logs as he requests them.
Here's to a %100 working CM7.
And yes, beers.
mstrk242 said:
A hard reboot is not the healthiest thing to do on our phone because it's a journaling file system, can create corruption.
Click to expand...
Click to collapse
I was under the impression that a journaling file system is specifically there to protect against file system corruption. Your comment made it sound like it's riskier to hard-shutdown a journaled file system than a non-journaled one...or maybe I'm misreading you.
Quoth wikipedia:
"A journaling file system is a file system that keeps track of the changes that will be made in a journal (usually a circular log in a dedicated area of the file system) before committing them to the main file system. In the event of a system crash or power failure, such file systems are quicker to bring back online and less likely to become corrupted.[1]"
Read the sentence after. Its very rare but it happens. Ext2/3/4 filesystems are extremely robust. Much better than ntfs and the like. On most other file systems its very likely a hard reboot will corrupt data. Its super rare on journaling file systems but there is a possibility. I just wanted to point out the difference in that post not scare people into not hard rebooting if the need arises.
Sent from my LG-P999

Getting Random Reboots...

Hey guys,
I am getting random reboots on my Nexus 5. It doesn't happen too often. Maybe twice a week or so. It may be happening more often when Im not looking at it, so maybe Im not noticing it sometimes. I haven't been able to pinpoint the cause. Im sure it's some app that is causing it (at least I hope it's not hardware related).
Has anyone else experienced this? Any suggestions on how to find the culprit? Thanks.
I am getting random reboots as well. I enabled generating a bug report with the power button in the developer options. Create a bug report the next time it reboots and share it to your Google Drive or Gmail so you can open the bug report.
Look for "Last boot reason" I was getting Kernel Panics with this error or very similar L1 / TLB Error detected on CPU 2!
[ 7370.931283] I-cache data parity error
[ 7370.931458] I-side CESYNR = 0x00201e01
[ 7370.931557] Kernel panic - not syncing: L1 recoverable error detected
Seems to be bad hardware. I am doing an RMA now ugh.
Hope that helps.
I agree that'd it's bad hardware. There have been some others who have had the same issue
Whenever I get a device. I don't ever restart it for a long time to see if its stable. Because ive had my original gnex random reboot every 24hrs and it was hardware related.
Sent from my Nexus 5 using XDA Premium 4 mobile app

Blaze Signal Keeps Going Out Problem(On Any ROM!)

So here's my issue, my Galaxy S Blaze has been switched from ROM to ROM constantly, I have seen ROMS with modified build.props, other added features, and a bunch of other tweaks, you name it! I don't know what all those tweaks mean, I have no idea if it could affect the way my phone receives the signal but it got me so frustrated that I kept switching roms until finally then I went back to stock and am no longer am switching to another ROM.
Here's a history of the ROM switching I've made in the past couple of months:
1st - MIUI
2nd- Cyanogenmod
3rd- Gummy ROM
4th- Liquidsmooth ROM
5th- Cyanogenmod
6th- Dirty Unicorns (problems with signal started occurring right about here, and onwards)
7th- Stock ROM (hmm... nope nothing fixed.)
8th- Validus (still no, I didn't like the constant force-closing of many apps)
9th- Gummy ROM (nope, what's worse is my screen kept freezing if I had atleast 2 apps open and I slid down the notification drawer)
10th- Cyanogenmod (well, maybe switching to cyanogenmod will fix it)
11th- Gummy ROM (*sigh* switching back? Nope, still didn't help my signal)
12th- Stock ROM (you would expect it to be fixed right about here, but nope)
So what's up what is the exact problem with my signal? Here's the thing: My signal works! That's a start atleast. However, if I turn on my Wi-Fi while I'm home, I can still call/text people, all of that works. But after maybe 2 hours or so, the signal bar is still there, it's telling me it has signal and it's connected, SOMETIMES it will be empty meaning I have no signal(when I really do). But in reality, I can't receive texts, nor calls, none of that. So how do I fix it? By restarting my phone sadly, that has been the only solution for me for these past 2 months. People have complained to me because I don't answer my phone anymore, well I'm sorry my phone can't receive those calls due to this messed up signal. There are 3 other T-Mobile phones in the house that have no problem! The problem here is with my Blaze phone.
So what if I turn the Wi-Fi off for the whole day and see if it's the main thing causing the issue? Well, I did this. Turns out that the signal stays on longer than when I'm on Wi-Fi but it still goes out. I have switched SIM Cards, I have tried switching my APN: from "epc.tmobile.com" to "fast.t-mobile.com" but the problem appears to happen more quickly on the "epc" one than the "fast" one. Please help me with this, this has been frustrating me a lot lately. I'm not sure if anyone has even had the same exact problem that I'm having, I've searched online but haven't seen a similar problem.
Some of you might say, wow that is a lot of ROMS you've switched to, I'm sure there were more that I missed but that's as of recent. I can install ROMS correctly, I know how to use CWM when installing a .zip and using Odin when it's a .tar(or other supported file extensions). I've factory reset, wiped the cache, the dalvik cache, all before installing a new rom. After installing each rom, I've also factory reset and wiped the cache to make sure no other problems could affect the way the rom would work. Hopefully I did the procedure right, thanks for anyone who's willing to help me!
Right now I am running:
Baseband Version:
T769UVLH5
Kernel Version:
3.0.8-perf-T769UVLH5-CL990184
[email protected] #1
SMP PREEMPT Fri Aug 17 15:12:14 KST 2012
Android Version:
4.0.4
Another Issue is that I can't even transfer files to and from my phone when connected to my computer! This is another big issue, here are some images:
http :// i.imgur.com/xx699ss.png
http :// i.imgur.com/1wRzJpX.png
Here's what happens when I turn Wi-Fi Calling on but maybe it's just a built-in function that I forgot it had and it's probably normal:
http :// i.imgur.com/cTSqRci.png
By the way, sorry for the links just copy and paste them in a browser to and remove the spaces between the http :// and i.imgur, thanks! Unfortunately, I can't post links until I reach 10 posts. If the links don't work for you, I've also provided attachments.
Many thanks!!!
That last picture does show the proper function of Wi-Fi calling however I don't know what to say about the rest of your problems.
Sent from my SAMSUNG-SGH-T769 using XDA Free mobile app
There are two things I would recommend trying...
1. Use Blackhole System Wipe
I know you've been following all the proper steps in CWM (and I would say to keep doing so), but I've added using Blackhole, in addition to the first steps, and I always get great system performance on my phone, and my parent's phones (I put them on ProvisionMod after stock was being stupid). It works well for pre installation for ANY ROM and helps prevent pesky issues. However, chances are, your issue is baseband related and this probably won't solve it... But still! You never know! It's worth a shot!
2. Reroot your phone
I know this will be annoying and pesky... but sometimes the process goes wrong from the beginning and starts giving issues later on... When I first rooted my mom's blaze, something went wrong, despite my following all the directions, and one of her partitions was completely disabled, no matter the ROM. I redid the process of rooting her phone (not from GB though... From the ICS stock) and fixed the issue instantly! I would try these two steps first and see if they do anything! Good luck!
Sent from The Doctor's Blaze

Categories

Resources