[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] CTCaer:
After a busy week with my job here some replies and an update to my work.

Hmm I don't think it's kernel's problem (have in mind I didn't changed anything to power management and suspend/sleep functions).

Mine currently uses 0.2% with gsm and wifi on + a weather widget waking it every hour.

It doesn't have a cap. Just vsync. Also right now the vsync works at 63fps because our screen refresh rate is 63.5Hz

Disabling vsync will disable triple buffering also and introduce unnecessary battery drain. And not only that it will introduce screen tearing,

which is not a pleasant visual.

Some 720p videos use a codec that the vidc driver can't decode them. It's normal and just use mxplayer with HW+ and if that don't work it will default to SW rendering.

Only when you recorded a video with camera and if that is not playing through quickpic or stock album apps it's then a kernel problem.

Also the recorded video must not be corrupted. For example I once removed the phone while it was doing writing from my computer and some videos and photos got corrupted.

And last but not least, for some reason the GB libraries are fully optimized and faster than ics.... Stupid sony with beta ICS

About the IO, some CM kernels do some hacks to confuse benchmarks.

For example if you link /data/data/com.aurorasoftworks.quadrant.ui.standard to a class 10 sdcard you will see an awesome score at quadrant.

There's no way to have so much difference with kernel hacks with our crappy nand. Mine has a low 3.5-4.5mb write and 4.5-6mb read.

And that can't be improved enough with io schedulers and stuff. Only with sd linking.

What I have done to my ray? I linked /data/app and /data/data to ext2 partition of my sd card. Opening and general use of my rom is quite fast because my sd write speed is 12mb/s and read is 24mb/s with 512kb read ahead. And mass storage works because it never unmounts the 2nd partition. So no problems.

Hmm what kind of logcat is that? I need the /proc/last_kmsg file. It's the only one that shows the error when bootloop.

But anyway the problem with you is that your phone can't cope with the UV.

A bootloop because of this show nothing in last_kmsg but then a second file appears:

/proc/last_amsslog

That's what it shows when cpu halt because of UV

ERR crash log report. Version 3.

Error in file cm, line 0
Time of crash (m-d-y h:m:s): 03-10-2013 2:18:38
Uptime (h:m:s): 17:42:26
Build ID: M7630A-ABBQMAZM-2.0.3028DT

REX_TCB ptr: 0x058bda60
tcb.task_name: dog

Coredump ARCH type is: ERR_ARCH_ARM
Register values from coredump:
ARM_SVC_R0 : 0x00000056
ARM_SVC_R1 : 0xb0081a0a
ARM_SVC_R2 : 0x00000000
ARM_SVC_R3 : 0xffff081c
ARM_SVC_R4 : 0x0000000e
ARM_SVC_R5 : 0x064d2690
ARM_SVC_R6 : 0x064d2508
ARM_SVC_R7 : 0x000000ff
ARM_SVC_R8 : 0x00000000
ARM_SVC_R9 : 0x00000000
ARM_SVC_R10 : 0x00000000
ARM_SVC_R11 : 0x00000000
ARM_SVC_R12 : 0xf0074928
ARM_SVC_SP : 0x00000000
ARM_SVC_LR : 0x00000000
ARM_SVC_SPSR : 0x00000000
ARM_SVC_PC : 0x04c07b64
ARM_SYS_SP : 0x058bec70
ARM_SYS_LR : 0x05425db7
ARM_IRQ_SP : 0x00000000
ARM_IRQ_LR : 0x00000000
ARM_IRQ_SPSR : 0x00000000
ARM_ABT_SP : 0x00000000
ARM_ABT_LR : 0x00000000
ARM_ABT_SPSR : 0x00000000
ARM_UDF_SP : 0x00000000
ARM_UDF_LR : 0x00000000
ARM_UDF_SPSR : 0x00000000
ARM_FIQ_R8 : 0x00000000
ARM_FIQ_R9 : 0x00000000
ARM_FIQ_R10 : 0x00000000
ARM_FIQ_R11 : 0x00000000
ARM_FIQ_R12 : 0x00000000
ARM_FIQ_SP : 0x00000000
ARM_FIQ_LR : 0x00000000
ARM_FIQ_SPSR : 0x00000000
ARM_JVA_SP : 0x00000000
ARM_JVA_LR : 0x00000000
ARM_JVA_SPSR : 0x00000000
ARM_CPSR : 0x20000010

