ice cream sandwich bug on a500

[Mrhelper]

What a thorough job of confirming the results. Remarkable scientific method. It's great to see a master at work.

One final quick question though, if you don't mind. What about cache cleaners? Are they ok to use often? I'm running 1-Tap Clean Cache a few times a day to free up memory.

I put "cache cleaners" in a similar category. Indiscriminantly clearing cache for apps will slow apps down, and in turn the system. The cache is there for a reason, and that is to enhance application performance. Cache is used to keep frequently used data available, so it does not have to be recreated, reread from separate and sometimes numerous individual files, or downloaded from the network each time it is requested. If Android needs the space for something else, it removes the cache. This is handled on an as needed basis to enhance the performance of apps in general. When you forcibly remove cache for certain applications, you circumvent a significant performance enhancer, and in general, slow the system down. The system is slowed because it has to keep repeating work that it already did. Again, when Android needs the space, it has no problem reclaiming it.

Using a cache killer is kind of like waiting for your pond to fill every morning, and then opening the dam to drain it quickly every day when you go home. When you return, you have to wait to fill the pond all over again before you can swim. That wastes resources. If you leave the pond filled, you just dive in.

A lot of these tools just make the user feel good by showing unused resrouces, but actualy impair app performance, and in turn overall system performance. Snake oil.

 

[J515OP]

I understand the questions and sentiment but this is really left over thinking from computers 20 years ago (the 90's and early 00's). It is very common for computer users to fall into the trap of thinking that a low amount of unused RAM is bad, that your system will run slower and that you constantly need to clear caches, etc. Not to start another debate but it is much like the idea that you need to change your motor oil every 3000 miles, ingrained by multiple generations of repetition, when in fact manufacture and technology has improved since the 50's and 60's for both making the engines and the oils. Now most new vehicles call for oil changes in the 7000 mile range or more than double what everybody has become accustomed to. However old habits die hard and the "old wisdom" still prevails in the minds of most.

Back on track it really is the same with "computer devices." It is common to have 512MB of RAM or more (larger than most hard drives 20 years ago) and GBs of data memory which can easily accommodate multiple programs and caches of data. Yet many of us are stuck in the mentality that resources must be "free" to be fast. On top of that the speed of the RAM, multi-threading multi-core chips, faster hard drives (or even flashed based drives such as tablets), dynamic allocations and OS optimizations have all contributed to a state of computing where to have the fastest device you really need to trust the system to run as designed and utilize the full capacity of the resources.

One more example, Microsoft changed the Disk Defrag in Windows Vista so that it would not longer run a preview of the fragmentation and show what the hard drive looked like or show the progress of defragging. They found that people were continuously and unnecessarily defragging their hard drives so they changed the program to a simple text based box that would simply tell you if you needed to defrag or not. If I recall correctly, it would actually tell you a defrag was not necessary and not run one if the threshold wasn't met. People freaked out because they could no longer see their drive, view the progress or even run defrag at will despite there being no need to do so. Microsoft partially gave on this in Windows 7 allowing an analysis scan but only showing a % fragmented and allowing the user to run to defrag if they chose despite having a lower fragmentation threshold than necessary. I have not read reports of the user habits since this change but I believe it did a lot to placate users mentally while at the same time largely weaning them off the heavy defrag routines inspired by the visualizations of the fragmentation process under XP. (Not the original MS source I recall reading but Wikipedia does touch on this http://en.wikipedia.org/wiki/Disk_Defragmenter_(Windows))

For most of us a life time of computer experience has reinforced the idea that free resources = fast machines. It did take some optimization from Android as well which is still an OS in it's infancy. Starting with Gingerbread Google really addressed the performance issues so that they could take advantage of multi-tasking and free the user from thinking about system resources.

Now it is up to us as users to trust the OS and be on the lookout for poorly designed and rouge apps and to work with their developers to correct the apps rather than use system band-aids such as task managers that hide the real issues through indiscriminate cleaning. It is not always an easy mental shift to make but the end result is having a device that runs better since you are addressing the real issues and apps that run better because their developers have better feedback.

 

[frapshake]

I put "cache cleaners" in a similar category. Indiscriminantly clearing cache for apps will slow apps down, and in turn the system...

A lot of these tools just make the user feel good by showing unused resrouces, but actualy impair app performance, and in turn overall system performance. Snake oil.

