yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] rps13:
Also something I've noticed ,maybe only on 32a, but when building any 2.6.35 cm kernel with jesus-phone in the config above 614 or 633 MHZ the freezes while with 2.6.34 it doesn't at even 710 so I think the new branch isn't very optimized for our phones
[G1 Android Development] ezterry:
or that there have been some patches to OC to make it more accurate .. and its more optimized so it spends more time at the top speed and not io bound.
[G1 Android Development] vermaekansh:
hey terry are you making some more kernels...for more efficiency and more stability for your AOSP 2.2 ROM for G1
[G1 Android Development] farmatito:
In this thread: http://xdaforums.com/showpost.php?p=10547680&postcount=347

A new kernel based on pershoot 2.6.35.10

1)with some minor patches,

2)build time configurable overclocking,

3)choice of all forward-ported HTC variants of msm72k_udc.c

4)bfs

compiled with:

BFS

OC

NO_TURBO

MEMORY_COMPACTION

Seems to run fine, no usb battery drain bug so far.

LowmemoryKiller is not called very often, maybe

due to the use of memory compaction.

The kernel is for gingerbread and 32b, cannot say

if it works with other android versions.
[G1 Android Development] hrk:
I can confirm that it runs on CyanogenMod 6.1.0 stable. It booted fine, USB storage is working, radio seems to be working (I tested SMS only). I saw a couple of errors in the log regarding to dalvik-vm not being able to find the cpu subsystem, but... it booted. :)
[G1 Android Development] hrk:
Looks like this is even worse than the previous kernel I was using (pershoot's 21 dec 2010): after 2h 19m 12s from last charge, battery is at 37%.

Android Operating System: 46% [34m 49s]

Cellulare in standby (cope with me): 17% [2h 19m 12s, 7% w/o signal]

Display: 10% [11m 19s]

Android System: 9% [Total CPU 6m 18s, CPU 4s, Sent 262bytes, Received 38.8KB]

Archiviazione calendario: 5% [3m 48s]

And so on w/ the < 5% stuff.

What can I provide you with? Would a logcat be useful?

EDIT: sorry for the immediate editing. I forgot to say that yesterday I had battery at 7% after 17 hours of usage, w/ frequencies set to 524/524 and governor set to "interactive". Today I got this result w/ 614/128 Mhz and same governor.

What puzzles me is that on Jan 1st-2nd I charged my Dream 3 times from the USB port of a DVD Player w/ the same 614/128 settings and I had no quick draining. (The 3 times depend of the fact that the DVD Player wasn't very powerful and I could not leave it connected long).
[G1 Android Development] farmatito:
This would prove what I suspected that it is not TURBO_MODE as ezTerry thinks , but something in OC code that triggers it. I was not able to trigger

the bug with the NO_OC kernel. Will build a new one tonight.
[G1 Android Development] hrk:
1. What is TURBO_MODE?

2. I'm currently charging the battery, then I'll have the phone run at 614/528 (so just overclocking but not "underclocking") and report back.
[G1 Android Development] ezterry:
I'm just not sure what else you are doing.. that default cm rom I have in the gingerbread build has OC disabled unless you use setCPU.. I verified the codes state changes.. Yet still has the drain. Also I've verified the acpu code with overclock from non usb oc draining older kernels with the newest kernels.. they are the same.

Personally I don't see how USB + OC can be related.. and have yet to make a kernel that stopped it from the 2.6.35.* sourcre trees.

Some things to note:

> Newer versions of the USB gadget force max speed of the clock.

> Most new kernels recently have a combo of gingerbread and froyo vold support. 2.6.34.* is missing the gingerbread support.

Regarding OC the real diffrence is tweaking PLL2:

>PLL2 is not reset after we enter an oc state. I'm unsure the impact on CPU speed this has.. because the speed logic is still addind up with some fuzzy math for me.. patching this did nothing for the drain

> we have the PLL2 value precalculated in the table but then recalculate it via division from the speed, this seems like a watre of cpu calculating (arm can't divide) and a memory hit when the calcuated value is likely in a register from a >0 check. This is just efficency questions not the usb bug

That CM6.1 exp build I made last weekend seems to last 9h without sim or wifi after usb unplug.. and a < 30% drain/day if AC adapter unplug.
[G1 Android Development] farmatito:
I do.

Neither I do know, but my results are consistent, as soon as OC

is turned off, battery life is well and entries in battery monitoring app change with standby being the biggest (60%)

If you intend msm72k_udc.c, I've tested them all and it makes no difference.

Eppur si muove! (Galileo Galilei)

With my last build I'm at 8h 22min and 65% battery left on a 2300 mAh battery. Usb bug used to drain the battery in a few hours.
[G1 Android Development] hrk:
Ok, I run the phone at 528/614@interactive (overclock only) and battery usage looked more or less normal (around 10-11 hours before I decided to charge it again).

After charging, I set the speeds to 128/524 ("downclock" only) and here are the results...

7h 56m 56s - 38%

Android Operating System: 26% [25m 54s]

Cellulare in standby: 24% [7h 56m 56s / 2%]

Google Reader (wtf?): 14% [13m 20s / 12 s / 98.63KB / 705.60KB]

Display: 11% [16m 40s]

Inactive phone: 8%

Android System 8%

And so on w/ less than 5% stuff.

Looks like the drain from Android Operating System only occurs when in "downclocking". I am aware that I'm setting the lowest value and it may be unstable, but this seems to prove that somehow -and I really can't understand why- low frequencies and usb-from-computer cause an insane drain.
[G1 Android Development] hrk:
Update: same Android Operating System % crazyness + drain with max=528,min=128,governor=ondemand.

I'm now recharging and I'll try to see the first value for which it starts the crazyness of Android Operating System. Somehow, even though I cannot understand why, USB must have something to do with underclocking. :|

EDIT: I forgot to add that all the tests have been made without reboots between charges.
[G1 Android Development] highlandsun:
Probably a dumb question, but are any of you G1 hackers also working with any HTC WinMo phones? I'm a little surprised to see that the XDAndroid stuff is still using kernels based off 2.6.27 while all of these kernels are 2.6.35. Seems to me that you guys have already solved a lot of the Gingerbread compatibility issues that they're still running into, and it's all msm72k stuff at heart. Shouldn't a lot of the work being done here be relevant to their stuff too? (Asking because I'm looking at giving up on my G1 for a TouchPro2. Higher rez display, more memory, and still a good keyboard...)
[G1 Android Development] pershoot:
ds/nexus - 2.6.35.10 - http://droidbasement.com/db-blog ; RM updated.
[G1 Android Development] pershoot:
ds - 2.6.35.10 - refreshed - http://droidbasement.com/db-blog
[G1 Android Development] sparksco:
Thank you sir, I'm always looking for your updates ;)
[G1 Android Development] farmatito:
On the gingerbread thread more kernel fun
[G1 Android Development] pershoot:
can some people pls report back if any axi reduction errors can be seen in the kernel logs, for your particular device?
[G1 Android Development] farmatito:
unsigned long acpuclk_power_collapse(int from_idle) {
int ret = acpuclk_get_rate();
ret *= 1000;
if (ret > drv_state.power_collapse_khz)
acpuclk_set_rate(drv_state.power_collapse_khz,
(from_idle ? SETRATE_PC_IDLE : SETRATE_PC));
return ret;
}

unsigned long acpuclk_get_wfi_rate(void)
{
return drv_state.wait_for_irq_khz;
}

unsigned long acpuclk_wait_for_irq(void) {
int ret = acpuclk_get_rate();
ret *= 1000;
if (ret > drv_state.wait_for_irq_khz)
acpuclk_set_rate(drv_state.wait_for_irq_khz, SETRATE_SWFI);
return ret;
}

This stuff looks broken to me:

1) the return values are mostly passed to acpuclk_set_rate

which expects hz.

2) acpuclk_get_rate returns khz: the result is multiplied * 1000

to hz and then compared to values in khz.

3) acpu_clk_set_rate expects hz and is fed khz

Maybe I'am overlooking something silly?
[G1 Android Development] pershoot:
yea. i too (in the past) have tried to debunk it, and got sidetracked and didn't complete the trace. removing the * 1000 causes strange errors. im unsure on the current state of things with regards to that.

the only diff here from AOSP .35 -wip, is: from_idle ? SETRATE_PC_IDLE : SETRATE_PC from ,1. i believe this was done with the adition of AXI scaling.

ill look through the timeline and get back to you.
[G1 Android Development] plumppp:
works great! thanks!
[G1 Android Development] sparksco:
github?

Could you please push the new radio/spl kernel to github? I think it would help a lot if we could look at the source code
[G1 Android Development] ezterry:
New radio != new kernel repository just new configuration:

https://github.com/pershoot/kernel-.../configs/pershoot_msm-32b_radio2708_defconfig

EBI0 (32b):

CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1 unset

CONFIG_MSM_AMSS_RADIO2708_MEMMAP unset

EBI1 (32a):

CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1=y

CONFIG_MSM_AMSS_RADIO2708_MEMMAP unset

32B 2708+ Radio:

CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1 unset

CONFIG_MSM_AMSS_RADIO2708_MEMMAP=y
[G1 Android Development] captaincrook:
Will flash latest pershoot to test the USB issue once I get home ... anyone have good results yet?
[G1 Android Development] sparksco:
honestly I haven't gotten around to it yet
[G1 Android Development] goukipoo:
I've got a G1 running

HBOOT: 1.33.0013d

Radio: 2.22.28.25

ROM: CyanogenMOD 6.1 2708port

And I've been running Pershoot's kernel since 12-21. With SetCPU at 122/576. Yesterday I updated to the one from 1-16, and it drained my battery, around 10% an hour. I have everything off (WIFI, GPS, Mobile Data), and since i'm on ATT, 2G only. Android OS was the culprit. Now I'm back on the one from 12-21, and the battery lasts like it should.
[G1 Android Development] roccoadam32:
the phone still does not sleep after using the usb
[G1 Android Development] sparksco:
Turn usb debugging off
[G1 Android Development] roccoadam32:
Usb debugging is off I never have it on my phone don't even sleep after unplugging from a ac outlet I always have to reboot
[G1 Android Development] d12unk13astard:
/Spareparts/End button behavior/Go to sleep that should work :D
[G1 Android Development] roccoadam32:
Nope checked I'm not a noob with android lol
[G1 Android Development] captaincrook:
Yeah still have drain here as well. I recall reading somewhere that someone pin pointed the last build before the USB drain came. Could be wrong but I'll have a stab with searches tomorrow, at least the commits from that nightly can be looked at.
[G1 Android Development] roccoadam32:
2.6.34.5 wouldt be nice to try thay kernel with 2708 port
[G1 Android Development] farmatito:
I'm wondering if this is rather a userspace issue as all efforts of bug tracking

in kernel failed so far. I've made a little experiment, by killing /sbin/adbd

after usb disconnect and it it seems to put the android os to deep sleep

with about 10% battery usage in 7 hrs in standby . Now I'm trying to find a way

to automatically kill adbd after usb disconnect, but was not able to find a way yet.

Maybe somebody familiar with the adb d code could take a look if there were some

changes thast could cause the drain.
[G1 Android Development] farmatito:
I've reverted the AXI frequency scaling patch in my build

as the patch was suspected to be the cause of usb battery drain

and I can confirm..... that the drain is still there.

After having reviewed and tested many versions of acpuclk-arm11.c

and msm72k_udc.c I'm almost sure that the bug must

be somewhere else. There is still the fact that turning OC

off sometimes make it difficult to trigger it.
[G1 Android Development] hrk:
Since I got a Dream/G1 only recently, I am missing some background here. I have noticed that when I unplug my G1 from the USB plug of a computer, the battery drains faster and at the same time, I see the most power is used by "Android Operating System", which otherwise is always very low in consumption. When I see this, htop always reports an high number of average active processes (8-11), whereas it's usually a lower number (2-4).

Is this the very same behavior you all call "USB draining issue"? If it is, monitoring the process list could provide useful informations.
[G1 Android Development] farmatito:
Yes it is, indeed. The problem is that it happens with a specific version of kernel (2.6.35.10-pershoot) but not with others, so the first thought is to see what is different in it and fix it. So far I've investigated a little the acpuclock code and the msm72k_udc code but was not able to pinpoint a bug. Now I've run out of ideas, and now I'm running the precompiled stock kernel of ezterry's GB source tree.

Let me know if you have some ideas.
[G1 Android Development] pershoot:
nexus/ds - 2.6.35.10 - http://droidbasement.com/db-blog ; RM updated ; last update for froyo
[G1 Android Development] robuser007:
I use it on gingerbread :-)
[G1 Android Development] wjsturgis3:
Me too! See my sig,
[G1 Android Development] plumppp:
thanks! are there any kernels around that clock past 614?

