I create this thread to track the issue and want to get any idea and fix on the random reboot of CM10 series (it looks the Cm10.1 also has this issue).
One major problem is reading the CPU OM file (/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state, please find the details reporting in below link). This problem can be fixed in framework.jar by increasing the buffer. I have done for it and the frequency of reboot is down. But still have some random reboots....., disappointed.
https://code.google.com/p/android/issues/detail?id=9733
Remaining reboots will cause the screen in yellow and then reboot. Please find the details in below two links (one is reporting to CM bug tracking, but no one take care of it.).
https://jira.cyanogenmod.org/browse/CYAN-388
http://forum.cyanogenmod.com/topic/61997-cm10-freeze-yellow-screen-reboot-issue/
Also find someone had already reported this issue in XDA (http://forum.xda-developers.com/showthread.php?t=2301552) but cannot get the answer..., disappointed.
The problem is how to get the log for this issue? It will break logcat working since the reboot running.
Is there any idea or suggestion for this issue. Thank you so much!!!
If you want a log after a reboot, the file last_kmsg is used. http://forum.xda-developers.com/showthread.php?t=2093987
Good luck with your endeavor.
A bug report from 2011 is very unlikely relevant to recent ROMs, for one, unless you know for sure this buffer bug is still an issue and is not otherwise accounted for. And the 'yellow screen reboot' could be any number of things, but feel free to get something like a USB serial device going and really do some debugging on it.
You can be disappointed all you want, patches welcome...
Related
I've been having crash events on my Galaxy Nexus, which creates bugreport text files and screen shots on a regular basis, not to mention popping up an Intent dialog asking me how I want to send crash info. It's an annoyance I'd like to correct, so I'm looking for ways to figure out and fix whatever is causing the problem.
Is there a good methodology I can run through to at least narrow down what software is throwing the errors and triggering bug reports? Failing that, is there a decent way to suppress them?
The crashes aren't predicable and seem to occur regardless of what app I'm currently using. Some (I think) occur when I'm not using the phone, and produce a screenshot of my lockscreen as debug info. I've done a fair amount of tinkering, including basic programming in Eclipse, so I'm wondering if I can use LogCat or some other debug tool to observe a crash. Or if I can look for a specific line of the 4 meg bugreport.txt to find what process is freaking. I just don't have enough experience with analyzing when things go wrong to know where to look.
Some simple facts about my case if you're interested in offering opinions:
-Been rooted on the Nexus for ages, but crashes only started fairly recently.
-Started roughly when (give or take a few days) I flashed to stock 4.0.4 and latest Verizon radios, because my collection of mods (maybe Clockwork Recovery) was preventing an OTA update from succeeding. Interestingly, it continued after doing a SuperWipe (of absolutely everything) and flashing in Jelly Bean with stock kernel.
-The radios were reflashed, but are the same between 4.0.4 and 4.1
-All the apps I use are all installed on both OS's. I don't particularly want to go through the time required to remove apps, wait for crashes, and reload them, particularly if there is a quicker solution.
I'm having the same issue. It has persisted through multiple re-images and wipes so It has to be something that I reload on the system, but I cannot figure out what it is...
I've tried digging through the crash reports and watching logcat but i haven't been able to reproduce the crashes on demand...
Update: Actually I have a theory that these crashes may actually be related to Google Wallet. My Secure Element is locked, but i don't have a need for wallet anyhow so I never got my device replaced. I don't remember having this issue before I switched my GNex to the Takju ROM (which included Wallet). This would also explain why the issue seems to persist between wipes (Each ROM I've loaded has always had Wallet pre-installed). I'm going to try using Titanium Backup to freeze Wallet and see if I get anymore crashes. I'll keep you posted.
Resolution:
The bug reports are being generated when USB Debugging is on and Volume Up, Volume Down, and Power are all hit. For me, this was happening frequently because my TPU case is fairly tight and it depresses the volume keys inadvertently.
Thread where I found the problem: http://forum.xda-developers.com/showthread.php?t=1451521
First off here is my info:
Phone: AT&T Samsung Galaxy Note i717
ROM: Cyanogenmod 10 quincyatt nightly build 12/23 (in attempt to remedy my problem)
Using this guide http://forum.xda-developers.com/showthread.php?t=1958944&highlight=install+cyanogenmod in installed the 11//14 stable build initially without too much trouble.
I did find right away that I was unable to locate any camera application or any way to access it other than the lockscreen shortcut.
When I attempted to use the shortcut from the lockscreen it simply does nothing. It doesn't crash my phone, but it also does not open my camera.
I also tried installing a couple of camera applications from the play store and they start up, but the camera never activates.
This problem persisted even when I upgraded to todays nightly build 12/23, also so far I have noticed no new problems with this build as opposed to the 11/14 stable build.
I have searched for a solution for this problem in the forums, and perhaps I missed something, if that is the case then please direct me to the proper thread.
I tried posting this in the development section only to find out that I am unable to (I've been using this site for a while but never needed to register to ask a question).
If anyone has had this problem and/or knows how to fix it I would greatly appreciate your input.
I apologize if I have left anything out, if I have then let me know and I will get back to you as soon as I can.
Edit: I updated to the 12/24 nightly build today and it appears to have resolved the camera issue right away. If anyone else is having this problem then I hope this helps.
ill give $5 to the person that fixes this.
tatzelworm said:
First off here is my info:
Phone: AT&T Samsung Galaxy Note i717
ROM: Cyanogenmod 10 quincyatt nightly build 12/23 (in attempt to remedy my problem)
Using this guide http://forum.xda-developers.com/showthread.php?t=1958944&highlight=install+cyanogenmod in installed the 11//14 stable build initially without too much trouble.
I did find right away that I was unable to locate any camera application or any way to access it other than the lockscreen shortcut.
When I attempted to use the shortcut from the lockscreen it simply does nothing. It doesn't crash my phone, but it also does not open my camera.
I also tried installing a couple of camera applications from the play store and they start up, but the camera never activates.
This problem persisted even when I upgraded to todays nightly build 12/23, also so far I have noticed no new problems with this build as opposed to the 11/14 stable build.
I have searched for a solution for this problem in the forums, and perhaps I missed something, if that is the case then please direct me to the proper thread.
I tried posting this in the development section only to find out that I am unable to (I've been using this site for a while but never needed to register to ask a question).
If anyone has had this problem and/or knows how to fix it I would greatly appreciate your input.
I apologize if I have left anything out, if I have then let me know and I will get back to you as soon as I can.
Edit: I updated to the 12/24 nightly build today and it appears to have resolved the camera issue right away. If anyone else is having this problem then I hope this helps.
Click to expand...
Click to collapse
I have the same problem.
Fixed?
James Musacchio said:
I have the same problem.
Click to expand...
Click to collapse
Well as I stated in my edit, the 12/24 nightly appears to have fixed this issue so far as i can tell. Also updated to the 12/25 nightly and the camera still works. One bad thing about this is that I have experienced more than a few reboots, but my phone starts up so fast afterwards that its a small price to pay for having my camera back.
As always, make a backup before you flash the newest nightly but I haven't seen too many problems other than the occasional crash of a couple apps and the unfortunate reoccurring crash of Apollo which is annoying.
Let me know if this fixes your issue, if it does then I'm glad I could help.
Tried CM10 nightly myself tonight, and was quite happy with it, until ....
Random reboots ....5 in 3 hours.
Camera is good, but the menu button was iffy ....
It's getting better, but I'm gonna stay with my backup for a bit longer I think ....g
12/25 is a bit sketchy
gregsarg said:
Tried CM10 nightly myself tonight, and was quite happy with it, until ....
Random reboots ....5 in 3 hours.
Camera is good, but the menu button was iffy ....
It's getting better, but I'm gonna stay with my backup for a bit longer I think ....g
Click to expand...
Click to collapse
Yeah I decided to try the 12/25 build and didn't notice any improvements from the 12/24. Ironically about an hour after my last post my phone then went into a reboot loop that I couldn't stop until I removed my battery. I had to boot into cwm recovery and then reflash the 12/24 build. So far this is the most stable nightly that allows for the camera to work without causing too many issues besides one incident I had the first day I flashed it.
I recommend people stay away from 12/25 as it was extremely unstable in my experience. I may try the 12/26 build simply because I can, but I'll definitely keep the 12/24 on hand if that fails as well.
ok, for some reason, thought build.prop q's were relevant to the kernel...
anyway, I edited build.prop in /system with RootExplorer's text editor. changed the value for wifi.supplicant_scan_interval from 30 to 120. no extra lines or spaces, etc- just changed the number, saved, then rebooted. it took an obscene amount of time to boot up and the device stopped going into deep sleep after a short while. I installed better battery stats to see what was wrong and the app indicated mmc_delayed_work under kernel or partial wakelocks (i forget which). I restored the original build.prop and the device worked like normal.
Is this a bug or is ICS/JB different enough from GB that you have to go through alternate means to change build.prop (eg flashing an update script from CWM, or something similar)?
I've tried this twice already and gotten similar results and the method by which I edited the build.prop was exactly the same as I used to edit it on GB without issue.
another thread I checked out in the S II dev thread indicated that this is possible- editing build.prop (wifi scan at least, on top of a few others parameters)- w/o issue, so....yeah.
alljokingaside said:
ok, for some reason, thought build.prop q's were relevant to the kernel...
anyway, I edited build.prop in /system with RootExplorer's text editor. changed the value for wifi.supplicant_scan_interval from 30 to 120. no extra lines or spaces, etc- just changed the number, saved, then rebooted. it took an obscene amount of time to boot up and the device stopped going into deep sleep after a short while. I installed better battery stats to see what was wrong and the app indicated mmc_delayed_work under kernel or partial wakelocks (i forget which). I restored the original build.prop and the device worked like normal.
Is this a bug or is ICS/JB different enough from GB that you have to go through alternate means to change build.prop (eg flashing an update script from CWM, or something similar)?
I've tried this twice already and gotten similar results and the method by which I edited the build.prop was exactly the same as I used to edit it on GB without issue.
another thread I checked out in the S II dev thread indicated that this is possible- editing build.prop (wifi scan at least, on top of a few others parameters)- w/o issue, so....yeah.
Click to expand...
Click to collapse
I have no idea why that would happen, but I guarantee you the interval is fine where it is. I've left my player on with wi-fi over a week.
Mevordel said:
I have no idea why that would happen, but I guarantee you the interval is fine where it is. I've left my player on with wi-fi over a week.
Click to expand...
Click to collapse
I'm recording atm but problem isn't replicating. go figure; well, if it does, I'll post a logcat. if not, good for me since I forget to turn the wifi off most of the time and especially in places with no open wifi. anyway, I was posting this in case someone else did come across a similar problem and had a solution since my searches led nowhere (searching for anything mmc_delayed_work related comes up with little useful info/apparently a lot of once-valid GB tweaks are "busted"/not in ICS code base)
whether or not the scan interval isn't exactly the point, why I'm pursuing it; it's the specific point atm, but the general point is device ownership- tailoring your device to your heart's desire; complete ownership. that's the premise behind this whole site as I'm sure everyone here is aware. if I did something to mess it up along the way, great. but if it is a bug or something with ICS code base, it's be nice to know. a lot of folk like messing with build.prop so it'd be nice to know what can or cannot be messed with.
atm, it does look like I messed something up when editing and saving- perhaps I added a space or line where it shouldn't've been- since the device is sleeping as it should, again, if I find something, I'll post the logcat.
thanks for the re:
alljokingaside said:
I'm recording atm but problem isn't replicating. go figure; well, if it does, I'll post a logcat. if not, good for me since I forget to turn the wifi off most of the time and especially in places with no open wifi. anyway, I was posting this in case someone else did come across a similar problem and had a solution since my searches led nowhere (searching for anything mmc_delayed_work related comes up with little useful info/apparently a lot of once-valid GB tweaks are "busted"/not in ICS code base)
whether or not the scan interval isn't exactly the point, why I'm pursuing it; it's the specific point atm, but the general point is device ownership- tailoring your device to your heart's desire; complete ownership. that's the premise behind this whole site as I'm sure everyone here is aware. if I did something to mess it up along the way, great. but if it is a bug or something with ICS code base, it's be nice to know. a lot of folk like messing with build.prop so it'd be nice to know what can or cannot be messed with.
atm, it does look like I messed something up when editing and saving- perhaps I added a space or line where it shouldn't've been- since the device is sleeping as it should, again, if I find something, I'll post the logcat.
thanks for the re:
Click to expand...
Click to collapse
I understand.
Thinking about it, mmc_delayed_work seems like it's tryng to catch up the SDcard or something. Did you reboot cleanly? That may be the issue.
Mevordel said:
I understand.
Thinking about it, mmc_delayed_work seems like it's tryng to catch up the SDcard or something. Did you reboot cleanly? That may be the issue.
Click to expand...
Click to collapse
No clue. what do you mean by "reboot cleanly"? if by that you mean, did I reboot using the reboot option in the power menu, then yes. always.
After restoring a backup and re-editing build.prop, sleep worked like gamebusters. Except, bluetooth auto-toggled on ("bluetooth is turning on"). After rebooting, it was stuck on the boot animation screen for a few minutes. A reboot after that pretty much boot looped it. I restored my backup afterwards...
Looking in the logcat (after editing), I noticed a ton of errors and permission denials.... Since I don't have much expertise here, I can't say for sure that they're normal but they seem to be abnormal. Wayyy more than I remember seeing when I browsed through before on a "clean" boot. But again, with the lack of expertise (or any functional knowledge for that matter)
==
Now, after having restored the backup before making the edits and rebooting, it seems to be stuck in a bootloop....huh. ok, after rebooting it 2x, it finally seems to have booted up "normally." Both before restoring (w/ edits and BT error) and after restoring (w/o build.prop edits), it's taking a lot longer to boot up than it used to....guesstimating 3-4 minutes. When it boots up, I get/got: "process system isn't responding" (both before and after restores now) and something about alarm error.
I've attached logcats of both pre- and post-event, if you're curious. As to "solving" this,I'm just gonna re-flash the PA ROM and wipe caches to get rid of these problems. ergh. device meets my foot against the wall is next on the checklist.
thanks again. I'd like to say, Stay classy, San Diego, but we all know San Diego and its class
I did a search here before posting this question. I did not find the answer.
When reporting an issue, like a boot loop, with a ROM, what files, if any should be captured before wiping/formatting?
For example, yesterday I installed the CM10.1 - WILD-FOR-THE-NIGHT-04082013-shooter.zip ROM. The phone was performing fantastic all day yesterday. I installed some apps and set things up. This morning, I decided to reboot the phone. Boot stuck at the CyanogenMod boot screen. I tried a battery pull, wiping cache & dalvik. Still the boot hang. I ended up formatting the 'data' partition then the phone successfully booted without having to reload the ROM.
I would have posted this in the CM10.1 thread in the development side but I'm not at my "10 posts" yet.
If you ever run into a bootloop or any issue like random reboots or a sudden FC of an app, the best thing for you to do IF you want to help that developer is this....
1. Provide as much information as possible about the issue.
Many users tend to think that by saying "my phone is getting random reboots" it helps BUT honestly, it does nothing at all!
In fact, think of it like if you took your car to the repair shop and said....my car makes a funny noise and ran out the repair shop! Do you think that would help the mechanics?
Unless they are wizards, I doubt it! Developers are not wizards either....clever individuals BUT not wizards
So when you're reporting an issue, state what you were doing to your phone if anything at all. What HBOOT, Kernel, CPU settings (min/max and governor) and just anything that you can think of! I personally would rather have MORE information then what I needed then not enough.
If is possible, provide a step by step of how to recreate the problem! Most developers love to able to recreate the issue on their phone so they can pull logcats of their own and test fixes
2. Along with providing vital information about your issue, there's also things that you may not know are happening in the background which might play a role in your issue.
This is where pulling a logcat is useful! Below is a link that goes into detail on what you need in order to pull a logcat and some useful information for you to read over as well...
http://forum.xda-developers.com/showthread.php?t=2141817
I am overall really happy with my Mi A3 but there are a lot of bugs and I came from a device that received unofficial LOS builds from a single developer once every couple of weeks. I had my phone for 20 days and it received 2 updates since I got it but still not a single bug is fixed, where do I actually report these? does anyone know? some of them are extremely annoying (like screen elements sticking to screen and not going away until you clear recent apps).
System settings -> feedback. Type in your problem, check "include logs" and submit the bug. App collects system logs for a minute or two, so make sure that you replicate the issue at least once during this period. I would advise reporting and replicating one bug at a time.
You won't get any confirmation from Xiaomi (though you can see bugs you submitted), so don't be surprised by a lack of response.
_mysiak_ said:
System settings -> feedback. Type in your problem, check "include logs" and submit the bug. App collects system logs for a minute or two, so make sure that you replicate the issue at least once during this period. I would advise reporting and replicating one bug at a time.
You won't get any confirmation from Xiaomi (though you can see bugs you submitted), so don't be surprised by a lack of response.
Click to expand...
Click to collapse
This feedback is always crashes, while I'm trying to report real problem:
https://forum.xda-developers.com/mi...aving-screen-watermarks-t3994067#post81079831
https://in.c.mi.com/thread-1990058-1-0.html
https://in.c.mi.com/thread-1996143-1-0.html
https://in.c.mi.com/us/thread-2011897-1-0.html
dkorzhevin said:
This feedback is always crashes, while I'm trying to report real problem:
https://forum.xda-developers.com/mi...aving-screen-watermarks-t3994067#post81079831
https://in.c.mi.com/thread-1990058-1-0.html
https://in.c.mi.com/thread-1996143-1-0.html
https://in.c.mi.com/us/thread-2011897-1-0.html
Click to expand...
Click to collapse
I've just submitted a bug report with screenshot and logs, showing this issue. Did you allow all permissions which were asked on the first run of feeedback app?
Yes, I gave all permissions to app.