I see. I figured that would be your answer, and you explained it very well, and it all makes a lot of sense to me. So I will refrain from using my cache cleaners too. I like your analogy of the pond, and your last statement hit the nail on the head for me. Guilty as charged! Thank you.

 

[frapshake]

I understand the questions and sentiment but this is really left over thinking from computers 20 years ago (the 90's and early 00's). It is very common for computer users to fall into the trap of thinking that a low amount of unused RAM is bad that your system will run slower and that you constantly need to clear caches, etc. Not to start another debate but it is much like the idea that you need to change your motor oil every 3000 miles, ingrained by multiple generations of repetition, when in fact manufacture and technology has improved since the 50's and 60's for both making the engines and the oils. Now most new vehicles call for oil changes in the 7000 mile range or more than double what everybody has become accustomed to. However old habits die hard and the "old wisdom" still prevails in the minds of most...

Now it is up to us as users to trust the OS and be on the lookout for poorly designed and rouge apps and to work with their developers to correct the apps rather than use system band-aids such as task managers that hide the real issues through indiscriminate cleaning. It is not always an easy mental shift to make but the end result is having a device that runs better since you are addressing the real issues and apps that run better because their developers have better feedback.

Thanks for this, J5. I have been a "tweaker" of Windows OS since the beginning with Win98, up to Vista. I've never seen an OS build up the amount of junk all over the place that Vista does! I don't know about Win7. Tweaking did become a habit with me and that habit just continued with Android, and I need to just enjoy the tablet and stop trying to fix something that isn't broken. I strongly agree with everything you wrote, and you will not get any debate from me. Your last paragraph sums it up so well and everyone would benefit greatly from the advice.

 

[J515OP]

By all means, have fun tinkering and tweaking. I love to do it myself. You just get better results tweaking and tinkering with the things that make a difference. In your case, your experience with the app killers lead to the ability to isolate and remove a rouge app. The task and cache apps themselves might have been fighting the system but at least you found out how they work and had some fun playing with them and learning about your tablet in general.



JP

 

[iamkoza]

so no news on the screen rotation problem from ACER over the last week?

I figured I might as well complain directly to Acer too, acer support just acknowledged it was a known issue to me.... below is my chat

Vinoth H: Hi, my name is Vinoth H. How may I help you?

Vinoth H: Are we connected?

: Hi, I own an acer a500 iconia tablet. Ever since the ICS update, the auto-rotate function on my tablet has not worked. In searching various forums and other websites many other users have reported this problem as well. I just wanted to report it.

: im speaking about the screen auto-rotating

: from landscape to potrait mode

Vinoth H: I understand that you are experiencing issues with the auto rotate function and would like to report it. Am I correct?

Vinoth H: Are we connected?

: yes

Vinoth H: I will do my best to help you.

: yes, just looking to report this error and perhaps see if others have reported it and if a fix was on the way

Vinoth H: It is a known issue. I will do my best to help you.
Vinoth H: Jeff, may I have the serial number if the computer?

: I'm actually at work, I don't have my tablet with me

Vinoth H: Okay, No problem.

Vinoth H: May I place the chat on hold for 3 minutes while I check the information for you?

ok

Vinoth H: Thank you for being on hold. I appreciate your patience.

Vinoth H: Jeff, I suggest you to perform the reset which will fix this issue.

Vinoth H: You can perform the reset with the help of the link given below:

Vinoth H:

http://acer.custhelp.com/app/answers/detail/a_id/8108/kw/reset

Vinoth H: Please make note that before performing the reset, please take backup of all the data, as you may lose the data.

: others have posted that even after a factory reset the problem will/may replicate if you power down the tablet. One forum user posted a detailed analysis of the problem and it occurs during boot up

Vinoth H: In rare cases, some tablets may face these issues.

Vinoth H: However, I suggest you to perform the reset which will surely fix the issue.

: If I choose to wait because I don't want to lose all my data.... is a patch in the works?, or is the official stance that I need to do a factory reset

Vinoth H: It is a official announcement that the tablets needs to perform the factory reset.​

 

[diiorio]

When ICS isntalls and reboots it does a period of optimization including hardware, if it is interrupted, or glitched durign that timed certain hardware aspects can be affected, that is why some have the issue and aothers so not. IT will ahppen if your sreen happened to be locked at the time, which hapnned on another tablet manufacturer when ICS was released.

 

[Mrhelper]

so no news on the screen rotation problem from ACER over the last week?

