[ROM][GEN2]CyanogenMod 7 (Android 2.3.7)

[Guest Geree]

I reflashed Patch5, no GPS reboot so far...but this time market didn't update itself, while it did first time. It's quite mysterious, since I did everything the same like before (wiped everything etc..) however there are several differences...:S

[Guest Tom G]

I sent you my logs in email, haven't you received them?

Your logs were for a different issue (GPS reboot, not shutdown). Thank you for sending them.

The GPS reboot issue is one that I can replicate, it just isn't easy so additional logs may help to see a pattern (on patchset 5 I haven't been able to reproduce it but there is no reason that it should be fixed).

I can't get proximity to work using patch five. Tried full wipe (factory reset) and davlic and system format - still doesn't work. Gone back to 179 and it works. Any suggestions please?

I changed the default calibration settings in patchset 5 so it should work for more people without calibration now. The new default are based on the calibrated values from one of my blades, but I guess they don't work for everyone. Can everyone testing the new kernel run the proximity calibration program and then report back the prox_threshold_hi & prox_threshold_lo values so we can get better defaults.

i ran the logcat/kmsg script, didn't think anything was going to happen, i was playing with wifi and gps, maps and market, facebook, twitter etc; desperately trying to reproduce the wifi reboots i had.

then i gave up and put the phone on the table, and after a while it powered off completely with a vibrate!

can't see anything obvious in the kmsg, but logcat seems to point to it being a gps or battery issue, so possibly the false-overheat issue?

emailed to tom_g

It looks like the overheating issue, which is often triggered by using GPS (use GPS, phone is fine. After stopping using GPS, when it wakes from suspend battery temps go high).

I'm uploading a new patchset for it. It will extend the ignore time further, but the main purpose it to improve the log messages. Try to get more log output, you can tell if it has happened by the 'ignoring battery temperature reading' messages in kmsg (I want the logs even if it doesn't shutdown, but only if the messages appear, logcat isn't very important for this one).

I'm not sure why you are getting wifi problems. Nothing blade specific has changed that should effect that.

Edited September 20, 2011 by Tom G

[Guest asm19]

Patch 6 out, thanks Tom G. Waiting new version KANG... :)

[Guest sej7278]

Can everyone testing the new kernel run the proximity calibration program and then report back the prox_threshold_hi & prox_threshold_lo values so we can get better defaults.

hi = 4185

lo = 3348

It looks like the overheating issue, which is often triggered by using GPS (use GPS, phone is fine. After stopping using GPS, when it wakes from suspend battery temps go high).

I'm uploading a new patchset for it. It will extend the ignore time further, but the main purpose it to improve the log messages. Try to get more log output, you can tell if it has happened by the 'ignoring battery temperature reading' messages in kmsg (I want the logs even if it doesn't shutdown, but only if the messages appear, logcat isn't very important for this one).

I'm not sure why you are getting wifi problems. Nothing blade specific has changed that should effect that.

i'll have a go at building patch6 in the morning (well it is the morning, but after a few hours sleep) and will get logcats back to you.

[Guest The_Duck]

I changed the default calibration settings in patchset 5 so it should work for more people without calibration now. The new default are based on the calibrated values from one of my blades, but I guess they don't work for everyone. Can everyone testing the new kernel run the proximity calibration program and then report back the prox_threshold_hi & prox_threshold_lo values so we can get better defaults.

My Prox High is 405

My Prox Lo is 324

Duck

[Guest rockstarszzzz]

My Prox readings:

Hi: 2134

Low: 1492

[Guest Woody Guo]

WHERE ARE THE LOGS?!?!

