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 ?
Could you also look into black screen issue with JellyX? It will make that kernel perfect(for normal usage).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:
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: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, }, \
The following patch fixes this bug:Code:$ watch -n 1 cat /proc/overclock/info
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: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];
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.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)
---------- 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...
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.Could you also look into black screen issue with JellyX? It will make that kernel perfect(for normal usage).
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 itselfJellyX has a black screen problem? Cool! It's not my hardware failing thenI almost forgot I was on 2012.01.10 + jellyX
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.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!
Installed here. It boots and works fine.
https://github.com/Quarx2k/android/commit/dd8c6c904639972b398835f4d28405e074b87e5bUpdate: Correct me if am wrong, but I don't see anything about reverting back to older kernel on commits summary.
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 nowThe 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
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
Does it mean that the "ringtone" bug is gone with this new Quarx build based on 2.6.32.9 kernel ?https://github.com/Quarx2k/android/commit/dd8c6c904639972b398835f4d28405e074b87e5b
PS: Flashed CM10-20130220-NIGHTLY-mb526.zip, it uses kernel 2.6.32.9 and "feels" good.
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;
}
}
I hope so, current uptime with the latest Quarx ROM here is 4h.Does it mean that the "ringtone" bug is gone with this new Quarx build based on 2.6.32.9 kernel ?
Yes, the current Quarx ROM matches my latest ROM, but based on current git. I see noI mean, is it the same idea as you, sevenrock, to revert back to 2.6.32.9 kernel to avoid this bug ?