kovaxo

Member
Jul 2, 2009
37
6
0
i were on 12/23 build with jelly+ kernel , now wiped cach then updated 17/2 the phone it self rebooted while installing and hanged at motorola logo any idea ?
 

lief.erl

Senior Member
Mar 29, 2012
67
4
0
For those of you who absolutely need to see how much time their processor has spent on which clock speed I have some good news. These statistics have been missing since the move to 2nd-boot but it is really easy to get them back - just load the cpufreq_stats.ko module. This is best done in /system/bootmenu/scripts/overclock.sh, in the [FONT="Monospace, Courier New"]get_address() [/FONT]function. This makes sure the module gets loaded before overclock.ko which depends on some symbols exported by this module for exporting statistics. I'll add some more details on this later/earlier, suffice to say it works and it gets rid of some log spam from overclock.ko ([FONT="Monospace, Courier New"]overclock: cpufreq_stats_table address not configured, aborting action[/FONT]). You'll need the following patches to get this to work as intended:

Code:
diff --git a/bootmenu/script/overclock.sh b/bootmenu/script/overclock.sh
index b98975e..6cd5f79 100755
--- a/bootmenu/script/overclock.sh
+++ b/bootmenu/script/overclock.sh
@@ -85,8 +85,9 @@ param_safe()
 
 get_address()
 {
+  insmod $MODULE_DIR/cpufreq_stats.ko
   cpufreq_table=`grep -e omap2_clk_init_cpufreq_table /proc/kallsyms | sed -e "s/\([0-9A-Fa-f]\{8\}\).*/\1/"`
-  stats_update=`grep -e cpufreq_stats_update$ /proc/kallsyms | sed -e "s/\([0-9A-Fa-f]\{8\}\).*/\1/"`
+  stats_update=`grep -e cpufreq_stats_freq_update /proc/kallsyms | sed -e "s/\([0-9A-Fa-f]\{8\}\).*/\1/"`
 }
 
 #############################################################
diff --git a/modules/sources/overclock/Makefile b/modules/sources/overclock/Makefile
index da91e9b..200ed69 100644
--- a/modules/sources/overclock/Makefile
+++ b/modules/sources/overclock/Makefile
@@ -1,7 +1,7 @@
 # Modules
 
 #obj-m += cpufreq_conservative.o cpufreq_interactive.o cpufreq_powersave.o
-#obj-m += cpufreq_stats.o
+obj-m += cpufreq_stats.o
 #obj-m += cpufreq_smartass.o cpufreq_boosted.o
 
 #sio_iosched-objs = sio-iosched.o
diff --git a/modules/sources/overclock/cpufreq_stats.c b/modules/sources/overclock/cpufreq_stats.c
index 4047872..1464a99 100644
--- a/modules/sources/overclock/cpufreq_stats.c
+++ b/modules/sources/overclock/cpufreq_stats.c
@@ -23,6 +23,8 @@
 
 static spinlock_t cpufreq_stats_lock;
 
+static int cpufreq_stats_freq_update(unsigned int cpu, int index, unsigned int freq);
+
 #define CPUFREQ_STATDEVICE_ATTR(_name, _mode, _show) \
 static struct freq_attr _attr_##_name = {\
        .attr = {.name = __stringify(_name), .mode = _mode, }, \
There is a bug in commit 76189f17f91f4f2c1dc7e09c44bd251287680c6c (power hal: fix "atoi", fix freq list") which makes the phone go to the lowest available frequency (instead of allowing it to reach the highest available when needed) whenever the screen is on. This makes the current build lag like never before. To observe the effect of this bug, just open a shell through adb and watch /proc/overclock/info. Switch the screen on and off, and you'll see the usermax and max go from 300000 (screen on) to whatever you have set as the second-to-highest clock frequency (screen off).
Code:
 $ watch -n 1 cat /proc/overclock/info
The following patch fixes this bug:
Code:
diff --git a/power/power_omap3.c b/power/power_omap3.c
index 95a119e..1fa3cb7 100644
--- a/power/power_omap3.c
+++ b/power/power_omap3.c
@@ -130,7 +130,7 @@ static void omap3_power_init(struct power_module *module)
         return;
     }
 
