System lock-up stops if suspend has occurred

["Shane Volpe" <shanevolpe@xxxxxxxxx>]

I have  a Xscale (PXA270) system that occasionally we have a unit that
will frequently lock up when I run an application using directfb with
no kernel panic or other debug information outputted from the kernel.
The lock-up is a complete lock-up with no response and even the PXA270
frame buffer quits refreshing.  Originally I thought it was defective
hardware or cold solder joints since it was limited to only a couple
of boards but then I discovered that if you suspend the system to mem
and wake it up the system it will run with out locking-up.  My belief
is that there is some race condition at power-up causing something not
to be initialized properly and it is then re-initialized during the
wake-up process from suspend causing everything to function properly.

There are several other details that I have found while trying to
debug this issue:
1.) Only suspending to mem stops the lock-up, if I suspend using
standby, the system will still lock-up.
2.) It seems somehow related to the PXA frame buffer as it is during
the accessing of the frame buffer that the lock-up happens (as best I
can tell)
3.) About 10% of the time the lock-up occurs the first time I run my
app using directfb and occures 90% of the time if I kill the app and
run it a second time.
4.) If I add delays around the directFB function calls in the app
accessing the frame buffer it seems to also stop the lock-up. If it
was not do to the fact that suspending to mem and then waking up stops
the lock-ups (after doing this I can kill/start the app as many times
as I want with no lock-ups) with out the delays I would assume
directFB was doing something nasty with the FB but that is NOT the
case.
5.) Compiling the PXAFB as a module and loading it before or after the
suspend to mem makes no difference, the system still locks up if no
suspend to mem has occurred and becomes very stable after one occurs.
6.)  Making the PXAFB a module and loading well after the system is up
and running makes no difference.
7.) Turning on DEBUG in the kernel provides no additional information
before the lock-up state.
8.) Compiling the Audio and touchscreen as modules and loading it late
or not loading it at all makes no difference


Hardware:
PXA270
64MB RAM
128 MB NOR Flash
UC1400 Audio Codec + TouchScreen
uSD (MMC)


I realize I have not provided much *real* use full information but
that is my issue I'm having a hard time finding a way to generate
information that will narrow down were the problem is.  I'm open for
any suggestions or test cases to run.  The lock-up is very repeatable
so I can perform any test or add in any debug code and in a matter of
minutes get results.
Regards,
Shane

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php