well anyway, even if they released the source i guess it would be janky due to cos base, even now playing with boot on oos causes crashdump and boot destroyed warning on cos.
if it was working before, it should now though, i had my 5t 18w brick and it's cable. it was charging fine with dash(when i was on oos11 with previous kernel versions.). I could say maybe cable got damaged somehow? but i really dont know. if you are using oos, maybe try stock oos kernel or try an older elemental kernel version which was working for you?
imo i would keep it off if my ram was 12gb, dunno about 8 ones. one thing i could do is give 1-2 days for both on and off. compare it and see which suits best.
if i was him, I would try my luck with a cable which supports power delivery like PD100. I know people with 8t using other branded PD100 cables and get 60W charging normally.
Are you willing to share your gpu table? Is it meant for gaming or battery?imo i would keep it off if my ram was 12gb, dunno about 8 ones. one thing i could do is give 1-2 days for both on and off. compare it and see which suits best.
also try to use a single kernel manager, if you use more than 1, they could both have inflict over eachother. (also someone once told me that fkm locks userspace. dont know what it means but i like elemental manager more.) I use my own custom made gpu table and voltages, fkm doesnt work well with custom gpu freqs but elemental does.
I might be able to shed a bit of light.
The QCom CrashDump Mode seems to be due to a kernel or dtbo mismatch, for example @mauronofrio and I noticed it when the kernel was updated between OOS versions but not in TWRP's .img. The solution was to always use the latest prebuilt stock kernel and use the one from India, IIRC.
So, if I had to guess why restoring a kernel backup might cause this issue, I'd probably think perhaps the user made that backup before getting an OTA or something, so once they went to restore it it wasn't for the correct OOS version anymore.
So none of that would be flar2 or EXKM's fault, but more on the end user for not understanding how their device behaves or updating their backups.
@czerdrill, @old_fart can you please report exactly steps how you backup and restore through the exkm app ( before getting crashdump)
Are you sure you didn't try to restore a backup from a previous oos ?
---------- Post added at 09:14 AM ---------- Previous post was at 08:42 AM ----------
That's i believe the issue...
Most custom kernels are using custom dtbo
So users when they restoring stock kernel through your app the stock dtbo it doesn't be restored...
It will be very useful to add a dtbo.img backup ..
I go to kernel backup, click the saved backup i have and say yes to restore. I want to be clear i don't think it's ekxms fault either, it's something i did I'm sure. It's possible i restored from an earlier version although i make it a habit to backup after each update.
In another instance i restored the stock kernel and lost wifi and lte. Was only able to get them back after flashing elemental again.
I don't know what I'm doing wrong but was just sharing my experience.
Sent from my IN2025 using Tapatalk