-    max_freq = freq_list[freq_num - 1];
+    max_freq = freq_list[0];
     tmp = (NOM_FREQ_INDEX > freq_num) ? freq_num : NOM_FREQ_INDEX;
     nom_freq = freq_list[tmp - 1];
The fmradio stuff crashes the system server when the device is switched into airplane mode, complaining about a missing FM transmitter reset method. This is of course both correct - it does not contain an FM transmitter - as well as silly - it does not need to contain an FM transmitter. Even though the fmradio stuff compiles after applying the patch I posted earlier it is probably best to revert it for the time being. The proof is in the pudding:

Code:
D/FmTransmitterService( 1592): onReceive:ACTION_AIRPLANE_MODE_CHANGED
W/dalvikvm( 1592): No implementation found for native Lcom/stericsson/hardware/fm/FmTransmitterService;._fm_transmitter_reset:()I
W/dalvikvm( 1592): threadid=11: thread exiting with uncaught exception (group=0x40a9f300)
I/Process ( 1592): Sending signal. PID: 1592 SIG: 9
E/AndroidRuntime( 1592): *** FATAL EXCEPTION IN SYSTEM PROCESS: android.server.ServerThread
E/AndroidRuntime( 1592): java.lang.UnsatisfiedLinkError: Native method not found: com.stericsson.hardware.fm.FmTransmitterService._fm_transmitter_reset:()I
E/AndroidRuntime( 1592): 	at com.stericsson.hardware.fm.FmTransmitterService._fm_transmitter_reset(Native Method)
E/AndroidRuntime( 1592): 	at com.stericsson.hardware.fm.FmTransmitterService.access(FmTransmitterService.java:45)
E/AndroidRuntime( 1592): 	at com.stericsson.hardware.fm.FmTransmitterServiceonReceive(FmTransmitterService.java:351)
E/AndroidRuntime( 1592): 	at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:755)
E/AndroidRuntime( 1592): 	at android.os.Handler.handleCallback(Handler.java:615)
E/AndroidRuntime( 1592): 	at android.os.Handler.dispatchMessage(Handler.java:92)
E/AndroidRuntime( 1592): 	at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 1592): 	at com.android.server.ServerThread.run(SystemServer.java:1020)
I have made a new build containing the JellyX kernel. I'll test it for a bit, if it performs OK I'll post it here.

---------- Post added at 02:23 AM ---------- Previous post was at 02:20 AM ----------



The lag in your build will be caused by the bug in power_omap3.c I described in my previous post. Apply the relevant patch (included in that post) and build again...
Could you also look into black screen issue with JellyX? It will make that kernel perfect(for normal usage).
 

d3xt3r

Senior Member
Dec 22, 2012
315
98
58
Jamshedpur
The thing I'd I'm not facing any data drops or WiFi drops or any kind of drops nor the ringtone bug.. Maybe m lucky enough.. always flashed the rom from stock ie rsdlite then root then set up from scratch.. N my custom ringtone are copied to root/media/audio/ringtone... N the 17th Feb build USD the smoothest n most stable build for me.. Thank you quarx fot your great work... You kept our defy defying Motorola:thumbup::p

Sent from my MB526 using xda app-developers app
 
  • Like
Reactions: frozenwaverider

YetAnotherForumUser

Senior Member
Oct 31, 2008
470
1,665
0
Could you also look into black screen issue with JellyX? It will make that kernel perfect(for normal usage).
As I have never experienced this black screen issue on my phone it will be hard to track it down without more information. Have a look and/or post to the JellyX thread, maybe someone over there has more to contribute... make sure to read the first sentence of that thread: If you want to report something head over here and make a "new Issue". You'll find that it has already been reported.
 

niksy+

Senior Member
Jan 16, 2012
1,357
1,082
0
Last edited:

niksy+

