[Q] Getting Random Rebooots

2,279 posts
Thanks Meter: 522
Post Reply Subscribe to Thread Email Thread
10th July 2014, 11:41 PM |#11  
rovo89's Avatar
Senior Recognized Developer
Thanks Meter: 51,521
Donate to Me
Originally Posted by sabret00the

Maybe a debug version can print something after every command in order to pinpoint the faulty command and then we can look for a workaround?

I really wouldn't know what to print there and what this could verify. As I said - if any of the commands hangs or shows unwanted results, you wouldn't even get the reboot prompt.
11th July 2014, 05:24 AM |#12  
Senior Member
Thanks Meter: 125
Took a look and thats what I think:
- the system is working fine, no signs of troublse (at least no signs within the logged stuff).
- immediately something called "mmc0: mmc_start_bkops: raw_bkops_status=0x2, from_exception=1" happens. It's undoubtly some kind of error related to mmc0 = internal memory (equals to WHOLE nand in a typical configuration). Neverthless of what happens next, this is the event that triggers further steps leading to sys collapse. Also it does not look like something you should totały ignore, as it is always possible that its caused by a hardware failure resulting in disconnecting nand from time to time, however the chance is small... well, i wouldn't be surprised if it is a something natural that read failures happen on every system from time to time . It would be a good idea to investigate further into this issue as it may be everything or even nothing. Maybe ef2fsck -y mmcblk* of all ext4 partitions will help? Check if ext4 filesystems are mounted with barrier=1 and remount if the answer is no; maybe set a different governor or check io_scheduler settings like nomerges which is recommended to be 1 at least, if you have touched it in any way or if you are using some tweaking app...

- sysrq 40 is called due to discussed failure. Sysrq is a linux interface providing possibility of echo'eing some values to call various system reactions, including forcing kernel panic, syncing data, shutting something down, etc random stuff. It is turned off by default on Android as it is more applicable for desktop pcs with harddisks etc. I also think that we should worry about why something opens up sysrq access and dont care about the fact that something was allowed to sendit, guess calling sysrqs remained from linux code.

Any sysctl tweaking recently?

The most possible solution that may stop the reboots is to turn off depreciated sysrq support so no strange actions, some of them probably not tested within android at all, shall happen.
echo 0 > /proc/sys/kernel/sysrq
chmod 000 /proc/sys/kernel/sysrq
You may want to run above commandś using init.d script on boot.
Please however remember that it is your responsibility for what you'll do and there is a light chance that if the real issue is the hardware, disabling the security exit for the system giveś some risk of blowing something up ;]

The most recommended solution is to either diagnose and solve mmc0 error or/and find out what may be the cause of opening such a depreciated interface as sysrq at all.

- first action after receiving signal is short and is CPU related. No idea what happens here - maybe it is some kind of reset given to the core which iś responsible for mmc0 support, or i dunno...
- second action is a procedure of remounting some partitions as read-only. I wonder if it is triggered just to stop writing operations before reboot or it is causing the reboot because it is designed for desktop linux pcs, not for mmc/android devices, ill bet the 2nd one is a winner.
- amount of ext4 devices suggest that /data and other standard partitions were included without exceptions.
- all partitions are probably remounted as ro. Nothing can write nowhere. Some stuff starts to call first warnings, iincluding xposed process, which is not the cause but the victim. Even android cannot save anything for any purposes anywhere. And soon....

...something worse than warning happened. Something fragile stopped working due to writing denial. Reboot.

I guess Android finally dies in a result of numerous failures caused by the fact that no data can be written to physical memory by any system component or any other element.

Summarize: something is opening sysrq support, guess not the best idea...? Solution: close it, lock it, investigate into why it is opened and what causes that it becomes open.Anyway, after some time, unpredictable suspicious event related to mmc0 of unknown origin happens, may be dangerous! However, event causes system to initiate procedure which consist of disabling write access to any partition. In short time various failures happened and as Android was designed with assumption of 24/7 rw mounted /data plus also using /cache is impossible reboot happens.
Last edited by esgie; 11th July 2014 at 06:20 AM.
The Following User Says Thank You to esgie For This Useful Post: [ View ]
Post Reply Subscribe to Thread

lg g3, towelroot, xposed

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes