Kernel hang on OMAP3 based Beagle board about beagleboard

[GoogleCodeExporter]

Koen tried disabling RTC and he get the same hang, so the RTC isn't to blame.

http://marc.info/?l=linux-omap&m=121502995021151&w=2

Original comment by [email protected] on 4 Jul 2008 at 5:55

[GoogleCodeExporter]

I tried running git-bisect. I got this far today.
The bad commit is probably between:
# good: [3ffec4e18484c34838fa341de3848306c29ecd5d] 24XX: PM: Move pm.c to 
pm24xx.c
and sleep.S to sleep24xx.S
and # bad: [458776cfe389ff03bd6c56c47e059df0778cdfca] OMAP3430SDP: Enable config
options CONFIG_OMAP_RESET_CLOCKS and CONFIG_SUSPEND

This is a 9-patch series by Jouni Hogander related to suspend and 
power-management.
Will get back to this tomorrow and see if I can narrow it down further.

Original comment by [email protected] on 4 Jul 2008 at 7:19

[GoogleCodeExporter]

As far as I can tell, the beagle hang issue aries after this commit:

397f49cde4e75cf662a23814097db35f3e6c6b62 is first bad commit
commit 397f49cde4e75cf662a23814097db35f3e6c6b62
Author: Jouni Hogander <[email protected]>
Date:   Fri May 16 13:58:25 2008 +0300

    34XX: PM: Initial version of suspend and dynamic retention

    This is initial version of suspend and dynamic retention for
    34xx. Omap is tried to put to full retention on suspend and pm_idle.

    Signed-off-by: Jouni Hogander <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>


Could someone please test and confirm if the previous commit works without a 
hang?
I waited for around 20 minutes and did not observe a hang.

These were the last two good commits I got from git-bisect.
# good: [1c66e10c850950a84da68cafb07022eab5e7eec0] 34XX: Suspend: Take suspend 
sram \
code from ti cdp kernel git-bisect good 1c66e10c850950a84da68cafb07022eab5e7eec0
# good: [131ce2d1dd5081f97885419678a8b3211c7c2dee] 34XX: Add miscellaneous \
definitions related to 34xx

Original comment by [email protected] on 5 Jul 2008 at 4:54

[GoogleCodeExporter]

Questions, hints and change to try:

http://marc.info/?l=linux-omap&m=121541612613301&w=2

Original comment by [email protected] on 8 Jul 2008 at 4:08

[GoogleCodeExporter]

Workaround/Fix seems to work

http://marc.info/?l=linux-omap&m=121604209723787&w=2

Original comment by [email protected] on 14 Jul 2008 at 3:45

[GoogleCodeExporter]

http://groups.google.com/group/beagleboard/browse_thread/thread/566283f7496d19eb

Proposed Workaround:

Instead of using 32K timer for GPT1, if we use MPU timer then this hang will 
not happen. 

Original comment by [email protected] on 5 Aug 2008 at 6:22

[GoogleCodeExporter]

Work-around of using MPU timer has been confirmed.

Board revision B5 removes capacitor C70, which improves the 32kHz clock quality 
and
avoids this hang-up.

Original comment by [email protected] on 15 Aug 2008 at 3:06

• Changed state: Started
• Added labels: Component-Board

[GoogleCodeExporter]

Summary: As stated above, there is a software workaround and a hardware fix for 
this:

(A) Software workaround: Don't use 32kHz timer to clock Linux, instead use MPU 
timer.

(B) Hardware workaround: Remove capacitor C70, which improves the 32kHz clock 
quality
and avoids hang-up.

See

http://www.flickr.com/photos/25691331@N04/2766671437/in/pool-beagleboard

for capacitor C70 on rev A and rev < B5 boards.

Note: Board revision >= B5 removes capacitor C70 by default

Original comment by [email protected] on 16 Aug 2008 at 6:46

• Changed state: Fixed