yashsingh1/xdaforums huggingface dataset:
[Defy Android Development] slimshady76:
Please install either BetterBatteryStats (look for it here in XDA) or Wakelock Detector from Play Store, charge your phone and leave it running for a while. Then, take a look at the kernel wakelocks and partial wakelocks. Note the ones with bigger number of entries. Also, enter a terminal, and run the following two commands:

$ su
# dmesg > /mnt/sdcard/dmesg.txt

Upload the file dmesg.txt (attach it to your post, or somewhere else) and then the community might be able to help you pinpoint the culprit of your high battery drain.
[Defy Android Development] tombert.at:
Bluetooth Bug

I can confirm some Bluetooth bugs:

When paired and enabled with a free-speaker the voice comes totally distorted. Then when switching to headset or speaker there is no voice at all.

thx
[Defy Android Development] Benoe:
What experience do you have with this patch? The same?

I'm not sure that it is related any way, tough.
[Defy Android Development] bonedriven:
No I didn't apply other patches.
[Defy Android Development] Quiksilver20:
Does the ogt cable work in the latest build? i bought one, but i'm not able to make it work....
[Defy Android Development] atulclassic:
it doesn't works with Quarx/Blechd0se kernel as of now..there is a separate kernel but in a early stage and limitations are yet to be discovered
[Defy Android Development] MarcinRN:
once again I compiled a build from Quarx's repo and if you want to try it, here it is :

cm-10.2-20131019-UNOFFICIAL-mb526.zip md5sum: 06e3b51b972140f95a49209462147a63

for changelog as usually visit Quarx's github. of the most interesting changes:

- this commit

- android 4.3.1

- fixed data transfer arrows

as for the hwa commit the interface really seems more snappier for me :D

all the thanks should go to Quarx, Blechd0se, SlugZero, Epsylon3 and all the other contributors! :good:
[Defy Android Development] justjr:
Holy Marcin thank you. Will test it now.
[Defy Android Development] TJKV:
I think that commit just enables the "Enable high end GFX" options (eg as in the commit message, and one more: as you pull down the notification drawer, the foreground app gradually darkens). I don't think the commit makes any performance or memory usage improvements.
[Defy Android Development] Fight4Music:
The Defy parts are back :D

Gesendet von meinem Nexus 4 mit Tapatalk 2
[Defy Android Development] runeupo:
any improvement for blue tooth headset in MarcinRN's latest?

[mb525red taki_jeden 09052013 [SlimBased]]
[Defy Android Development] Blechd0se:
Hello guys,

its been a while since my last update. Finally i found some time to work again on the kernel :)

This release covers all contributions so far and furthermore some more changes. Bug #18 should be fixed in this release for sure.

Moreover i reworked my suspend/resume logic i introduced earlier this year. I am just referring to my github message, because

its a pretty big change. Oh and yes, you can tweak this new parameter with the aero control app right out of the box :)

I also tried to adress issue #13, i haven't pushed my changes for this to github yet. I hope that deep sleep is know fixed

and those stupid wakelocks won't occur [MENTION=4916555]okij[/MENTION] waiting for your feedback :)

Changelog;

* reworked suspend/resume logic in interactive

* updated ondemand (fixed a bug and introduced sampling_down_rate parameter)

* hopefully ehci_pm fix

* some smaller fixes

As always i am happy to read some feedback :)
[Defy Android Development] SlugZero:
I stumbled upon some log messages that stated that the /data and /cache partitions (which are ext4) are mounted without journal while the /system partition (which is ext3) is mounted in ordered data mode, i.e. with journal. The journal is crucial to prevent file system corruption on sudden power loss etc.

For the /system partition, tune2fs -l /dev/block/mmcblk1p21 gave me:

Filesystem features: has_journal filetype

while for the /data partition, tune2fs -l /dev/block/mmcblk1p25 showed that the has_journal feature is missing:

Filesystem features: ext_attr resize_inode filetype needs_recovery extent sparse_super large_file uninit_bg

Now here's the fix:

(Warning: Worked fine for me, but could result in data loss anyway)

Boot into recovery, connect via usb and adb, then enter

/system/bin/tune2fs -O has_journal /dev/block/mmcblk1p25

Maybe someone has a solution that works without adb (flashable zip or unmount /data somehow).

Interestingly, the tune2fs version from recovery did not work (only the one in /system/bin), so I believe that the ext4 version in recovery simply does not support this.

