Related
Seems like having SD card inserted causes high IOWait.
User 1%, System 3%, IOW 95%, IRQ 0%
User 5 + Nice 0 + Sys 10 + Idle 0 + IOW 291 + IRQ 0 + SIRQ 0 = 306
Currently running smsBackup+ that restores sms messages from Gmail (1 message in 4 sec)
This also seems to cause reported installation issues:
(thread http://forum.xda-developers.com/showthread.php?t=926507)
Installed several times myself... waited up to 0.5 hour.. still splash screen.
Several processes (com.android.phone, etc) got "Force" or "Wait" messages.
Only after connecting ADB console was i able to see that android was still initializing.. waited for longer and in the end ~1 - 1.5 hours phone booted up.
Are you affected? .. Try removing SD card.. does HD2 boot up within 10 min.? .. then probably you have the same issue.
(not really usable with no SD card.. settings are lost on each boot)
This is discussed very often in the developing thread that you already mentioned: Dev Thread
The first time it needs a lot of time - in my case it was more then one hour before the splash screen was away - for the FCs just press the "Wait" button and wait - after the first time it will become less and less and the device will work quite fast (just the known bugs are still there).
Some people told that they had to wait for 2 or one even for 4 hours before the splash screen was away. I had very strong problems with installing and it did not disappear after 6 hours.
If you have that try the following:
1.) data wipe
2.) d-cache wipe
3.) starting in MAGLDR
4.) USB flasher / DAF.exe
5.) recovery menu / cwm partition sd card (1024/0M)
6.) mounting and transfering .zip
7.) install .zip
8.) reboot
hope i got you right
Ok, in this thread I will describe one problem that I have faced with my Iconia and that was also reported by one other user on a forum.
Basically, Iconia uses Atmel mxt1386 touchscreen controller. The same controller is used in Asus EEE Transformer and Motorola Xoom and even Samsung Galaxy Tab 10.1. So far, there are a lot of reports of EEE Transformer's and Xoom's touchscreens suddenly stopping working and starting working after a full battery discharge.
One day after a reboot my Iconia stopped booting - it keeped hanging on the Acer logo and when I tried entering recovery it was hanging at "booting recovery kernel image". However, that only happened with Acer kernels. With my own kernel, ported from EEE Transformer, the tablet could boot. I have recompiled the acer kernel with framebuffer console and found out it got stuck at the touchscreen interrupt handler while EEE's driver just printed an error and stopped working.. Basically, the response I got from from the touchscreen was [1, 0x80, 0, 0, 0, 0, 0, 0]. And it was not detected with i2cdetect
At first, I thought my touchscreen cable was damaged. I have disassembled the tablet and tried twisting the cable to see if it gives any result. My result was that if I disconnect and reconnect the cable, an interrupt comes. Btw, the cable has sharp 'teeth' and you can crimp it pretty much like ethernet.
Ok, so then I added some printks to the driver. Turns out, when some data coming from the touchscreen was incorrect, the driver hanged (deadlocked) because the semaphore was pushed down two times and never upped. So, I have commented out semaphores and bingo - it continued booting. Although there were a lot of warn_slowpath errors and CRC error, it reported correct coordinates. I flashed Acer's kernel after it and it booted fine. Looks like a proper init by Acer driver reset the controller.
The archive in the link contains tegra i2c driver from the chromium tree (in case it finds i2c errors like nak, it retries the transmission several times) and the touchscreen driver. You need to comment out "#define USE_SEMA" to disable semaphores and build the kernel with it in case you encounter the problem..
http://www.mediafire.com/?jt6b19nr7rsy70s
I do not have another 'brick' to test if my solution works in all cases but I'm just leaving the stuff here in case anyone faces the trouble. To flash when your tablet is not booting you'll probably some help from sc2k..
What's the moral of the story? The moral is that as touchscreen is not used in recovery, it may be a good idea to add the 'hacked and buggy' driver to the recovery kernel to allow to recover the device by just booting recovery in case anyone faces the problem.. Of course it's better to fix the driver properly or even use the driver from mainline linux and patch it.
EDIT 29-oct-2011:
here is a link to the cwm recovery image with the 'hacked' driver. Boots just fine.
http://www.mediafire.com/?39jk1j15wkpr57o
So just to clarify this is a software/recovery problem not a hardware problem?
This is a combined problem. It is a hardware problem as the touchscreen stops getting recognized by i2cdetect, probably due to firmware bugs.. It is a software problem because the driver behaves incorrectly when the hardware fails.
Ok, I will post the reply from sc2k who investigated the issue a bit. Let's keep it here for reference. I think it will be nice to patch the mainline driver (from chromium or mainline linux) and use it instead of acer's driver but I won't probably do it unless I hit the issue again or make some progress with my chromium kernel
sc2k said:
Ok.. I finally understand the issue:
Your tochscreen always responded with [1, 0x80, 0, 0, 0, 0, 0, 0]
buffer[1].bit7 seems to be some kind of "message incomplete" bit. As this is always transmitted, the worker thread never releases the semaphore which causes the ATMEL_Initial to stop at ATMEL_SyncWithThreadToReadMsg.
After you disabled the semaphore, ATMEL_Initial continues. ConfigError is probably 0, so next function to be called will be ATMEL_CheckConfig.
This function first calls ATMEL_SendCMDgetCRC. As semaphores are disabled, this will probably not be able to receive the checksum (due to timing) so that ConfigChecksumError=1.
If ConfigChecksumError==1, ATMEL_CheckConfig will call ATMEL_WriteConfig and ATMEL_Backup that will probably be successful and thus fixes the configuration issue. Even if it does not complete succesfully, the whole recovery process is repeated until all conditions are satisfied.
Conclusion:
- Somehow the configuration in your touchscreen controller got messed up.
- Removing the semaphores triggered ATMEL_WriteConfig + ATMEL_Backup which probably fixed the issue.
I believe, a good fix would be to add a check "if (counts > 20) { up(&mxt->sema); goto fail; }" or similar to mxt_worker for irq_type == ATMEL_ReadResponseMsg_Noaddress. This would prevent these endless interrupt loop and allow the driver to fix the configuration.
Really nice bug that you have found in this driver
Click to expand...
Click to collapse
Link to cwm recovery image invalid
Hi sp3dev,
sorry to ask but could you pls reupload your cwm recovery image? Mediafire says the file is not available any more.
I am not an expert in ROMs and I know nothing about cooking them or kernels. But I think I am having a problem similar to that described in your thread: after a sw update the touchscreen became unsensitive. Shutdown, reset, factory reset do not solve the problem. When I flash a new ROM to try and "reset" the screen controller, I get stuck at the "ACER" logo after flashing with CWM and rebooting the system. If I shut down and restart again, the machine starts but the touchscreen is still unresponsive. Luckily enough, I can use a USB mouse to interact with the device.
I am currently running HC 3.1 (stock), rooted. I took a full nandroid backup with CWM. Do you think it is safe to flash your recovery with the modified touchscreen driver (that is, if you are kind enough to re-upload it for me...)?
Thanks a lot for any advice you can provide.
Best, Andrea
I see that thor2002ro has seen this thread, but will we see the driver implemented in the next CWM release?
If it can help people recover from a known brick and if the stack does not introduce problems then I hope that we see something, at least a recovery instruction for the touchscreen added to CWM or the whole stack. aferall this could be something that ends up happening to alot of us :S
I had this problem with my Galaxy Tab and tried the fixes mentioned but it just didn't work for me. I have, however, figured out what's really going wrong.
I always had this failure showing up in dmesg:
[ 1.707677] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.707913] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.708080] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.709363] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
[ 1.748037] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.748355] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.748523] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.749788] sec_touch 1-004c: Failure accessing maXTouch device
So, it can't read from the touchscreen controller at address 0x4c. The fix mentioned in this thread was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement.
I tried adding a reset. No change. Disconnected the battery overnight. Also no change.
Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, I just called the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.
I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.
http://www.rickmurphy.net/mxt1386_fixer.zip. While this is a p4wifi (Gtab 10.1 Wifi-only) it'll probably fix the problem on a 3G tablet as well as long as you restore the correct kernel once it's done..
Whew. It's good to have the toy back working.
k1mu said:
I had this problem with my Galaxy Tab and tried the fixes mentioned but it just didn't work for me. I have, however, figured out what's really going wrong.
I always had this failure showing up in dmesg:
[ 1.707677] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.707913] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.708080] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.709363] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
[ 1.748037] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.748355] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.748523] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.749788] sec_touch 1-004c: Failure accessing maXTouch device
So, it can't read from the touchscreen controller at address 0x4c. The fix mentioned in this thread was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement.
I tried adding a reset. No change. Disconnected the battery overnight. Also no change.
Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, I just called the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.
I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.
http://www.rickmurphy.net/mxt1386_fixer.zip. While this is a p4wifi (Gtab 10.1 Wifi-only) it'll probably fix the problem on a 3G tablet as well as long as you restore the correct kernel once it's done..
Whew. It's good to have the toy back working.
Click to expand...
Click to collapse
Though I don't have this problem, and hope never to, it is a scary scenario. Thanks for investing your time to come up with a fix for ppl who have this problem.
Sent from my GT-P7510 using xda app-developers app
OTAw said:
Though I don't have this problem, and hope never to, it is a scary scenario. Thanks for investing your time to come up with a fix for ppl who have this problem.
Click to expand...
Click to collapse
Thanks. I've also sent a patch to the person who I thing maintains the driver. If they'll accept the fix, it'll automatically correct this problem regardless of the type of device being used. That'd be a good thing.
I have the common problem with my Acer Iconia A500.
The tablet's touchscreen suddenly stopping working. And didn't start working after reset, shutdown, deattaching the battery, or any firmware upgrades/downgrades.
Custom bootloaders and restores also didn't help.
It is starting working only when I shutdown the tablet and don't use it for a while.
When I turn on the tablet after 2-3 hours, the touchscreen works. But after 10-15 minutes of usage(or even idle), touchscreen stop working again.
I tried many ways to solve this problem, but nothing works for me.
When I tryed to figure out this issue, I found only a few topics in the internet, but all of them was leading to this thread.
So, tell me please, is there any workaround to this touchscreen problem?
I suggest, this is the hardware problem. But if there is any software fix, it would be good.
DIZAZTER said:
I have the common problem with my Acer Iconia A500.
The tablet's touchscreen suddenly stopping working. And didn't start working after reset, shutdown, deattaching the battery, or any firmware upgrades/downgrades.
Custom bootloaders and restores also didn't help.
It is starting working only when I shutdown the tablet and don't use it for a while.
When I turn on the tablet after 2-3 hours, the touchscreen works. But after 10-15 minutes of usage(or even idle), touchscreen stop working again.
I tried many ways to solve this problem, but nothing works for me.
When I tryed to figure out this issue, I found only a few topics in the internet, but all of them was leading to this thread.
So, tell me please, is there any workaround to this touchscreen problem?
I suggest, this is the hardware problem. But if there is any software fix, it would be good.
Click to expand...
Click to collapse
Well, if you have done a rollback using TD's V4 rollback tool, and the problem still persists, then it's likely a hardware issue.
If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.
I would suggest, if you are no longer under warranty, to pop off the cover, and start checking connections. More than likely a connection is failing. (cold expands, heat contracts). Might explain why it works when it's cool. (this is why we put old HDD's in the freezer, sounds strange, but can't deny physics)
You can google for 500 breakdown videos. Plenty of them out there.
As a test in the temp theory, just play with the tab till it fails. Toss it in the fridge for 15 minutes or so. If it works, then it's mechanical.
I'd bet on the connectors. Then check the board with a magnifying glass.
MD
Moscow Desire said:
Well, if you have done a rollback using TD's V4 rollback tool, and the problem still persists, then it's likely a hardware issue.
If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.
I would suggest, if you are no longer under warranty, to pop off the cover, and start checking connections. More than likely a connection is failing. (cold expands, heat contracts). Might explain why it works when it's cool. (this is why we put old HDD's in the freezer, sounds strange, but can't deny physics)
You can google for 500 breakdown videos. Plenty of them out there.
As a test in the temp theory, just play with the tab till it fails. Toss it in the fridge for 15 minutes or so. If it works, then it's mechanical.
I'd bet on the connectors. Then check the board with a magnifying glass.
MD
Click to expand...
Click to collapse
You're right about the temp.
Actually, I put the tablet in the fridge even before I saw you reply.
After that procedure, touchscreen works fine for a while. And after freezing it works much longer period. I guess, it works just before getting warm.
I wanted to mention about the temperature dependence, but you did it first.
My warranty is expired. So I'm already has disassembled and taken the tablet apart. But I saw nothing noticeably wrong there.
I guess, there is some kind of connection failure, but it's microscopically small. Or it's situated inside of a board or a chip.
Anyway, thanks a lot.
At least I figured out that this is only hardware issue and there is no way to fix it with software patch.
Moscow Desire said:
If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.
..
I'd bet on the connectors. Then check the board with a magnifying glass.
Click to expand...
Click to collapse
I agree. Your problem has nothing in common with the issue that was causing my touchscreen to not work. That was a software problem with a reliable software fix.
I have seen a Galaxy Tab with a flaky touchscreen, but when I took it apart to look at what was wrong I found that the connector for the touchscreen had been ripped completely off the motherboard. The induhvidual responsible tried to fix it by taping the touchscreen connector to the motherboard! Needless to say, that wasn't a very reliable fix. :laugh:
I've pulled the kernel that had my patch off of my web site because it's only usable on the P7510 (WiFi) device and caused a 3G tablet to hang.
Could someone please explain what went wrong?
I use a acer a700 and get everytime i make display on such errors:
mXT1386E: mxt_late_resume
<4>[ 1641.027524] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.027938] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.028178] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.045244] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.045398] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.045670] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.069140] mXT1386E i2c write 3 time
<4>[ 1641.069539] mXT1386E: ATMEL_Resume OK!
Any idea?
Why?
On boot, dmesg write this:
mXT1386E: reenter_count: 0
mXT1386E: Config has errors
mXT1386E: The status is 0x90
mXT1386E: reenter_count: 1
mXT1386E: Config status is ready
How can we fix it?
Please devs!Help us!!!
djsven said:
Could someone please explain what went wrong?
I use a acer a700 and get everytime i make display on such errors:
mXT1386E: mxt_late_resume
<4>[ 1641.027524] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.027938] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.028178] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.045244] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.045398] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.045670] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.069140] mXT1386E i2c write 3 time
<4>[ 1641.069539] mXT1386E: ATMEL_Resume OK!
Any idea?
Why?
On boot, dmesg write this:
mXT1386E: reenter_count: 0
mXT1386E: Config has errors
mXT1386E: The status is 0x90
mXT1386E: reenter_count: 1
mXT1386E: Config status is ready
How can we fix it?
Please devs!Help us!!!
Click to expand...
Click to collapse
That "no acknowledge from address 0x4c" means that your touchscreen chip is not responding. It's possible that it's just dead, or possible that it's stuck in firmware update mode (in update mode, the address changes to 0x26). If you can point me to kernel source for your A700, I can modify it try to recover the touchscreen. (Of course, I'm assuming that it's just dead and that the touchscreen never works. If it works some of the time but fails later, it's probably just a hardware problem.)
k1mu said:
That "no acknowledge from address 0x4c" means that your touchscreen chip is not responding. It's possible that it's just dead, or possible that it's stuck in firmware update mode (in update mode, the address changes to 0x26). If you can point me to kernel source for your A700, I can modify it try to recover the touchscreen. (Of course, I'm assuming that it's just dead and that the touchscreen never works. If it works some of the time but fails later, it's probably just a hardware problem.)
Click to expand...
Click to collapse
Hi @k1mu got a question regarding this discussion. Would there also be benefits from this fix if it's only a unresponsiveness in runtime? I assume also djsven has it within runtime and the ts recovers itself... what I get from this thread is that it's regarded to the tab being unrecoverably stuck on firmware update mode? If not and it could fix hangs for some seconds in runtime it would be awesome if you could make a patch for this driver or just point me to a diff...
Thanks in advance
Elibl said:
Hi @k1mu got a question regarding this discussion. Would there also be benefits from this fix if it's only a unresponsiveness in runtime? I assume also djsven has it within runtime and the ts recovers itself... what I get from this thread is that it's regarded to the tab being unrecoverably stuck on firmware update mode? If not and it could fix hangs for some seconds in runtime it would be awesome if you could make a patch for this driver or just point me to a diff...
Thanks in advance
Click to expand...
Click to collapse
If it's just slow to respond, then the touchscreen is basically working and isn't going to be helped by this fix.
That (slow, jerky response to screen input) is caused by CPU hogging processes keeping the tablet too busy, or too many applications running at once, keeping the OS busy shuffling memory around (that's called thrashing).
k1mu said:
If it's just slow to respond, then the touchscreen is basically working and isn't going to be helped by this fix.
That (slow, jerky response to screen input) is caused by CPU hogging processes keeping the tablet too busy, or too many applications running at once, keeping the OS busy shuffling memory around (that's called thrashing).
Click to expand...
Click to collapse
Sure that's only system hangs... I ment does your fix help for input lags/death regarding 0x4c address/firmware update mode... If you show me the diff I could just test it... Would be highly appreciated
Elibl said:
Sure that's only system hangs... I ment does your fix help for input lags/death regarding 0x4c address/firmware update mode... If you show me the diff I could just test it... Would be highly appreciated
Click to expand...
Click to collapse
No, the system doesn't hang, it works just fine if you plug in a keyboard.
Here's the diff:
Code:
diff -c drivers/input/touchscreen/orig/atmel_mxt1386.c drivers/input/touchscreen/atmel_mxt1386.c
*** drivers/input/touchscreen/orig/atmel_mxt1386.c 2012-10-10 08:11:10.543325982 -0400
--- drivers/input/touchscreen/atmel_mxt1386.c 2012-10-10 08:35:30.545044039 -0400
***************
*** 22,27 ****
--- 22,29 ----
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+ #define FIX_CHIP_HANG
+
#define DEBUG_INFO 1
#define DEBUG_VERBOSE 2
#define DEBUG_MESSAGES 5
***************
*** 2539,2544 ****
--- 2541,2550 ----
/* Initialization of driver */
/******************************************************************************/
+ #ifdef FIX_CHIP_HANG
+ extern int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn);
+ #endif
+
static int __devinit mxt_identify(struct i2c_client *client,
struct mxt_data *mxt)
{
***************
*** 2559,2564 ****
--- 2565,2585 ----
msleep(30);
goto retry_i2c;
}
+ #ifdef FIX_CHIP_HANG
+ /* If we tried twice and no response, maybe it's in firmware
+ * load mode. Try to upload firmware.
+ */
+ if (mxt->read_fail_counter == 2) {
+ printk(KERN_DEBUG "Trying firmware reload.");
+ mxt->last_read_addr = -1;
+
+ mxt_do_firmware_load(mxt, MXT1386_FIRMWARE);
+
+ reset_chip(mxt, RESET_TO_NORMAL);
+ msleep(300);
+ goto retry_i2c;
+ }
+ #endif
dev_err(&client->dev, "Failure accessing maXTouch device\n");
return -EIO;
}
diff -c drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c drivers/input/touchscreen/atmel_mxt1386_cfg.c
*** drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c 2012-10-10 08:12:43.773952501 -0400
--- drivers/input/touchscreen/atmel_mxt1386_cfg.c 2012-10-10 08:36:55.704576439 -0400
***************
*** 408,417 ****
return 0;
}
- int mxt_load_firmware(struct device *dev, const char *fn)
- {
- struct mxt_data *mxt = dev_get_drvdata(dev);
unsigned int frame_size;
unsigned int pos = 0;
unsigned int retry;
--- 408,416 ----
return 0;
}
+ int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn)
+ {
unsigned int frame_size;
unsigned int pos = 0;
unsigned int retry;
***************
*** 518,520 ****
--- 517,526 ----
return ret;
}
+ int mxt_load_firmware(struct device *dev, const char *fn)
+ {
+ struct mxt_data *mxt = dev_get_drvdata(dev);
+
+ return mxt_do_firmware_load(mxt, fn);
+ }
+
Hi!
I have a Nexus 10 and it's been working flawlessly since I bought it, running CyanogenMod 10.1 most of the time. After I upgraded to 4.4 it started to hang, become unresponsive when being left on with screen turned off for a couple hours. Wouldn't last a night without hanging, regardless if it was being charged or not. Every time after that I had to hard reboot (press power button for longer than 8-10 seconds). This would happen on stock 4.4, stock 4.3, CM 10.2, stock kernel, francoKernel. Even on fresh install with no apps installed.
When I left it connected to USB with ADB logging, I could see that the last thing in the log before it hangs was usually something related to libEGL, GL, GL Operation, glDrawArrays.
For example:
Code:
11-23 13:08:34.250 W/System.err( 1012): java.lang.RuntimeException: GL Operation 'glDrawArrays' caused error 505!
(I found somewhere that this is GL Out of Memory error)
Code:
11-23 13:08:38.955 W/ ( 1012): GLES-MALI OOM error: execution failed (gles_fbp_read_pixels at vendor/arm/mali6xx/gles/src/fb/mali_gles_fb_read_pixels.c:693)
Code:
12-15 21:06:40.813 D/libEGL (16985): glGetIntegerv(GL_FRAMEBUFFER_BINDING_OES, (GLint *) 0x426e3be0);
12-15 21:06:40.813 D/libEGL (16985): glBindFramebuffer(GL_FRAMEBUFFER_OES, 2);
12-15 21:06:40.813 D/libEGL (16985): glGetError();
This is the latest log on CM 10.2 with OpenGL tracing in logcat (just the last part):
http://pastebin.com/6rpmfYca
The full log:
http://www61.zippyshare.com/v/5060489/file.html
This is some previous log:
http://pastebin.com/J9dNBBZS
What is causing this? What app/service is it dying in (there is MovieMaker in the log before the issue happens, but WTH?)? How can I debug this further?
_anarion_ said:
Hi!
I have a Nexus 10 and it's been working flawlessly since I bought it, running CyanogenMod 10.1 most of the time. After I upgraded to 4.4 it started to hang, become unresponsive when being left on with screen turned off for a couple hours. Wouldn't last a night without hanging, regardless if it was being charged or not. Every time after that I had to hard reboot (press power button for longer than 8-10 seconds). This would happen on stock 4.4, stock 4.3, CM 10.2, stock kernel, francoKernel. Even on fresh install with no apps installed.
When I left it connected to USB with ADB logging, I could see that the last thing in the log before it hangs was usually something related to libEGL, GL, GL Operation, glDrawArrays.
For example:
Code:
11-23 13:08:34.250 W/System.err( 1012): java.lang.RuntimeException: GL Operation 'glDrawArrays' caused error 505!
(I found somewhere that this is GL Out of Memory error)
Code:
11-23 13:08:38.955 W/ ( 1012): GLES-MALI OOM error: execution failed (gles_fbp_read_pixels at vendor/arm/mali6xx/gles/src/fb/mali_gles_fb_read_pixels.c:693)
Code:
12-15 21:06:40.813 D/libEGL (16985): glGetIntegerv(GL_FRAMEBUFFER_BINDING_OES, (GLint *) 0x426e3be0);
12-15 21:06:40.813 D/libEGL (16985): glBindFramebuffer(GL_FRAMEBUFFER_OES, 2);
12-15 21:06:40.813 D/libEGL (16985): glGetError();
This is the latest log on CM 10.2 with OpenGL tracing in logcat (just the last part):
http://pastebin.com/6rpmfYca
The full log:
http://www61.zippyshare.com/v/5060489/file.html
This is some previous log:
http://pastebin.com/J9dNBBZS
What is causing this? What app/service is it dying in (there is MovieMaker in the log before the issue happens, but WTH?)? How can I debug this further?
Click to expand...
Click to collapse
I can't offer a solution, but I have the same problem. Mine started when I moved to KitKat. I thought the problem was occurring when on a charger and the charge level reached FULL. But I also have the OLD MovieMaker app loaded. I am going to uninstall it and see if that has any effect.
Have you had any luck tracking down the problem?
rlrbjr said:
I can't offer a solution, but I have the same problem. Mine started when I moved to KitKat. I thought the problem was occurring when on a charger and the charge level reached FULL. But I also have the OLD MovieMaker app loaded. I am going to uninstall it and see if that has any effect.
Have you had any luck tracking down the problem?
Click to expand...
Click to collapse
Hi!
I was able to find some old threads about this aptly named Sleep of Death issue, here for example.
Unfortunately no conclusion, most people seem to return their devices :/
Now I think this is indeed some massive memory leak, becasue I was able to see ADB logs with all processes stopping, and the screen blinking with lock screen once when this happened.
As for MovieMaker, this might be misleading - I froze it in TitaniumBackup but the issue still exists.
My plan now is to write a script that would run
Code:
adb shell dumpsys meminfo
every couple seconds/minutes and plot the memory usage until the issue strikes.
I will report here if I find anything.
Best regards,
anarion
I uninstalled Movie Editor (rather than freezing it) and my system is much better (so far). I have not had a single lockup. It still too early to know if this is a god long term solution but I will keep you informed.
Sent from my Nexus 10 using Tapatalk 4
Hi Guys,
Has anyone tried the encryption feature found in Security settings? I'm using a recent nightly CM11 from Quarx/Blechd0se (Thanks, brilliant work!) quite stably for days now, but fail to make the encrypt phone function work...
When fully charged and USB powered, which are requirements, the successive encrypt phone buttons end up on a green android picture. This screen misses text and a progress bar which should normally appear on top of the screen, as seen on some screenshots. Even left for several hours, nothing progresses and a simple press on back button cancels action immediately which proves nothing has been encrypted in the meanwhile.
Took a Catlog and the only interesting message is the following:
Code:
01-02 01:34:23.732 E/Cryptfs ( 1197): Cannot get size of block device
In case it helps, find attached the output of mount command : View attachment mnt.txt
Could you have a look / help me out? (add to bug list if it applies)
In fact, for me, this function needs to be activated for connecting to my professional mails ...
Thanks in advance! :good:
Cheers
Further tested...
Hello all,
Just some more info... I flashed back to Quarx' CM9 and quickly tested once more the encryption and face the same problem but I didn't catlog, neither checked the mounts... Then I flashed Epsylon3's CM9 and quickly checked with the same result too...
But then I checked at catlog and now I get another type of error... Which is interesting and maybe promising as I already read some posts about this message...
Code:
04-14 21:11:13.101 E/Cryptfs ( 2219): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
Problem seems to be more general than only Quarx/Blechd0se's CM11 but a friend uses a CM9 flavor on a Samsung Galaxy S and has encrypted the phone successfully...
All in all it's linked with the filesystem (block device or not), how it is formated (yaffs/ext3/ext4) and mounted (mount/mount_all)...
Some interesting reading on jira.cyanogenmod.org/browse/CYAN-87 (not linked, I don't have 10 posts yet)...
Hope to find, test and come back with some more info soon...:fingers-crossed:
Cheers!
I recently restarted my phone after the battery died, and now every time it gets to the lock screen, I can unlock it, and it'll function seemingly fine for up to 30 seconds (usually more like 5-10), but then it automatically restarts.
The only apps I've installed since last restarting, maybe a week ago, are FolderSync and Tasker. It's possible I haven't restarted since installing AnyConnect and OpenConnect, although I'm pretty sure I did restart at least once after those, and haven't touched them since. OpenConnect did have some permissions fix item in the settings menu that would supposedly attempt to get it to work on devices where it wouldn't (it didn't work on mine), so that has me suspicious, especially since it seems sometimes these boot loops are related to permissions errors.
I'm running Philz recovery, which I can get into fine. I read about a permissions fix in some recoveries, but Philz (at least mine) doesn't seem to have it.
When the battery died, I was connected to a bluetooth speaker, playing music with Spotify. Not sure if something could have gotten corrupted having it die while the bluetooth connection was active.
It's a T-Mobile S5 and the ROM I'm running XtreSoLite 2.1 Lollipop XXU1BOC7.
Any suggestions for things to check to get it to stop restarting? If I have to wipe it, are there any ways to sort of partially wipe it? Are there a series of things I can try that would go from least extreme (not losing anything) to most extreme (fully re-flashing)? I have been able to open an adb shell and pull everything from internal storage that I don't want to lose.
Thanks in advance for any help.
Boot into recovery and clear the CACHES
Boot back up, see if that fixes it, if it died while busy, it might just be a corrupted cache
Don't factory reset while you are running that ROM, it is a deadly bricking ROM because it doesn't allow you to disable Reactivation Lock, if you missed the setting during first boot, it's now permanently enabled and will lock you out of your phone if you try to flash something else, or reset
I tried "wipe cache partition" and "wipe dalvik cache" with no luck. After dalvik, it even did the "optimizing x out of y android apps" thing at startup, getting my hopes up that at least *something* was happening so it'd possibly get fixed.
So no factory reset... is there any way to then to get the ROM back to its original, freshly-installed, state? I guess the way to do it would be to install the ROM again with the zip file in recovery.
Are there any system logs that show what's happening at startup? There's gotta be a way to figure out what step it's getting to that causes it to restart... there's definitely a consistent set of things that happen before it does it. Lock screen comes up, the "no sim installed" notification comes up. There's an "unable to update automatically" message pop up (not in the notification panel), which I think is from the clock being unable to update from the internet from having no network connection. Usually happens right after that. Wish I could get a task manager installed that could view which processes/services are running.
Use an adb log/shell, just get adb working and then you can have it so adb sits there waiting for the device and starts spewing logs as soon as it can until it looses the device.
Sent from my SAMSUNG-SM-G900A using Tapatalk
Having trouble getting the logs. I boot into recovery, connect via USB, then on my PC, enter "adb locat".
I got "/sbin/sh: exec: line 1: logcat: not found"
After a quick search, found that I should go into the "Mounts and Storage" menu in recovery, and mount /system. Did that, now I got some output:
Code:
--------- beginning of system
I/Vold ( 203): Vold 2.1 (the revenge) firing up
D/Vold ( 203): Volume sdcard1 state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 203): Volume usbdisk state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 203): Volume sdcard1 state changing 0 (No-Media) -> 2 (Pending)
D/DirectVolume( 203): DirectVolume::handlePartitionAdded -> MAJOR 179, MINOR 65, PARTN 1
D/Vold ( 203): Volume sdcard1 state changing 2 (Pending) -> 1 (Idle-Unmounted)
--------- beginning of main
I/ARMAssembler( 201): generated scanline__00000077:03545402_00000A02_00000000 [ 31 ipp] (53 ins) at [0xb3acc1f0:0xb3acc2c4] in 72552 ns
I/ARMAssembler( 201): generated scanline__00000077:03545402_00000A01_00000000 [ 31 ipp] (52 ins) at [0xb3acc2d0:0xb3acc3a0] in 45208 ns
I/ARMAssembler( 201): generated scanline__00000077:03545402_00000A08_00000000 [ 31 ipp] (53 ins) at [0xb3acc3b0:0xb3acc484] in 38177 ns
I/ARMAssembler( 201): generated scanline__00000077:03545402_00000000_00000000 [ 30 ipp] (44 ins) at [0xb3acc490:0xb3acc540] in 36562 ns
I/Vold ( 203): /dev/block/vold/179:65 being considered for volume sdcard1
D/Vold ( 203): Volume sdcard1 state changing 1 (Idle-Unmounted) -> 3 (Checking)
D/Vold ( 203): Trying to get filesystem type for /dev/block/vold/179:65
I/fsck_msdos( 203): ** /dev/block/vold/179:65
D/Vold ( 203): Found vfat filesystem on /dev/block/vold/179:65
I/fsck_msdos( 203): ** Phase 1 - Read and Compare FATs
I/fsck_msdos( 203): Attempting to allocate 3747 KB for FAT
I/fsck_msdos( 203): Attempting to allocate 3747 KB for FAT
I/fsck_msdos( 203): ** Phase 2 - Check Cluster Chains
I/fsck_msdos( 203): ** Phase 3 - Checking Directories
I/fsck_msdos( 203): ** Phase 4 - Checking for Lost Files
I/fsck_msdos( 203): 176 files, 3026368 free (749934 clusters)
I/Vold ( 203): Filesystem check completed OK
W/Vold ( 203): blkid failed to identify /dev/block/vold/179:65
D/Vold ( 203): Volume sdcard1 state changing 3 (Checking) -> 4 (Mounted)
I restart the device through the "reboot" menu option in recovery, and the logcat session exits. I retype "adb logcat", and then I get
"- waiting for device -"
Seems promising, like once the OS on the device starts loading I might start getting log messages, but nothing happens, and it just sits there. Device starts up, then restarts like it's been doing.
Anything obvious I'm doing wrong regarding getting a realtime output of the log? Anything of interest in the log output that did get while it was in recovery? That "blkid failed to identify /dev/block/vold/179:65" could be something, couldn't it?
While in recovery, USB connected, after mounting /system so logcat works, started logcat. Then mounted /data. Then mounted /storage/sdcard1. This was the logcat output:
Code:
--------- beginning of system
I/Vold ( 204): Vold 2.1 (the revenge) firing up
D/Vold ( 204): Volume sdcard1 state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 204): Volume usbdisk state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 204): Volume sdcard1 state changing 0 (No-Media) -> 2 (Pending)
D/DirectVolume( 204): DirectVolume::handlePartitionAdded -> MAJOR 179, MINOR 65, PARTN 1
D/Vold ( 204): Volume sdcard1 state changing 2 (Pending) -> 1 (Idle-Unmounted)
--------- beginning of main
I/ARMAssembler( 202): generated scanline__00000077:03545402_00000A02_00000000 [ 31 ipp] (53 ins) at [0xb3aa01f0:0xb3aa02c4] in 70573 ns
I/ARMAssembler( 202): generated scanline__00000077:03545402_00000A01_00000000 [ 31 ipp] (52 ins) at [0xb3aa02d0:0xb3aa03a0] in 46563 ns
I/ARMAssembler( 202): generated scanline__00000077:03545402_00000A08_00000000 [ 31 ipp] (53 ins) at [0xb3aa03b0:0xb3aa0484] in 37604 ns
I/ARMAssembler( 202): generated scanline__00000077:03545402_00000000_00000000 [ 30 ipp] (44 ins) at [0xb3aa0490:0xb3aa0540] in 36042 ns
I/Vold ( 204): /dev/block/vold/179:65 being considered for volume sdcard1
D/Vold ( 204): Volume sdcard1 state changing 1 (Idle-Unmounted) -> 3 (Checking)
D/Vold ( 204): Trying to get filesystem type for /dev/block/vold/179:65
D/Vold ( 204): Found vfat filesystem on /dev/block/vold/179:65
I/fsck_msdos( 204): ** /dev/block/vold/179:65
I/fsck_msdos( 204): ** Phase 1 - Read and Compare FATs
I/fsck_msdos( 204): Attempting to allocate 3747 KB for FAT
I/fsck_msdos( 204): Attempting to allocate 3747 KB for FAT
I/fsck_msdos( 204): ** Phase 2 - Check Cluster Chains
I/fsck_msdos( 204): ** Phase 3 - Checking Directories
I/fsck_msdos( 204): ** Phase 4 - Checking for Lost Files
I/fsck_msdos( 204): 176 files, 3026368 free (749934 clusters)
I/Vold ( 204): Filesystem check completed OK
D/Vold ( 204): blkid identified as /dev/block/vold/179:65: UUID="9016-4EF8" TYPE="vfat"
D/Vold ( 204): Volume sdcard1 state changing 3 (Checking) -> 4 (Mounted)
The /dev/block/vold/179:65 were written after mounting /storage/sdcard1. So I wonder if that "blkid failed to identify /dev/block/vold/179:65" message indicates some issue with my internal storage. Could it somehow be unavailable once the OS starts up?
Brent212 said:
I tried "wipe cache partition" and "wipe dalvik cache" with no luck. After dalvik, it even did the "optimizing x out of y android apps" thing at startup, getting my hopes up that at least *something* was happening so it'd possibly get fixed.
So no factory reset... is there any way to then to get the ROM back to its original, freshly-installed, state? I guess the way to do it would be to install the ROM again with the zip file in recovery.
Are there any system logs that show what's happening at startup? There's gotta be a way to figure out what step it's getting to that causes it to restart... there's definitely a consistent set of things that happen before it does it. Lock screen comes up, the "no sim installed" notification comes up. There's an "unable to update automatically" message pop up (not in the notification panel), which I think is from the clock being unable to update from the internet from having no network connection. Usually happens right after that. Wish I could get a task manager installed that could view which processes/services are running.
Click to expand...
Click to collapse
No, don't flash anything custom, not even the same ROM
That ROMs links were removed from XDA because of this problem, where did you get it from?
Go into settings, hit the magnifying glass at the top, and search for "Reactivation Lock" - it's possible you might find it that way, and if you do, disable it immediately
Once it's turned off, you can factory reset, or flash another ROM
I have a vague memory of someone else finding it that way
*Detection* said:
No, don't flash anything custom, not even the same ROM
That ROMs links were removed from XDA because of this problem, where did you get it from?
Go into settings, hit the magnifying glass at the top, and search for "Reactivation Lock" - it's possible you might find it that way, and if you do, disable it immediately
Once it's turned off, you can factory reset, or flash another ROM
I have a vague memory of someone else finding it that way
Click to expand...
Click to collapse
Wow, so reactivation lock is enabled by default for this ROM, but is it possible to set it to disabled at some point during the install process, and if so, is there a way I can see if I set it to disabled?
I got the ROM almost a year ago, so it doesn't look like this issue was known at that point, at least in the ROM's thread.
I'm running 2.1. Is it possible the reactivation lock wasn't an issue with that version (latest is 2.2, although looks like there are unofficial versions 2.3 and 2.4)?
Would I be able to re-install the ROM from zip file in recovery, then at first boot follow this procedure? -- http://myandroid.nl/reactivation-lock-solution-for-galaxy-s5/
Or actually, upon looking at that, can I just go into settings-->security and uncheck "Reactivation Lock"? It sometimes gives me up to 30 secs before restarting, so I could probably manage that.
If the setting is there, disable it and you're golden
The problem was with the latest version (2.2 I think), the only setting was during 1st boot
Possibly able to find using the search function in settings too according to a member here but not 100% on that
I was finally able to get some potentially useful logs.
Not sure if it was all necessary, but I enabled developer options by doing the "tap build number 7 times" thing, then enabled USB debugging, which I thought I've always had on for every phone/ROM I've had, but must not have ever done it for this one. Then I had to either plug in the USB cord after the phone started booting up, or select the USB connection options notification (not sure which of those actions did it), and I was suddenly able to maintain an adb shell while the phone continuously booted up and restarted.
At first, trying to use logcat, I'd get a "Unable to open log device 'main'" error message. So I had to comment out the "rm /dev/log/main" line from /system/etc/init.d/logcat. Which I was only able to do which the phone in recovery mode. However, in recovery mode, I didn't have vi in my path, but eventually found it under /system/xbin (just putting that here in case it helps anyone in the future).
So finally logcat was working while the boot loop was in progress, and I got the attached logs. The first one was taken starting from right after the phone restarted. It went until it got to the lock screen, then for some reason my adb session would get dropped, even though I could immediately reconnect. The second file is from right after that happened to just after the restart happened again.
Any obvious messages that explain why it's restarting?
"FATAL EXCEPTION IN SYSTEM PROCESS: WifiStateMachine" doesn't look good.
"FATAL EXCEPTION: UlrDispSvcFastTask" also... I see here that enabling "keep awake" permission for Play services fixed that, so I'll try to figure out how to do that.
There are a lot of "Unknown permission" messages.
Lot of "RuntimeException: android.os.DeadObjectException" and "RuntimeException: Package manager has died" errors. Maybe some/all of these are caused by the system shutting down and aren't actually problematic.
Also looks like some warnings/errors could be related to lack of any network connectivity (no SIM installed and I have wifi off).
Thanks for any help deciphering this stuff.
I'm not into the coding side of Android, so it would be the blind leading the blind if we went down that route
--Try safe mode--
Turn on safe mode
Turn the device off.
Press and hold the Power key.
When 'Samsung Galaxy S5' appears on the screen, release the Power key.
Immediately after releasing the Power key, press and hold the Volume down key.
Continue to hold the Volume down key until the device finishes restarting.
Thanks for the suggestion, but that was actually the very first thing I tried. I was totally confident it *must* be an issue with one of the two apps I installed since last rebooting, so all I'd have to do is start in safemode, remove those apps, and it'd be fixed, right? Man I wish it had been that easy.
Is it even possible to set reactivation lock to disabled at some point during the ROM install process, or is it just forcefully enabled? Seems like a lot of people must not be having this issue, so they must have been able to disable it at some point, unless it's just that all those people haven't had to reset, reinstall, or install a new ROM. Really wish I could see if it's enabled or disabled for me, as I can't see myself enabling it if given the choice. If that question came up during the install, I'm pretty sure I'd have looked up what "reactivation lock" was and chosen to disable it.
Didn't have any luck finding a way to enable "keep awake" permission for Play services. At least, under settings-->Application Manager-->Google Play Services, I see a bunch of descriptions for permissions, but no way to enable/disable them. And I haven't even been able to find one that looks like it'd be the "keep awake" permission.
Looking at t-mobile's page on reactivation lock, they have directions for enabling/disabling it: https://support.t-mobile.com/docs/DOC-21136
Logging into http://findmymobile.samsung.com/, my account shows that no devices are associated with it. Would that indicate that I haven't had reactivation lock enabled before, or is this completely irrelevant?
Boot into download mode and check if it tells you Reactivation Lock is enabled (Volume Down & Home & Power)
Problem is, if you flash that ROM again, to initiate setup, you'll get locked out most likely
There is a solution, which works for 'most' people, but lately it's been less and less effective, and it means risking locking yourself out to try it
Flashing a stock KitKat ROM, and logging into your Samsung / Google accounts on first boot, allows disabling of reactivation lock
Problem would only start, if ODIN fails to flash that KitKat ROM
Like I say, this usually works, but with newer revisions of the S5, it's been failing for a few people lately
You say you have had this ROM installed for a year, and I got my S5 around a year ago, and I can flash with ODIN fine, so you will likely be OK to go for it
Other alternative would be to remove the apps manually from recovery or ADB via PC USB
*Detection* said:
Boot into download mode and check if it tells you Reactivation Lock is enabled (Volume Down & Home & Power)
Click to expand...
Click to collapse
Okay, I went into download mode and it's not giving me any sort of info that blatantly tells me whether or not RL is enabled/disabled. This is what I get:
Code:
ODIN MODE
PRODUCT NAME: SM-G900T
CURRENT BINARY: Custom
SYSTEM STATUS: Custom
KNOX WARRANTY VOID: 0x1 (4)
QUALCOMM SECUREBOOT: ENABLE (CSB)
RP SWREV: S1, T1, R1, A1, P1
SECURE DOWNLOAD : ENABLE
UDC START
Then there's the message on the middle of the screen with the green android logo saying "Downloading... Do not turn off target".
*Detection* said:
Like I say, this usually works, but with newer revisions of the S5, it's been failing for a few people lately
You say you have had this ROM installed for a year, and I got my S5 around a year ago, and I can flash with ODIN fine, so you will likely be OK to go for it
Click to expand...
Click to collapse
I got it almost two years ago, pretty much right when the S5 came out, so it's probably the first version.
*Detection* said:
Other alternative would be to remove the apps manually from recovery or ADB via PC USB
Click to expand...
Click to collapse
How would I go about doing that? In recovery I can't find any option that looks related to app removal, and I can't even really browse+delete files from there (there is an "aroma file manager" item, which fails because it says it's not installed). From ADB I could delete files, but I'm not sure what all I'd need to delete in order to fully remove an app. Plus, I've already uninstalled the apps that should, *in theory*, be the only possible offenders, just through regular means (app drawer, drag app icon to "uninstall") during the small window of time I get after each boot.
I was expecting a screen showing this
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
For removing the apps, you'd need to navigate to /data/app and delete any packages you think could be the offenders
That should be enough to kill them from starting up with Android
but it could also be a system app, /system/app
Other location could be /data/data
If the phone is 2 years old, I'd say you have a very good chance of just flashing a KitKat ROM and then boot into recovery > factory reset > log in with your Samsung & Google accounts and disable reactivation lock (If it is enabled, which I assume it will be)
Looking at the thread, and in particular this guy's post, it sounds like the reactivation lock issue might have been introduced in 2.2. Since I'm on 2.1, maybe I can still re-install 2.1 without RL-related problems. Seems like people with the RL enabled can't even boot into recovery. I've been living in recovery.
Even if I can't, and I get locked out after re-installing the ROM, I can still go back and flash a KK ROM with Odin, disable the RL setting, which is what I'd have to do anyway, right? Is there any disadvantage to trying to install the ROM directly to see if I have RL disabled?
Give it a shot, phone is not usable as it is
I went ahead and installed the original version I was on, 2.1, but tried selecting the non-full wipe option in an attempt to keep my apps/settings. Basically did nothing. Phone still restarted after booting. Then I did a full wipe+install, got through the startup prompts, including the "do you want to enable reactivation lock?", which I unselected (and am now positive I unselected the first time as well). Google/Android gives an option to restore apps/settings from some backup done through your google account, so I selected a few that I knew I'd need right away and/or have extensive setup.
Unfortunately, I think that last step was a bad one, because I still got the auto restarts. So I did the whole thing again, and instead selected the option that's along the lines of "set this up as a new device". Everything worked fine after that. Phone boots up, and amazingly, stays on.
I even went ahead and upgraded to 2.2, since I figured, if I'm going to start from ground zero, I might as well use a newer version of the ROM, mainly because I'm hoping I can use the KToonsez kernal, which I remember seemed to cause my phone to be unstable/buggy when I first installed 2.1 almost a year ago.