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.