ice cream sandwich bug on a500
- Thread starter btmh
- Start date
There has apparently been a breakthrough on at least one of the sensor driver problems by a developer working on the ICS leak at xda-developers. I am hopeful that this may be related to the auto rotation lockup problem many are seeing (described above), and that this fix gets passed into the official Acer source if it is the solution. See: [ICS PATCH][CWM] Dear XDA, I present to you...the rotation fix 
- xda-developers.
If someone at Acer already fixed it, then that's great also.
- xda-developers.If someone at Acer already fixed it, then that's great also.
Last edited:
WOW! Thank goodness for this forum!! I would have never have guessed that's what you had to do. I'm turning my tablet on just to give this a try!
Gerry
You know I was having this non-auto rotate issue also and discovered that the little lock switch on top of the tablet accidently was brushed to a in-between state causing the auto rotate of the screen to act strangely. I to was thinking it was a OS update glitch because after an update, it just so happened that by accquincadence the lock switch was moved inadvertantly. So this just might be the sollution to some of the auto-rotate problems if the problem can't be resolved in the display settings. The Switch......Check Out the Switch! :
Douvie
Senior Member
- Jun 10, 2011
- 1,030
- 71
Excellent info. double and triple check that SCREEN LOCK SWITCH - slide it back and forth afew times. If it doesn't feel right check it properly.
Here is a somewhat detailed description of the a500 MPU (motion sensor) problem that many users are apparently encountering, and many are not. If you know a convenient way to get someone at Acer to look at this, feel free to pass it on.
An obvious early symptom is the loss of automatic screen orientation (auto rotate). Power off/on will not always clear this. Locking the screen orientation by sliding the lock switch to the right will pause the errors.
What happens: Power up boots of the a500 in this version of ICS intermittently fail to initialize the MPU 3050 sensor device, and the log then shows a constant stream of MLUpdateData error (code 26) messages. The "aLogcat" app from the Market is handy for seeing errors like this. There may be an impact to system resources while the errors are occurring, but I have not determined how significant the direct impact is. The associated sensor errors are posted to the log every 50ms... that's 20 times each second. Again, sliding the auto rotate switch to the locked position apparently suspends the sensor error condition, and reduces some symptoms as long as the switch stays locked. Unlocking causes the rapidly repeating MLUpdateData errors to immediately resume.
If I never power the unit off after a hardware reset (pressing the pinhole button, not the "factory data reset"), I never see the problem occur. One workaround then is to avoid powering the unit down, and then when you occasionally do, use the reset button after power up if symptoms appear.
The condition only starts immediately after a power off /on cycle. I observed that with a clean factory data restore, and no other apps installed, I could reproduce the problem more often by powering down immediately within 2-3 seconds after powering up, proving that this can be triggered without installing any applications beyond those provided in the OS package by Acer.
Beyond the loss of automatic screen rotation, symptoms of the g-sensor error problem can be relatively mild, and at times, unnoticeable. I suspect that many users are generally satisfied with the performance of their tablet with this error occurring because they may not notice it.
############################################
############################################
POWER ON BOOT EXAMPLE WHERE MPU FAILS TO INITIALIZE:
In the kernel log excerpt below, look at time 2.609914. The i2c_readl() call by i2c-tegra.c|tegra_i2c_isr() returns 0x8 (I2C_INT_NO_ACK) while attempting to read status from the mpu3050, and so mpu3050_probe fails because the MPU is apparently just not ready to respond when this happens.
KERNEL LOG EXCERPT:
...
<6>[ 2.608737] compass sensor is AKM8975 0x48
<6>[ 2.608899] i2c i2c-0: mpu3050: +kxtf9
<6>[ 2.608989] i2c i2c-0: Installing Accel irq using 343
<6>[ 2.609272] i2c i2c-0: mpu3050: +ak8975
<6>[ 2.609434] i2c i2c-0: Installing Compass irq using 301
<4>[ 2.609706] i2c i2c-0: mpu3050: No Pressure Present
<4>[ 2.609914] tegra-i2c tegra-i2c.0: I2c error status 0x00000008
<4>[ 2.610004] tegra-i2c tegra-i2c.0: no acknowledge from address 0x68
<4>[ 2.610163] tegra-i2c tegra-i2c.0: Packet status 0x00010009
<3>[ 2.611283] mldl_cfg:/home/pandora/pandora_build_root/main_rom/android/PicassoV041_A500_mdrr/kernel/drivers/misc/mpu3050/inv_330/mldl_cfg.c|MLDLPowerMgmtMPU|579 returning 135
<3>[ 2.611520] mldl_cfg:/home/pandora/pandora_build_root/main_rom/android/PicassoV041_A500_mdrr/kernel/drivers/misc/mpu3050/inv_330/mldl_cfg.c|mpu3050_open|1225 returning 135
<3>[ 2.611684] i2c i2c-0: Unable to open mpu3050 135
<6>[ 2.611770] misc compassirq: Unregistering compassirq
<6>[ 2.612052] misc accelirq: Unregistering accelirq
<3>[ 2.612250] i2c i2c-0: mpu3050_probe failed -19
<4>[ 2.612489] i2c-core: driver [mpu3050] using legacy suspend method
<4>[ 2.612577] i2c-core: driver [mpu3050] using legacy resume method
<7>[ 2.612741] mpu_init
...
SYSTEM LOG EXCERPT:
...
05-04 12:03:49.330 82 82 I dalvikvm: System server process 145 has been created
05-04 12:03:49.330 82 82 I Zygote : Accepting command socket connections
05-04 12:03:49.490 145 145 E BatteryService: usbOnlinePath not found
05-04 12:03:49.510 145 145 I sysproc : Entered system_init()
05-04 12:03:49.510 145 145 I sysproc : ServiceManager: 0x12f4788
05-04 12:03:49.510 145 145 D SensorService: nuSensorService starting...
05-04 12:03:49.590 145 145 V Sensors : sysapi object at 0x5afd6a1c
05-04 12:03:49.590 145 145 V Sensors : sysapi getBiases func at 0x5afd176d
05-04 12:03:49.590 145 145 E Sensors : could not open the mpu irq device node
05-04 12:03:49.590 145 145 E Sensors : could not open the accel irq device node
05-04 12:03:49.590 145 145 I MPL-mlsl: MLSLSerialOpen: /dev/mpu
05-04 12:03:49.590 145 145 I MPL-mlsl: I2C Error: could not bind address 68: -1
05-04 12:03:49.590 145 145 E Sensors : Fatal Error : could not open MPL serial interface
05-04 12:03:49.590 145 145 E MPL-mlstates: Error : illegal state transition from ML_STATE_SERIAL_CLOSED to ML_STATE_DMP_OPENED
05-04 12:03:49.590 145 145 E MPL-dmp : vendor/invensense/Invensense330/libsensors/mlsdk/mllite/mldmp.c|MLDmpOpen|82 returning 25
05-04 12:03:49.590 145 145 E Sensors : Fatal Error : could not open DMP correctly.
05-04 12:03:49.590 145 145 E Sensors : could not open MPL calibration file
05-04 12:03:49.600 145 145 E MPL-mldl: DmpFeatureSupported : sGetAddress is NULL
05-04 12:03:49.610 145 145 W MPL-9_sup: 9 axis sensor fusion not available - No compass detected.
05-04 12:03:49.610 145 145 E Sensors : Error : Bias update function could not be set.
05-04 12:03:49.610 145 145 E Sensors : Error : could not set motion interrupt
05-04 12:03:49.610 145 145 E Sensors : Error : could not set fifo interrupt
05-04 12:03:49.610 145 145 E Sensors : Fatal error: MLSetFIFORate returned 26
05-04 12:03:49.610 145 145 E Sensors : Error : Motion callback could not be set.
05-04 12:03:49.610 145 145 E Sensors : Error : Processed data callback could not be set.
05-04 12:03:49.610 145 145 E Sensors : Fatal error: FIFOSendAccel returned 26
05-04 12:03:49.610 145 145 E Sensors : Fatal error: FIFOSendQuaternion returned 26
05-04 12:03:49.610 145 145 E Sensors : Fatal error: FIFOSendLinearAccel returned 26
05-04 12:03:49.610 145 145 E MPL-fifo: vendor/invensense/Invensense330/libsensors/mlsdk/mllite/mlFIFO.c|FIFOSendGravity|1000 returning 26
05-04 12:03:49.610 145 145 E Sensors : Fatal error: FIFOSendGravity returned 26
05-04 12:03:49.610 145 145 E Sensors : Fatal error: FIFOSendGyro returned 26
05-04 12:03:49.610 145 145 V Sensors : MPLSensor::getFd returning -1
05-04 12:03:49.610 145 145 V Sensors : MPLSensor::getAccelFd returning -1
05-04 12:03:49.610 145 145 V Sensors : MPLSensor::getTimerFd returning 34
############################################
############################################
REPEATING E/SENSOR ERRORS IN LOGS AFTER FAILED MPU INIT
(the sensor does not work at all when this condition is present
and must be reset by pressing the switch in the pinhole)
...
[ 05-04 06:51:48.520 141:0x99 E/Sensors ]
MLUpdateData error (code 26)
[ 05-04 06:51:48.570 141:0x99 E/Sensors ]
MLUpdateData error (code 26)
[ 05-04 06:51:48.620 141:0x99 E/Sensors ]
MLUpdateData error (code 26)
[ 05-04 06:51:48.670 141:0x99 E/Sensors ]
MLUpdateData error (code 26)
[ 05-04 06:51:48.680 1329:0x531 D/TestLog ]
start
[ 05-04 06:51:48.720 141:0x99 E/Sensors ]
MLUpdateData error (code 26)
[ 05-04 06:51:48.780 141:0x99 E/Sensors ]
MLUpdateData error (code 26)
[ 05-04 06:51:48.780 1329:0x533 D/dalvikvm ]
GC_CONCURRENT freed 934K, 12% free 8123K/9159K, paused 2ms+7ms
[ 05-04 06:51:48.810 1329:0x531 D/TestLog ]
end
[ 05-04 06:51:48.830 141:0x99 E/Sensors ]
MLUpdateData error (code 26)
############################################
############################################
REPEATING E/SENSOR ERRORS PAUSE WHILE SCREEN ORIENTATION LOCK
SWITCH IS SLID RIGHT TO THE LOCKED POSITION
(the errors resume when the switch is again unlocked)
...
[ 05-04 06:51:48.860 141:0x98 V/Sensors ]
handle : 14 en: 0 mEnabled:00004000
[ 05-04 06:51:48.860 141:0x98 V/Sensors ]
sensor state change what=14
[ 05-04 06:51:48.860 141:0x98 V/Sensors ]
enabled_sensors: 0 dmp_started: 1
[ 05-04 06:51:48.860 141:0x98 V/Sensors ]
Stopping DMP
[ 05-04 06:51:48.860 141:0x98 E/MPL-mlstates ]
Error : illegal state transition from ML_STATE_SERIAL_CLOSED to ML_STATE_DMP_OPENED
[ 05-04 06:51:48.860 141:0x98 E/MPL-dmp ]
vendor/invensense/Invensense330/libsensors/mlsdk/mllite/mldmp.c|MLDmpStop|161 returning 25
[ 05-04 06:51:48.860 141:0x98 E/Sensors ]
error: unable to stop DMP (retcode = 25)
[ 05-04 06:51:49.260 1329:0x544 D/PersistentEventStore/putEvent ]
Row ID: 319, Event ID: 319
...
############################################
############################################
POWER ON BOOT EXAMPLE IMMEDIATELY AFTER HARDWARE RESET (PINHOLE) WHERE MPU STARTS AND OPERATES NORMALLY:
...
I/dalvikvm( 82): System server process 141 has been created
I/Zygote ( 82): Accepting command socket connections
E/BatteryService( 141): usbOnlinePath not found
I/sysproc ( 141): Entered system_init()
I/sysproc ( 141): ServiceManager: 0x163da10
D/SensorService( 141): nuSensorService starting...
V/Sensors ( 141): sysapi object at 0x59414a1c
V/Sensors ( 141): sysapi getBiases func at 0x5940f76d
I/MPL-mlsl( 141): MLSLSerialOpen: /dev/mpu
I/ ( 141): mpu3050_suspend: suspending sensors to 0000
I/ ( 141): mpu3050_suspend: Will resume next to 03ff
D/MPL-storeload( 141): 00(00) 01(00) 02(00) 03(24)
D/MPL-storeload( 141): 04(00) 05(05) 06(ce) 07(1a)
D/MPL-storeload( 141): 08(00) 09(00) 10(7c) 11(ff)
D/MPL-storeload( 141): 12(00) 13(00) 14(ab) 15(df)
D/MPL-storeload( 141): 16(ff) 17(ff) 18(15) 19(a1)
D/MPL-storeload( 141): 20(ff) 21(ff) 22(f9) 23(68)
D/MPL-storeload( 141): 24(ff) 25(ff) 26(f6) 27(ec)
D/MPL-storeload( 141): 28(ff) 29(ff) 30(f4) 31(28)
D/MPL-storeload( 141): 32(b5) 33(42) 34(79) 35(df)
V/Sensors ( 141): MPLSensor::getFd returning 34
V/Sensors ( 141): MPLSensor::getAccelFd returning 35
V/Sensors ( 141): MPLSensor::getTimerFd returning 36
...
Last edited:
frapshake
Senior Member
- Apr 22, 2011
- 244
- 35
Mrhelper...I've read all your comments with great interest, including the long post on androidforums.com from the link in this post and my experience with my tablet seems to be a little different than yours and I would be interested and appreciate your comments.
A day or so after upgrading to ICS, I noticed that my orientation wouldn't change to portrait view. I shut down the tablet completely and while off, I switched the screen rotation lock switch back and forth a few times, and after booting back up, the problem was gone and has never returned. I have powered down completely a few times since, and it's still fine. I didn't have to do the pinhole reset to fix it, and powering down and restarting doesn't seem to trigger the error on mine as you say it does on yours. I have used the aLogcat app since you mentioned it to me in another post and I have never seen the MLUpdateData error, but I don't know if I had the error code the very first time I noticed the screen was locked in landscape. So this is different than your experience with the screen rotation problem.
The second thing has to do with the ... more general app related performance management issues comment from your post I quoted above, and from your other posts I've read, about certain apps like app killers, and others that perform automatic app maintenance, etc. causing problems. After a post from you recommending I delete those types of apps, I did. But a couple of days ago my tablet started freezing on me. The more I used it, the worse it got. When this happened, I noticed my user memory was very low, sometimes under 100MB. It seems to me that my tablet has a problem with closing apps and freeing up memory. If I wait several seconds, the tablet is usable again. Well, I reinstalled the Android Assistant app I uninstalled a day or so ago, set it to clean every 30 minutes, and I haven't had the freezing problem since. I always have over 200MB of user memory now and my tablet is faster and humming along again like it should. But I shouldn't have to use an app like this to prevent low memory and freezing, so do you think one of my installed apps could be causing the low memory freezing problem when I don't use Android Assistant, or is it most likely an ICS bug?
What you describe sounds like an app or apps hogging CPU. Android is not by nature memory bound (especially on an a500), it is however CPU bound. Android manages app memory very simply and effectively. CPU usage management is not as simple. Full memory is typically not a problem on Android, in fact, it is a normal and desired condition, and actually enhances perfomance. It's a fundamental strategy in the Android design -- so more frequently used apps start faster from the perspective of the user. When the OS needs memory for another app, it quickly discards the least used apps from the background to make room.
Task managers that kill apps on the basis of memory footprint operate on an invalid myth, are just shooting in the dark, and are occasionally hitting the right target. That's likely why you were able to see some improvement, but on the whole, these memory based killer apps tend to waste CPU and I/O time, and will slow down a healthy system. Your system was apparently very sick, so you saw some improvement, but that is not an ideal solution as you noted in your post. You should not have to kill apps on Android, unless one becomes hung, but at that point a restart may be more appropriate, followed by removal of the bad app.
What I think you may more likely be seeing is an odd behavior that I see also. Whenever I park Dolphin or the Stock browser (Android up button) without first closing tabs and exiting, I often see moderate to severe system slowdowns. What I found is that these two apps tend to consume significant CPU in the background. As long as I close these browsers (Dolphin and the stock Android browser) completely, I never see the problem.
I've been using Chrome Beta more often lately, and monitoring it closely, and it does not cause the same problem.
I still use Dolphin when I need more features, and even the stock browser for speed, but I find Chrome Beta has some advantages, and again, does not cause the background CPU consumption problem.
Other browsers may cause this problem, but I have not tested them.
There are a lot of apps out there, and any one may be causing a similar problem, so if your browser usage style is not similar to mine, then apps other than browsers could be causing problems for you instead.
When your a500 Android system slows, you can almost be certain that the problem is a CPU resource issue, or possibly a network delay issue, but not a memory shortage.
I recommend that you remove Android Assistant, and instead install Watchdog. Watchdog monitors CPU usage for apps running in the background, and will alert you when some app in the background uses CPU over the threshold. Just use the default setup. The default threshold for an alert is about 40%, I recall (which is most of one of your two cores). I've seen Dolphin consuming 45-80% in the background when I was having problems.
You may also want to place the Watchdog widget on your home screen. It's interesting to watch sometimes, and you can use it in place of the app shortcut to bring up the monitor. When you pull up the Watchdog monitor, select real time monitoring to see what's going on at that instant. Of course, when you do that you will see Watchdog near the top. Don't worry about that, it goes back down when you are not using the monitor.
This will help you identify the app or apps that are causing your slowdowns, so you can decide how to better manage them, or to remove them.
Task managers that kill apps on the basis of memory footprint operate on an invalid myth, are just shooting in the dark, and are occasionally hitting the right target. That's likely why you were able to see some improvement, but on the whole, these memory based killer apps tend to waste CPU and I/O time, and will slow down a healthy system. Your system was apparently very sick, so you saw some improvement, but that is not an ideal solution as you noted in your post. You should not have to kill apps on Android, unless one becomes hung, but at that point a restart may be more appropriate, followed by removal of the bad app.
What I think you may more likely be seeing is an odd behavior that I see also. Whenever I park Dolphin or the Stock browser (Android up button) without first closing tabs and exiting, I often see moderate to severe system slowdowns. What I found is that these two apps tend to consume significant CPU in the background. As long as I close these browsers (Dolphin and the stock Android browser) completely, I never see the problem.
I've been using Chrome Beta more often lately, and monitoring it closely, and it does not cause the same problem.
I still use Dolphin when I need more features, and even the stock browser for speed, but I find Chrome Beta has some advantages, and again, does not cause the background CPU consumption problem.
Other browsers may cause this problem, but I have not tested them.
There are a lot of apps out there, and any one may be causing a similar problem, so if your browser usage style is not similar to mine, then apps other than browsers could be causing problems for you instead.
When your a500 Android system slows, you can almost be certain that the problem is a CPU resource issue, or possibly a network delay issue, but not a memory shortage.
I recommend that you remove Android Assistant, and instead install Watchdog. Watchdog monitors CPU usage for apps running in the background, and will alert you when some app in the background uses CPU over the threshold. Just use the default setup. The default threshold for an alert is about 40%, I recall (which is most of one of your two cores). I've seen Dolphin consuming 45-80% in the background when I was having problems.
You may also want to place the Watchdog widget on your home screen. It's interesting to watch sometimes, and you can use it in place of the app shortcut to bring up the monitor. When you pull up the Watchdog monitor, select real time monitoring to see what's going on at that instant. Of course, when you do that you will see Watchdog near the top. Don't worry about that, it goes back down when you are not using the monitor.
This will help you identify the app or apps that are causing your slowdowns, so you can decide how to better manage them, or to remove them.
Last edited:
frapshake
Senior Member
- Apr 22, 2011
- 244
- 35
Thank you for your excellent advice. First I want to say, after reading in another post of yours about closing tabs in browsers and closing them down completely, I've been making sure I do that, so I ruled that out as causing problems...Ok, I did what you suggested. I uninstalled Android Assistant and installed Watchdog Lite and used the tablet heavily to see what happened. After a short while I noticed the MB's dwindling and not coming back, and when they went down to 114, the tablet completely froze. (I know you said it's the CPU usage and not the memory that causes problems) I was unable to do anything at all. Watchdog didn't alert me to a misbehaving app, so it didn't do its job. I forgot to put the widget on my home screen, so I didn't monitor it. The good news is...I was using the News360 app when it happened, so after a forced shutdown and booting up again, MB's at 422, I uninstalled News360 and gave the tablet a good test and everything seems to be working the way it should now. No slow downs, everything stable. I would have to say at this point that News360 was causing my tablet to be unstable. It's working great now like a fine tablet should. Thanks again for your help.
Excellent! Another application-caused performance problem bites the dust. That was great work on your part!
The News360 app must have had a terrible memory leak. You've identified another thing for users to look for -- i.e., apps with large memory leaks. Using a memory based task killer was apparently just masking the problem. Android was probably not able to remove it to reclaim memory because it was apaprently always or very often in the foreground. Android would also not just remove an app because it used a lot of memory, or manyy apps would not be able to run. Some apps use a lot of memory by design. News360 apprently had a severe leak though.
It may have been using excessive CPU also, but Watchdog only alerts on background processes by design. Otherwise it would be going off all the time when you were intentionally using CPU intensive apps. The design assumption was that users would typically know that they were using CPU in the foreground, but had no easy way to tell what was going on in the background. Watchdog could have helped you with identifying the memory problem also, because it shows memory usage next to CPU usage in the list when you bring up the monitor. You would have had to brought up the monitor though and scanned through the list of apps when you were seeing issues to recognize the problem. You can also sort entries in the Watchdog monitor list by memory instead of CPU. It seems like it would be nice if Watchdog also had an option to alert by % of memory used by a single app.
I still advise not running Android Assistant or other taks/app killers. The best solution if you want snappy overall top performance from your tablet is to identify and eliminate individual problem sources, rather than just masking them with an automatic task killer.
Very nice catch!
Last edited:
frapshake
Senior Member
- Apr 22, 2011
- 244
- 35
Thanks! It was definitely News360. I was curious so I reinstalled it so I could monitor it with Watchdog and to see if maybe I had a bad install before and it might run fine with a fresh install. No luck there. After running it then checking Watchdog it was using 40% CPU and 94MB memory. I used it just a little longer and it jumped up to 50.8% / 103MB, then right after checking that the second time, good old Watchdog gave me the alert for a misbehaving app, and guess which one it was. I agree with you, it must have a terrible memory leak. It's a shame because I really like the app and the devs have been hard at work trying to squash all the bugs. I have had email correspondence with them in the past for different problems and they are nice, caring guys that really want to put out a good app. I will try it again in the future, but for now, it's gone.
Thanks for all the CPU info, and the info on the workings of Watchdog. I will keep it around and get a lot of use out of it. Yes, it would be nice if it had an option to alert by % of memory used by a single app.
I am finally totally convinced that using Android Assistant and other task/app killers isn't such a good idea for the proper running of an ICS tablet. Hey, maybe you could get a job as an Acer tablet tech.
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.Similar threads