If you're referring to the MPU initialization problem (causing error code 26), I don't know if Acer is working on that, and I'm not sure how to make that happen. Hopefully one of the moderators may have an idea about how to get some vendor focus on this. Most users don't report problems of this technical detail, and so Acer customer call centers are not likely to handle a report of this type very effectively.

There is some activity in the thread I started a few weeks ago in another forum: Possible Relief for Several A500 ICS Related Symptoms/Problems - Android Forums. Check out the last post by cryptonym today. He has found that different versions of the Acer ICS code -- i.e., a version of the leak at XDA, and the stock build -- behave differently. With an XDA leak build (Acer_AV041_A500_1.041.00_WW_CUS1) , he could not get the error to clear at all, and so he then had no motion sensor support -- not even with the hardware reset. When he reinstalled the stock Acer ICS build, he could again use the hardware reset (pinhole) to clear the error, which restores all motion sensor functionality. What he saw with the stock Acer ICS build is the same problem that I described above. What he saw with the rooted version from XDA was worse, because there is apparently no workaround.

What he described advances a theory I have that this is caused by a race condition, where the a500 boot sequence appears to be getting ahead of the MPU, and trying to subscribe to MPU IRQs before that device is ready. I cannot confirm this, but it seems possible that this may be a consequence of Acer optimizing the ICS boot sequence to minimize boot times, where they may have shortened the time to sensor service initialization a little too tightly for some number of systems, possibly with slightly different hardware builds. That also seems consistent with what I see, where the cold power up causes the problem, and the warm hardware reset clears it. My assumption is that during the cold start, the MPU takes longer, or Android boots faster, and the MPU loses the race. When I use the hardware reset, the MPU wins, and the Sensor driver/service finds the device active and ready. Just a theory at this point, without having looked at any of the code.

I am very curious to know if you and others are seeing the error 26 messages. If would be helpful if you would install aLogcat, run it when you are seeing the problem, and then post your results here -- i.e., whether or not you see error code 26 messages in the log. Actually, if others who have been encountering the autorotate problem are reading this, and would do the same, we could possibly build a concensus and have a better case prepared to engage Acer.

 

[Douvie]

When ICS isntalls and reboots it does a period of optimization including hardware, if it is interrupted, or glitched durign that timed certain hardware aspects can be affected, that is why some have the issue and aothers so not. IT will ahppen if your sreen happened to be locked at the time, which hapnned on another tablet manufacturer when ICS was released.

Well I agree with Diiorio. Mine working fine. It is quite possible that there has been some kind of interruption - maybe a power source. Mybe some saw the update suddenly happen and decided to plug the power in during the update sequence. Mine was full so I didn't plug the power in. I had an issue with DELL laptops going stupid if you plug the power in during some process activity.
This could be causing the issue described by Mrhelper in such great detail.

 

[Mrhelper]

The MPU initialization does fail as a result of a race condition as I suspected, but the race was not nearly as close as I thought.


I have now been able to reproduce the InvenSense MPU-3050 initialization failure at will, and prevent it at will, with ~95% effectiveness in over twenty a500 power cycle tests. The problem appears to be the result of the MPU-3050 not shutting down entirely until a significant period of time has passed after an a500 power down. This effect can be seen by powering down the tablet, and then immediately powering it back up, where all MPU-3050 sensors are then unavailable, and associated features like automatic screen rotation do not function. The condition persists until manually cleared by the user as described below.


I've observed that there are two ways to clear the MPU initialization failure condition, and one way that usually prevents it, but as I write in a followup post is not quite 100% effective:


** To clear the condition in less than 30 seconds, just press the hardware reset button (pinhole). The hardware reset appears to shorten the associated MPU-3050 shutdown period, possibly by shorting down residual voltage that may be delaying restart. It's hard to determine the precise cause without having more detailed specs on a500 internals, but this seems to be a reasonable theory.


** An alternate way to clear the condition is to power off the a500, and wait at least 5 minutes before powering back up. This may allow residual voltage on the MPU to drain prior to restart, and thus permit normal initialization of sensors at power up. Again, a theory, but a reasonable one based on past experience with other systems.


** To reduce the chances of encountering the problem, do not power the a500 back on until at least 5 minutes after power down. I would not be surprised to learn that some a500s take less time, and others take more. I actually saw some good restarts at power cycle intervals closer to 1 minute. I just got to a point where I thought I was splitting hairs, became bored with the repeated testing, and settled on 5 minutes.