Senior Member
Jan 16, 2012
1,357
1,082
0
JellyX has a black screen problem? Cool! It's not my hardware failing then :) I almost forgot I was on 2012.01.10 + jellyX
The kernel black screen issue only happens at boot... The screen remains black after boot logo, nothing else happens. For some wiping data fixes the problem. So, if your screen is going off at any other time... Hope it fixes itself :D

New nightly up'ed by Quarx!

http://quarx2k.ru/cm10-2ndboot-nightly-defy(+)/

Changelog, afaik - fixed cpu frequencies info, kernel reverted back to -9, call recording improvements
 
Last edited:

sbE

Senior Member
Jun 28, 2007
278
48
0
Edit: BTW will this be safe 28.11(clean install yesterday)->20.02.13? Just don't wanna re-configure everything again in just one day!
no problem, you can simply update your installation with this new build. in recovery: wipe cache, wipe dalvik, flash zip from sdcard, wipe cache, wipe dalvik, reboot.
 

YetAnotherForumUser

Senior Member
Oct 31, 2008
470
1,665
0
Some calculations around the observed cpu, wakelock and battery stats with JellyX

I'm currently running a build based around Quarx' git (synced 20130216) with some added patches (see earlier posts) and the JellyX kernel (synced 20130216). This build has now been running for about half a day. As before, Android System is on top in the battery stats and some services hog wakelocks (AlarmManager is the biggest sinner with 11%, 1h 31m). As before, Android OS does not show up in the battery statistics while it does in 2.6.32.9.

CPU stats show the following since boot (rounded to minutes, mostly):

  • 14 h since boot
  • 1 GHz 11 m
  • 800 MHz 22s
  • 600 MHz 7m
  • 300 MHz 1h 34m
  • Deep Sleep 12h 30m

Oddly enough, BBS shows two rows marked with Deep Sleep. The first row has 0s of use, otherwise they are identical.

Battery stats show a Screen on time of 1 h 7m. Wifi has been running for 3 h 13 m. The phone is set to turn off Wifi when the screen is off, idle time is 15 minutes. It also tells me Android System kept the phone awake for 1h 47m.

From these numbers it shows that the phone has NOT been in deep sleep for 1 h 30m. Of those 1 h 30 m the screen has been on for 1 h 7 m, leaving 27 m of screen-off wake time. Now that power hal is enabled again the phone reduces the maximum available clock rate with screen off to the second available clock rate (and not the second highest as I stated in an earlier post). This probably accounts for the 7m of activity in the 600MHz frequency. Those 11m at 1GHz are mostly from my experimenting with the thing to see what I can break (not much yet, by the way).

The outcome of these calculations leaves me wondering where the missing 1h 20m of wake time went which Android System is responsible for according to the battery statistics...

Battery consumption is comparable to earlier kernels, including 2.6.32.9. Overnight it lost 0.3% per hour (in airplane mode), during the day this rises to about 0.7% per hour.

I suspect that the battery and wakelock statistics show erroneous data in 2.6.32.60. The discrepancies between the observed battery consumption, the reported 'battery hogs' and the wakelocks in BBS just does not seem to add up. As shown by these calculations it literally does not add up. I'll keep on running this build for a bit more to see whether problems crop up, if they don't I'll post it here for others to test. If anyone has any suggestions as to what change in 2.6.32.60 can be the culprit for the observed battery/wakelock anomalities please speak up. If anyone has any deeper knowledge about what goes in to creating these statistics, let us hear. I could delve into the source to find out but I have to much to do as it is.
 

Persechini

Senior Member
Mar 12, 2012
439
151
0
Rio de Janeiro
The kernel black screen issue only happens at boot... The screen remains black after boot logo, nothing else happens. For some wiping data fixes the problem. So, if your screen is going off at any other time... Hope it fixes itself :D

New nightly up'ed by Quarx!

http://quarx2k.ru/cm10-2ndboot-nightly-defy(+)/