i'm bored and wanna do some experimenting :D

Edit: never mind.. :D
[G1 Android Development] pershoot:
nexus/ds - 2.6.35.11 - froyo - http://droidbasement.com/db-blog ; RM updated
[G1 Android Development] roalex:
Since Terry's rom is picking up quite nicely and Cm devs are working on importing D/S to 2.6.37 wouldn't it be just uber to have some 32a/32b and 2708 GB kernels ^_^
[G1 Android Development] farmatito:
You can try this http://xdaforums.com/showpost.php?p=11195878&postcount=1285
[G1 Android Development] roalex:
Was more like um can't we have our best kernel dude support GB :)
[G1 Android Development] learningmore:
Ive been using pershoots kernel on gingerbread roms and they seem to work good if not better than the kernels that come stock with the rom.:cool:
[G1 Android Development] sada23:
Do you have battery drains? Pershoot does mention not to use his kernels on GB/CM 7 RC0.
[G1 Android Development] pershoot:
Sorry all.. been a lil slow with updates. Been a madhouse as of late for me. Ill try my best to sort for all devices swiftly.
[G1 Android Development] hrk:
USB draining issue IDENTIFIED

Ok, folks, I am 99% positive I've found the culprit behind the "battery drains fast if unplugged from USB from computer but not wall outlet".

