|2012-11-22 11:06:05||Re: [Omapandroid-discussion] Need pointers to look into Androiddevice lock-up|
|Posted By: Chaitral Purkar <email@example.com>|
Join Date: 2006-06-12
Location: UNITED STATES
Thanks for your inputs.
I figured out that problem is on the kernel side and not on user land. This=
is because, I took the latest rootfs from TI devkit 2.1 and kept my custo=
mized (old)kernel (2.6.32). I found that the 'lock-up' happens in that case=
as well. However, on beagleboard-xm the same rootfs seems to be working fin=
e. So I need to look into the kernel side.
I will try your suggestion to trim the kernel to bare minimum. I will look i=
nto the power management as well.
Thanks and regards,
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Wednesday, November 21, 2012 7:21 PM
To: Chaitral Purkar
Subject: Re: [Omapandroid-discussion] Need pointers to look into Android dev=
Perhaps you can try to isolate the problem by
a. Stripping Android to the bare minimum set of core services and applicatio=
ns. Then run the app test.
b. Trim the linux kernel, to the absolute bare minimum, and repeat the tests=
at the android app level. Try to first fully remove wifi and bluetooth supp=
ort, and run the app to see if it locks up. After that, try to disable the p=
hones GSM functionality and serial UART, and repeat the test.
c. Disable power management, and screen blanking / suspend, at the android l=
evel, and see if the screen locks up.
d. If all the above three points don't work, try to create a simple qt app,=
and stress test the kernel, to see if the lock up occurs, without the andro=
id user land stack.
In short, perhaps the only way to trouble shoot this issue is by isolating t=
he problem to being either from the kernel or android user land, and then pr=
ogressively drillling down into the kernel or android user land.
I suspect it might be the kernel, or some driver that is not fully power man=
agement compliant. the older 2.6.29 kernels didnt have any power management.=
With 2.6.32 there was some ability to enable power management, but it wasn'=
t safe to use it due to suspend resume issues, etc. That's the only scenario=
where I've seen the system lock up or act funny, i.e. cannot come out of su=
spend or resume after a minute, or it gets stuck after coming out from suspe=
On Nov 21, 2012, at 2:25 PM, Chaitral Purkar
We are having a problem with our device - VoIP desk phone powered by the OMA=
P 3530. We are running TI's Android 2.3 devkit 1.0 (Linux 2.6.32) from the=
Out of the blue, the OMAP will simply lock up. By "lock up", I mean that it=
will stop executing instructions. Here are some salient features of the lo=
ck up failure:
1. No messages are written to serial console, no kernel panic, nothing. =
The serial port is completely unresponsive. One cannot use sysreq to send=
commands to the kernel.
2. We are unable to use the JTAG interface to halt the processor. We are=
using TI Code Composer with an XDS100v2 JTAG emulator to access the JTAG in=
terface. Prior to the failure it is possible to halt the processor and look=
at registers, and then restart the processor. Once the failure happens we=
get this message connecting to the target:
Trouble Halting Target CPU:
Fatal Error during: Execution, Timeout, Target,
Cannot halt the processor
3. The display remains frozen with the screen is lit up and showing whate=
ver was on it when the failure happened, in other words phone's DRAM (frameb=
uffer) is alive.
4. No process is now running in Linux. We have a very simple program tha=
t writes a "0" to /dev/watchdog every 30 seconds. The purpose of this progr=
am is to reboot the phone after the lockup. On lockup, the process doesn't=
run anymore, and eventually OMAP's Watchdog Timer triggers a reset.
5. We've developed an app that can trigger the lockup. This app scrolls=
images thumbnails left/right quickly and the lockup happens in less than a=
minute. However, when we ran this app on an older version of our software=
based on Android Eclair (Linux 2.6.29) it took about 4-5 hours before the l=
ock up happened.
6. We are using graphics acceleration using the PowerVR/SGX library suppl=
ied by TI. However, the lock up occurs even on a build that doesn't use the=
7. We are not using the OMAP 3530's DSP. In fact, our build uses softwar=
e acceleration for video playback.
8. Other than the app that scrolls images, we can make the failure occur=
in several ways all of which involve using the screen. Phones will sometim=
es (although rarely) lock up even when no one is using the phone (the clock=
on the screen shows minutes so there is some screen activity even when the=
phone is idle).
9. >From user reports, we feel strongly that there is a correlation of th=
e lock up with heavier phone usage.
So far, we have not been able to figure out why such a lock up would happen=
and how to debug it given that JTAG isn't available.
Thanks and regards,
DISCLAIMER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e-mail may contain privileged=
and confidential information which is the property of Persistent Systems Lt=
d. It is intended only for the use of the individual or entity to which it i=
s addressed. If you are not the intended recipient, you are not authorized t=
o read, retain, copy, print, distribute or use this message. If you have rec=
eived this communication in error, please notify the sender and delete all c=
opies of this message. Persistent Systems Ltd. does not accept any liability=
for virus infected mails.
Omapandroid-discussion mailing list
This e-mail may contain privileged and confidential information which is the=
property of Persistent Systems Ltd. It is intended only for the use of the=
individual or entity to which it is addressed. If you are not the intended=
recipient, you are not authorized to read, retain, copy, print, distribute=
or use this message. If you have received this communication in error, plea=
se notify the sender and delete all copies of this message. Persistent Syste=
ms Ltd. does not accept any liability for virus infected mails.