I could not force any data corruptions with my device any more. Please test and confirm if this works.

There is probably another issue that prevents syncing all data on the partition when shutting down due to low battery, but having a journal in general is a good idea, I think. Personally, I prefer a slight performance decrease over having to go to recovery once a week.

Btw, in my experiments I was also quite successful in corrupting my data partition using "adb reboot" or "reboot now" command or by simply pulling out the battery.

I agree, but I have some other ideas I'd like to try out. Unfortunately (or fortunately for me, because I have no data drops), I can't test it myself, so I will post something soon.

It probably has to be compiled specifically for CM10, but I do not see any reason why it should not work. Unfortunately, I do not have a build environment for CM10, so maybe ask your favorite CM10 ROM builder to integrate the fixed repository:)

wfm, I have ~200MB free most of the time. Do you have any apps installed that might behave differently with working data counters? The patch itself should not have caused this.

I'm still working on this, but it is not working properly yet. Seems that the USB power management does not play well with OTG.
[Defy Android Development] Blechd0se:
Thats funny, because has_journal is enabled for me when i run this command;

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file

Also i do plenty of adb reboot when i test kernels (like ~20 a day). Looks like there is something missing, if this isn't enabled

by default for all. Maybe something here is missing. I should investigate this, thanks for the hint!
[Defy Android Development] Hasuris:
No. I am now on a newer version of Slimbean and it works like a charm (data arrows are there and connection seems stable). I guess your patch is integrated too, so no idea why it didn't work before. Keep up the good work :)
[Defy Android Development] SlugZero:
Interesting, there are even more differences in file system features. Wonder how many other configurations exist and what issues these might cause...

From my limited knowledge, the file system features usually are set when the drive is being formatted. So probably you were using a different version of recovery than I did for formatting the /data partition. The mount options also were my first guess and are definitely worth to be looked at, but the file system feature is a necessary precondition. The command I posted adds an inode for the journal to the file system (so you only have to do this once, ever), afterwards it is mounted correctly.

Let's see what features other users have, especially those with data corruption issues:)
[Defy Android Development] TJKV:
[MENTION=4855459]Blechd0se[/MENTION] [MENTION=4841764]SlugZero[/MENTION]

Here is my data partition on my Slimbean 4.3:

has_journal resize_inode filetype needs_recovery extent sparse_super large_file

Just ext_attr and dir_index missing compared to Blechd0se's

I always use TWRP to wipe/install/backup&restore, never had data corruption on 4.2 and 4.3 based ROMs.
[Defy Android Development] MarcinRN:
mine's just the same as Blechd0se's & TJKV's. i've never experienced data corruption though.
[Defy Android Development] hotdog125:
I just installed TJKV's slimbean 4.3 build 1.8 and ran the command and got this-

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file

I had a data corruption on Slim 4.3 build 1 just an hour back, but unfortunately I didn't read the newer posts regarding this bug.
[Defy Android Development] playitlouder:
Correcting this could be quite simple.

I'm no dev, but this is how I would do it...

Check the FileSystem flags, if the flags are not correctly set ask the user if it has a backup of /data (system is quite inrelevant in my opinion, cause you can reformat /system and flash again without loosing anything). If the user doesn't have a backup cancel the install. If the user has a backup set the flags and tell him if the system doesn't boot he has to restore a data backup. Maybe check again after install to be shure everything succeded.

Put that check in the flashable rom .zip and it should iron out the diffrences in the file systems...
[Defy Android Development] SlugZero:
Here is the modified version of libril that might help to fix the data connectivity issues.

I modified it to only forward requests to the Moto RIL that the Moto RIL actually understands and fixed some of the formats to match the Gingerbread version.

Please test and report any data dropouts.
[Defy Android Development] TJKV:
I still have data drops using this libril. I isolated the section of the logcat where it happens. I don't know if it contains any useful log messages but I have attached it here anyway.

The first line shows mobile data is working, since the weather refreshed. I am pretty sure the data connection dropped at the time of the first "opprofdaemon" messages. Then I turned on the screen, disabled the data toggle in the notification drawer. Lost mobile connectivity here, it reconnected in a few seconds and in a few minutes regained a data connection too.
[Defy Android Development] TJKV:
720p rec enabled in today's Quarx build again. Someone tested yet?

EDIT: Still being uploaded, so I am guessing not :P
[Defy Android Development] MarcinRN:
if you flashed the build i posted yesterday you can enable it by going to system/etc/media_profiles.xml and edit it just as in this commit & reboot.