For the impatients, it's a single word: EHCI.

Now for the not-so-impatient, I found out that I experienced the drain if I unplugged my Dream from a MacBook Pro, from a Windows/HP laptop, from a Linux server but not from another Linux workstation (yeah, I'm a bit crowded here...).

Looking for differences, I found out that (when plugged) the workstation would recognize/activate it as a full speed device using UHCI, whereas the server would recognize/activate it as a high speed device using EHCI.

I disabled EHCI on the server, connected the dream, charged to 100%, disconnected and... no USB draining issue. After around 10 hours (of my standard usage) I still had around 20% of battery left w/ "Android Operating System" having sucked around 9% of battery.

As much as I'd like to tinker with the kernel myself (just got pershoot's latest git dump), I have neither a clue where to start, nor the time to learn->find->fix->p0wn->gloat. I hope that having found the culprit, with your current experience you'll know where to look. :-)
[G1 Android Development] roccoadam32:
good work but still does not explain why when i unplug from a ac outlet my phone does not sleep and yes end button is configured to sleep in spar parts using pershoots latest
[G1 Android Development] ezterry:
ezterry - kernel 20110222

[size=+1]== 2.6.34.8 Build ==[/size]

May 26, 2011: These kernels are also available via Rom Manager under 'EzTerry'

