Paul, On Mon, Nov 5, 2012 at 4:15 AM, Paul Walmsley <paul@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html