Changelog, afaik - fixed cpu frequencies info, kernel reverted back to -9, call recording improvements
I first got it a couple of times after the screen went erratic (probably moisture from being in my pocket while biking) and I had to remove the battery to regain control and wipe the screen. After that, since it happened once more without being in my pocket (learned the lesson) I wondered if maybe the water resistance was old and worn off (18 months of use). But I guess I'll try the new Quarx build now
 

woodman

Senior Moderator / RC-RT & Moderator Committees
Staff member
Jul 21, 2012
12,431
22,951
263
40
France
Last edited:

YetAnotherForumUser

Senior Member
Oct 31, 2008
470
1,665
0
Found the cause of excessive wakelocks, Android system battery 'use': reporting error

As I suspected, the excessive wakelocks and high battery 'use' for Android System in the JellyX kernel are due to erroneous reporting. These reporting errors are caused by a faulty patch in the JellyX kernel (and only the JellyX kernel, not in generic 2.6.32.60). The patch to kernel/power/wakelock.c needs to be reverted as it does more than just 'change some compiler warnings' - it causes the wakelock report to show expired locks as if they're still active.

Either reverse the patch or apply the following patch to revert the single change:
Code:
diff --git a/kernel/power/wakelock.c b/kernel/power/wakelock.c
index 0c231b3..4d28d80 100644
--- a/kernel/power/wakelock.c
+++ b/kernel/power/wakelock.c
@@ -222,7 +222,7 @@ static void print_active_locks(int type)
                                pr_info("wake lock %s, expired\n", lock->name);
                } else {
                        pr_info("active wake lock %s\n", lock->name);
-                       if (!debug_mask && DEBUG_EXPIRE)
+                       if (!debug_mask & DEBUG_EXPIRE)
                                print_expired = false;
                }
        }
With this change JellyX shows normal battery and wakelock statistics. Another one bites the dust.
 

ktmbikerman

Senior Member
May 7, 2011
1,990
656
0
51
Cape Town
I have a problem with the default browser... whenever I download an update from Quarx's website, the download crashes as it finishes, every time. Seems to be an issue with the writing of the download to the sd card, particularly large downloads. Smaller downloads are fine.

Any ideas?

Tonight's build is running great, by the way. Thanks Quarx, YAFU and sevenrock for all your efforts.

Sent from my MB526 using xda premium
 

sevenrock

Senior Member
Nov 27, 2012
659
1,095
123
Does it mean that the "ringtone" bug is gone with this new Quarx build based on 2.6.32.9 kernel ?
I hope so, current uptime with the latest Quarx ROM here is 4h.
I mean, is it the same idea as you, sevenrock, to revert back to 2.6.32.9 kernel to avoid this bug ?
Yes, the current Quarx ROM matches my latest ROM, but based on current git. I see no
reason why the ringtone bug should still be present in CM10-20130220-NIGHTLY-mb526.zip.

I am glad to see this development because I am overall short of time and had to divert more
attention to Android, because of the ringtone bug, than I wanted to at the time I bought my
phones in Nov 2012. My first flashed ROM was 17.11, the first ROM ever containing kernel
2.6.32.60, so I was affected with the ringtone bug from the beginning on until Jan 10th,
when I first compiled kernel 2.6.32.9. I am really enjoying my Defy+ phones, real good value
for the money and I will follow the developments here closely, but do not expect more ROMs
from me when the Quarx ROM solves its purpose :)
 

lief.erl

Senior Member
Mar 29, 2012
67
4
0
20.2 is great indeed - no more ringtone bug(hopefully), fast and responsive and cpu states now working(partially)

I have noticed following hiccups in this build:-
1. I have overclocked my phone with following setup - 300|600|900|1100 and I have noticed in system tuner times' tab(also CPU spy) that only 300, 600 graph/values are shown. Whereas, 800 and 1000 bar remain at 0. Shouldn't these apps must show current frequencies?
2. In battery option of settings, there is a blank process! I mean no name is shown for it. Any suggestion about this?
Update: After a reboot it disappeared.

BTW, is there ever going to be rtsp support in cm10?

Note: I did a clean install -> wipe data,cache and dalvik
 
Last edited:
  • Like
Reactions: frozenwaverider