EBI0 (32b) port for 2.22.* radio users (includes 32a MT1.2/Fender):

ezBiffTestKernel20110222-ebi0_S.zip

MD5: 31a358b19b4928791ec419ac8ee90022

EBI1 (32a) port for 3.22.* radio users:

ezBiffTestKernel20110222-ebi1_S.zip

MD5: 43cd86fa0cf568949c5162b7c4b14d40

2708 port for 32b only devices with 2.22.27.08 or 2.22.28.25 radios users with 1.33.0013 or 1.33.0013d SPLs

ezBiffTestKernel20110222-2708_S.zip

MD5: c6e4b6f34b9f4e5507090b678499198c

Anykernel installers for use on android 2.2 (froyo) roms. Highly recommended as an update to those running my previous 2.6.34.7 builds.

(To those who will install on other versions of android: pre-froyo roms may have issues with camera, particular on 2708+ build or 32a boards; gingerbread can be made to work however will require a compatible vold not in gingerbread by default for USB Mass Storage;)

Key features

* Derived from my 20101031 build: derived from pershoots 2634 kernel with CM and other patches

* Linux update from 2.6.34.7 to 2.6.34.8 including many Linux security updates.

* Updated CPU governors per 2.6.35.* builds (pershoot/cm)

* added 10MB ram (reducing camera from 16MB to 6MB) for 32a boards (both MT2.1 ebi0 kernel {patch} and classic 32a magic's ebi1 kernel {patch)

* Some sched updates.

* Built with gcc version 4.4.3 (via gingerbread tool chain)

Thanks to rattking for helping me test the kernel on a MT1.2/Fender

Known issue:

powering down when USB attached fails [for me anyway].. AC may or may not fail.. so unplug to powerdown. (or as its your phone... don't powerdown)

[size=+1]== Source Code ==[/size]

Build from tag:

ezBiffTestKernel20110222

[size=+1]== Previous Builds: ==[/size]

October 6th 2010 (ebi0/ebi1) here 595oc

October 17th 2010 (ebi0 only) here 595oc w/ 1MB ram (dream)

October 24th 2010 (ebi0/ebi1) here 614OC 1MB ram (dream)

October 31st 2010 (ebi0/ebi1 + nov6 2708+) here
[G1 Android Development] roccoadam32:
my phone is freezing at reboot sometimes with the new kernel terry running your foyo rom
[G1 Android Development] ezterry:
Please fill out the following information for your request to be looked at:

1) Phone model:

a. HTC Dream

b. 32b MAGIC (aka classic MT3G)

c. 32a Classic Magic/Magic+ (no audio jack)

d. 32a MT2.1/Fender (audio jack)

2) kernel version:

