Related
What is fsync
crazyboyxx said:
What is fsync
Click to expand...
Click to collapse
It's a system call in Unix/Linux. "man fsync" says:
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Click to expand...
Click to collapse
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data.
_that said:
It's a system call in Unix/Linux. "man fsync" says:
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data.
Click to expand...
Click to collapse
Thanks :good:
What kind of data may be lost when fsync is disabled? could you please give an example? may it cause a serious damage to the phone's system?
your_login said:
What kind of data may be lost when fsync is disabled? could you please give an example? may it cause a serious damage to the phone's system?
Click to expand...
Click to collapse
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.
So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.
In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.
So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.
If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.
So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.
_that said:
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.
So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.
In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.
So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.
If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.
So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.
Click to expand...
Click to collapse
What about RRs [Random Reboots] ??
alizafar said:
What about RRs [Random Reboots] ??
Click to expand...
Click to collapse
Obviously, the same considerations apply as with a "hard" system hang -- the only difference being that the system reboots itself instead of you pressing the button.
EDIT: I thought it was a strange question (due to the answer being so obvious),, but then I read _that's answer and he even explicitly stated it in his reply. Please read a reply, he didn't formulate so nicely and eloquently to have you read only 4% of what he wrote. :S
_that said:
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.
So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.
In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.
So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.
If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.
So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.
Click to expand...
Click to collapse
How would having fsync enabled help save data in case of a system crash? I mean, its unexpected and can interrupt the block call verification anyway, no? I'm assuming that without fsync you go for longer without "notifying" the OS about the changes in your data. So is it possible to change the fsync intervals so it doesn't happen constantly and cause lag, but happens frequently enough so that nothing extremely bad happens if the battery runs out or I get a random reboot? Or is that not how it works?
_that said:
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.
So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.
In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.
So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.
If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.
So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.
Click to expand...
Click to collapse
Long press back kill apps shouldn't be used if dynamic fsync is disabled?
yavu said:
Long press back kill apps shouldn't be used if dynamic fsync is disabled?
Click to expand...
Click to collapse
I don't know what you mean, but I thought I had already made it clear that the only situation where disabled fsync can cause problems is in case of unexpected whole system hangs, shutdowns and reboots.
_that said:
I don't know what you mean, but I thought I had already made it clear that the only situation where disabled fsync can cause problems is in case of unexpected whole system hangs, shutdowns and reboots.
Click to expand...
Click to collapse
I think his question is, can he corrupt an app or i's data if he kills it with either a task killer or with a shortcut setup as a task killer. Based on your response, the answer (correct me if I'm wrong) is the only thing that could possibly be affected with a disabled fsync is the app that was killed - which isn't a big deal because it does not fall into your catastrophic loss category of RR, Hard shut, etc. where your system becomes vulnerable.
sgkla said:
I think his question is, can he corrupt an app or i's data if he kills it with either a task killer or with a shortcut setup as a task killer. Based on your response, the answer (correct me if I'm wrong) is the only thing that could possibly be affected with a disabled fsync is the app that was killed - which isn't a big deal because it does not fall into your catastrophic loss category of RR, Hard shut, etc. where your system becomes vulnerable.
Click to expand...
Click to collapse
Killing an app is exactly as dangerous or safe with fsync disabled as with fsync enabled.
@_that
Can FSync be in any way related to system lag... I mean if it does, will it reduce lag with FSync enabled or disabled???
Thanks
Sent from my GT-I9500 using Tapatalk 4 - Hassan K. Malik
HassanM said:
@_that
Can FSync be in any way related to system lag... I mean if it does, will it reduce lag with FSync enabled or disabled???
Click to expand...
Click to collapse
Have you read post #2?
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
I see what you are trying to say here but unfortunatelly my experiences are different:
With Dynamic FSync Enabled - when my system crashes from any reason I always loose some data (e.g. my tapatalk app always lost all data).
So I keep Dynamic Fsync Disabled - my system can crash anytime and my data are kept intact. ...
So how this really works?
s3icc0 said:
I see what you are trying to say here but unfortunatelly my experiences are different:
With Dynamic FSync Enabled - when my system crashes from any reason I always loose some data (e.g. my tapatalk app always lost all data).
So I keep Dynamic Fsync Disabled - my system can crash anytime and my data are kept intact. ...
So how this really works?
Click to expand...
Click to collapse
If you disabled dynamic fsnc then you have fsync enabled and you are not getting any benefits.
Dynamic FSYNC = ENABLED
- Screen on = NORMAL FSYNC OFF = faster IO
- Screen off = NORMAL FSYNC ON = slower IO
Dynamic FSYNC = DISABLED
- Screen on = NORMAL FSYNC ON = slower IO
- Screen off = NORMAL FSYNC ON = slower IO
sbdags said:
If you disabled dynamic fsnc then you have fsync enabled and you are not getting any benefits.
Dynamic FSYNC = ENABLED
- Screen on = NORMAL FSYNC OFF = faster IO
- Screen off = NORMAL FSYNC ON = slower IO
Dynamic FSYNC = DISABLED
- Screen on = NORMAL FSYNC ON = slower IO
- Screen off = NORMAL FSYNC ON = slower IO
Click to expand...
Click to collapse
But with enabled I am loosing my data in case of system errors
s3icc0 said:
But with enabled I am loosing my data in case of system errors
Click to expand...
Click to collapse
Yes only if the system crashes you may lose some data.
sbdags said:
Yes only if the system crashes you may lose some data.
Click to expand...
Click to collapse
That is not a good news for someone who spend half of life on XDA trying all possible features, tweaks and roms
_that said:
All data that any app thinks it has written to storage (as it explicitly instructed the OS to do so), but has not been written yet by the OS, may be lost in case of an unexpected system crash.
So as long as the system is running normally, all cached data is eventually written to the eMMC/SD, usually a few seconds after the write request, and everything works normally.
In case of a random reboot, or a "hard" system hang which requires you to power off and restart, or if you run out of battery, AND some app or background service wanted to write something to the file system just before that crash, such cached data is lost.
So what can happen? No hardware is damaged. In the absolutely worst case, the filesystem on your data partition is irrecoverably damaged and you have to do a factory reset, losing all your apps and your data, photos etc. (you do have a backup, don't you?). The chance for this worst case to happen is extremely low - in most cases the filesystem is automatically repaired at startup, and the incompletely written files are simply deleted. If this does not work for some reason, you can still manually try running fsck from the recovery.
If some system service just updated a database before the crash, it may be inconsistent after restarting. This can lead to malfunction of that service, e.g. FCs, missing info in your calendar, missing or garbled media files, etc.
So in summary - as long as the system is stable, disabling fsync only increases performance. By the way, app crashes (FC, ANR, ...) do not hurt here, only complete system crashes are bad.
Click to expand...
Click to collapse
I got such a huge problem with the force reboot thing and now i'm really thinking it is Fsync related. I own a note 6 pro and i always keep fsync disabled because of the performance increase that people say. One day the phone had to restart the UI and for some reason UI wasn't starting again, so i forced the reboot. The phone ended up with stutters anytime it entered the system and in any rom (even stock), imei and mac got gone and the rom i was on was really buggy, like: status bar wouldn't expand, home button wasn't working and a lot of other things.
This issue happened on the moto g falcon i'm using due to my note 6 pro bug. I also kept Fsync disabled on this one, and i had to forced reboot it because an app had freezed. Again, status bar wasn't expanding, home and recents button wasn't working, notificatons wasn't showing... Thank god my imei and mac isn't gone. A clean rom reflash worked for moto g, but nothing i tried worked out for note 6 pro. It doesn't happens on the first forced reboot, but takes some of them to happen.
Do you think Fsync can have such a deep impact even to mess with some partitions on the phone if it's suddenly rebooted?
UPDATE:
It seems that something not related to this driver relies on the old wakelock and it's now causing some partial wakelocks and causing some failed attemps to suspend:
Code:
PM: Device power.0 failed to suspend late: error -11
Restore the old module if you think your battery life is worse than before.
You can do that by flashing your favourite kernel, your current ROM or restoring the backuped module as explained here below.
I'll see if I can solve the problem.
_______________
I did some changes to decrease samsung-battery wakelock total time doing some optimizations, getting good results.
Ideally, the changes I made would save some battery, but I didn't properly verify this.
What I'm sure about is that samsung-battery wakelock total time is now very low, which means less time spent awake when the screen is off.
BetterBatteryStats screenshot after 3 and a half hours of use: 2 seconds of total time for samsung-battery. Not bad considering that the fixed duration of a single wakelock request was 3 seconds.
The driver had never been directly built into the kernel (EDIT: Adi_Pat did it in his kernel, read the notes below), we had always used a module, so you don't need to change kernel or ROM in order to use this, it shouldn't matter which ROM you are on as long as it's a CyanogenMod (9+) based ROM. You just need to flash the zip attached, which will replace the module in /system.
Flashing this on stock ROMs won't do anything.
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
A backup is automatically created after the flash, you can find it in:
Code:
/sdcard/backup-battery/m-d-y-H.M.S/samsung_battery.ko
To restore it, simply copy samsung-battery.ko in /system/lib/modules/ overwriting the existing one, set its permission to 644 and then reboot.
There's a backup copy for each flash you made, each copy is in a different subdirectory. The name of the subdirectory is the time and date of the flash.
Or more simply reflash the ROM or restore a CWM backup.
I've tested the changes for some time, but I can't guarantee everything is working correctly. Flash at your own risk.
Source code:
battery-monitor: minimize awake time
battery-monitor: make polling timer deferrable
battery-monitor: don't use boot_complete flag
battery-monitor: add wakelock...
Notes:
A reflash of this zip could be required after flashing custom kernels.
I had to add an additional wakelock (samsung-battery-charge), but it's only used when charging the battery. It behaves as the old samsung-battery wakelock.
I looked around and I can say that Adi_Pat's SIRI kernel is the only incompatible kernel. The driver is inbuilt and my module will be ignored. Flashing this zip won't do anything, you need to rebuild the kernel with the above changes.
loSconosciuto said:
A reflash of this zip could be required after flashing custom kernels.
Click to expand...
Click to collapse
Maybe i should try this but sir what do you mean by this? You mean a custom kernel for CM is required before flashing this? Cant we flash this with the stock lets say CM10 kernel?
marshygeek said:
Maybe i should try this but sir what do you mean by this? You mean a custom kernel for CM is required before flashing this? Cant we flash this with the stock lets say CM10 kernel?
Click to expand...
Click to collapse
What my zip does is to replace a kernel module located in /system.
Custom kernels usually include modules in their flashable zips, so if you first flash my zip and then a custom kernel, my modified samsung-battery.ko will be overwritten.
Custom kernels are not required for this. They could actually be incompatible with this module (to know whether it's working or not, read the OP), but in that case you can restore the original module as written above.
Ohhhh hahaha. I've read again today, i was confused a while ago. LOL. That was a dumb question of mine. Sorry. Ok ill try and feedback after few cycles.
---------- Post added at 09:22 PM ---------- Previous post was at 09:11 PM ----------
loSconosciuto, can you check what ive noticed before. I was on Alpha 3 and im using BetterBatteryStats. I just tried freezing the Calendar sync and Contacts sync. I dont know if its just my mind saying or it was really a lucky try and i got INSTANT noticeable battery performance for the whole cycle.
Flashed! So far so good....
Sent from my Samsung Galaxy SL on CyanogenMod 9 !
Flashing it now. Will report back with impressions in the morning. Will check night time battery drop. CM10A4, crackersizer! kernel.(1200-300, Smartassv2,NOOP)
EDIT: First impressions, night time battery drop was 30 % as compared to usual 50-60 % in my case. Also due to some network issues the testing was halted. Will report back when i get a couple of battery cycles done with this tweak.
EDIT: Testing halted as installed the SIRI kernel of adi!!!
Did anyone try this with Siri Kernel v2?
Does it work correctly?
Thanks!
BachuArg said:
Did anyone try this with Siri Kernel v2?
Does it work correctly?
Thanks!
Click to expand...
Click to collapse
Mate, the OP said it doesn't work on Siri Kernel. I doesn't know about Siri Kernel v.2 but I think it's not a bright idea.
Sent from Galaxy SL Powered by JellyBam
BachuArg said:
Did anyone try this with Siri Kernel v2?
Does it work correctly?
Thanks!
Click to expand...
Click to collapse
adi pas insert the module to siri kernel v2
loSconosciuto said:
I did some changes to decrease samsung-battery wakelock total time doing some optimizations, getting good results.
Ideally, the changes I made would save some battery, but I didn't properly verify this.
What I'm sure about is that samsung-battery wakelock total time is now very low, which means less time spent awake when the screen is off.
BetterBatteryStats screenshot after 3 and a half hours of use: 2 seconds of total time for samsung-battery. Not bad considering that the fixed duration of a single wakelock request was 3 seconds.
The driver had never been directly built into the kernel (EDIT: Adi_Pat did it in his kernel, read the notes below), we had always used a module, so you don't need to change kernel or ROM in order to use this, it shouldn't matter which ROM you are on as long as it's a CyanogenMod (9+) based ROM. You just need to flash the zip attached, which will replace the module in /system.
Flashing this on stock ROMs won't do anything.
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
A backup is automatically created after the flash, you can find it in:
Code:
/sdcard/backup-battery/m-d-y-H.M.S/samsung_battery.ko
To restore it, simply copy samsung-battery.ko in /system/lib/modules/ overwriting the existing one, set its permission to 644 and then reboot.
There's a backup copy for each flash you made, each copy is in a different subdirectory. The name of the subdirectory is the time and date of the flash.
Or more simply reflash the ROM or restore a CWM backup.
I've tested the changes for some time, but I can't guarantee everything is working correctly. Flash at your own risk.
Source code:
battery-monitor: minimize awake time
battery-monitor: make polling timer deferrable
battery-monitor: don't use boot_complete flag
battery-monitor: add wakelock...
Notes:
A reflash of this zip could be required after flashing custom kernels.
I had to add an additional wakelock (samsung-battery-charge), but it's only used when charging the battery. It behaves as the old samsung-battery wakelock.
I looked around and I can say that Adi_Pat's SIRI kernel is the only incompatible kernel. The driver is inbuilt and my module will be ignored. Flashing this zip won't do anything, you need to rebuild the kernel with the above changes.
Click to expand...
Click to collapse
I have one question. What is normal discharging time of battery,moderate use,stand by n normal use what so ever .As i saw in my case it wont lost more than 4 hour of continues use of net both wen i was on stock rom and after custom rom.
Sent from my GT-i9003 using xda premium
loSconosciuto said:
I did some changes to decrease samsung-battery wakelock total time doing some optimizations, getting good results.
Ideally, the changes I made would save some battery, but I didn't properly verify this.
What I'm sure about is that samsung-battery wakelock total time is now very low, which means less time spent awake when the screen is off.
BetterBatteryStats screenshot after 3 and a half hours of use: 2 seconds of total time for samsung-battery. Not bad considering that the fixed duration of a single wakelock request was 3 seconds.
...
Click to expand...
Click to collapse
Question: Are you referring to this line if you talk about the standard wakelock length of 3 seconds? Because I would think that this actually means that the wakelock length is 3*HZ with HZ=1/128 s (see config entry), resulting in 0.0234375 s. This, in turn, gives roughly 2.8125 s of battery monitor wakelock every hour if the system wakes up every 30 s. Am I wrong?
Anyway, your patch is very cool and should result in improved standby times
XDA_Bam said:
Question: Are you referring to this line if you talk about the standard wakelock length of 3 seconds?
Click to expand...
Click to collapse
Yes.
XDA_Bam said:
Because I would think that this actually means that the wakelock length is 3*HZ with HZ=1/128 s (see config entry), resulting in 0.0234375 s. This, in turn, gives roughly 2.8125 s of battery monitor wakelock every hour if the system wakes up every 30 s. Am I wrong?
Anyway, your patch is very cool and should result in improved standby times
Click to expand...
Click to collapse
That's what I thought too, but then, I can't remember why, I opened wakelock.c to verify this.
This is what conveinced me that the they are 3 seconds. See how timeout is converted when it's printed.
With timeout=3*HZ, the result of that operation should be 3.000.
Because I'm lazy, instead of reading the rest of the code I looked for commented piece of code on the internet and found few examples that confirmed my hypothesis. Here two examples I've just found: 1, 2.
I've also tried something. I plugged in the phone, waited for "samsung-battery-charge", unplugged it and got this in /proc/wakelocks
Code:
name [COLOR="Blue"][B]count[/B][/COLOR] expire_count wake_count active_since [B][COLOR="Red"]total_time[/COLOR][/B] sleep_time max_time last_change
"samsung-battery-charge" [COLOR="Blue"][B]1[/B][/COLOR] 1 0 0 [B][COLOR="Red"]2988677920[/COLOR][/B] 825195313 2988677920 957372533720
I assume those are nanoseconds: 2988677920 ns = 2.989 s.
I'm still not sure of this, because it doesn't make so much sense to me, I mean, what's the purpose of this?
By the way the battery is checked more often than I thought, sometimes I have even less than a second of interval between two checks. Not a big deal with this patch .
You can easly see how often the battery is checked with:
Code:
dmesg | grep "monitor BATT"
loSconosciuto said:
Yes.
That's what I thought too, but then, I can't remember why, I opened wakelock.c to verify this.
This is what conveinced me that the they are 3 seconds. See how timeout is converted when it's printed.
With timeout=3*HZ, the result of that operation should be 3.000.
Because I'm lazy, instead of reading the rest of the code I looked for commented piece of code on the internet and found few examples that confirmed my hypothesis. Here two examples I've just found: 1, 2.
I've also tried something. I plugged in the phone, waited for "samsung-battery-charge", unplugged it and got this in /proc/wakelocks
Code:
name [COLOR="Blue"][B]count[/B][/COLOR] expire_count wake_count active_since [B][COLOR="Red"]total_time[/COLOR][/B] sleep_time max_time last_change
"samsung-battery-charge" [COLOR="Blue"][B]1[/B][/COLOR] 1 0 0 [B][COLOR="Red"]2988677920[/COLOR][/B] 825195313 2988677920 957372533720
I assume those are nanoseconds: 2988677920 ns = 2.989 s.
I'm still not sure of this, because it doesn't make so much sense to me, I mean, what's the purpose of this?
By the way the battery is checked more often than I thought, sometimes I have even less than a second of interval between two checks. Not a big deal with this patch .
You can easly see how often the battery is checked with:
Code:
dmesg | grep "monitor BATT"
Click to expand...
Click to collapse
Ahhh, I think I got it, thanks! The kernel expects all time values in jiffies. Therefore, X*HZ gives you the value of X seconds converted to jiffies (and HZ actually is 128, not 1/128).
Re: Optimized Samsung battery driver [CM]
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
Excuse me what do u mean by battery percentage here i flashed zip now how will i know it is working? Thanks alot
Sent from my GT-i9003 using xda premium
Re: Optimized Samsung battery driver [CM]
Just set permission
Sent from my GT-I9003 using xda premium
I sadly discovered, not so much time ago, that this module is making "Android System" use more battery than normal. At first I thought it was a roughly made app, but I then found that the problem is this module.
From my kernel logs I can see that sometimes when the device tries to enter into deep sleep right after it woke up, it can't because there's something blocking the process (I don't know what yet) and it has to try again before it succeeds. This is causing increasing the number of alarms (Partial wakelocks in BBS) and the saved time is not as much as I hoped.
I don't think the problem is in this module, because the same thing happens when the module is not loaded. I'd say is something which normally would require a wakelock, but not in our case because of the omnipresent samsung-battery (correct me if I'm wrong). I did some changes here and there, but the resulting driver is not so different from the original one, so, for the moment, if you think your battery is worse than before (the mentioned problem was pretty random on my device) just restore the original module as explained in the first post.
I'll maybe look better into that when I'll have some time and in case I'll discover something, I'll let you know.
latief.makhdoomi said:
If you can't see the battery percentage after you've flashed the zip attached, it simply means that the module is not working as it should and you need to restore the original one.
Excuse me what do u mean by battery percentage here i flashed zip now how will i know it is working? Thanks alot
Click to expand...
Click to collapse
Sorry for the late reply. To check if it's working, just look for samsung-battery-charge inside /proc/wakelocks. If it's there, it's working (plug and unplug your phone if you can't see it immediately).
With "can't see the battery percentage" I meant that you can't see how much battery is left: instead of the usual icon you have the battery icon with an exclamation point in it and you can't see the percentage from the settings.
hi losconoscuit i got a problem,when my phone screen is off or in standby mode am getting IM messages late i mean in watsapp or any IM messages are delivered to me late or at time wen i unlock my screen at least 10 mints late is it related to wake lock or anything else .please help.
Sent from my GT-i9003 using xda premium
latief.makhdoomi said:
hi losconoscuit i got a problem,when my phone screen is off or in standby mode am getting IM messages late i mean in watsapp or any IM messages are delivered to me late or at time wen i unlock my screen at least 10 mints late is it related to wake lock or anything else .please help.
Sent from my GT-i9003 using xda premium
Click to expand...
Click to collapse
Which rom/kernel are you on? Maybe something to do with the new sync bug workaround...
Sent from my Samsung Galaxy SL on CyanogenMod 9 !
Ehndroix ROM with Dhiru's kernel
Sent from my GT-i9003 using xda premium
Problem Reproduction:
1. Boot the device.
2. No problems during normal usage or when charging.
3. Let the device go to sleep for a couple 2-4 hours
SOD:
When pressing the power button after opening the lid the screen turn on but instead is a black screen, device still seems operational, but screen does not come on, only happened two times since flashing and randomly with nothing I can pin-point it to have a theory from some research, but do not know if it is related.
RR:
Device not reboot unless reboot is initiated, TF101 is rebooting randomly during deep sleeps.
Neither RR or Deep Sleeps occur when the tablet is charging or in active use.
Specifics
Tablet: TF101 Tab and Dock, 16 GB WIFI
Recovery: TWRP 2.3.2.3
ROM: EOS 4 Nightlies Build 99
Kernel: KatKernel_96_JB4.2_Lidpatch
Specific Customization Apps:
K.A.T_V1.2.7 - using KAT Audio, KAT Media Service, GPS fix installed, and adblock hosts file in place.
SetCPU - Profile 1 (screen-on priority 50): Overclocked to 1504Mhz with Smartassv2 govenor, min setting 312 MHZ (read some people do this prevent SOD and RR for the min setting)I/0 Scheduler SIO (also read on XDA others have been very stable with this setup). Profile 2 (Battery less than 38%, priority 75): Stock Max to 312 Mhz Min with conservative governor and SIO scheduler.
**Note: All SOD and RR have occured while SetCPU is in profile 1.
Ram Manager Pro: Minfree setting set to More RAM for devices with over 512MB Memory. JV Heap set to 64MB
Lux Dash: Used to fix auto-brightness setting being too low on transformers. Have it set to dynamic update brightness.
Other settings
Disabled Hotword detection for Google Now fix.
Removed test keys from build.prop and renamed SuperSU to SU in system/apps to get around the Root checks of the TimeWarnerCable live streaming app.
Background: My transformer was in on stock ICS OTA update and was so slow it was barely usable and used battery like crazy. I followed all the procedures on XDA (http://forum.xda-developers.com/showthread.php?t=2063406) and http://public.timduru.org/Android/tf101/eos4/ for wiping, i wiped and formated everything (dalvick, cache, system, factory)besides the externalSD card. Flashed the 99 nightly build and was impressed with how smooth everything was, was like a brand new tab. Did some bench marking and saw the good reviews on KAT kernel, so I flashed KAT kernel and installed KAT app and was even more impressed with performance, benchmarks jumped significantly. Tested everything I could think possible and did not see any major bugs so I figured this would be a good settling point. I did not re-install any of my apps from the Titanium or My Backup Pro or system settings, i installed everything from the market and configured systems settings, after I stopped all the update activities that when I noticed the SOD and RR issues (due to android assistant showing startup times when I had not initiated a reboot). Two days or so ago I installed Reboot Logger to keep track of the RRs. I noticed one SOD on the 18th after 2 hours of inactivity and one on the 19th around the same amount of time of inactivity. There was four RRs on the 19th and two on the 20th. Last night I was doing some digging and saw a bunch of feedback for JB on disabling the location services in setting and app settings, so I implemented that last night as well as removed the dock SD card after before leaving the device in a state of inactivity. After those two changes there was only two RR vs the four the prior day (Although if this is a semi-fix it is a pain not being able to use auto-location for apps) and no SODs again YET.
Let me just say that I love the ROM and KAT Kernel and KAT app, I am extremely impressed with all of it with the way to performs and how buttery smooth it is compared to stock. Lots of Kudos to the developers. If possible I would like to leave KAT Kernel in place because of the performance benefits. If I could get eliminate or minimize the SOD and RRs to an extreme minimum this would be a perfect/Rock solid solution. Attached are the Kmsg and logcats before the last RR and a screenshot of the RR from the Reboot Logger (note the RR/soft boots do not have a restart timstamp next to them, the ones that do are initiated reboots. .
Do you think the latest preview (175) or nightly 100 help the SODs or RRs? Also since the previews are compiled in Linaro and this is the native format for the TF101 be slightly more stable (I did a lot of digging on XDA but could not find a lot one way or the other to justify one direction or another), any empirical data from testing? Just curious. Thanks
Turning on Fsync in KatKernel
pursleyt said:
Problem Reproduction:
1. Boot the device.
2. No problems during normal usage or when charging.
3. Let the device go to sleep for a couple 2-4 hours
SOD:
When pressing the power button after opening the lid the screen turn on but instead is a black screen, device still seems operational, but screen does not come on, only happened two times since flashing and randomly with nothing I can pin-point it to have a theory from some research, but do not know if it is related.
RR:
Device not reboot unless reboot is initiated, TF101 is rebooting randomly during deep sleeps.
Neither RR or Deep Sleeps occur when the tablet is charging or in active use.
Specifics
Tablet: TF101 Tab and Dock, 16 GB WIFI
Recovery: TWRP 2.3.2.3
ROM: EOS 4 Nightlies Build 99
Kernel: KatKernel_96_JB4.2_Lidpatch
Specific Customization Apps:
K.A.T_V1.2.7 - using KAT Audio, KAT Media Service, GPS fix installed, and adblock hosts file in place.
SetCPU - Profile 1 (screen-on priority 50): Overclocked to 1504Mhz with Smartassv2 govenor, min setting 312 MHZ (read some people do this prevent SOD and RR for the min setting)I/0 Scheduler SIO (also read on XDA others have been very stable with this setup). Profile 2 (Battery less than 38%, priority 75): Stock Max to 312 Mhz Min with conservative governor and SIO scheduler.
**Note: All SOD and RR have occured while SetCPU is in profile 1.
Ram Manager Pro: Minfree setting set to More RAM for devices with over 512MB Memory. JV Heap set to 64MB
Lux Dash: Used to fix auto-brightness setting being too low on transformers. Have it set to dynamic update brightness.
Other settings
Disabled Hotword detection for Google Now fix.
Removed test keys from build.prop and renamed SuperSU to SU in system/apps to get around the Root checks of the TimeWarnerCable live streaming app.
Background: My transformer was in on stock ICS OTA update and was so slow it was barely usable and used battery like crazy. I followed all the procedures on XDA (http://forum.xda-developers.com/showthread.php?t=2063406) and http://public.timduru.org/Android/tf101/eos4/ for wiping, i wiped and formated everything (dalvick, cache, system, factory)besides the externalSD card. Flashed the 99 nightly build and was impressed with how smooth everything was, was like a brand new tab. Did some bench marking and saw the good reviews on KAT kernel, so I flashed KAT kernel and installed KAT app and was even more impressed with performance, benchmarks jumped significantly. Tested everything I could think possible and did not see any major bugs so I figured this would be a good settling point. I did not re-install any of my apps from the Titanium or My Backup Pro or system settings, i installed everything from the market and configured systems settings, after I stopped all the update activities that when I noticed the SOD and RR issues (due to android assistant showing startup times when I had not initiated a reboot). Two days or so ago I installed Reboot Logger to keep track of the RRs. I noticed one SOD on the 18th after 2 hours of inactivity and one on the 19th around the same amount of time of inactivity. There was four RRs on the 19th and two on the 20th. Last night I was doing some digging and saw a bunch of feedback for JB on disabling the location services in setting and app settings, so I implemented that last night as well as removed the dock SD card after before leaving the device in a state of inactivity. After those two changes there was only two RR vs the four the prior day (Although if this is a semi-fix it is a pain not being able to use auto-location for apps) and no SODs again YET.
Let me just say that I love the ROM and KAT Kernel and KAT app, I am extremely impressed with all of it with the way to performs and how buttery smooth it is compared to stock. Lots of Kudos to the developers. If possible I would like to leave KAT Kernel in place because of the performance benefits. If I could get eliminate or minimize the SOD and RRs to an extreme minimum this would be a perfect/Rock solid solution. Attached are the Kmsg and logcats before the last RR and a screenshot of the RR from the Reboot Logger (note the RR/soft boots do not have a restart timstamp next to them, the ones that do are initiated reboots. .
Do you think the latest preview (175) or nightly 100 help the SODs or RRs? Also since the previews are compiled in Linaro and this is the native format for the TF101 be slightly more stable (I did a lot of digging on XDA but could not find a lot one way or the other to justify one direction or another), any empirical data from testing? Just curious. Thanks
Click to expand...
Click to collapse
Turned on Fsync in KatKernel for additional testing on SODs and RRs.
pursleyt said:
Turned on Fsync in KatKernel for additional testing on SODs and RRs.
Click to expand...
Click to collapse
1 RR while tablet was asleep, plugged in and charged to 100%.
Solved
pursleyt said:
1 RR while tablet was asleep, plugged in and charged to 100%.
Click to expand...
Click to collapse
After Upgrading to preview version 181 and turning Fsync on with K.A.T kernel the TF101 is 100% stable with no RR or SODs after 48 hours.
pursleyt said:
After Upgrading to preview version 181 and turning Fsync on with K.A.T kernel the TF101 is 100% stable with no RR or SODs after 48 hours.
Click to expand...
Click to collapse
1 RR with SD CARD in dock, know problem with EO4/Kat Kernel removed SD card from dock when not in use, stable again.
pursleyt said:
1 RR with SD CARD in dock, know problem with EO4/Kat Kernel removed SD card from dock when not in use, stable again.
Click to expand...
Click to collapse
using preview 181 kk96 dock sd removed getting RR during sleep, I tried with fsync=on, rr's stopped but that prevented tab from entering deep sleep. now trying with microsd removed. still docked
Hi all,
I´m still running my nexus 5 with rooted stock android (6.0.2) and TWRP and Franco Kernel. I see that my phone has almost 600 MB of "swap" ZRAM reserved and every time that SWAP fills up (0 KB free) the phone gets extremely laggy and unresponsive... Reboot fixes it, but it´s annoying. How can I disable ZRAM completely? Is that a kernel feature (so it might return aufter kernel update?) or an OS feature?
EDIT: never mind, solved it myself. Used app "trickster mod" to change the setting and done.
Ever since Android announced trim support this topic seems to be ignored ever since.
It shouldnt have been.
At least on some devices manual fstrim (busybox) of any version dont work, at least not fully properly as it should.
Never did, and i highly doubt it does work with android kernel built in command thats supposed todo that on its own.
That would explain the usual performance gain after formating data poartition at least for a few days.
I testet this over the years on S2, Note3, NExus 5, nexus 9 and a few other phones.
latest tests are note 3 and nexus 9 on lineage 14.1 (droid 7.2) and oreo.
Here is the results
On Android (native app, or shell via busybox):
it says it trims, consecutive trims lead smaller sizes and at some point to "trim not required" - as it should be.
However a fter a few minutes data trims again hundreeds of megs, an hour later gigabytes
- wtf - monitoring the write activity showed nothing at all. also the battery should be drained if it writes 20gigs an hour to the sdcard constantly - something seems off.
This behaviour has been as is ever since. fstrim never seem todo much.
Now we test this under twrp on the shell.
after one trim it was imidiatly to zero (so second trim says not required)
allright fine, this is how its supposed to be...
well .... nope ... after remounting it imiditaly wants to trim 100% of the free space.
ext4 is not supposed to work like this on trim, it should always only allow untrimmed freespace (in contrast to btrfs which always trims all).
Now important to know is that fstrim is no relyable method to find out if trim is working or what your block devices does.
it could be very well trim is working as intended but reports wrongly.
However the behaviour of trimming down to little, then to zero, then growing big and fast seems to indicate otherwise.
it looks more l ike trim job marks as trimmed (while its sheduled todo that really) - and unamrk step by step later
if this is true it also means the discard mount option actually is contraproductive at best.
Resolution:
i found that switching to f2fs solves that issue.
Trims are now realistic (like 300mb after 5 hours) zero for a long time, correct sizes when you delete a bigger file and so on.
also its now incredible fast.
the massive difference on my devices between f2fs and ext4 is another indicator that trim never worked. it seems like on the first day.
f2fs is supposed to be 20% slower on reads yet i have across all devices a massive improvment, no mroe lags or stutter on ceertain operations. specially chromiun based browser became lightning fast, as in only fractions of a second loading time, compared to seconds before (which make sense considering how the cache is working all the littel files take up an insane time if you need to clear those bytes first)
oh and did i mention it works very well with encryption on?
well it does, and thers no real speed difference now beween unecrypted and encrypted.
bottom line, i doubt trim ever worked on ext4 systems, at least not on all of them.
f2fs is teh solution at least for such older devices like mine, together with oreo my old ones are back in business... watining for a samsung note with on screen fingerprint reader and no knox )