works great, 25fps with 6.5Mb/s bitrate, preview while recording feels a bit "heavy" though.
[Defy Android Development] mohegan:
Is the last build from Quarx (20131020) included the last Blechd0se's kernel and the SlugZero's patch to data drop ?
[Defy Android Development] niksy+:
If the video recording is smooth during playback afterwards, than who cares :) I didn't even know that 720p playback works on anything except Gingerbread (and the builds with the v3.0 kernel)! Great :cowboy:

Blechd0se's commits to the kernel go straight to Quarx's repository, so yes. It's been like that for months now :p :victory:

P.S. The upload seems finished, since it's definitely not moving from 160mb anymore. Everybody, get the new CM10.2 nightly! http://quarx2k.ru/cm10.2-nightly-defy+/
[Defy Android Development] atulclassic:
wakelocks in 19.20 build

[MENTION=4855459]Blechd0se[/MENTION] attached herewith the screenshot from wake lock detector..as you see wakelocks for ehci_pm has reduced a great no. of times and battery drain improved a lot..i have lost only 1% in the last 2 hours.

But the system is unable to go into deepsleep on its own after reboot..i have to toggle airplane mode once after reboot to make it enter deepsleep..after theat i haven't faced any issue..UI smooth as butter..thanks for all your great work.
[Defy Android Development] okij:
I'm not sure about this, because Blechd0se wrote yesterday " I also tried to adress issue #13 , i haven't pushed my changes for this to github yet."

[MENTION=4855459]Blechd0se[/MENTION]: Is this commit in Quarx's new nightly? If not - can I use your yesterday's kernel ontop of today's nightly or do I miss some other new commits if I do? I'm eager to test if bug #13 is fixed now! :D

[MENTION=4841764]SlugZero[/MENTION]: Do you know if your libril patch from yesterday made it into Quarx's new nightly or if we must flash it separately? I'm eager to test that too! :D

[MENTION=513620]Quarx[/MENTION] and the other devs: Thanks once more for your great work! I will update the list of known bugs later today. Seems like for the new nightly I can strike out quite some of them. :good::)
[Defy Android Development] Blechd0se:
As i wrote it's not included, because i need confirmation. Sure you can flash it on top :)

About the updated lib; i guess without source its not included.

Thank you, but i guess its to early to say anything. The bug reports stated out that it only will happen after a certain amount

of uptime. Just give me feedback after a few cycles, in the end you tell me if this patch works :)

Yeah i really changed interactive to make the best possible UI experience possible, testing new things is now even simpler because of the app :)

[MENTION=4841764]SlugZero[/MENTION] I have used the most recent recovery (TWRP 2.6) to wipe data. Should i include a check in my app to let the user notify he is missing

this feature?
[Defy Android Development] Proverbs2:
logcat from data partition corruption

As I described here, the latest builds of CM10, CM10.1, and CM10.2 all seem to suffer from a serious bug in which the data partition is sometimes corrupted when the phone shuts down due to low battery. My earlier attempts to obtain logs during a data-corrupting shutdown were unsuccessful, as I explained in my previous post.

Over the last several days, I tried following the suggestions given by [MENTION=4243329]kapil_dheer[/MENTION] in this post. Surprisingly, no data corruption occurred during the first seven trials that I logged.

On the eighth trial, the data corruption bug did occur, and I've attached the log (which I obtained using the terminal emulator method). Note that I was using MarcinRN's build from September 29 with Slugzero's kernel from October 6th. I have not tested the data corruption issue with the new build that [MENTION=4526183]MarcinRN[/MENTION] just released yesterday.

[MENTION=4855459]Blechd0se[/MENTION], please let me know if there is anything else I can do to assist in debugging this issue. Thanks!

Edit: I'll try the fix that [MENTION=4841764]SlugZero[/MENTION] posted here, and report back after a few days.
[Defy Android Development] atulclassic:
thanks..what advise would you give for deepsleep issue.
[Defy Android Development] sevenrock:
The source for the libril patch can be found here: https://github.com/slugzero/android_hardware_ril/commit/f9fbd90c01998ca853f27f9284e63cf10302244e
[Defy Android Development] defim:
To bad, without that i have to stick with cm10. Is it even possible that this could be fixed? Can't the components of the 4.1.2 release been used to make car headset working?
[Defy Android Development] TJKV:
Could someone on CM tell me if the default aosp keyboard in the ROM has working swipe? Has to be tested without installing my minimal CM gapps because my gapps will replace the keyboard in the ROM with the play store version.