a. EBI0

b. EBI1

c. 2708+

3) Radio/SPL (HBOOT) installed on your phone, just copy the information from your HBOOT screen, power on holding camera on the dream; vol down on the magics.

4) Overclocking/underclocking if you use SET CPU what is it set to

4.b) Do you use custom MTD.. did you remember to re-apply the boot patcher after flashing the new kernel?

5) Any errors on install, dmesg/last_kmsg if possible, logcat if possible .. all these can go into pastbin as they are long and annoying to need to read in tapatalk.
[G1 Android Development] roccoadam32:
1) Phone model: HTC Dream 32b

2) kernel version: 2708+

3) Radio 2.22.28.25 spl 1.33.0013d

4) cpu is set to 528 max 245 min

no custom mtd

no error on install i dont have logcat installed right now

if i overclock phone will boot up mount sd card then reboot on its own
[G1 Android Development] BrandoHD:
gonna try this now, will report back, Promise
[G1 Android Development] Pfeffernuss:
Running this on Cyanogen 5.08. So far all is great and working well. Anxious to see how the battery performance will be :D
[G1 Android Development] loukvlav:
So is this newer/better to use than the previous one you posted in

http://forum.cyanogenmod.com/topic/...tlies/page__pid__117678__st__5660#entry117678 ?

Thanks!
[G1 Android Development] ezterry:
I can't really answer because you are comparing apples and oranges.

The kernel you are pointing at (exp20110109) is a Cyanogen CM6.1 nightly kernel based on linux version 2.6.35.10.. it is nearly an out of the box CyanogenMod build with no/little interaction from me.