If people aren't going to provide logs I'm not going to try to fix it (how can I, it doesn't happen on either of my blades). I guessed that extending the time we ignore temperatures might help, but there is really no reason why it should be longer than it was with 2.6.32, other than that there isn't much I can do with absolutely no information about the problem. It may be a totally new problem unrelated to the issues we had with the old kernel and without logs there is no way to know.

I modified the shutdown method to run the command "cat /proc/kmsg > /data/lost+found/kmsg &" before actually shutting down the phone, but unfortunately I found no file was generated when I power on the phone

maybe it's too late to run the cat command when it comes to run the low level shutdown, because the volume has already been unmounted?

[Guest SebbesApa]

hi = 4185

lo = 3348

Am i doing something wrong when my values are:

hi = 541

lo = 433 ?

Or should i like hold my finger over the prox sensor when calibrating?

[Guest SergeyVG]

low-level shutdown procedur.

1. Run Camera app, wait 10sec and press back button.

2. Press Power button for sleep.

3. Wait 5min

4 Phone vibration and shutdown

ver p3+2

log

kmsg.txt

logcat.txt

[Guest Simono]

I have question to people that test new kernel and have got reboots. All You have overclocked Blade? Maybe some that don't have reboots don't overclock phone.

[Guest Geree]

Wow...great finding.. I didn't beleave first time, but it works :) alhtough it is clearly related to false temperature reading.

Edit: I'm on patch 5.

Edited September 21, 2011 by Geree

[Guest sej7278]

Am i doing something wrong when my values are:

hi = 541

lo = 433 ?

Or should i like hold my finger over the prox sensor when calibrating?

no don't do that. is this with the 2.6.35 kernel? what generation phone - mine's a gen1 black oled tpt'd to gen2 (orange).

these variations might explain why a default value of any sort is not going to work!

patch6 is up by the way folks, trying the camera trick now with logging running. there's nothing functionally new, but more debugging is enabled if you run the script.

edit: just reproduced the shutdown using the camera app in patch6, sending logs. although that is definitely different to the wifi/gps reboots i've had with earlier builds.

not overclocked, proximity: hi=4210, low=3368

Edited September 21, 2011 by sej7278

[Guest SebbesApa]

no don't do that. is this with the 2.6.35 kernel? what generation phone - mine's a gen1 black oled tpt'd to gen2 (orange).

these variations might explain why a default value of any sort is not going to work!

patch6 is up by the way folks, trying the camera trick now with logging running.

I'm on KANG-n179-2635p3. sf orange updated to gen2 with windows software.

Now i'm getting:

hi = 564-502

lo = 451-402

[Guest]

I have question to people that test new kernel and have got reboots. All You have overclocked Blade? Maybe some that don't have reboots don't overclock phone.

A very good point there.If users are going to be testing,they really need to be running standard clock speeds.

I like a bit of extra cpu power myself,just like everyone else.

But if we find a bug or get reboots,then we should firstly return to standard clock speeds and see if we can reproduce the problem.It would save developers a lot of hastle if all the overclock related problems are weeded out.

A fine example of overclock related bugs is the camera app.With overclock there is a lot of flickering going on,at least for me anyway.As soon as I return to standard clock speed,the camera is fine.

[Guest tsddave]

Yes but some people like me prefer official nightly.

You must be crazy! What is there to prefer?

Would you prefer some of my nice blue colour £5 notes for your old not so nice coloured £20 notes then? :P

[Guest Benoe]

Can everyone testing the new kernel run the proximity calibration program and then report back the prox_threshold_hi & prox_threshold_lo values so we can get better defaults.

prox_threshold_hi = 4735

prox_threshold_lo = 3788

with patch5

[Guest Simono]

tsddave

I don't discuss with You because I must have stable phone without reboots. You see posts above?

:)

Edited September 21, 2011 by Simono

[Guest sej7278]

tsddave

I don't discuss with You because I must have stable phone without reboots. You see posts above?

:)

come on folks, lets drop this. some people prefer sticking to a stable-ish n179, some people prefer bleeding edge but a little buggy.

that said, i think this thread is going to be all about 2.6.35 from now on, especially as nightlies past 179 are broken.

[Guest Simono]

Yes sej7278 You are be in the right.

There is a metod to build ROM on Windows machine, I don't use linux or simple tutorial for ubuntu?

Edit:

I found it Building from sources

Edited September 21, 2011 by Simono

[Guest .mil]

Any information about RC2 (when?), and when new nightlies will work on our phones?

[Guest Tom G]

hi = 4185

lo = 3348

i'll have a go at building patch6 in the morning (well it is the morning, but after a few hours sleep) and will get logcats back to you.

on 2.6.35? that looks very wrong. they should be about a 10th of that.

[Guest Jean85]

KANG P3+, Orange SF TPT to Gen2, prox sensor just calibrated

hi = 886

lo = 709

It really seems that there isn't a real correct default value...

[edit] cleaned up the screen, recalibrated:

hi = 871

lo = 697

It seems to depend a lot on model or lighting in the ambient...

Edited September 21, 2011 by Jean85

[Guest ChrisD1]

Can everyone testing the new kernel run the proximity calibration program and then report back the prox_threshold_hi & prox_threshold_lo values so we can get better defaults.

hi = 579

lo = 463

[Guest massycat]

First of all, many thanks to everybody who has been working on CyanogenMod for the Blade. I have installed KANG-2635p5 and all seems good so far.

Proximity values are:

prox_theshold_hi = 481

prox_theshold_lo = 385

Does the 2.6.35 kernel used in KANG-2635p5 support the USB Accessory?

Looking at the kernel source (TomG kernel source - assuming that is the correct source) it does not have f_accessory.c file that is present in other kernels that do support USB Accessory (e.g. Samsung Crespo kernel).

If USB Accessory is not currently supported then does anybody know if support is possible and what work is required to implement it?

[Guest Pelemanne]

KANG-2635p5 working fine.

Proximity values are:

prox_theshold_hi = 519

prox_theshold_lo = 415