Jump to content

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


Guest Test Zeppelin

Recommended Posts

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

Link to comment
Share on other sites

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 by Tom G
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by Geree
Link to comment
Share on other sites

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 by sej7278
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Jean85
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.