[Motorola Triumph] Genesis3:
To file a BUG report

Use the Bugtracker Git at https://github.com/ikarosdev/CM7_Triumph_bug_tracker/issues?sort=created&direction=desc&state=open

Filing a new bug will require that you set up a login ID on Github if you don't have one. Please note that bugs reported in this thread (as opposed to discussion, which is always welcome) may or may not be noticed and tracked; if you care about whatever you're reporting, please use the GITHub system. Bugs filed on Github must include steps to re-create the problem if you're able to do so and if you can obtain one, a logcat or other trace is very helpful. You can also look at the above link to see what issues are open (please do not duplicate already-reported bugs, although if you have comments on them adding them is fine) as well as what has bene closed which may be of interest if you're looking for what is likely to show up in the next code turn.

Notes

Do

NOT

tamper with the following lines in build.prop:

ro.telephony.ril_nid=97

ro.telephony.ril_prl=1115

ro.telephony.ril_class=Triumph

ro.ril.def.preferred.network=4

ro.telephony.default_network=4

rild.libpath=/system/lib/libril-qc-1.so

rild.libargs=-d /dev/smd0

If you do there is a high probability that the radio will break. In particular the ril_class is required to deal with the oddities in the Qualcomm radio code. If you are running a different PRL you can change the prl line but it should remain present.

If you are updating from previous releases and have problems format the /system partition before you load the update. You should not need to format the data partition ("factory reset") and reload your applications, but no promises can be made at this point in development.

Custom backlight options (Settings->Cyanogen Mod->Display->Automatic Backlight) are available; you can change the behavior of the LCD backlight, including thresholds and illumination settings, the number of steps, whether averaging is used, whether hysteresis is operational and whether the button backlight is on or off as desired. Please note that unlike many devices the sensor value returned to the code is not in "lux"; it is a raw value and tops out in full sunlight somewhere under 100, with "0" being a fairly dim (but not dark) room. The default table I have loaded has the button backlight

OFF

for very dim ambient conditions (I like to use the phone as an alarm clock and want the buttons off at night),

ON

for low-but-present ambient conditions, and then

OFF

again (power saving) for ambient light high enough that the backlight has no real purpose. You may change this to suit yourself and your desires; some people will want the buttons on for zero-ambient conditions.

Note: As of 9/24 this load is using the "ext4" filesystem. Alternative kernels must support both that filesystem and the options CONFIG_NETFILTER_XT_TARGET_TCPMSS and CONFIG_IP_NF_MANGLE. If they do not MSS clamping will not function. If ext4 is not supported the kernel will not boot.

3g/1x data lock

If you are in a place that often switches down to 1xRTT for data due to questionable signal levels it is possible to lock the RIL to 3g mode. Note that doing so means you either get 3g speed or nothing. You need to access the "Phone Info" menu to do this using either AnyCut (from the market) or from the "Battery Monitor" Widget (go to "Tests" in the selected screen from there.) Note, however, that doing so (1) will not survive a reboot and (2) disables SMS/MMS and inbound phone calls during the time it is active. SMS/MMS will come through if you make a phone call but the EVDO-only mode for data blocks something in the radio that is required to receive and send SMS messages and the notifications of an inbound call. Since this "mode change" is actually a request to the radio ROM (which we do not have source for) this probably can't be worked around. However, I am looking into what this mode select does in the hope of being able to detect the 1x switch (which I can easily do with the existing RIL support code) and temporarily force a 3g switchback - which may or may not be highly-disruptive to data transport (if it is it's not worth doing at all, but if not...)

Note: There is an apparent memory leak in the base CM7 code somewhere. This is the cause of sensor slowdown (e.g. rotation is not immediately recognized) as the system becomes memory-constrained and ultimately will fault and reboot. I do not have isolation of this problem as of yet and have no reasonable expectation on when or if I may; for the time being I recommend a reboot on a daily basis to avoid the worst of these effects. The impact becomes particularly-severe if you use things like CoPilot that require large working sets of RAM. My instrumentation leads me to believe the problem is not in the kernel nor in the user application side of the system, but rather is in the base CM7 load. Investigation continues.

A note on overclocked kernels:

I will not be supporting these in my builds. They work, and some people want them. Isaac has built one that can (theoretically) go to 1.9Ghz.

Here's the issue in a nutshell: It's pretty easy to exceed thermal limits in a CPU doing this, and if you do, the best thing that happens is that the device becomes unstable and reboots. The worst thing that can happen is that the internal junctions in the CPU can be damaged or even destroyed. This damage is not always immediately apparent and can in fact be cumulative.

I understand some people want to overclock, but nobody really knows where "the wall" in this regard, and if you find it you're going to be very unhappy. As such if you want to have fun of this sort you'll need to load your own overclocked kernel over what I build. I respect those who are willing to take the risk but I just don't see the potential reward as being worthwhile and I don't want to be the guy that hands you a build that smokes the CPU in your phone.