The method I suggest for prevention -- i.e., not using short power up/down cycles -- is probably the natural behavior for most users, and why many have not seen the problem. I can't rule out that there may be subtle differences in hardware between a500 owners either, because I've only tested this so far on my own tablet, so some users may not be able to reproduce the problem.


Apparently then, a500 owners like me who have been seeing this problem more regularly, have possibly been testing for this or other problems, and actually increasing the frequency by performing that specific test -- i.e., the short power up/down cycle. I first saw this sensor problem while repeatedly powering up/down to diagnose problems that I was seeing with certain apps after the ICS update. Others who have detected this problem are possibly behaving similarly while working on other tasks where they perform short power down/up cycles.


It's possible that that root XDA build that cryptonym tried merely had some other problem with MPU initialization, and that the cause for his error code 26 issue may have a different origin. Maybe, maybe not.


Android ICS did come with some code changes relative to the MPU though -- specifically in the use of the gyro to reduce latency and smooth output for the gravity sensor, the linear acceleration sensor, and the rotation vector sensor. This may or may not have anything to do with the problem, but seems worth mentioning.


I can now prevent the problem more effectively, but it is clearly a bug in the a500 OS, and one that appears to have been delivered with ICS.

 

[frapshake]

Breakthrough! The MPU initialization does fail as a result of a race condition as I suspected, but the race was not nearly as close as I thought.


I have now been able to reproduce the InvenSense MPU-3050 initialization failure at will, and prevent it at will, with 100% reliability in over twenty a500 power cycle tests.

Thank you for letting all of us know the results of your tests. I noticed my lack of rotation problem several days ago when posters were starting to report it. I tried turning mine and it was locked in landscape. When I did my fix, I figured the problem would eventually show up again, but so far it hasn't. If you remember me telling you, I shut mine down completely, flipped the lock switch back and forth a few times, then restarted. Guess I'm fortunate that seemed to fix it, but it's good to know what you found out in case the problem comes back.

 

[Mrhelper]

If you were having the problem I wrote about, and that seems possible, then I suspect your solution had more to do with the timing -- i.e., of waiting long enough (while flipping the switch) to allow the MPU to restart properly. Next time try twiddling your thumbs while waiting instead, and see if that works also.

 

[frapshake]

Oh, you have a point there, it probably was the timing, not the flipping lock switch. But please don't misunderstand me, I was in no way trying to dispute your findings. I'm sure you're right. My point was to thank you because you eased my mind in case the problem comes back.

 

[Mrhelper]

Thanks frapshake. That was just my attempt at a joke. I also may have announced my findings a little too soon anyway, because I powered up my tablet after it had been off cold for ~6 hours, and there it was again -- the error code 26s with no autorotate. I powered down, waited for 2 minutes, and the sensors were again working perfectly. So it looks like I have more testing to do. There appears to be a sweet spot on the timing, and I ran some 20 power cycles in that spot late last night where the problem never appeared. One problem with this test is that it takes so long for each full cycle.

Update 5-16-12: Only saw the condition once since I have been giving the tablet enough time between power down and power up. I have powered up a few times now after longer down intervals, on at least 10 hours, and no symptoms of the problem after that one hit yesterday (noted in the previous paragraph). ...so my workaround still appears to be relatively effective so far.

What I have written in the post above on this is still generally valid, except the part where I'm finished and satisfied with the solution I have. I will revise it with what I learn as I get time. Hopefully what I have provided so far will at least mitigate the problem for others seeing the same thing.

By the way I would not doubt that you and others may occasionally have encountered a different form of the auto rotate problem. The only way to confirm is by checking the logs for error code 26 messages.

 

[frapshake]

Mrhelper...I got the joke and it made me smile, no worries there. I wish I knew about aLogcat and the MLUpdateData error the first time I noticed my screen being stuck in landscape so I would know if it showed up. I haven't seen the error any time at all since using aLogcat, but I don't have the problem now either, so I wouldn't see it.

Wanted to report to you that I just now shut down my tablet the regular way, and immediately booted up again, then checked aLogcat and didn't see anything suspicious, and my rotation is fine. I'm thinking I must be one of the lucky ones who doesn't have the problem, even though it happened once. If you would like me to try any test on mine to give you more data on a different tablet, just let me know. I would be happy to help.