PXA270 Random Hangs at Low Core Freq
Haojian Zhuang
haojian.zhuang at gmail.com
Fri Oct 22 04:41:29 EDT 2010
On Fri, Oct 22, 2010 at 8:22 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> Dne Po 18. října 2010 19:38:49 Michael Cashwell napsal(a):
>> Greetings,
>>
>> I've been fighting inexplicable hangs on two different PXA270 designs
>> running various kernels since early 2.6.28.x. The first board was custom
>> (and of dubious integrity) but I'm currently seeing it on Gumstix Verdex
>> PROs running 2.6.35.7.
>>
>> At first I thought it was a problem with CPU-freq code itself hitting some
>> unaddressed errata but I've eliminated that possibility. The hangs occur
>> even if CPU-freq is disabled in the kernel config. All that's required in
>> that case is for u-boot to run the kernel at a core frequency of 312MHz or
>> lower. If it runs at 416MHz or higher no hangs occur. (With CPU-freq
>> enabled the hangs only occur if speeds at or below 312MHz are allowed.
>> With those commented out, no hangs.)
>>
>> At low core frequencies I can trigger the hang every time by copying a
>> several-MB file to a uSD card via the MMC interface. The copy command
>> completes but a few seconds later (while the background processes write to
>> the card) the CPU hangs.** However, the issue is not specific to uSD/MMC.
>> Another developer told me he has seen hangs while receiving data through a
>> UART connected via I2C.
>>
>> The hangs are hard (rendering JTAG inoperable) and since I have no hardware
>> with the Embedded Trace Module exposed I have no way to gather a trace of
>> execution up to the freeze.
>>
>> I'd like to solve the problem since the lower speeds are more power
>> efficient but I'm somewhat stuck regarding how to debug it. I'd like to
>> know if it's something I'm doing wrong so my first step is to ask the
>> ARM-Linux community if anyone else has run recent kernels on a PXA270
>> system at core clock rates of 312MHz or less. (That's also a not so veiled
>> plea for someone to perhaps do so if they have the hardware and a few
>> spare cycles.)
>
> Could it be memory-related ? Like, RAM crashes because of refresh speed or
> something?
>
> Cheers
>>
>> Thanks for any information.
>> -Mike
>>
>> **: Here's a hang where I'd just started top while background threads were
>> writing to the uSD card. top did its first pass and then everything froze.
>> (Is the high rate of context switches and interrupts normal?)
>>
>> last pid: 389; load avg: 0.13, 0.05, 0.01; up 0+00:28:15
>> 12:40:22 27 processes: 1 running, 24 sleeping, 2 uninterruptable
>> CPU states: 0.0% user, 0.0% nice, 31.1% system, 13.6% idle, 55.3% iowait
>> Kernel: 30832 ctxsw, 16262 intr
>> Memory: 32M used, 92M free, 244K buffers, 27M cached
>> Swap:
>> This terminal can only display 16 processes
>> PID USERNAME THR PRI NICE SIZE RES SHR STATE TIME CPU COMMAND
>> 236 root 1 20 0 0K 0K 0K disk 0:00 28.43% mmcqd
>> 389 root 1 20 0 2696K 804K 648K run 0:00 3.92% top
>> 378 root 1 20 0 0K 0K 0K disk 0:00 1.96%
>> flush-179:0 1 root 1 20 0 2784K 672K 588K sleep 0:00 0.00%
>> init 119 root 1 20 0 0K 0K 0K sleep 0:00 0.00%
>> rpciod/0 371 root 1 20 0 4208K 1592K 1340K sleep 0:00 0.00%
>> sshd 369 root 1 20 0 2788K 716K 632K sleep 0:00 0.00% ash
>> 4 root 1 20 0 0K 0K 0K sleep 0:00 0.00% events/0
>> 128 root 1 20 0 0K 0K 0K sleep 0:00 0.00% nfsiod
>> 251 root 1 20 0 2784K 460K 380K sleep 0:00 0.00% klogd 249
>> root 1 20 0 2784K 464K 396K sleep 0:00 0.00% syslogd 5
>> root 1 20 0 0K 0K 0K sleep 0:00 0.00% khelper 370
>> root 1 20 0 2784K 440K 376K sleep 0:00 0.00% busybox 103
>> root 1 20 0 0K 0K 0K sleep 0:00 0.00% kmmcd 2 root
>> 1 20 0 0K 0K 0K sleep 0:00 0.00% kthreadd 3 root
>> 1 20 0 0K 0K 0K sleep 0:00 0.00% ksoftirqd/0
>>
>>
Suggest to check errata first. Maybe we need some special code sequence.
More information about the linux-arm-kernel
mailing list