If it works then I can remove the CM version of the minimal gapps and have just one for all 4.3 ROMs.
[Defy Android Development] itsnotmeatall:
I can confirm there is no swipe in the default AOSP keyboard in the 20131020 ROM.

Need your minimal gapps soon coz the play store keeps force closing!
[Defy Android Development] TJKV:
Okay, thanks! You can find my minimal gapps thread link in the OP.
[Defy Android Development] GeFeBe:
I flashed the latest Quarx Rom without wiping data and only the Home Button Works. The other buttons I get the vibrating feedback, but they are without function. I this issue resolvable or should I reflash the Rom with wiping Data?
[Defy Android Development] Schattenspieler:
Yes, do a clean install. Had that several times bwfore and its already mentioned in the thread.
[Defy Android Development] okij:
Update to known bugs for the 10-20 nightly of CM10.2 for Defy(+)

I just updated my list of known bugs for the new 10-20 nightly of CM10.2 for Defy(+).

I kept the update in the same place because it has been linked to by Quarx on his opening post, so that everybody can easily find it. :)

As you can see, quite some bugs have been fixed by our devs in the meantime. :victory: Furthermore, there are already fixes for bugs #6, #13 and #19 which can be installed (or manually applied) and tested, and for bug #11 there is a suggestion for a fix which still has to be applied. As always, feedback to our devs is much appreciated! :)

[MENTION=513620]Quarx[/MENTION], [MENTION=4855459]Blechd0se[/MENTION], [MENTION=4841764]SlugZero[/MENTION], [MENTION=1316716]YetAnotherForumUser[/MENTION], [MENTION=4148153]TJKV[/MENTION] and [MENTION=4173406]Kayant[/MENTION] (and to all other devs, in case I missed someone): Thanks again for your great work! :good::victory::highfive:
[Defy Android Development] hotdog125:
I had a data corruption episode again just 5 minutes back, this time with slimbean 4.3.1.

So I ran the commands given by SlugZero, and the output was the same as the output I got when the first time. Journal was enabled already to start with (Did it yesterday).
[Defy Android Development] defim:
Data corruption bug: I think this bug was introduced with ext4. As it was newly added, everyone formated /data new - the wrong way -.-

I was to lazy to backup /data, and keept old format, no advantages - and i have still has_journal enabled for /data.
[Defy Android Development] hrk:
Taken from the official ext4 documentation:

Data Mode
=========
There are 3 different data modes:

* writeback mode
In data=writeback mode, ext4 does not journal data at all. This mode provides
a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
mode - metadata journaling. A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash. This mode will
typically provide the best ext4 performance.

* ordered mode[B][COLOR="Red"] --> this is the default, and what is currently enabled.[/COLOR][/B]
In data=ordered mode, ext4 only officially journals metadata, but it logically
groups metadata information related to data changes with the data blocks into a
single unit called a transaction. When it's time to write the new metadata
out to disk, the associated data blocks are written first. In general,
this mode performs slightly slower than writeback but significantly faster than journal mode.

* journal mode
data=journal mode provides full data and metadata journaling. All new data is
written to the journal first, and then to its final location.
[COLOR="Red"][B]In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state.[/B][/COLOR] This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
outperforms all others modes. Enabling this mode will disable delayed
allocation and O_DIRECT support.

I'd give it a try, just in case. Performance may degrade, but I think it's worth as a test for corruptions.

Note also that...

barrier=<0|1(*)>	This enables/disables the use of write barriers in
barrier(*)	the jbd code. barrier=0 disables, barrier=1 enables.
nobarrier	[COLOR="Red"][B]This also requires an IO stack which can support
barriers, and if jbd gets an error on a barrier
write, it will disable again with a warning.[/B][/COLOR]
Write barriers enforce proper on-disk ordering
of journal commits, making volatile disk write caches
safe to use, at some performance penalty. If
your disks are battery-backed in one way or another,
disabling barriers may safely improve performance.
The mount options "barrier" and "nobarrier" can
also be used to enable or disable barriers, for
consistency with other ext4 mount options.

Just FYOI, all my ext4 partitions have the "has_journal" feature, but all of them were mounted without journal (as reported by dmesg).
[Defy Android Development] SlugZero:
Thank you everyone for the feedback. Seems like neither the data connection nor the data corruption issues are really solved yet :(

It's not included since I did no pull request to Quarx as long as I do not know if it helps. But you can still apply it on top.

However since there is already one report of a data drop with the patch applied, I think there is more work to do. I hope I can provide another modified lib with verbose log output within the week so we can finally spot this bug:)

