Re: System lock-up stops if suspend has occurred

["Shane Volpe" <shanevolpe@xxxxxxxxx>]

The main issue turned out to be timing on the SDRAM clock, The clock was not
in the low state for the 3ns required by the RAM and was easily fixed by
increasing the PXA drive strength.  The concerning part of the problem is
why having the board sleep seemed to stabilize the board.  After further
investigation I have discovered that the boot loader sets the SDRAM clock at
102MHz but when the board wakes back up the kernel sets the SDRAM clock to
92MHz.  The slower clock speed improved the timing margin allowing the board
to be stable.  This may be a bug in the PXA wake-up code for the kernel.  I
will look into that code and see if I can find the problem.
Regards,
Shane

On Wed, Apr 2, 2008 at 9:11 AM, Shane Volpe <shanevolpe@xxxxxxxxx> wrote:

> 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
>



-- 
Registered Linux User: #293401
-------------------------------------------------------------------
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