Help Ally re-starting on its own???

[biggdave92]

I've had the ally about 2 weeks now and about once a day it will re-start on its own. it sucks because sometimes i'll be in the middle of something. anybody else have this issue?

 

[marcus531]

Your problem sounds like something replacement-worthy

The restart-problem that I see consistently is the tendency to have browser-page-reloads when I switch from browser to anything-else and back.

I have become used to editing a forum-post, going to look something up, coming back (and seeing my edited-text-box briefly before a page-reload returns me to a blank posting-box.

I now never exit a forum-posting page without doing a select-all and copy.

Additionally, I keep having browser crashes, even when i'm foregrounded and actively typing.

(Brutal-type closedown that never records history data, not a OS-freeing-background-processes type ... I'm working out that it seems to be page-specific and probably some kind of javascript->crash bug.)

 

[marcus531]

I just had a random reboot that I actually watched ...

The interesting question is how many reboots might I have not seen and assumed browser-crash-when-I-wasn't-looking when it was a full reboot, since the browser is the only really state-maintaining program that I have had consistently awake (I usually close Connectbot sessions out).

Current state at time of reboot:

Driving, Ally in magnetized car-dock;

in navigation-program (so GPS was on), but not speaking at that moment;

not running any multimedia apps like the mp3-player or Pandora;

BT was off, so not blue-tooth-synced to any headset or hands-free device at that time;

Wifi was passively on but not locked on to anything;

"Drive Safe.ly" was auto-running (upon car-docked) but no message had arrived or did in the 20 minutes after the reboot (so none arrived+caused-reboot+was-not-ack'd+retried-later)

 

[yellowfrizbee]

Marcus! Awesome to see you on THESE forums. Check the "Want root?" thread


Such a shame. My Ally ran so smooth and without any issues the 1st week, but come 3rd week, I am getting reboots and the "50% bug".

 

[biggdave92]

i took mine back yesterday and got a new ally. it did fine until lunchtime today. I'm thinking' droid.

 

[marcus531]

On a similar note, I had an *interesting* (chinese curse version) experience ... while taking pictures of BIOS/CMOS settings screens for new hardware (to compare every BIOS/CMOS setting screen before and after a BIOS upgrade for new firewall hardware) ...

My camera locked ON ... it still was fully active, but all inputs were stuck, so as I moved the Ally around, the screen image moved as you'd expect a camera to do, but no button and none of my shortcut buttons managed to exit the camera app ... after intentionally trying every imaginable thing, I had to pull the battery ... most annoying.

And The next day, continuing to do more of the same kind of thing, I got "Capture fail" and that was only cured by rebooting the Ally ... but at least the inputs kept working to do so.

YF: wilco ... I actually have a set of relevant links etc for other LG devices that I've gathered up to post over in that forum, just been caught up in boss-requests for a few days.

 

[biggdave92]

well, i returned the ally today and picked up a droid for 48.00. so far so good.

 

[jreed2560]

I think you will be much much happier with the droid. I can't for the life of me understand why LG put the dated arm 11 processor in the ally. With there reputation for making outstanding keyboards, this phone could have really filled a void on verizon's network (atleast until the droid2 comes out). Fail LG fail!

 

[marcus531]

I had another reboot incident, but I'm pretty sure I know enough about what was going on to give *some* useful answers ...

I had a text message arrive while
A: in car mode (running with "car dock" not native "car mode" app)
B: which launches Drive-Safe.ly, to speak text messages and emails
C: I launched Pandora from Car-Dock and started Pandora playing via 3G
D: I then went back to Car-Dock and launched a shortcut to Navigate to my workplace

When the text message arrived, Handcent SMS popped up with the quick-message-box ... but Drive-Safe.ly failed to speak ... approx 15-30 seconds later the Ally rebooted

Upon waking up, the Ally immediately recognized that it was in the car cradle and re-launched Drive-Safe.ly, which immediately spoke the text message that had not been spoken seconds earlier.

I then re-launched Pandora and my navigation-to-work shortcut (yes I know how to get there, it's my daily commute, but this way I see traffic and time-left / delay amount)

Then about 1 minute later, another text message arrived and again, Handcent popped up, Drive-Safely failed to speak, 15-30 sec later the Ally rebooted, and Drive-safe.ly again spoke the message, I re-launched everything and drove to work without further crashes.

BTW: I will set a cron-job to auto-send myself several text messages during my return commute to try to replicate this.

What I believe is happening is what in Unix terms is called a "watchdog timer" event:

The motherboard / BIOS has a (memory-location / interrupt / IRQ / etc) spot that it watches for "event-start" ... if it reaches N seconds (15,30,60,whatever) and the event is not marked as completed, the hardware assumes (often incorrectly) that the OS / software has hung / frozen and died, therefore needs to be rebooted. The BIOS then reboots the device.

I have seen this when my tests at work cause a firewall to be so overburdened with decoding encrypted traffic and intentional other induced loads that the OS fails to come-up-for-air long enough to tickle the watchdog-timer i'm-alive_flag and the BIOS reboots the firewall.

In the Ally's case, I believe that the problem is not a peak-load watchdog event but an operation-incomplete watchdog event, namely Pandora held onto the CPU / audio system in a way that Handcent managed to send my sonar-ping alert-tone but the more complicated / total-takeover of Drive-safe.ly failed to get a free-state / lock-state on the audio-system and waited and waited and waited ...

But since Drive-Safe-ly had first touched / initiated some form of multimedia-event-waiting-to-launch state, the OS / BIOS considered this wait-wait-wait to be a sign of total-lockup, not 2 apps competing for the same resource ... Android never considered an app like Pandora would do the cold-dead-hands-thing on the audio-system, since Pandora _should_ have behaved more nicely and surrendered temporary control when Drive-Safe.ly requested it, assuming that Drive-Safe.ly did it's request in the proper manner. Conversely, Drive-Safe.ly may have made their request-for-audio-lock in an improper way, , i.e. in a way that Pandora might not have been even supposed to listen for. I have no knowledge of which side of this conversation mismanaged the signaling, but the watchdog reboot paradigm makes the most sense until we get better information.

 

[travel_rob]

Wow Marcus, I had been trying for two weeks to get navigation to function on my drive to or from work, and had been totally unsuccessful. I placed the blame on a faulty GPS sensor, battery temperature, Verizon call dropping, etc. - anything but messaging.

When the phone rebooted I didn't get any text messages, but I did have K-9 Mail running, and it was getting push messages from my office coming in. In checking the email message timestamps, there always seemed to be one that came in about the time the phone rebooted.

This morning I killed off the K-9 process, turned off GMail notification, and started up the Navigation app. I made it all the way into work running the Navigation app without a reboot for the first time!

Since my reboots did not involve Drive-Safe.ly, Pandora, or SMS - but I did have on Bluetooth (but did not get any calls) - I think you can rule Pandora and Drive-Safe.ly out as contributors. I also don't think a dormant Bluetooth connection is a problem (will test to see if the Ally reboots when a call comes in and report back).

Thanks for your post, otherwise I would have continued to look in the wrong place and would have eventually given up on the whole navigation app.

 

[marcus531]

ARGH ... reconstructing a long and perfectly-worded post from amnesiac-memory because the Android default browser reloads web-pages when you switch applications ... my Ally time-out powered-off 10+ paragraphs into a long post and reloaded this page (clearing the posting-box) when I woke it up (I may have to disable Executive-Assistant, the on-wake-up info page if this becomes a nuisance, but I wish I could disable auto-reloads in the browser).

I apologize if this second attempt to answer you skips over anything ...

=-=-=-=-=-=-=

Watchdog-reboot-timers are a good OS design on expected-use appliances like DVRs and phones, especially where the system-programmers know what chunks of code will have access and rights to "lock" key system resources and consider any N-second delay to be a malfunction or extremely unusual condition.

Watchdogs are dangerous when users have the capability to install non-manufacturer software onto their system / PC, especially when that software directly interacts with system interrupts and resources and the user may not mind pauses (and our installations of Windows do have so very many pauses).

But by definition, smartphones are expected-use-appliances that users can install software to to do important things like dealing with time-critical message streams.

Watchdog reboots in our case are similar to:
1: user-land programs are not supposed to rigidly lock key system resources
1a: and probably should not set maximum-priority+watchdog status
2: but Drive-Safe.ly or K-9 etc are being triggered by an incoming message alert
3: they launch but for some reason are prevented from engaging their pop-up box or other mandatory action because something else was holding a key system resource locked and failed to renew / refresh the lock in time for this watchdog timeout (renewal would have put the program back at the tail of the queue for resource X, which 99% of the time would be empty and nothing would change, but it allows the Android/Linux kernel to process the queue in case something else wants to get a word in edgewise.)
4: because a high-priority incoming message was not allowed to progress through the user-defined procedure-tree, (note the conflict of paradigms there), the watchdog reboots the Android-device under the (incorrect/complicated) assumption that the system was resource locked (which is actually true from a certain point of view).

=-=-=

It is possible that my reboots were from an email-triggered source also, since I only noted message-arrived,music-continued,reboot,Drive-Safe.ly-speaks ...

DS speaks both email and text messages, but when I get email on my commute, it is invariably from my co-workers, and I have a strange email-system in place that sends me a SMS message anytime a co-worker emails my work address, and if I am more than an hour idle on my unix system, ALSO forwards that email to my phone-monitored-gmail-account.

I am certain that _some_ messages did not cause crashes (I get frequent SMS messages via AOL-AIM from my server+network-monitoring-systems), but uncertain which ones did not cause crashes between the human-origin SMS+gmail and robot-origin SMS-only. I have a nagging (amnesiac) memory that just after the 3-days-ago crash, DS spoke from gmail but not the SMS that accompanied it.

I'll trigger this intentionally for my next commute and observe how things happen.

In your case, I would suggest that you
1: set up a Linux at-job or Windows scheduler job to email you something during a known time window of your commute
2: just before that commute, turn ON everything you normally would, except
3: turn OFF the K-9 message-arrival pop-up window notification.

From the Fedora-11 manpage for the at command ...
For example, to run a job at 4pm three days from now, you would do at 4pm + 3 days, to run a job at 10:00am on July 31, you would do at 10am Jul 31 and to run a job at 1am tomorrow, you would do at 1am tomorrow.

The program will then put up a "at> " prompt and wait for you to enter commands until you give it an end-of-file trigger (control-d ... generally on a line by itself)

... so if your commute is 0800 to 0830, you would do the following

MyLinuxSystemPrompt$ at 8:15 Jul 6
at> echo this is a test | mail -s "Ally reboot test" MyEmailAddr@gmail.com
at> ^d
job 1 at 2010-07-06 08:15

Although you should test this in non-commute hours also just to confirm that your Linux system can in fact send / deliver email to somewhere that can deliver it to your gmail account _in_a_timely_manner_. My home and work Linux / FreeBSD systems all deliver email to my gmail account in under a minute, but you should always test this (mail queues can be set to flush instantly or every 15 / 30 / 60 minutes or arbitrary time values ... alternatively, you may have firewalls in the way stopping you from direct-delivery to external email servers)

In Windows, to open Scheduled Tasks, click Start, click All Programs, point to Accessories, point to System Tools, and then click Scheduled Tasks.

Since the scheduled-tasks wizard wants to have you run a program, you'll have to have something set up ... I suspect that sending email from a batch-file is asking far too much from a paradigm that predates the web or GUIs, but MicroSoft has a wonderful system called "PowerShell" which will run on XP or later (I am uncertain about Win2000 or earlier, but you'd assumedly have very good knowledgable reasons to be on anything that old now). I believe that there are thousands of available powershell script examples around that will show you how to send email just by launching a powershell script ... so launching it from the scheduled-tasks-wizard will do so just as well and you can schedule your test.

As an aside, do you have anything else (like Executive-Assistant) installed that may try to "help" with email notifications ... their help may be counter-productive.

 

[travel_rob]

Thanks for the suggestions. When I'm back in the office on Tuesday I will setup a serious of events staggered over my estimated travel time, and see if I can delibertly create a reboot. I've got a spare Linux VM I can hijack to send me office emails, GMail emails, SMS, and generate phones calls to me on my ride home. I'll let you know which one (or more) of these items tripps up the navigation app.

I've noticed that the navigation app makes the other functions of the phone less responsive, so I follow the logic on how an "event" like a message notification could take just a bit too long to process. If the Navigation program happens to be running as a system process at a highter proirity than the userspace K-9 Mail, the Navigation app may never yield enough cycles to process the waiting notifications.

If any of this is speculation is even close to what is going on in the Ally, probably only a faster CPU is going to solve the issue. I wonder if the map data could somehow be cached locally on the storage card (and not make the phone pull it down in real-time) would lessen the stress on the system? Maybe FroYo will bring us some relief

 

[travel_rob]

(Sorry for the delay in posting, had something unexpected come up that consumed all of my time for the last couple of days.)

Looks like the reboot issue may be more complicated than just messaging - I'm noticing the phone is running very hot at the time it reboots (battery is reading 96+F after a restart, and the phone is VERY warm to handle). I haven't noticed the phone heating up at other times, only when the Navigation application running. Could Navigation (using the GPS) put that much of a strain on the processor, or create that much drain on the battery that the phone is cooking itself into a reboot?

 

[CREVZ21]

My wife just got an Ally last night. As we were charging it it had to have rebooted more that a dozen time just sitting on the charger while we were sleeping ( I heard it at least 12 times). Any ideas?

 

[jreed2560]

I would take it back. Nothing ireally going to fix that

 

[netizenmt]

Actually mine was doing that when I first got it. Once I visited here and got brave enough to root and play around with the custom roms, those problems became a thing of the past. I -never- have random reboots now!

I'm currently beta testing Raptor v0.2 with the latest kernel from drelllisdee. My phone personally didn't do well with Velocity, but it tends to be a phone by phone thing apparently.

Taking it back won't help if you get another Ally. Almost all Allys do it. Rooting and a custom ROM will more than likely fix you right up. And if you still aren't happy, you can always put it back to stock and return it within the 30 days.

 

[jinwons]

My wife just got an Ally last night. As we were charging it it had to have rebooted more that a dozen time just sitting on the charger while we were sleeping ( I heard it at least 12 times). Any ideas?

If you install many apps into its small memory and push it hard on web surfing, games, videos then Ally can sometimes freeze or reboot. But fresh new one rebooting on its own is very unlikely unless it's defective one.

Are you sure it was really rebooting by itself? It could have been email/text notification sound/vibration.

 

[CREVZ21]

If you install many apps into its small memory and push it hard on web surfing, games, videos then Ally can sometimes freeze or reboot. But fresh new one rebooting on its own is very unlikely unless it's defective one.

Are you sure it was really rebooting by itself? It could have been email/text notification sound/vibration.

No it was definitely rebooting it self. I was looking over every time I heard it. Hardly slept the night. It was showing the Verizon logo and saying android then it would prepare the SD card. Just as when you first boot the phone.

I did do a factory reset this morning, seemed to clear it all up my wife was saying at 10 that it hadn't done it since I left for work at 6:30. So I'm thinking it was an app I had put on it last night that didn't agree with the phone. So we are going to install them one by one and see what the culprit was.

As far as rooting, I have a Droid Incredible my self and have it rooted for my wireless tether. Is wireless tether available on the Ally haven't seen anything about it yet but I also haven't looked deep into it.

 

[CREVZ21]

Update. Started up again Tuesday night when we went to bed. Last night charged in the kitchen, so we wouldn't hear it. Definitely restarted again this morning when I woke up. Went back to Best Buy and got a new one. Hopefully we won't have the issue again tonight.

 

[CREVZ21]

Update again. 2nd Phone did the same thing. Got a completly different phone not to impressed with LG and Android phones now.

 

[jinwons]

Sorry to see your trouble. I have no idea what's wrong in your Ally. Never had that problem in my Ally. Unless it's pushed hard on video streaming, games, there is no reason it would reboot on its own.

 

[netizenmt]

My Ally did that to me as well when I first got it. Best thing I ever did was root it and blow the whole thing off, then installed AmonRa Recovery and Raptor v0.1. It's run perfectly ever since with rarely a reboot or FC or Kernel Panic.

Seriously, I would look through the forum section All Things Root for the Ally and consider modding your phone. You will be so much happier.