Good idea, I think it would be really helpful to get a warning if people have non-optimal filesystem settings. Today I reformatted /data from bootmenu (not TWRP) and got the same features I posted earlier (no journal). Seems that TWRP formats differently.

[MENTION=4472055]Proverbs2[/MENTION], since you are among those who suffer most from the /data corruptions, could you post your output of tune2fs?

---------- Post added at 10:20 PM ---------- Previous post was at 10:13 PM ----------

Oops, that's interesting. I got (with dmesg |grep EXT4 )

<6>[ 2.983489] EXT4-fs (mmcblk1p21): mounted filesystem with ordered data mode
<3>[ 2.987518] EXT4-fs (mmcblk1p24): Unrecognized mount option "nomblk_io_submit" or missing value
<6>[ 3.289276] EXT4-fs (mmcblk1p24): mounted filesystem without journal
<3>[ 3.292053] EXT4-fs (mmcblk1p25): Unrecognized mount option "nomblk_io_submit" or missing value
<6>[ 3.453704] EXT4-fs (mmcblk1p25): mounted filesystem with ordered data mode

so I assumed it automatically enables the (default, as you said) ordered mode as soon as the has_journal feature is there. Seems not to be the case for everyone though.
[Defy Android Development] TJKV:
[MENTION=4916555]okij[/MENTION]

You should add the swipe not working on ROM's keyboard to your buglist. The solution in my gapps isn't really ideal, that is switching to play store google keyboard. There are some differences between the play store version and the AOSP one in use by CM. I am pretty sure the fault lies in the libjni_latinime.so in the ROM, just need to find the right one.
[Defy Android Development] hrk:
I get

# dmesg | grep EXT4
<6>[ 2.086212] EXT4-fs (mmcblk1p21): INFO: recovery required on readonly filesystem
<6>[ 2.086242] EXT4-fs (mmcblk1p21): write access will be enabled during recovery
<6>[ 2.100341] EXT4-fs (mmcblk1p21): recovery complete
<6>[ 2.103912] EXT4-fs (mmcblk1p21): mounted filesystem with ordered data mode
<3>[ 2.104766] EXT4-fs (mmcblk1p24): Unrecognized mount option "nomblk_io_submit" or missing value
<6>[ 2.392028] EXT4-fs (mmcblk1p24): mounted filesystem with ordered data mode
<3>[ 2.392700] EXT4-fs (mmcblk1p25): Unrecognized mount option "nomblk_io_submit" or missing value
<6>[ 2.652404] EXT4-fs (mmcblk1p25): mounted filesystem with ordered data mode
<6>[ 2.817474] EXT4-fs (loop7): recovery complete
<6>[ 2.817626] EXT4-fs (loop7): mounted filesystem with ordered data mode
<6>[ 26.452758] EXT4-fs (dm-0): mounted filesystem without journal
<6>[ 26.580963] EXT4-fs (dm-1): mounted filesystem without journal
<6>[ 26.970642] EXT4-fs (dm-2): mounted filesystem without journal
<6>[ 67.717590] EXT4-fs (dm-3): mounted filesystem without journal
<6>[ 68.437408] EXT4-fs (dm-4): mounted filesystem without journal

I must clarify that I'm still running 4.2.2 (and the touchscreen went mad today, so I can't update to the latest 4.3 build...)
[Defy Android Development] Benoe:
I can confirm that BT still doesn't work on CM10.2.

I made however a logcat, where I enabled BT, started a call, switched over the three outputs (Speaker-Earpiece-back to BT), hung up, disabled BT.

It was interesting, that right after I switched from, and right after I switched back to BT I did hear a 1 sec. noise from speaker.

Then I went back to CM10, and made a similar logcat, to compare.

You can find them both here.
[Defy Android Development] btwin:
As reported here on issue #17, I can confirm that the BT bug is still present: enabling BT actually mutes earphone and speaker during calls even with no handset or without any other device connected.
[Defy Android Development] bhupatib:
AOSP keyboard isn't updated so doesn't it makes sense to keep the play store version as default? Or are there some additional features missing in the play store version? Google's strategy to deal with OS fragmentation is by detaching core apps and offering them on play store (unified messaging and launcher are said to come out soon).