Stack Dump (from 0x058bec70):
Addr Data
0x058bec70 0xb0119cc0
0x058bec74 0x05425ced
0x058bec78 0x00000000
0x058bec7c 0x00000000
0x058bec80 0x00000000
0x058bec84 0x0485a441
0x058bec88 0x00000000
0x058bec8c 0x04c07ebc
0x058bec90 0x00000000

Dog Report Information (dog_state_table)
[idx] Task Name Pri Timeout Count Is_Blocked
[ 0] fmrds 0 60 56 0
[ 1] bt_ftm 0 60 56 0
[ 2] time_ipc 0 60 59 0
[ 3] ds_sig 0 60 59 0
[ 4] loc_middlew 0 60 59 0
[ 5] snd 0 4 3 0
[ 6] hs 0 11 10 0
[ 7] diag 0 11 10 0
[ 8] ui 0 41 39 0
[ 9] nv 0 60 59 0
[ 10] ds 0 119 118 0
[ 11] ps 0 119 118 0
[ 12] sleep 0 237 237 0
[ 13] fs 0 60 59 0
[ 14] cm 0 21 0 0
[ 15] voc 0 11 11 0
[ 16] qdsp 0 11 11 0
[ 17] sec 0 119 95 1
[ 18] uim 0 60 60 0
[ 19] wms 0 21 21 0
[ 20] gsdi 0 60 59 0
[ 21] mdsp 0 60 60 0
[ 22] Gcsd 0 11 11 0
[ 23] gsm_l1 0 11 11 0
[ 24] gsm_l2 0 11 11 0
[ 25] gprs_llc 0 11 11 0
[ 26] gprs_rlc_ul 0 11 11 0
[ 27] gprs_rlc_dl 0 11 10 0
[ 28] gprs_mac 0 11 11 0
[ 29] wcdma_l1 0 11 11 0
[ 30] wcdma_l2_dl 0 11 10 0
[ 31] wcdma_l2_ul 0 11 11 0
[ 32] mn_cnm 0 11 11 0
[ 33] mm 0 11 11 0
[ 34] reg 0 11 11 0
[ 35] rr 0 11 11 0
[ 36] rrc 0 11 11 0
[ 37] sm 0 11 10 0
[ 38] tc 0 61 61 0
[ 39] ftm 0 91 91 0
[ 40] gstk 0 61 60 0
[ 41] secssl 0 119 117 0
[ 42] seccryptarm 0 119 117 0
[ 43] cb 0 91 91 0
[ 44] wcdma_mac_h 0 11 10 0
[ 45] pbm 0 91 88 0
[ 46] cnv 0 60 60 0
[ 47] adsp_rtos 0 11 11 0
[ 48] comp

Anyway look below to dev update for what options are for you.

I tested it all week. Indeed many elements that use /dev/random and urandom to take data speed up by a big margin.

Overall the lowest speed up that I saw was 5x and the biggest was 68x and was seen in a zip app when I used encrypted zip file.

You can't imagine how many portions of our android system uses random for encryption. Even native ics app2sd uses random for the encrypted asec files.

Not yet..

Kernel dev update:

As I didn't had a lot of time next update's biggest upgrade will be random/urandom replaced by frandom.

It will also bring less battery drain as I optimised the lower frequencies and also a little stability to the higher ones.

Some bugfixes too.

I tested other things too but either didn't have an effect or they broke stock libraries.

I will still try and test things that will speed up our SoC's VPE that is responsible for video stabilizer.

At next version, people that bootloop after boot try first the 1.4Ghz+UV version because it will bring some stability.

If that don't work you have to try the 1.6GHz+VDD control version and add your own UV.

Update ETA: Some hours to 1 day

EDIT1------

I forgot to tell that next update will bring a bugfix to bfq io/scheduler which enables cgroup.

Results in many forums/blogs showed that it behaves better than noop/deadline with ssd and hdd, as it is lighter than deadline on cpu usage and faster than noop at thoughtput and also priotises IO with every proccess. It's also optimised for android. Still don't know BFQ vs SIO

I'm testing it the last 2 days to both nand and sd card.