OMAP baseline test results for v3.7-rc1

Jean Pihet jean.pihet at newoldbits.com
Mon Nov 5 04:26:27 EST 2012


Paul,

On Mon, Nov 5, 2012 at 4:15 AM, Paul Walmsley <paul at pwsan.com> wrote:
> Hi Jean,
>
> On Sat, 3 Nov 2012, Jean Pihet wrote:
>
>> The setup is as identical as possible to yours:
>> - U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58) from
>> http://www.pwsan.com/tmp/3530es3beagle-MLO-u-boot-20121023.tar.bz2.
>>   Please note that the MLO image does not run on my board and so I had
>> to use my known-to-work image.
>
> Interesting...
>
>> The result is that I could reproduce the issue but it happens much
>> more rarely on my side (only once vs quasi 100% on ~50 boot cycles).
>
> Hmm...
>
>> The issue is triggered by running 'hwclock --systohc'  while the
>> system is heavily loaded (running depmod etc.).
>
> OK.
>
>> More investigation on-going, so more to come!
>
> Great, keep us posted.
I ran some intensive stress tests on the I2C and ... unfortunately I
could not trigger the problem. It looks like the issue is caused by
some transient situation where the CORE and/or I2C is in a low power
state.

Here are the tests that have been performed from the user space:
- stress test the I2C IRQ handler by reading and writing the RTC, and
checking the amount of IRQs for the I2C bus. In that case the CORE
never goes in low power mode,
- stress test the CORE low power and wake-up transition by adjusting
the autosuspend delay (e.g.
/sys/devices/platform/omap_i2c.1/power/autosuspend_delay_ms) and
accessing the RTC after the CORE has gone in low power.

Those tests have been run for hours (>200000 IRQs) and the I2C timeout
issue could not be observed. The target low power mode is RET (not
tried with OFF).

The next step is to detect an error situation and have data logged
about the state at that moment. What do you think?

This brings an interesting discussion. As you indicated earlier,
withtout CPU_IDLE enabled nothing except the autosuspend delay is
preventing the power domains to go in low power mode. This could lead
to situations where latency constraints are not respected. The easy
and straight forward solution is to enable CPU_IDLE and use the PM QoS
constraints.

What do you think?

Regards,
Jean

>
> Will try to kick off those tests you requested within the next 24-48
> hours.
>
>
> - Paul



More information about the linux-arm-kernel mailing list