Issue report: 100% CPU use, battery drain, and laggy system after a long period of time when overclocked with a large scaling range.
See here: http://code.google.com/p/android/issues/detail?id=9733
If the number of possible speed settings is too high, a ROM which uses the default buffer sizes for processStats.TIME_IN_STATE would overflow after a long period of use, causing the above problem which will only stabilize after reboot (or the file is made unreadable). Users who overclock with a dynamic governor in the range of 245-1536Mhz, for instance, would experience unbelievable device lag and battery drain after a certain amount of time when the logfile overflows (occurs with most sense roms). The patch increases the buffer size and fixes this problem.
Users who don't overclock, or overclock for only a small amount of time, reboot frequently, or otherwise limit the range of speeds to which their device can scale will not experience this issue. After a number of days on 245-1536 interactive, however, most non-CM ROMs using this kernel will experience a crippling scenario in which the size of the speed and time_in_state logfile exceeds the buffer size of the i/o process (on a word fault), causing the system to occupy almost 100% of the CPU in a fruitless read-fail loop and forcing a reboot to restore device functionality.
From the kernel side, a simple fix is to eliminate some (many) of the speed steps. Certainly many settings in the range of 245-998 can be weeded out, as can many of the trivial steps afterward.
Also, what about the new BT stack patches? Have they already been committed? Thanks like always,
I am waiting on a charger for my laptop, moreover i have a college admission exam on June 8 which obviously will be my top most proirity seeing my life depends on the exams. After June 8 i will be back on this project. Just wait for a month, I have some local changes that i cant commit so .37 kernel will take around 15 days to port
|Thread Tools||Search this Thread|