This new kerenl is based off my previous biff testing (2708+) code for 2.6.34.7 (now updated to 2.6.34.8) And before I forked the development tree was the 2.6.34.7 pershoot kernel from September.

In terms of overall android patches the CM based exp20110109 is probably well ahead of this one.. and prehaps a bit more powerful. However many people have been running my 20101031/20101106 biff-testing kernels for the better well rounded stability it has provided. This provides an update to those that have been running those versions.

Some of the stability benefits people find in this new version are:

> No or at least a very mild USB drain bug (so if you forget to reboot after using USB the phone will still get decent battery life)

> No green screen on magics

> little more overall stable than some of the earlier 2.6.35.* builds.. but exp20110109 has worked very well as long as you didn't have the green screen and remembered to reboot after unplugging the USB wire so I'm not sure this part still applies.

Overall the original 2708+ kernel (the biff testing 20101106) has been much more popular than exp20110109 this provides a direct update for those users. Feel free however to continue using exp20110109.
[G1 Android Development] BrandoHD:
so far, all is well for me, slight battery drain more than pershoots latest, but i have to continue testing over the next week or so
[G1 Android Development] :
Where as for me battery life was terrible on pershoots latest, four to five hours max on standby and bye bye battery. The latest biff testing (2708+) code for 2.6.34.7 (now updated to 2.6.34.8) is currently running eight hours standby, few calls and text and still have 41% left.
[G1 Android Development] beav_35:
Someone mentioned a little while back that the battery drain might be caused by the alarm clock not letting the phone go into sleep mode properly and I think they might have been on to something. I was getting bad battery life with one of pershoot's kernels and the alarm clock always on. I recently flashed ezterry's latest so I will see how that goes. I am curious whether you guys are using the alarm clock or not.
[G1 Android Development] R3N0V4D0:
finally i can post gah! anyways just a heads up, the original ramhack kernel on donut 2.6.29 or w/e it was works on the new radio/spl i flashed i think it was called super-fast 1.3.3 and i forgot to flash the 2708 kernel and it booted fine... i was like...wait did i flash the kernel? so i check th phone info and behold i have the donut kernel! so maybe we can patch the ramhack kernel to get 25 mb?? someone plz expermient!! btw the kernel i used was WG's kernel ramhack.

and btw no flamers please i remember my battery draining after i flashed the new spl and radio..... i noticed it as soon a i loaded it... so i bought an extended battery cause i thought it was just old... so i dunno...
[G1 Android Development] fatjohnny:
Thank you again Terry !!!

Sounds like those wiser than I are making some progress on the USB thing which is great, maybe soon I'll only have to reboot after using bluetooth, not bluetooth and/or USB charging.
[G1 Android Development] :
Actually I do use the alarm clock and it's constantly on so will try a pershoot kernel myself with alarm clock on and off and see what the results are and we can compare.
[G1 Android Development] colonelk:
Does anyone know a 2708 compatible Kernel that clocks past 614?

I used to run at a stable 652 on the older kernels and would like to return to that if possible :)

BTW, I know running it like that is at my own risk / will shorten the life of my G1 etc etc

Since Dumfuq has stopped updating Kernels no one else goes over 614 it would seem :(

I have looked through the thread and googled trying to find one but no joy.

I know people say it doesnt make a performance difference vs battery life, but thats not been my personal experience :)
[G1 Android Development] farmatito:
New 2.6.37.2 Frankenstein Kernel

http://xdaforums.com/showpost.php?p=11637515&postcount=1433

Enjoy.
[G1 Android Development] yokonunz:
can you build a .37 for old radio? im asking this because if i load the new spl i wont boot because kernel flashing often fails.

thanks
[G1 Android Development] Ntadeusz:
This kernel is for 32b. Is it exist frankenstein krenel for 32a?
[G1 Android Development] beav_35:
It would help if you would tell us what radio version you have. The new 2.6.37.2 Frankenstein kernel is only for 2708+ radios.

http://xdaforums.com/showthread.php?t=831139